[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 --- Comment #23 from Benoit Jacob 2011-09-30 21:22:05 PDT --- (In reply to comment #22) > Looking at Firefox's fork of jemalloc, TINY_MIN_2POW is 1, making the smallest > allocation size 2 bytes, which is broken. This sounds like something

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 --- Comment #22 from Nicholas Miell 2011-09-30 21:08:50 PDT --- Looking at Firefox's fork of jemalloc, TINY_MIN_2POW is 1, making the smallest allocation size 2 bytes, which is broken. -- Configure bugmail:

[PATCH 21/21] drm/i915: No need to wait for eDP power off delay if panel is on

On Thu, Sep 29, 2011 at 06:09:53PM -0700, Keith Packard wrote: > If the panel is powered up, there's no need to delay for the 'off' > interval when turning the panel on. > > Signed-off-by: Keith Packard I'll hold off carefully checking this one until the previous patches settle. Especially when

[PATCH 20/21] drm/i915: Restrict ILK-specific eDP power hack to ILK

On Thu, Sep 29, 2011 at 06:09:52PM -0700, Keith Packard wrote: > This eliminates a fairly long delay when power sequencing newer > hardware > > Signed-off-by: Keith Packard Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48

[PATCH 19/21] drm/i915: Asynchronous eDP panel power off

On Thu, Sep 29, 2011 at 06:09:51PM -0700, Keith Packard wrote: > Using the same basic plan as the VDD force delayed power off, make > turning the panel power off asynchronous. > > Signed-off-by: Keith Packard > --- > drivers/gpu/drm/i915/intel_dp.c | 71 >

[PATCH 18/21] drm/i915: Disable eDP VDD in a delayed work proc instead of synchronously

On Thu, Sep 29, 2011 at 06:09:50PM -0700, Keith Packard wrote: > There's no good reason to turn off the eDP force VDD bit synchronously > while probing devices; that just sticks a huge delay into all mode > setting paths. Instead, queue a delayed work proc to disable the VDD > force bit and then

[Bug 40423] Firefox GLX test crashes with Mesa 7.12-devel, Gallium 0.4 on AMD JUNIPER

https://bugs.freedesktop.org/show_bug.cgi?id=40423 --- Comment #21 from Nicholas Miell 2011-09-30 20:45:37 PDT --- It isn't a bug, it is a perfectly valid and entirely safe optimization. Valgrind supplies its own overrides for the string functions that don't do this optimization specifically

[PATCH 14/21] drm/i915: Correct eDP panel power sequencing delay computations

ated patch that uses all of these values as above. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri

[Intel-gfx] [PATCH 17/21] drm/i915: Create helper functions to determine eDP power state

On Thu, Sep 29, 2011 at 06:09:49PM -0700, Keith Packard wrote: > We need to check eDP VDD force and panel on in several places, so > create some simple helper functions to avoid duplicating code. > > Signed-off-by: Keith Packard Ah, here's the code that kills my "... instead of re-reading

[PATCH 16/21] drm/i915: edp_panel_on does not need to return a bool

On Thu, Sep 29, 2011 at 06:09:48PM -0700, Keith Packard wrote: > The return value was unused, so just stop doing that. > > Signed-off-by: Keith Packard Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48

[Intel-gfx] [PATCH 15/21] drm/i915: Move eDP panel fixed mode from dev_priv to intel_dp

On Thu, Sep 29, 2011 at 06:09:47PM -0700, Keith Packard wrote: > This value doesn't come directly from the VBT, and so is rather > specific to the particular DP output. > > Signed-off-by: Keith Packard Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365

[PATCH 14/21] drm/i915: Correct eDP panel power sequencing delay computations

On Thu, Sep 29, 2011 at 06:09:46PM -0700, Keith Packard wrote: > Store the panel power sequencing delays in the dp private structure, > rather than the global device structure. Who knows, maybe we'll get > more than one eDP device in the future. > > Look at both the current hardware register

[Intel-gfx] [PATCH 05/21] drm/i915: Check eDP power when doing aux channel communications

On Fri, Sep 30, 2011 at 11:01:06AM -0700, Keith Packard wrote: > Should I bother to include this patch in the series at all? It's purely > for diagnostics to make sure the panel is powered during all aux channel > transactions. I'd say yes, imo paranoia in modesetting code is justified ;-)

[PATCH 03/21] drm/i915: Remove extra 300ms delay during eDP mode setting

On Fri, Sep 30, 2011 at 07:58:21PM +0200, Daniel Vetter wrote: > On Fri, Sep 30, 2011 at 10:50:10AM -0700, Keith Packard wrote: > > On Fri, 30 Sep 2011 18:27:28 +0200, Daniel Vetter > > wrote: > > > > > Can you elaborate a bit why this is no longer needed? Jesse seems to have > > > introduced

[Intel-gfx] [PATCH 13/21] drm/i915: Place long delays after each eDP VDD operation

On Thu, Sep 29, 2011 at 06:09:45PM -0700, Keith Packard wrote: > This ensures that the panel power sequencing is complete before > attempting to communicate over the aux channel. > > Signed-off-by: Keith Packard Looks like a patch useful for fixing up this mess, but I don't quite see the point

[PATCH 03/21] drm/i915: Remove extra 300ms delay during eDP mode setting

On Fri, Sep 30, 2011 at 10:50:10AM -0700, Keith Packard wrote: > On Fri, 30 Sep 2011 18:27:28 +0200, Daniel Vetter wrote: > > > Can you elaborate a bit why this is no longer needed? Jesse seems to have > > introduced this spefically for edp panels in d209848d61794968. If this > > becomes

[PATCH 02/21] drm/i915: Shut down PCH interrupts during irq_uninstall

On Fri, Sep 30, 2011 at 10:44:22AM -0700, Keith Packard wrote: > On Fri, 30 Sep 2011 18:20:48 +0200, Daniel Vetter wrote: > > > Shouldn't we mask/ack south DE irqs before before we mask DE irqs to avoid > > races, i.e. move this new code up? > > I don't know. What about the GT interrupts? I

[PATCH 12/21] drm/i915: Ensure eDP powered up during DP_SET_POWER operation in dp_prepare

On Thu, Sep 29, 2011 at 06:09:44PM -0700, Keith Packard wrote: > Any call to intel_dp_sink_dpms must ensure that the panel has power so > that the DP_SET_POWER operation will be correctly received. The only > one missing this was in intel_dp_prepare. > > Signed-off-by: Keith Packard If I

[PATCH 10/21] drm/i915: Wrap DP EDID fetch functions to enable eDP panel power

On Thu, Sep 29, 2011 at 06:09:42PM -0700, Keith Packard wrote: > Talking to the eDP DDC channel requires that the panel be powered > up. Wrap both the EDID and modes fetch code with calls to turn the vdd > power on and back off. > > Signed-off-by: Keith Packard Reviewed-by: Daniel Vetter --

[PATCH 11/21] drm/i915: Enable eDP panel power during I2C initialization sequence

On Thu, Sep 29, 2011 at 06:09:43PM -0700, Keith Packard wrote: > The DP i2c initialization code does a couple of i2c transactions, > which means that an eDP panel must be powered up. > > Signed-off-by: Keith Packard Ah, here's the code I've been looking for when reviewing patch 9. Reviewed-by:

[Intel-gfx] [PATCH 09/21] drm/i915: Delay DP i2c initialization until panel power timings are computed

On Thu, Sep 29, 2011 at 06:09:41PM -0700, Keith Packard wrote: > On eDP, DDC requires panel power, but turning that on uses the panel > power sequencing timing values fetch from the DPCD data. > > Signed-off-by: Keith Packard Can't really check more than what the patch does what it claims to do,

[Intel-gfx] [PATCH 05/21] drm/i915: Check eDP power when doing aux channel communications

On Fri, 30 Sep 2011 11:01:06 -0700, Keith Packard wrote: Non-text part: multipart/signed > On Fri, 30 Sep 2011 19:02:42 +0200, Daniel Vetter wrote: > > > Use pp_control instead of re-reading? > > Could, but you'll note a later patch eliminates both pp_status and > pp_control local variables,

[Intel-gfx] [PATCH 08/21] drm/i915: Turn force VDD back off when panel running in intel_dp_dpms

On Thu, Sep 29, 2011 at 06:09:40PM -0700, Keith Packard wrote: > The VDD force bit is turned on before touching the panel, but if it > was enabled, there was no call to turn it back off. Add a call. > > Signed-off-by: Keith Packard Nice catch of in inbalanced on/off. Reviewed-by: Daniel Vetter

[Intel-gfx] [PATCH 07/21] drm/i915: Check for eDP inside intel_edp_panel_vdd_on/off

On Thu, Sep 29, 2011 at 06:09:39PM -0700, Keith Packard wrote: > Cleans up code dealing with eDP VDD a bit. Remove redundant checks in > callers > > Signed-off-by: Keith Packard > --- > drivers/gpu/drm/i915/intel_dp.c | 20 ++-- > 1 files changed, 10 insertions(+), 10

[Intel-gfx] [PATCH 06/21] drm/i915: Unlock PCH_PP_CONTROL always

On Thu, Sep 29, 2011 at 06:09:38PM -0700, Keith Packard wrote: > Avoid any question about locked registers by just writing the unlock > pattern with every write to the register. > > Signed-off-by: Keith Packard grep shows that we also write to PCH_PP_CONTROL in intel_lvds.c in the dpms

[Intel-gfx] [PATCH 05/21] drm/i915: Check eDP power when doing aux channel communications

On Thu, Sep 29, 2011 at 06:09:37PM -0700, Keith Packard wrote: > Verify that the eDP VDD is on, either with the panel being on or with > the VDD force-on bit being set. > > This demonstrates that in many instances, VDD is not on when needed, > which leads to failed EDID communications. > >

[Bug 41375] VDPAU not working on RS880

https://bugs.freedesktop.org/show_bug.cgi?id=41375 --- Comment #4 from Michael Lothian 2011-09-30 18:49:01 PDT --- I start smplayer with LD_LIBRARY_PATH=/usr/lib/vdpau VDPAU_DRIVER=r600 smplayer If there is anything else I can provide to help debug this please let me know the sample mpeg

[Bug 41375] VDPAU not working on RS880

https://bugs.freedesktop.org/show_bug.cgi?id=41375 --- Comment #3 from Michael Lothian 2011-09-30 18:43:54 PDT --- Created an attachment (id=51831) --> (https://bugs.freedesktop.org/attachment.cgi?id=51831) Screen shot of garbled picture -- Configure bugmail:

An inquiry about DRM Driver for Samsung SoC Exynos4.

--- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/5b6dca18/attachment.htm>

[Bug 41375] VDPAU not working on RS880

https://bugs.freedesktop.org/show_bug.cgi?id=41375 --- Comment #2 from Michael Lothian 2011-09-30 18:41:17 PDT --- Created an attachment (id=51829) --> (https://bugs.freedesktop.org/attachment.cgi?id=51829) mplayer2 log -- Configure bugmail:

[Bug 41375] VDPAU not working on RS880

https://bugs.freedesktop.org/show_bug.cgi?id=41375 --- Comment #1 from Michael Lothian 2011-09-30 18:40:52 PDT --- Created an attachment (id=51828) --> (https://bugs.freedesktop.org/attachment.cgi?id=51828) Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email

[Bug 41375] New: VDPAU not working on RS880

https://bugs.freedesktop.org/show_bug.cgi?id=41375 Summary: VDPAU not working on RS880 Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium

No subject

pplied to mainline. Thanks, Inki Dae. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/946a407d/attachment.html>

[PATCH 04/21] drm/i915: Only use VBT panel mode on eDP if no EDID is found

On Thu, Sep 29, 2011 at 06:09:36PM -0700, Keith Packard wrote: > We're going to assume that EDID is more reliable than the VBT tables > for eDP panels, which is notably true on MacBook machines where the > VBT contains completely bogus data. > > Signed-off-by: Keith Packard Ok, this is way over

[PATCH 03/21] drm/i915: Remove extra 300ms delay during eDP mode setting

On Thu, Sep 29, 2011 at 06:09:35PM -0700, Keith Packard wrote: > There's no reason to enforce a 300ms delay during eDP mode setting. > > Signed-off-by: Keith Packard Can you elaborate a bit why this is no longer needed? Jesse seems to have introduced this spefically for edp panels in

[PATCH 02/21] drm/i915: Shut down PCH interrupts during irq_uninstall

On Thu, Sep 29, 2011 at 06:09:34PM -0700, Keith Packard wrote: > This masks out all interrupts and ack's any pending ones at IRQ > uninstall time to make sure we don't receive any unexpected interrupts > later on. > > Signed-off-by: Keith Packard > --- > drivers/gpu/drm/i915/i915_irq.c |4

[Intel-gfx] [PATCH 01/21] drm/i915: Enable digital port hotplug on PCH systems

On Thu, Sep 29, 2011 at 06:09:33PM -0700, Keith Packard wrote: > We were relying on the BIOS to set these bits, which doesn't always > happen. > > Signed-off-by: Keith Packard Ok, I'll try to increase our review-bandwidth for modesetting stuff by jumping into this maze myself. For the moment

[Bug 41373] memory leak when drmModeRes is freed.

https://bugs.freedesktop.org/show_bug.cgi?id=41373 --- Comment #1 from Boram Park 2011-09-30 17:32:09 PDT --- Created an attachment (id=51824) View: https://bugs.freedesktop.org/attachment.cgi?id=51824 Review: https://bugs.freedesktop.org/review?bug=41373=51824 another patch for memory leak

[PATCH 3/3] drm/radeon: Set cursor x/y to 0 when x/yorigin > 0.

From: Michel D?nzer Apart from the obvious cleanup, this should make the line cursor_end = x - xorigin + w; correct now. Signed-off-by: Michel D?nzer --- drivers/gpu/drm/radeon/radeon_cursor.c | 20 ++-- 1 files changed, 10

[PATCH 2/3] drm/radeon: Update AVIVO cursor coordinate origin before x/yorigin calculation.

From: Michel D?nzer Fixes cursor disappearing prematurely when moving off a top/left edge which is not located at the desktop top/left edge. Signed-off-by: Michel D?nzer Cc: stable at kernel.org --- drivers/gpu/drm/radeon/radeon_cursor.c | 12 +++- 1 files

[PATCH 1/3] drm/radeon: Simplify cursor x/yorigin calculation.

From: Michel D?nzer Signed-off-by: Michel D?nzer --- drivers/gpu/drm/radeon/radeon_cursor.c |8 ++-- 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c b/drivers/gpu/drm/radeon/radeon_cursor.c index

[PATCH 0/3] radeon cursor patches

While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image off-by-one error', I noticed at least one other bug (fixed by patch 2, and one potential bug fixed by patch 3) and opportunities for cleanup. Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch

[PATCH 0/3] radeon cursor patches

On 09/30/2011 08:16 AM, Michel D?nzer wrote: > While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image > off-by-one error', I noticed at least one other bug (fixed by patch 2, and one > potential bug fixed by patch 3) and opportunities for cleanup. > > Patch 1 is based on

[Intel-gfx] [PATCH 06/21] drm/i915: Unlock PCH_PP_CONTROL always

e Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/0630fac5/attachment.pgp>

[Bug 30402] xorg server fails to start when using xorg state tracker

https://bugs.freedesktop.org/show_bug.cgi?id=30402 --- Comment #18 from Martin Stolpe 2011-09-30 16:07:30 PDT --- Hello, I've found the problem why it didn't work. I didn't know that the entry funtion (or whatever it is called) has to have the same name as the driver. After creating a

[Bug 41373] New: memory leak when drmModeRes is freed.

https://bugs.freedesktop.org/show_bug.cgi?id=41373 Summary: memory leak when drmModeRes is freed. Product: DRI Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: medium

[Bug 30402] xorg server fails to start when using xorg state tracker

https://bugs.freedesktop.org/show_bug.cgi?id=30402 --- Comment #17 from Martin Stolpe 2011-09-30 16:01:36 PDT --- Created an attachment (id=51821) --> (https://bugs.freedesktop.org/attachment.cgi?id=51821) Xorg log file for r600 card when 2d acceleration is disabled -- Configure bugmail:

[Bug 30402] xorg server fails to start when using xorg state tracker

https://bugs.freedesktop.org/show_bug.cgi?id=30402 Martin Stolpe changed: What|Removed |Added Attachment #51820|application/octet-stream|text/plain mime type|

[Bug 30402] xorg server fails to start when using xorg state tracker

https://bugs.freedesktop.org/show_bug.cgi?id=30402 --- Comment #16 from Martin Stolpe 2011-09-30 16:00:31 PDT --- Created an attachment (id=51820) --> (https://bugs.freedesktop.org/attachment.cgi?id=51820) Xorg log file for r300 card when 2d acceleration is enabled -- Configure bugmail:

[Bug 30402] xorg server fails to start when using xorg state tracker

https://bugs.freedesktop.org/show_bug.cgi?id=30402 --- Comment #15 from Martin Stolpe 2011-09-30 16:00:06 PDT --- Created an attachment (id=51819) --> (https://bugs.freedesktop.org/attachment.cgi?id=51819) Xorg log file for r300 card when 2d acceleration is disabled -- Configure bugmail:

[Bug 30402] xorg server fails to start when using xorg state tracker

https://bugs.freedesktop.org/show_bug.cgi?id=30402 --- Comment #14 from Martin Stolpe 2011-09-30 15:59:24 PDT --- Created an attachment (id=51818) --> (https://bugs.freedesktop.org/attachment.cgi?id=51818) Xorg configuration for r300 card -- Configure bugmail:

[Bug 30402] xorg server fails to start when using xorg state tracker

https://bugs.freedesktop.org/show_bug.cgi?id=30402 --- Comment #13 from Martin Stolpe 2011-09-30 15:58:30 PDT --- Created an attachment (id=51817) --> (https://bugs.freedesktop.org/attachment.cgi?id=51817) Configuration for r600 card -- Configure bugmail:

[Bug 30402] xorg server fails to start when using xorg state tracker

https://bugs.freedesktop.org/show_bug.cgi?id=30402 --- Comment #12 from Martin Stolpe 2011-09-30 15:57:48 PDT --- Created an attachment (id=51816) --> (https://bugs.freedesktop.org/attachment.cgi?id=51816) Screenshot of Firefox when 2d acceleration is enabled -- Configure bugmail:

[Bug 30402] xorg server fails to start when using xorg state tracker

https://bugs.freedesktop.org/show_bug.cgi?id=30402 --- Comment #11 from Martin Stolpe 2011-09-30 15:57:21 PDT --- Created an attachment (id=51815) --> (https://bugs.freedesktop.org/attachment.cgi?id=51815) Screenshot of Firefox when 2d acceleration is disabled -- Configure bugmail:

[PATCH] drm/radeon/kms: fix cursor image off-by-one error

On Don, 2011-09-29 at 19:07 -0700, Nicholas Miell wrote: > The mouse cursor hotspot calculation when the cursor is partially off the > top or left side of the screen was off by one. > > Fixes https://bugs.freedesktop.org/show_bug.cgi?id=41158 > > Signed-off-by: Nicholas Miell > --- >

[Bug 41248] Monitor goes black when starting TV

https://bugs.freedesktop.org/show_bug.cgi?id=41248 --- Comment #5 from Gustav N?slund 2011-09-30 14:45:03 PDT --- Success! it works as it should -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee

[Bug 39897] Graphical glitches in some games on Evergreen

https://bugs.freedesktop.org/show_bug.cgi?id=39897 --- Comment #22 from chrisdhaag at googlemail.com 2011-09-30 14:41:56 PDT --- (In reply to comment #20) > (In reply to comment #18) > > Does: > > > > Option "ColorTiling" "false" > > > > in the device section of your xorg.conf help? If so, you

[PATCH 19/21] drm/i915: Asynchronous eDP panel power off

next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/e51a4a29/attachment.pgp>

[PATCH 18/21] drm/i915: Disable eDP VDD in a delayed work proc instead of synchronously

me: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/0d46736e/attachment.pgp>

[Bug 41248] Monitor goes black when starting TV

https://bugs.freedesktop.org/show_bug.cgi?id=41248 Leann Ogasawara changed: What|Removed |Added CC||leann.ogasawara at canonical.c

Radeon regression fix

On 30/09/11 12:59, Alex Deucher wrote: > On Thu, Sep 29, 2011 at 8:23 PM, Brad Campbell >> Looking at it with a nights sleep, it's obvious the code path in >> aux_native_write is ok. Is this a bit cleaner than the last patch? > > Looks pretty good. I was thinking of something more like this

[PATCH 14/21] drm/i915: Correct eDP panel power sequencing delay computations

-- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/37da8c13/attachment.pgp>

[Intel-gfx] [PATCH 13/21] drm/i915: Place long delays after each eDP VDD operation

L: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/05aa4fc0/attachment.pgp>

[PATCH 18/21] drm/i915: Disable eDP VDD in a delayed work proc instead of synchronously

On Thu, 29 Sep 2011 18:09:50 -0700, Keith Packard wrote: > +static void ironlake_panel_vdd_work(struct work_struct *__work) > +{ > + struct intel_dp *intel_dp = container_of(to_delayed_work(__work), > + struct intel_dp, > panel_vdd_work); > +

[PATCH 12/21] drm/i915: Ensure eDP powered up during DP_SET_POWER operation in dp_prepare

turned on. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/8cfb7f19/attachment.pgp>

[PATCH 03/21] drm/i915: Remove extra 300ms delay during eDP mode setting

hment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/80b0c3eb/attachment.pgp>

[PATCH 00/24] MacBook Air patch sequence (v2)

el.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/93eb7e48/attachment.pgp>

[PATCH 00/24] MacBook Air patch sequence (v2)

rt -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/317e3161/attachment.pgp>

[PATCH 18/21] drm/i915: Disable eDP VDD in a delayed work proc instead of synchronously

e Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/a850ad8e/attachment.pgp>

[Intel-gfx] [PATCH 07/21] drm/i915: Check for eDP inside intel_edp_panel_vdd_on/off

el.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/1cee2aa9/attachment-0001.pgp>

[Intel-gfx] [PATCH 06/21] drm/i915: Unlock PCH_PP_CONTROL always

crazy these days. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930

[Intel-gfx] [PATCH 05/21] drm/i915: Check eDP power when doing aux channel communications

L: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/7730cc2c/attachment.pgp>

[PATCH 04/21] drm/i915: Only use VBT panel mode on eDP if no EDID is found

ackard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/76152b52/attachment.pgp>

[Bug 41367] New: [r300g, bisected] WebGL test runner regression

https://bugs.freedesktop.org/show_bug.cgi?id=41367 Summary: [r300g, bisected] WebGL test runner regression Product: Mesa Version: git Platform: Other URL: https://cvs.khronos.org/svn/repos/registry/trunk/publi

[PATCH 03/21] drm/i915: Remove extra 300ms delay during eDP mode setting

the display is stable. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20

[PATCH 02/21] drm/i915: Shut down PCH interrupts during irq_uninstall

t harm... -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/8f9c8539/attachment.pgp>

[PATCH] [rfc] drm: add some caps for userspace to discover more info for dumb KMS driver

On Fri, Sep 30, 2011 at 10:12 AM, Alan Cox wrote: >> I don't think that matters for this driver, its totally not for >> acceleration, write a real driver if you have some case where copying >> algorithms are going to matter. > > > It will matter if you want a generic dumb server that can handle

[Bug 41366] [r600 KMS] HDMI on a Fusion board only comes up when LVDS is already enabled

https://bugs.freedesktop.org/show_bug.cgi?id=41366 Simon Farnsworth changed: What|Removed |Added Summary|HDMI on a Fusion board only |[r600 KMS] HDMI on a Fusion

[Bug 41366] HDMI on a Fusion board only comes up when LVDS is already enabled

https://bugs.freedesktop.org/show_bug.cgi?id=41366 --- Comment #2 from Simon Farnsworth 2011-09-30 10:13:24 PDT --- Created an attachment (id=51805) --> (https://bugs.freedesktop.org/attachment.cgi?id=51805) dmesg showing the modeset that results in HDMI working -- Configure bugmail:

[Bug 41366] HDMI on a Fusion board only comes up when LVDS is already enabled

https://bugs.freedesktop.org/show_bug.cgi?id=41366 --- Comment #1 from Simon Farnsworth 2011-09-30 10:13:00 PDT --- Created an attachment (id=51804) --> (https://bugs.freedesktop.org/attachment.cgi?id=51804) dmesg showing the modeset that results in HDMI being off unexpectedly -- Configure

[Bug 41366] New: HDMI on a Fusion board only comes up when LVDS is already enabled

https://bugs.freedesktop.org/show_bug.cgi?id=41366 Summary: HDMI on a Fusion board only comes up when LVDS is already enabled Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW

[PATCH] [rfc] drm: add some caps for userspace to discover more info for dumb KMS driver

> I don't think that matters for this driver, its totally not for > acceleration, write a real driver if you have some case where copying > algorithms are going to matter. It will matter if you want a generic dumb server that can handle stuff like PCI cards as well, but in fact it may well be

[PATCH] TTM DMA pool v1.8

On Fri, Sep 30, 2011 at 08:59:52AM +0200, Thomas Hellstrom wrote: > Konrad, > > I'm really sorry for taking so long to review this. That is OK. We all are busy - and it gave me some time to pretty up the code even more. > > I'd like to go through a couple of high-level things first before >

[Bug 30402] xorg server fails to start when using xorg state tracker

https://bugs.freedesktop.org/show_bug.cgi?id=30402 Michel D?nzer changed: What|Removed |Added Attachment #51780|application/octet-stream|text/plain mime type|

[Bug 30402] xorg server fails to start when using xorg state tracker

https://bugs.freedesktop.org/show_bug.cgi?id=30402 Michel D?nzer changed: What|Removed |Added Attachment #51779|text/x-log |text/plain mime type|

[PATCH 00/24] MacBook Air patch sequence (v2)

On Thu, Sep 29, 2011 at 08:33:56PM -0700, Greg KH wrote: > I'm all for enabling new hardware like this, and overall, the patches > aren't that bad, just want to verify this. > > And, I do have to tell you, "curses, now I have no excuse to not buy > that laptop!" What kind of battery life do you

[PATCH] TTM DMA pool v1.8

Konrad, I'm really sorry for taking so long to review this. I'd like to go through a couple of high-level things first before reviewing the coding itself. The page_alloc_func structure looks nice, but I'd like to have it per ttm backend, we would just need to make sure that the backend is

[PATCH 4/9] swiotlb: Expose swiotlb_nr_tlb function to modules

On Thu, 29 Sep 2011 16:33:47 -0400 Konrad Rzeszutek Wilk wrote: > As a mechanism to detect whether SWIOTLB is enabled or not. > We also fix the spelling - it was swioltb instead of > swiotlb. > > CC: FUJITA Tomonori > [v1: Ripped out swiotlb_enabled] > Signed-off-by: Konrad Rzeszutek Wilk >

Radeon regression fix

On 29/09/11 23:21, Brad Campbell wrote: > On 29/09/11 22:36, Alex Deucher wrote: >> On Thu, Sep 29, 2011 at 10:21 AM, Brad Campbell >> wrote: >>> This patch fixes a regression introduced between 2.6.39& 3.1-rc1 whereby >>> the displayport AUX channel stopped re-trying commands that elicited >>> a

[PATCH 00/24] MacBook Air patch sequence (v2)

On Fri, Sep 30, 2011 at 01:58:29AM -0700, Keith Packard wrote: > On Thu, 29 Sep 2011 20:33:56 -0700, Greg KH wrote: > > > Are these really all -stable material? > > I think just the sequence that actually makes the machine work; the > scarier patches are those which reduce the mode setting time

[PATCH 00/24] MacBook Air patch sequence (v2)

--- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110930/0da935b4/attachment-0001.pgp>

Radeon regression fix

On Fri, Sep 30, 2011 at 1:14 AM, Brad Campbell wrote: > On 30/09/11 12:59, Alex Deucher wrote: >> >> On Thu, Sep 29, 2011 at 8:23 PM, Brad Campbell > >>> Looking at it with a nights sleep, it's obvious the code path in >>> aux_native_write is ok. Is this a bit cleaner than the last patch? >> >>

Radeon regression fix

On Thu, Sep 29, 2011 at 8:23 PM, Brad Campbell wrote: > On 29/09/11 23:21, Brad Campbell wrote: >> >> On 29/09/11 22:36, Alex Deucher wrote: >>> >>> On Thu, Sep 29, 2011 at 10:21 AM, Brad Campbell >>> wrote: This patch fixes a regression introduced between 2.6.39& 3.1-rc1 whereby

No subject

Power_Down_delay value, which is actually documented to be the 'T3 time sequence' value used 'during power up'. There aren't separate T1 and T2 values, but there is a combined T1+T2 value in the PP_ON_DELAYS register, so I use that instead. VBT doesn't provide any values for T1 or T2, so we'll

Radeon regression fix

On 29/09/11 22:36, Alex Deucher wrote: > On Thu, Sep 29, 2011 at 10:21 AM, Brad Campbell > wrote: >> This patch fixes a regression introduced between 2.6.39& 3.1-rc1 whereby >> the displayport AUX channel stopped re-trying commands that elicited a DEFER >> response. >> > > It should still be

Radeon regression fix

On 29/09/11 22:36, Alex Deucher wrote: > On Thu, Sep 29, 2011 at 10:21 AM, Brad Campbell > wrote: >> This patch fixes a regression introduced between 2.6.39& 3.1-rc1 whereby >> the displayport AUX channel stopped re-trying commands that elicited a DEFER >> response. >> > It should still be

Re: [PATCH] TTM DMA pool v1.8

Konrad, I'm really sorry for taking so long to review this. I'd like to go through a couple of high-level things first before reviewing the coding itself. The page_alloc_func structure looks nice, but I'd like to have it per ttm backend, we would just need to make sure that the backend is

Re: [PATCH 00/24] MacBook Air patch sequence (v2)

On Thu, 29 Sep 2011 20:33:56 -0700, Greg KH g...@kroah.com wrote: Are these really all -stable material? I think just the sequence that actually makes the machine work; the scarier patches are those which reduce the mode setting time from 5-10s down to .7s. Is this stretching the bounds of

Re: [PATCH] [rfc] drm: add some caps for userspace to discover more info for dumb KMS driver

I don't think that matters for this driver, its totally not for acceleration, write a real driver if you have some case where copying algorithms are going to matter. It will matter if you want a generic dumb server that can handle stuff like PCI cards as well, but in fact it may well be best

Re: [PATCH] [rfc] drm: add some caps for userspace to discover more info for dumb KMS driver

On Fri, Sep 30, 2011 at 10:12 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: I don't think that matters for this driver, its totally not for acceleration, write a real driver if you have some case where copying algorithms are going to matter. It will matter if you want a generic dumb server

  1   2   >