Re: [PATCH] linux-firmware: update firmware for mhdp8546

Applied and pushed out. josh On Fri, May 7, 2021 at 2:00 AM Parshuram Thombare wrote: > > This patch updates mhdp8546 firmware to 2.1.0 > Fix memory leak in HDCP state machine. > > Signed-off-by: Parshuram Thombare > --- > WHENCE |2 +- > cadence/mhdp8546.bin | Bin 131072

Re: Update firmware for Qualcomm SM8250 platform

Pulled and pushed out. josh On Thu, Apr 1, 2021 at 4:11 PM Dmitry Baryshkov wrote: > > Hello linux-firmware maintainers, > > Could you please pull updated firmware for Qualcomm SM8250-based > platforms. Firmware successfully tested on Qualcomm Robotics RB5 platform. > > > The following changes

Re: linux-firmware for Qualcomm SM8250 platforms

Pulled and pushed out. josh On Fri, Jan 22, 2021 at 5:12 PM Dmitry Baryshkov wrote: > > Hello linux-firmware maintainers, > > We'd like to submit firmware for Qualcomm SM8250-based platforms. > Firmware successfully tested on Qualcomm Robotics RB5 platform. > > The following changes since

Re: linux-firmware: add firmware for Lontium lt9611uxc DSI to HDMI bridge

Pulled and pushed out. josh On Thu, Dec 10, 2020 at 7:46 PM Dmitry Baryshkov wrote: > > Hello linux-firmware maintainers, > > The following changes since commit 7455a36066741a6e52fba65e04f6451b4cdfd9c4: > > Merge branch 'guc_v49' of git://anongit.freedesktop.org/drm/drm-firmware > into main

Re: [PATCH] linux-firmware: Update firmware for Cadence MHDP8546 DP bridge

Applied and pushed out. josh On Wed, Sep 23, 2020 at 11:14 AM Swapnil Jakhade wrote: > > Update firmware for Cadence MHDP8546 DP bridge to version 2.0.0. > The firmware source code now complies with MISRA2012 and HIS > rules and directives. Also, there are some improvements in AUX > channel

Re: [PATCH v2] linux-firmware: update firmware for mhdp8546

On Mon, Jun 3, 2019 at 7:06 AM Damian Kos wrote: > > This patch updates mhdp8546 firmware from v1.2.12 to v1.2.15. > > Added support for performing arbitrary I2C-over-AUX transactions. > Corrected handling of erroneous requests for reading/writing 0 bytes over > DPCD. > Add mailbox message to

Re: [PATCH] linux-firmware: update firmware for mhdp8546

On Wed, Jan 30, 2019 at 8:24 AM Damian Kos wrote: > > Updated firmware for Cadence MHDP8546 DP bridge. > > Release version: 1.2.15 You're missing a Signed-off-by and can you please update the WHENCE file as well? josh > --- > cadence/mhdp8546.bin | Bin 131072 -> 131072 bytes > 1 file

Re: [PATCH 1/1] linux-firmware: add firmware for mhdp8546

On Mon, Aug 20, 2018 at 8:50 AM Damian Kos wrote: > > Add binary firmware for Cadence MHDP8546 DP bridge. > > Release version: 1.2.12 > > Signed-off-by: Damian Kos > --- > LICENCE.cadence | 63 +++ > WHENCE | 9 +++ >

Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

On Tue, Nov 21, 2017 at 10:07 AM, wrote: > On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote: >> - Document the autoselect process >>Information about about What, Why, and [ideally] How - analogous to >>the normal stable nominations. >>Insert reference to

[Intel-gfx] [PATCH] drm/vblank: WARN_ON nested use of drm_vblank_on/off

On Mon, Jun 22, 2015 at 9:27 AM, Jani Nikula wrote: > On Mon, 22 Jun 2015, Josh Boyer wrote: >> On Mon, Jun 22, 2015 at 8:02 AM, Daniel Vetter >> wrote: >>> We should never nest these since in theory kms drivers should know >>> when a pipe is on/off and call

[Intel-gfx] [PATCH] drm/vblank: WARN_ON nested use of drm_vblank_on/off

On Mon, Jun 22, 2015 at 8:02 AM, Daniel Vetter wrote: > We should never nest these since in theory kms drivers should know > when a pipe is on/off and call the corresponding enable/disable > functions for the vblank helper code only once. But for historical > reasons (the shared-with-ums version

[PATCH 00/11] Miscellaneous stability patches

On Wed, May 27, 2015 at 8:47 AM, Josh Boyer wrote: > On Wed, May 27, 2015 at 6:03 AM, Frediano Ziglio > wrote: >> This set of patches mainly contains fix for some memory issues >> using quite aggressively surfaces and other minor problems like >> images g

[PATCH 00/11] Miscellaneous stability patches

On Wed, May 27, 2015 at 6:03 AM, Frediano Ziglio wrote: > This set of patches mainly contains fix for some memory issues > using quite aggressively surfaces and other minor problems like > images going black after a while. > > Frediano Ziglio (11): > Do not cause spice-server to clean our

qxl deadlock splat

Hi Dave, Below is a qxl lockdep spew that I got with Linus' tree a few days ago. I actually suspect this is present in older kernels too as the DRM merge hasn't landed yet. If you have any ideas, I'd appreciate it. I tried to look at the locking a bit, but I'm not familiar with the ww ticket

[Intel-gfx] [git pull] drm fixes

On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote: >>> >> Yeah that fail looks like we're freeing an fb that's still in use. >>> >> Hilarity happens and since that happens under console_lock at boot-up >>> >> your >>> >> ma

[Intel-gfx] [git pull] drm fixes

On Wed, Mar 25, 2015 at 1:17 PM, Daniel Vetter wrote: > On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote: >> On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer >> wrote: >> > On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter wrote: >> >> On Wed, Mar 25,

[Intel-gfx] [git pull] drm fixes

On Wed, Mar 25, 2015 at 11:53 AM, Josh Boyer wrote: > On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter wrote: >> On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote: >>> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter wrote: >>> > On Wed, Mar 25, 2015 a

[Intel-gfx] [git pull] drm fixes

On Wed, Mar 25, 2015 at 11:50 AM, Daniel Vetter wrote: > On Wed, Mar 25, 2015 at 11:37:35AM -0400, Josh Boyer wrote: >> On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter wrote: >> > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote: >> >> On Wed, Mar 25,

[Intel-gfx] [git pull] drm fixes

On Wed, Mar 25, 2015 at 10:00 AM, Daniel Vetter wrote: > On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote: >> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter wrote: >> >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52 >> >> >> Author: Dam

[Intel-gfx] [git pull] drm fixes

On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter wrote: >> >> commit f55548b5af87ebfc586ca75748947f1c1b1a4a52 >> >> Author: Damien Lespiau >> >> Date: Thu Feb 5 18:30:20 2015 + >> >> >> >> drm/i915: Don't try to reference the fb in get_initial_plane_config() >> >> >> >> From linux-next?

[Intel-gfx] [git pull] drm fixes

On Tue, Mar 24, 2015 at 12:49 PM, Daniel Vetter wrote: > On Tue, Mar 24, 2015 at 05:48:31PM +0100, Daniel Vetter wrote: >> On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote: >> > On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer > > fedoraproject.org> wrote: >&g

[Intel-gfx] [git pull] drm fixes

On Tue, Mar 24, 2015 at 10:46 AM, Josh Boyer wrote: > On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter wrote: >> On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote: >>> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer >>> wrote: >>> > On Tue, Mar 24

[Intel-gfx] [git pull] drm fixes

On Tue, Mar 24, 2015 at 10:34 AM, Daniel Vetter wrote: > On Tue, Mar 24, 2015 at 10:22:30AM -0400, Josh Boyer wrote: >> On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer >> wrote: >> > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter wrote: >> >> On Tue, Mar 24,

[Intel-gfx] [git pull] drm fixes

On Tue, Mar 24, 2015 at 9:57 AM, Josh Boyer wrote: > On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter wrote: >> On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote: >>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter wrote: >>> > On Mon, Mar 23, 2015 at 02:3

[Intel-gfx] [git pull] drm fixes

On Tue, Mar 24, 2015 at 9:40 AM, Daniel Vetter wrote: > On Tue, Mar 24, 2015 at 09:15:32AM -0400, Josh Boyer wrote: >> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter wrote: >> > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote: >> >> On Mon, Mar 23

[Intel-gfx] [git pull] drm fixes

On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter wrote: > On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote: >> On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer >> wrote: >> >> >> >> >> Xi Ruoyao (1): >> >> drm/i915: Ensure plan

[git pull] drm fixes

On Mon, Mar 23, 2015 at 11:33 AM, Josh Boyer wrote: >> Xi Ruoyao (1): >> drm/i915: Ensure plane->state->fb stays in sync with plane->fb Turns out to be that commit. git bisect start 'drivers/gpu/drm/i915/' # good: [b314acaccd7e0d55314d96be4a33b5f50d0b3344] Me

[git pull] drm fixes

On Fri, Mar 20, 2015 at 5:49 PM, Dave Airlie wrote: > > Hi Linus, > > a bunch of fixes across drivers, > radeon: disable two ended allocation for now, it breaks some stuff > amdkfd: misc fixes > nouveau: fix irq loop problem, add basic support for GM206 (new hw) > i915: fix some WARNs people were

[PATCH] drm/vmwgfx: Fix drm.h include

On Fri, Sep 5, 2014 at 1:19 PM, Josh Boyer wrote: > The userspace drm.h include doesn't prefix the drm directory. This can lead > to compile failures as /usr/include/drm/ isn't in the standard gcc include > paths. Fix it to be , which matches the rest of the driver drm > header fi

[PATCH] drm/vmwgfx: Fix drm.h include

On Mon, Sep 8, 2014 at 8:01 AM, Emil Velikov wrote: > Hi Josh > > On 05/09/14 18:19, Josh Boyer wrote: >> The userspace drm.h include doesn't prefix the drm directory. This can lead >> to compile failures as /usr/include/drm/ isn't in the standard gcc include >> p

[PATCH] drm/vmwgfx: Fix drm.h include

://bugzilla.redhat.com/show_bug.cgi?id=1138759 Fixes: 1d7a5cbf8f74e Reported-by: Jeffrey Bastian Signed-off-by: Josh Boyer --- include/uapi/drm/vmwgfx_drm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/drm/vmwgfx_drm.h b/include/uapi/drm/vmwgfx_drm.h index

WARN_ON in qxl_ttm.c with v3.17-rc1-22-g480cadc2b7e0

Hi Dave, With Linus' latest tree as of this morning I'm hitting the WARN_ON below on my KVM guest using the qxl driver. The guest still boots and things appear to still be working (I can log in via GDM, etc), so I'm not sure exactly what the overall issue is. Hoping you have some ideas. josh

3.13 i915 brightness settings broken when going from docked -> undocked

On Thu, Feb 20, 2014 at 07:31:41PM -0500, Josh Boyer wrote: >On Wed, Feb 19, 2014 at 9:20 PM, Josh Boyer >wrote: >> Hi All, >> >> We've had a rather weird report[1] of the brightness adjustments being >> broken in a specific case with Thinkpad x220 hardware (Sandy

3.13 i915 brightness settings broken when going from docked -> undocked

On Wed, Feb 19, 2014 at 9:20 PM, Josh Boyer wrote: > Hi All, > > We've had a rather weird report[1] of the brightness adjustments being > broken in a specific case with Thinkpad x220 hardware (SandyBridge > based). If you boot the machine with it in a dock and then undock, &

[PATCH 1/1] drm/exynos: Fix build error in exynos_hdmi.c

ag > struct hdmi_infoframe { > > Signed-off-by: Sachin Kamat > Reported-by: Josh Boyer This does fix the build error I saw. I don't have hardware to test the results with, but it now compiles correctly. Thanks for the quick turn around! josh > --- > drivers/gpu/drm/exynos/ex

kernfs oops with i915+i2c_core in 3.14 merge window

On Thu, Jan 30, 2014 at 2:20 PM, Josh Boyer wrote: > On Thu, Jan 30, 2014 at 2:05 PM, Tejun Heo wrote: >> On Thu, Jan 30, 2014 at 02:03:18PM -0500, Josh Boyer wrote: >>> Hi All, >>> >>> I'm seeing the oops below on my MacBookPro 10,2 machine using i915 >

kernfs oops with i915+i2c_core in 3.14 merge window

On Thu, Jan 30, 2014 at 2:05 PM, Tejun Heo wrote: > On Thu, Jan 30, 2014 at 02:03:18PM -0500, Josh Boyer wrote: >> Hi All, >> >> I'm seeing the oops below on my MacBookPro 10,2 machine using i915 >> graphics. It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) ,

kernfs oops with i915+i2c_core in 3.14 merge window

Hi All, I'm seeing the oops below on my MacBookPro 10,2 machine using i915 graphics. It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) , but we seem to have one report[1] of this happening well before that, in v3.13-3260-g03d11a0 as well. Does anyone have a clue what is going on here?

exynos_hdmi.c fails to build with v3.13-10094-g9b0cd30

Hi All, After the DRM merge, the exynos_hdmi.c file fails to build with our ARM config. The error is: drivers/gpu/drm/exynos/exynos_hdmi.c:382:8: error: 'hdmi_infoframe' defined as wrong kind of tag struct hdmi_infoframe { ^ make[4]: *** [drivers/gpu/drm/exynos/exynos_hdmi.o] Error 1

Radeon crash with v3.13-rc3-157-g17b2112

On Tue, Dec 10, 2013 at 5:24 PM, Josh Boyer wrote: > On Tue, Dec 10, 2013 at 5:07 PM, Deucher, Alexander > wrote: >>> -Original Message- >>> From: jwboyer at gmail.com [mailto:jwboyer at gmail.com] On Behalf Of Josh >>> Boyer >>> Sent: Tuesday,

Radeon crash with v3.13-rc3-157-g17b2112

On Tue, Dec 10, 2013 at 5:07 PM, Deucher, Alexander wrote: >> -Original Message- >> From: jwboyer at gmail.com [mailto:jwboyer at gmail.com] On Behalf Of Josh >> Boyer >> Sent: Tuesday, December 10, 2013 5:04 PM >> To: Deucher, Alexander; Guenter Roeck; D

Radeon crash with v3.13-rc3-157-g17b2112

Hi All, Booting today's rawhide kernel fails on my Dell XPS 8300 machine. I added nomodeset to the command line because it seemed to glitch out when doing the handoff to the radeon driver and that let me boot far enough to start networking. I then loaded the radeon driver with: modprobe radeon

DRM_TEGRA not buildable as a module

On Mon, Nov 18, 2013 at 4:10 AM, Thierry Reding wrote: > On Sat, Nov 16, 2013 at 03:25:09PM +0100, Josh Boyer wrote: >> Hi All, >> >> The commit below seems to have made the Tegra DRM driver a bool option >> instead of tristate: >> >> commit dee8268f8fb

DRM_TEGRA not buildable as a module

Hi All, The commit below seems to have made the Tegra DRM driver a bool option instead of tristate: commit dee8268f8fb218c9e9b604a40f7dbdd395e910f9 Author: Thierry Reding Date: Wed Oct 9 10:32:49 2013 +0200 drm/tegra: Move driver to DRM tree In order to make subsystem-wide changes

[Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert "Revert "drm/i915: revert eDP bpp clamping code changes""

On Thu, Oct 31, 2013 at 1:01 PM, Jani Nikula wrote: > On Thu, 31 Oct 2013, Josh Boyer wrote: >> On Thu, Oct 31, 2013 at 10:58 AM, Jani Nikula >> wrote: >>> On Fri, 25 Oct 2013, Joseph Salisbury >>> wrote: >>>> On 10/16/2013 05:02 PM, Daniel Ve

[Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert "Revert "drm/i915: revert eDP bpp clamping code changes""

On Thu, Oct 31, 2013 at 10:58 AM, Jani Nikula wrote: > On Fri, 25 Oct 2013, Joseph Salisbury > wrote: >> On 10/16/2013 05:02 PM, Daniel Vetter wrote: >>> It's by far not that simple. Jani is working on both the underlying bug >>> and a better w/a. See >>> >>>

Re: [PATCH v5 0/4] Fix Win8 backlight issue

On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu aaron...@intel.com wrote: v5: 1 Introduce video.use_native_backlight module parameter and set its value to false by default as suggested by Rafael. For Win8 systems which have broken ACPI video backlight control, the parameter can be set to 1 in

Re: [PATCH v5 0/4] Fix Win8 backlight issue

On Fri, Oct 11, 2013 at 6:10 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote: On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu aaron...@intel.com wrote: v5: 1 Introduce video.use_native_backlight module parameter and set its value

Re: [PATCH v5 0/4] Fix Win8 backlight issue

On Fri, Oct 11, 2013 at 4:27 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Friday, October 11, 2013 06:01:43 PM Josh Boyer wrote: On Fri, Oct 11, 2013 at 6:10 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote: On Fri, Oct 11, 2013

Re: [PATCH v5 0/4] Fix Win8 backlight issue

On Fri, Oct 11, 2013 at 11:00 PM, Yves-Alexis Perez cor...@debian.org wrote: On sam., 2013-10-12 at 00:10 +0200, Rafael J. Wysocki wrote: On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote: On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu aaron...@intel.com wrote: v5: 1 Introduce

Re: [git pull] drm for 3.10-rc1

On Fri, May 03, 2013 at 06:08:52PM +0200, Daniel Vetter wrote: On Fri, May 3, 2013 at 4:39 PM, Josh Boyer jwbo...@gmail.com wrote: On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote: The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c: mm: prevent mmap_cache

Re: [git pull] drm for 3.10-rc1

On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote: On Fri, May 3, 2013 at 10:31 PM, Josh Boyer jwbo...@gmail.com wrote: OK. Git bisect tells me this: 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit commit 57c219633275c7e7413f8bc7be250dc092887458 Author: Daniel

[git pull] drm for 3.10-rc1

On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote: >On Fri, May 3, 2013 at 10:31 PM, Josh Boyer wrote: >> OK. Git bisect tells me this: >> >> 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit >> commit 57c219633275c7e7413f8bc7be250dc0928874

[git pull] drm for 3.10-rc1

On Fri, May 03, 2013 at 12:57:20PM -0400, Josh Boyer wrote: >On Fri, May 03, 2013 at 06:08:52PM +0200, Daniel Vetter wrote: >>On Fri, May 3, 2013 at 4:39 PM, Josh Boyer wrote: >>> On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote: >>>>The

[git pull] drm for 3.10-rc1

On Fri, May 03, 2013 at 06:08:52PM +0200, Daniel Vetter wrote: >On Fri, May 3, 2013 at 4:39 PM, Josh Boyer wrote: >> On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote: >>>The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c: >>> >&

[git pull] drm for 3.10-rc1

On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote: >The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c: > > mm: prevent mmap_cache race in find_vma() (2013-04-04 11:46:28 -0700) > >are available in the git repository at: > >

[git pull] drm merge for 3.9-rc1

On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer wrote: > On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer wrote: >> On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher >> wrote: >>> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer wrote: >>>> On Thu, Feb 28, 2013 a

Re: [git pull] drm merge for 3.9-rc1

On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu

Re: [git pull] drm merge for 3.9-rc1

On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher alexdeuc...@gmail.com wrote: ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit So I

Re: [git pull] drm merge for 3.9-rc1

On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer jwbo...@gmail.com wrote: On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher alexdeuc...@gmail.com wrote

[git pull] drm merge for 3.9-rc1

On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer wrote: > On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher > wrote: >> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer wrote: >>> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher >>> wrote: >>>>>>>> ca5

[git pull] drm merge for 3.9-rc1

On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher wrote: > On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer wrote: >> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher >> wrote: >>>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit >>&g

[git pull] drm merge for 3.9-rc1

On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher wrote: > On Wed, Feb 27, 2013 at 8:14 PM, Josh Boyer wrote: >> On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer wrote: >>> On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer wrote: >>>> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boye

[git pull] drm merge for 3.9-rc1

On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer wrote: > On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer wrote: >> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer wrote: >>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie wrote: >>>> Alex Deucher (29): >>>> dr

[git pull] drm merge for 3.9-rc1

On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer wrote: > On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer wrote: >> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie wrote: >>> Alex Deucher (29): >>> drm/radeon: halt engines before disabling MC (6xx/7xx) >>>

[git pull] drm merge for 3.9-rc1

On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer wrote: > On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer wrote: >> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie wrote: >>> Alex Deucher (29): >>> drm/radeon: halt engines before disabling MC (6xx/7xx) >>>

[git pull] drm merge for 3.9-rc1

On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer wrote: > On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie wrote: >> Alex Deucher (29): >> drm/radeon: halt engines before disabling MC (6xx/7xx) >> drm/radeon: halt engines before disabling MC (evergreen) >>

[git pull] drm merge for 3.9-rc1

On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie wrote: > Alex Deucher (29): > drm/radeon: halt engines before disabling MC (6xx/7xx) > drm/radeon: halt engines before disabling MC (evergreen) > drm/radeon: halt engines before disabling MC (cayman/TN) > drm/radeon: halt

Re: [PATCH] fbcon: fix locking harder

On Thu, Jan 24, 2013 at 8:43 PM, Dave Airlie airl...@gmail.com wrote: Okay so Alan's patch handled the case where there was no registered fbcon, however the other path entered in set_con2fb_map pit. In there we called fbcon_takeover, but we also took the console lock in a couple of places.

[PATCH] fbcon: fix locking harder

On Thu, Jan 24, 2013 at 8:43 PM, Dave Airlie wrote: > Okay so Alan's patch handled the case where there was no registered fbcon, > however the other path entered in set_con2fb_map pit. > > In there we called fbcon_takeover, but we also took the console lock in a > couple > of places. So push the

Re: Hangcheck timer elapsed... GPU hung in 3.8.0-rc2

On Thu, Jan 3, 2013 at 3:46 PM, J. Bruce Fields bfie...@fieldses.org wrote: I got a crash after a few minutes of running 3.8.0-rc2, was able to switch to a vt and look at dmesg: [ 490.962545] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 490.963019] [drm]

"Hangcheck timer elapsed... GPU hung" in 3.8.0-rc2

On Thu, Jan 3, 2013 at 3:46 PM, J. Bruce Fields wrote: > I got a crash after a few minutes of running 3.8.0-rc2, was able to > switch to a vt and look at dmesg: > > [ 490.962545] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... > GPU hung > [ 490.963019] [drm] capturing error

[PATCH] drm/radeon: force dma32 to fix regression rs4xx, rs6xx, rs740

On Tue, Aug 28, 2012 at 4:50 PM, wrote: > From: Jerome Glisse > > It seems some of those IGP dislike non dma32 page despite what > documentation says. Fix regression since we allowed non dma32 > pages. It seems it only affect some revision of those IGP chips > as we don't know which one just

Re: [PATCH] drm/radeon: force dma32 to fix regression rs4xx, rs6xx, rs740

On Tue, Aug 28, 2012 at 4:50 PM, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com It seems some of those IGP dislike non dma32 page despite what documentation says. Fix regression since we allowed non dma32 pages. It seems it only affect some revision of those IGP chips as

Re: [PATCH] fbcon: fix race condition between console lock and cursor timer

On Tue, Aug 21, 2012 at 2:40 AM, Dave Airlie airl...@redhat.com wrote: So we've had a fair few reports of fbcon handover breakage between efi/vesafb and i915 surface recently, so I dedicated a couple of days to finding the problem. Essentially the last thing we saw was the conflicting

[PATCH] fbcon: fix race condition between console lock and cursor timer

On Tue, Aug 21, 2012 at 2:40 AM, Dave Airlie wrote: > So we've had a fair few reports of fbcon handover breakage between > efi/vesafb and i915 surface recently, so I dedicated a couple of > days to finding the problem. > > Essentially the last thing we saw was the conflicting framebuffer >

gma500 opregion/power init order backtrace

Hi Alan, We had a report [1] of a machine with a Cedarview chip in it not being able to have the backlight level adjusted with the hardware function keys in F17. Matthew suggested that gma500 needs to work with opregion and the reporter (CC'd) tried a rawhide kernel based on

gma500 opregion/power init order backtrace

Hi Alan, We had a report [1] of a machine with a Cedarview chip in it not being able to have the backlight level adjusted with the hardware function keys in F17. Matthew suggested that gma500 needs to work with opregion and the reporter (CC'd) tried a rawhide kernel based on