[Bug 70706] Regression in fbconfig
https://bugs.freedesktop.org/show_bug.cgi?id=70706 --- Comment #12 from David "okias" Heidelberger --- X.Org X Server 1.14.99.905 (1.15.0 RC 5) I can confirm problem with kwin. -- You are receiving this mail because: You are on the CC list for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131224/3933d69b/attachment.html>
[Bug 73014] tahiti ways slower than juniper in dota2
https://bugs.freedesktop.org/show_bug.cgi?id=73014 --- Comment #2 from Sylvain BERTRAND --- https://bugzilla.redhat.com/show_bug.cgi?id=1046361 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131224/3bcac501/attachment-0001.html>
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 --- Comment #11 from Christoph Haag --- Created attachment 119551 --> https://bugzilla.kernel.org/attachment.cgi?id=119551=edit dmesg with acpiphp.disable=1 A quick search also showed this: https://bugzilla.kernel.org/show_bug.cgi?id=67461 Good news: With acpiphp.disable=1 there are no errors with booting and using X. In a tty the gpu is in DynOff state. Not so good news: When starting X it switches to DynPwr and after several minutes I don't think it ever powered down again. But when killing X it goes back to DynOff. Still bad news: rmmod radeon. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 67571] BUG: unable to handle kernel paging in amd E350 hdmi init
https://bugzilla.kernel.org/show_bug.cgi?id=67571 --- Comment #16 from Eric Valette --- initialization problem (tablet!) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 67571] BUG: unable to handle kernel paging in amd E350 hdmi init
https://bugzilla.kernel.org/show_bug.cgi?id=67571 --- Comment #15 from Eric Valette --- Will do. Kids are watching TV... Sound like an initial is at I on problem because I saw a lot of people having the same behavior after resume. BTW Merry Christmas! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 67571] BUG: unable to handle kernel paging in amd E350 hdmi init
https://bugzilla.kernel.org/show_bug.cgi?id=67571 --- Comment #14 from Alex Deucher --- Try removing the uvd firmware. That will cause the driver to skip UVD init. Maybe UVD is causing the problem. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 67571] BUG: unable to handle kernel paging in amd E350 hdmi init
https://bugzilla.kernel.org/show_bug.cgi?id=67571 --- Comment #13 from Eric Valette --- The first hang is caused when enabling radeon framebufer that does not work -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 67571] BUG: unable to handle kernel paging in amd E350 hdmi init
https://bugzilla.kernel.org/show_bug.cgi?id=67571 --- Comment #12 from Eric Valette --- I have mesa 10.0.0.1 already and x11 7.2.0. same user space works well on similar hardware. I can wait... -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 61891] Cannot switch off Radeon 6400M with vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=61891 Alex Deucher changed: What|Removed |Added CC||rjw at sisk.pl --- Comment #12 from Alex Deucher --- See also: https://bugzilla.kernel.org/show_bug.cgi?id=65761 https://bugs.freedesktop.org/show_bug.cgi?id=70687 From: https://bugs.freedesktop.org/show_bug.cgi?id=70687 "I seem to have discovered the root of the issue. I've just built 3.13-rc5 kernel which has the dynamic powering of the discrete gpu and all hell broke loose. I've narrowed the error down to the pci hotplug driver. My machine loads shpchp pci hotplug driver from what I can see in lsmod output. But the trick is, that there is another pci hotplug driver, acpi pci hotplug one, which seems to break all hell loose here. Disabling it seems to fix everything for me, at least on kernel 3.13. # CONFIG_HOTPLUG_PCI_ACPI is not set This kernel config option is the culprit for this, and that also can be seen from my backtrace: [ 22.731998] [] ? acpiphp_check_bridge+0x72/0x88 So the trick behind this is that acpi pci hotplug driver conflicts with shpchp one that my machine uses. And since it is a builtin driver, and can't be built as module it is always loaded. The other possibility is that this machine doesn't support acpi hotplug, but does support shpc pci hotplug. We need a kernel workarround so that acpi pci hotplug is disabled and out of the way when shpc pci hotplug is enabled." Rafael, any ideas? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71887] Garbled output when rendering to a framebuffer object
https://bugs.freedesktop.org/show_bug.cgi?id=71887 Victor Luchits changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #8 from Victor Luchits --- Turns out the issue was related to how glGenRenderbuffersEXT generated id numbers for framebuffers. Apparently some kernel change affected the outcome and in combination with bug in the game code caused the reported issue. Resolving as NOTABUG. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131224/b5b0fb30/attachment.html>
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 --- Comment #10 from Alex Deucher --- See also: https://bugzilla.kernel.org/show_bug.cgi?id=61891 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 --- Comment #9 from Alex Deucher --- This looks like a pci hotplug problem, not a radeon issue. See: https://bugs.freedesktop.org/show_bug.cgi?id=70687 "I seem to have discovered the root of the issue. I've just built 3.13-rc5 kernel which has the dynamic powering of the discrete gpu and all hell broke loose. I've narrowed the error down to the pci hotplug driver. My machine loads shpchp pci hotplug driver from what I can see in lsmod output. But the trick is, that there is another pci hotplug driver, acpi pci hotplug one, which seems to break all hell loose here. Disabling it seems to fix everything for me, at least on kernel 3.13. # CONFIG_HOTPLUG_PCI_ACPI is not set This kernel config option is the culprit for this, and that also can be seen from my backtrace: [ 22.731998] [] ? acpiphp_check_bridge+0x72/0x88 So the trick behind this is that acpi pci hotplug driver conflicts with shpchp one that my machine uses. And since it is a builtin driver, and can't be built as module it is always loaded. The other possibility is that this machine doesn't support acpi hotplug, but does support shpc pci hotplug. We need a kernel workarround so that acpi pci hotplug is disabled and out of the way when shpc pci hotplug is enabled." -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 73014] tahiti ways slower than juniper in dota2
https://bugs.freedesktop.org/show_bug.cgi?id=73014 --- Comment #1 from Alex Deucher --- Make sure you apply this patch: http://lists.freedesktop.org/archives/dri-devel/2013-December/050902.html Also, the radeonsi driver is not yet as optimized as the r600g driver. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131224/0f7206a3/attachment.html>
[Bug 67571] BUG: unable to handle kernel paging in amd E350 hdmi init
https://bugzilla.kernel.org/show_bug.cgi?id=67571 --- Comment #11 from Alex Deucher --- Something is causing the GPU to hang repeatedly and the driver resets it repeatedly. I'd suggest updating your userspace acceleration drivers (xf86-video-ati, mesa). -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 70687] vgaswitcheroo issues on Linux 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=70687 --- Comment #13 from Armin K --- I seem to have discovered the root of the issue. I've just built 3.13-rc5 kernel which has the dynamic powering of the discrete gpu and all hell broke loose. I've narrowed the error down to the pci hotplug driver. My machine loads shpchp pci hotplug driver from what I can see in lsmod output. But the trick is, that there is another pci hotplug driver, acpi pci hotplug one, which seems to break all hell loose here. Disabling it seems to fix everything for me, at least on kernel 3.13. # CONFIG_HOTPLUG_PCI_ACPI is not set This kernel config option is the culprit for this, and that also can be seen from my backtrace: [ 22.731998] [] ? acpiphp_check_bridge+0x72/0x88 So the trick behind this is that acpi pci hotplug driver conflicts with shpchp one that my machine uses. And since it is a builtin driver, and can't be built as module it is always loaded. The other possibility is that this machine doesn't support acpi hotplug, but does support shpc pci hotplug. We need a kernel workarround so that acpi pci hotplug is disabled and out of the way when shpc pci hotplug is enabled. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131224/e23da975/attachment.html>
[PATCH v2 rebased] ACPI / video: Add systems that should favor native backlight interface
Hi,
add some updates to the patch ;)
On Thu, 2013-11-21 at 13:29 +0800, Aaron Lu wrote:
> On 11/21/2013 04:56 AM, Igor Gnatenko wrote:
> > Any news here? If no - I think we need re-send patch as new..
>
> Since the v2 patch can't apply cleanly on top of pm's -next tree, I
> think it's worth a re-send, so here it comes.
>
> ---
> Subject: [PATCH] ACPI / video: Add systems that should favor native backlight
> interface
> From: Aaron Lu
> Date: Thu, 21 Nov 2013 11:24:48 +0800
>
> Some system's ACPI video backlight control interface is broken and the
> native backlight control interface should be used by default. This patch
> sets the use_native_backlight parameter to true for those systems so
> that video backlight control interface will not be created. To be
> specific, the ThinkPad T430s/X230, Lenovo Yoga 13, Dell Inspiron 7520
> and Acer Aspire 5733Z are added here, if they appear in some other DMI
> table before, they are removed from there.
>
> Note that the user specified kernel cmdline option will always have the
> highest priority, i.e. if use_native_backlight=0 is specified and the
> system is in the DMI table, the video module will not skip registering
> backlight interface for it.
>
> Thinkpad T430s:
> Reported-by: Theodore Tso
> Reported-and-tested-by: Peter Weber
> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51231
> Thinkpad X230:
> Reported-and-tested-by: Igor Gnatenko
> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51231
ThinkPad X1 Carbon:
Reported-and-tested-by: Igor Gnatenko
> Lenovo Yoga 13:
> Reported-by: Lennart Poettering
> Reported-and-tested-by: Kevin Smith
> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=63811
> Dell Inspiron 7520:
> Reported-by: Rinat Ibragimov
> Acer Aspire 5733Z:
> Reported-by:
> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=62941
HP ProBook 4340s:
Reported-and-tested-by: Vladimir Sherenkov
Reference: http://redmine.russianfedora.pro/issues/1258
>
> Signed-off-by: Aaron Lu
> ---
> drivers/acpi/blacklist.c| 8 --
> drivers/acpi/video.c| 65
> +
> drivers/acpi/video_detect.c | 8 --
> 3 files changed, 60 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> index 078c4f7fe2dd..2b6a76b6d59a 100644
> --- a/drivers/acpi/blacklist.c
> +++ b/drivers/acpi/blacklist.c
> @@ -261,14 +261,6 @@ static struct dmi_system_id acpi_osi_dmi_table[]
> __initdata = {
> },
> {
> .callback = dmi_disable_osi_win8,
> - .ident = "Dell Inspiron 15R SE",
> - .matches = {
> - DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> - DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 7520"),
> - },
> - },
> - {
> - .callback = dmi_disable_osi_win8,
> .ident = "ThinkPad Edge E530",
> .matches = {
>DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index 995e91bcb97b..7dc6071a04b6 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -82,11 +82,12 @@ static bool allow_duplicates;
> module_param(allow_duplicates, bool, 0644);
>
> /*
> - * For Windows 8 systems: if set ture and the GPU driver has
> - * registered a backlight interface, skip registering ACPI video's.
> + * For Windows 8 systems: used to decide if video module
> + * should skip registering backlight interface of its own.
> */
> -static bool use_native_backlight = false;
> -module_param(use_native_backlight, bool, 0644);
> +static int use_native_backlight_param = -1;
> +module_param_named(use_native_backlight, use_native_backlight_param, int,
> 0444);
> +static bool use_native_backlight_dmi = false;
>
> static int register_count;
> static struct mutex video_list_lock;
> @@ -232,9 +233,17 @@ static int acpi_video_get_next_level(struct
> acpi_video_device *device,
> static int acpi_video_switch_brightness(struct acpi_video_device *device,
>int event);
>
> +static bool acpi_video_use_native_backlight(void)
> +{
> + if (use_native_backlight_param != -1)
> + return use_native_backlight_param;
> + else
> + return use_native_backlight_dmi;
> +}
> +
> static bool acpi_video_verify_backlight_support(void)
> {
> - if (acpi_osi_is_win8() && use_native_backlight &&
> + if (acpi_osi_is_win8() && acpi_video_use_native_backlight() &&
> backlight_device_registered(BACKLIGHT_RAW))
> return false;
> return acpi_video_backlight_support();
> @@ -399,6 +408,12 @@ static int __init video_set_bqc_offset(const struct
> dmi_system_id *d)
> return 0;
> }
>
> +static int __init video_set_use_native_backlight(const struct dmi_system_id
> *d)
> +{
> + use_native_backlight_dmi = true;
> + return 0;
> +}
> +
> static struct dmi_system_id video_dmi_table[] __initdata = {
> /*
>* Broken
[PATCH v2 rebased] ACPI / video: Add systems that should favor native backlight interface
Hi,
please add some updates ;)
On Thu, 2013-11-21 at 13:29 +0800, Aaron Lu wrote:
> On 11/21/2013 04:56 AM, Igor Gnatenko wrote:
> > Any news here? If no - I think we need re-send patch as new..
>
> Since the v2 patch can't apply cleanly on top of pm's -next tree, I
> think it's worth a re-send, so here it comes.
>
> ---
> Subject: [PATCH] ACPI / video: Add systems that should favor native backlight
> interface
> From: Aaron Lu
> Date: Thu, 21 Nov 2013 11:24:48 +0800
>
> Some system's ACPI video backlight control interface is broken and the
> native backlight control interface should be used by default. This patch
> sets the use_native_backlight parameter to true for those systems so
> that video backlight control interface will not be created. To be
> specific, the ThinkPad T430s/X230, Lenovo Yoga 13, Dell Inspiron 7520
> and Acer Aspire 5733Z are added here, if they appear in some other DMI
> table before, they are removed from there.
>
> Note that the user specified kernel cmdline option will always have the
> highest priority, i.e. if use_native_backlight=0 is specified and the
> system is in the DMI table, the video module will not skip registering
> backlight interface for it.
>
> Thinkpad T430s:
> Reported-by: Theodore Tso
> Reported-and-tested-by: Peter Weber
> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51231
> Thinkpad X230:
> Reported-and-tested-by: Igor Gnatenko
> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51231
ThinkPad X1 Carbon:
Reported-and-tested-by: Igor Gnatenko
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51231
> Lenovo Yoga 13:
> Reported-by: Lennart Poettering
> Reported-and-tested-by: Kevin Smith
> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=63811
> Dell Inspiron 7520:
> Reported-by: Rinat Ibragimov
> Acer Aspire 5733Z:
> Reported-by:
> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=62941
HP ProBook 4340s:
Reported-and-tested-by: Vladimir Sherenkov
Reference: http://redmine.russianfedora.pro/issues/1258
>
> Signed-off-by: Aaron Lu
> ---
> drivers/acpi/blacklist.c| 8 --
> drivers/acpi/video.c| 65
> +
> drivers/acpi/video_detect.c | 8 --
> 3 files changed, 60 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
> index 078c4f7fe2dd..2b6a76b6d59a 100644
> --- a/drivers/acpi/blacklist.c
> +++ b/drivers/acpi/blacklist.c
> @@ -261,14 +261,6 @@ static struct dmi_system_id acpi_osi_dmi_table[]
> __initdata = {
> },
> {
> .callback = dmi_disable_osi_win8,
> - .ident = "Dell Inspiron 15R SE",
> - .matches = {
> - DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> - DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 7520"),
> - },
> - },
> - {
> - .callback = dmi_disable_osi_win8,
> .ident = "ThinkPad Edge E530",
> .matches = {
>DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index 995e91bcb97b..7dc6071a04b6 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -82,11 +82,12 @@ static bool allow_duplicates;
> module_param(allow_duplicates, bool, 0644);
>
> /*
> - * For Windows 8 systems: if set ture and the GPU driver has
> - * registered a backlight interface, skip registering ACPI video's.
> + * For Windows 8 systems: used to decide if video module
> + * should skip registering backlight interface of its own.
> */
> -static bool use_native_backlight = false;
> -module_param(use_native_backlight, bool, 0644);
> +static int use_native_backlight_param = -1;
> +module_param_named(use_native_backlight, use_native_backlight_param, int,
> 0444);
> +static bool use_native_backlight_dmi = false;
>
> static int register_count;
> static struct mutex video_list_lock;
> @@ -232,9 +233,17 @@ static int acpi_video_get_next_level(struct
> acpi_video_device *device,
> static int acpi_video_switch_brightness(struct acpi_video_device *device,
>int event);
>
> +static bool acpi_video_use_native_backlight(void)
> +{
> + if (use_native_backlight_param != -1)
> + return use_native_backlight_param;
> + else
> + return use_native_backlight_dmi;
> +}
> +
> static bool acpi_video_verify_backlight_support(void)
> {
> - if (acpi_osi_is_win8() && use_native_backlight &&
> + if (acpi_osi_is_win8() && acpi_video_use_native_backlight() &&
> backlight_device_registered(BACKLIGHT_RAW))
> return false;
> return acpi_video_backlight_support();
> @@ -399,6 +408,12 @@ static int __init video_set_bqc_offset(const struct
> dmi_system_id *d)
> return 0;
> }
>
> +static int __init video_set_use_native_backlight(const struct dmi_system_id
> *d)
> +{
> + use_native_backlight_dmi = true;
> + return 0;
> +}
> +
> static struct dmi_system_id
[Bug 67571] BUG: unable to handle kernel paging in amd E350 hdmi init
https://bugzilla.kernel.org/show_bug.cgi?id=67571 --- Comment #10 from Eric Valette --- Created attachment 119511 --> https://bugzilla.kernel.org/attachment.cgi?id=119511=edit dmesg when trying to log via kdm -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 --- Comment #8 from Christoph Haag --- Created attachment 119501 --> https://bugzilla.kernel.org/attachment.cgi?id=119501=edit rc5 with starting X (~line 1811) and trying to render something rc5 with these patches now: http://lists.freedesktop.org/archives/dri-devel/2013-December/050902.html I'm not sure what I can do more without getting into trying to debug kernel code of which I know nothing... Not really a change with rc5, but I think when starting X the lockups go away (not really sure). When trying to render something with DRI_PRIME=1 however, it locks up a bit harder and can't recover apparently because when trying to start another opengl program, it'll just segfault. rmmod radeon still creates problems that lock up the cpus and prevent proper rebooting etc. With runpm=0 it's not really good either at the moment. For example the Distance alpha causes a lockup too and after that lockup glxgears says $ DRI_PRIME=1 glxgears -info radeon: Failed to allocate virtual address for buffer: radeon:size : 4352 bytes radeon:alignment : 4096 bytes radeon:domains : 4 radeon:va: 0x0080 radeon: Failed to allocate virtual address for buffer: radeon:size : 4352 bytes radeon:alignment : 4096 bytes radeon:domains : 4 radeon:va: 0x0080 [1]2915 segmentation fault (core dumped) I'm cramming way too much in here, but I just want to say that the HD 7970M with the 8970M are the top mobile consumer GPUs AMD currently has and it would be really cool if the developers could buy that hardware (hey, it's christmas!) and fix this mess directly. From what I have seen so far it is really close to working amazingly well. If there's something specific I could test, I'll gladly try. Thanks -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] radeon: avoid possible divide by 0 in surface manager
On Tue, Dec 10, 2013 at 7:39 PM, Michel D?nzer wrote: > On Die, 2013-12-10 at 12:42 -0500, Alex Deucher wrote: >> Some users report hitting a divide by 0 with the tile split in >> certain apps. Tile_split shouldn't ever be 0 unless the surface >> structure was not properly initialized. I think there may be some >> cases where mesa uses an improperly initialized surface struct, >> but I haven't had time to track it down. > > It would be good to know where the bogus tile split is coming from > though ? who knows what else might be wrong in that case? Agreed. The reporter updated the bug with the full backtrace, I just haven't had a chance to look at it yet. https://bugs.freedesktop.org/show_bug.cgi?id=72425 Alex > > > -- > Earthling Michel D?nzer| http://www.amd.com > Libre software enthusiast |Mesa and X developer >
[pull] radeon fixes 3.13
Hi Dave, Radeon fixes, Christmas eve edition. Fix incorrect family for 0x9649 which lead to bogus rendering, tiling and RB fixes for SI and CIK, and a UVD fix. The following changes since commit 418cb50bd6f977249b38f359e0adca6fc8ea: Merge tag 'drm-intel-fixes-2013-12-18' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-12-23 10:35:57 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.13 for you to fetch changes up to 9482d0d37b46d2bd968d357bbd912cae49caf163: drm/radeon: Bump version for CIK DCE tiling fix (2013-12-23 11:31:44 -0500) Alex Deucher (2): drm/radeon: 0x9649 is SUMO2 not SUMO drm/radeon: Bump version for CIK DCE tiling fix Christian K?nig (1): drm/radeon: fix UVD 256MB check Marek Ol??k (4): drm/radeon: fix render backend setup for SI and CIK drm/radeon: expose render backend mask to the userspace drm/radeon: set correct pipe config for Hawaii in DCE drm/radeon: set correct number of banks for CIK chips in DCE drivers/gpu/drm/radeon/atombios_crtc.c | 83 -- drivers/gpu/drm/radeon/cik.c | 12 +++-- drivers/gpu/drm/radeon/radeon.h| 4 +- drivers/gpu/drm/radeon/radeon_drv.c| 3 +- drivers/gpu/drm/radeon/radeon_kms.c| 9 drivers/gpu/drm/radeon/radeon_uvd.c| 2 +- drivers/gpu/drm/radeon/si.c| 12 +++-- include/drm/drm_pciids.h | 2 +- include/uapi/drm/radeon_drm.h | 2 + 9 files changed, 80 insertions(+), 49 deletions(-)
[Bug 73014] New: tahiti ways slower than juniper in dota2
https://bugs.freedesktop.org/show_bug.cgi?id=73014 Priority: medium Bug ID: 73014 Assignee: dri-devel at lists.freedesktop.org Summary: tahiti ways slower than juniper in dota2 Severity: minor Classification: Unclassified OS: Linux (All) Reporter: sylvain.bertrand at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 9.2 Component: Drivers/Gallium/radeonsi Product: Mesa Up-to-date fedora20, mesa-libGL-9.2.4-1.20131128, radeon module with power profile forced to high. linux native dota2 (via linux native steam), all video details to minimum (2560x1600, vsync on or off), juniper (1002:68be) is *really* faster than tahiti (1002:6798). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131224/74479977/attachment.html>
[PATCH v2] drm/omap: Don't dereference list head when the connectors list is empty
The connectors list iterator returns the list head when the list is
empty. Fix it by returning NULL in that case.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_fb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Changes since v1:
- Use list_first_entry_or_null
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index f2b8f06..2c3acb3 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -302,7 +302,8 @@ struct drm_connector *omap_framebuffer_get_next_connector(
struct drm_connector *connector = from;
if (!from)
- return list_first_entry(connector_list, typeof(*from), head);
+ return list_first_entry_or_null(connector_list, typeof(*from),
+ head);
list_for_each_entry_from(connector, connector_list, head) {
if (connector != from) {
--
Regards,
Laurent Pinchart
[PATCH] drm/omap: Don't dereference list head when the connectors list is empty
Hi,
On Monday 23 December 2013 08:57 PM, Laurent Pinchart wrote:
> The connectors list iterator returns the list head when the list is
> empty. Fix it by returning NULL in that case.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/omap_fb.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
> b/drivers/gpu/drm/omapdrm/omap_fb.c
> index f2b8f06..1b48cf2 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fb.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fb.c
> @@ -301,8 +301,11 @@ struct drm_connector
> *omap_framebuffer_get_next_connector(
> struct list_head *connector_list = >mode_config.connector_list;
> struct drm_connector *connector = from;
>
> - if (!from)
> + if (!from) {
> + if (list_empty(connector_list))
> + return NULL;
> return list_first_entry(connector_list, typeof(*from), head);
looks like there is a list function which does that too:
list_first_entry_or_null()
We could probably replace it with this.
Archit
> + }
>
> list_for_each_entry_from(connector, connector_list, head) {
> if (connector != from) {
>
[PATCH] drm/radeon: fix ttm debugfs for multiple devices
Am 24.12.2013 05:58, schrieb Ilija Hadzic:
> debugfs files created in radeon_ttm_debugfs_init
> are broken when there are multiple devices in the system.
> Namely, static declaration of radeon_mem_types_list
> causes the function to overwrite the values when the
> executed for subsequent devices. Consequently, the debugfs
> access functions can get .data field that belongs to wrong
> device.
>
> This patch fixes the problem by moving the mem_types
> list into the radeon_device structure instead of using
> static declarations.
>
> Signed-off-by: Ilija Hadzic
That fix is already queued for 3.14 by removing dynamically creating the
debugfs file definition all together. See
http://lists.freedesktop.org/archives/dri-devel/2013-December/050478.html.
Christian.
> ---
> drivers/gpu/drm/radeon/radeon.h | 6 ++
> drivers/gpu/drm/radeon/radeon_ttm.c | 43
> +
> 2 files changed, 26 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index b1f990d..bcb173a 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -2098,6 +2098,10 @@ struct radeon_atcs {
> typedef uint32_t (*radeon_rreg_t)(struct radeon_device*, uint32_t);
> typedef void (*radeon_wreg_t)(struct radeon_device*, uint32_t, uint32_t);
>
> +#define RADEON_DEBUGFS_MEM_TYPES 2
> +#define RADEON_TTM_DEBUGFS_MEM_TYPES 2
> +#define RADEON_DEBUGFS_TOTAL_MEM_TYPES (RADEON_DEBUGFS_MEM_TYPES +
> RADEON_TTM_DEBUGFS_MEM_TYPES)
> +
> struct radeon_device {
> struct device *dev;
> struct drm_device *ddev;
> @@ -2213,6 +2217,8 @@ struct radeon_device {
> /* debugfs */
> struct radeon_debugfs debugfs[RADEON_DEBUGFS_MAX_COMPONENTS];
> unsigneddebugfs_count;
> + struct drm_info_list mem_types_list[RADEON_DEBUGFS_TOTAL_MEM_TYPES];
> + char mem_types_names[RADEON_DEBUGFS_TOTAL_MEM_TYPES][32];
> /* virtual memory */
> struct radeon_vm_managervm_manager;
> struct mutexgpu_clock_mutex;
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 051fa87..0de413b 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -832,9 +832,6 @@ int radeon_mmap(struct file *filp, struct vm_area_struct
> *vma)
> return 0;
> }
>
> -
> -#define RADEON_DEBUGFS_MEM_TYPES 2
> -
> #if defined(CONFIG_DEBUG_FS)
> static int radeon_mm_dump_table(struct seq_file *m, void *data)
> {
> @@ -855,40 +852,40 @@ static int radeon_mm_dump_table(struct seq_file *m,
> void *data)
> static int radeon_ttm_debugfs_init(struct radeon_device *rdev)
> {
> #if defined(CONFIG_DEBUG_FS)
> - static struct drm_info_list
> radeon_mem_types_list[RADEON_DEBUGFS_MEM_TYPES+2];
> - static char radeon_mem_types_names[RADEON_DEBUGFS_MEM_TYPES+2][32];
> unsigned i;
>
> for (i = 0; i < RADEON_DEBUGFS_MEM_TYPES; i++) {
> if (i == 0)
> - sprintf(radeon_mem_types_names[i], "radeon_vram_mm");
> + sprintf(rdev->mem_types_names[i], "radeon_vram_mm");
> else
> - sprintf(radeon_mem_types_names[i], "radeon_gtt_mm");
> - radeon_mem_types_list[i].name = radeon_mem_types_names[i];
> - radeon_mem_types_list[i].show = _mm_dump_table;
> - radeon_mem_types_list[i].driver_features = 0;
> + sprintf(rdev->mem_types_names[i], "radeon_gtt_mm");
> + rdev->mem_types_list[i].name = rdev->mem_types_names[i];
> + rdev->mem_types_list[i].show = _mm_dump_table;
> + rdev->mem_types_list[i].driver_features = 0;
> if (i == 0)
> - radeon_mem_types_list[i].data =
> rdev->mman.bdev.man[TTM_PL_VRAM].priv;
> + rdev->mem_types_list[i].data =
> + rdev->mman.bdev.man[TTM_PL_VRAM].priv;
> else
> - radeon_mem_types_list[i].data =
> rdev->mman.bdev.man[TTM_PL_TT].priv;
> + rdev->mem_types_list[i].data =
> + rdev->mman.bdev.man[TTM_PL_TT].priv;
>
> }
> /* Add ttm page pool to debugfs */
> - sprintf(radeon_mem_types_names[i], "ttm_page_pool");
> - radeon_mem_types_list[i].name = radeon_mem_types_names[i];
> - radeon_mem_types_list[i].show = _page_alloc_debugfs;
> - radeon_mem_types_list[i].driver_features = 0;
> - radeon_mem_types_list[i++].data = NULL;
> + sprintf(rdev->mem_types_names[i], "ttm_page_pool");
> + rdev->mem_types_list[i].name = rdev->mem_types_names[i];
> + rdev->mem_types_list[i].show = _page_alloc_debugfs;
> + rdev->mem_types_list[i].driver_features = 0;
> + rdev->mem_types_list[i++].data = NULL;
> #ifdef CONFIG_SWIOTLB
> if
[PATCH v2] staging: imx-drm: imx-tve: Fix a sparse warning
This patch declares the function of_get_tve_mode
as a static one to fix this sparse warning:
drivers/staging/imx-drm/imx-tve.c:563:11: warning: \
symbol 'of_get_tve_mode' was not declared. \
Should it be static?
Acked-by: Shawn Guo
Signed-off-by: Liu Ying
---
Changes from v2:
-Just added Shawn Guo's ack.
drivers/staging/imx-drm/imx-tve.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/imx-drm/imx-tve.c
b/drivers/staging/imx-drm/imx-tve.c
index 2c44fef..9abc7ca 100644
--- a/drivers/staging/imx-drm/imx-tve.c
+++ b/drivers/staging/imx-drm/imx-tve.c
@@ -560,7 +560,7 @@ static const char *imx_tve_modes[] = {
[TVE_MODE_VGA] = "vga",
};
-const int of_get_tve_mode(struct device_node *np)
+static const int of_get_tve_mode(struct device_node *np)
{
const char *bm;
int ret, i;
--
1.7.9.5
[Bug 67571] BUG: unable to handle kernel paging in amd E350 hdmi init
https://bugzilla.kernel.org/show_bug.cgi?id=67571 --- Comment #9 from Eric Valette --- I had a chance to look at the display on the tv set after my kids went to bed, here is whar happens: 1) I get on long black immediately after boot as if normal vga display does not work, 2) Once init is completed, I see the kdm loggin, 3) I see the begining of kde initialization and at one point the screen goes black, 4) After a GPU rest I see for one second the normal desktop, 5) screen goes black forever Looking at the dmesg, I have a pile of until it fails to reset I guess [ 52.398524] radeon :00:01.0: GPU lockup CP stall for more than 1msec [ 52.398545] radeon :00:01.0: GPU lockup (waiting for 0x0006 last fence id 0x0002 on ring 5) [ 52.398556] [drm:uvd_v1_0_ib_test] *ERROR* radeon: fence wait failed (-35). [ 52.418619] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-35). [ 52.418632] [drm] Found smc ucode version: 0x00010200 [ 52.419416] [drm:dce4_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 67631] New: Radeon UVD hang/crash
https://bugzilla.kernel.org/show_bug.cgi?id=67631 Bug ID: 67631 Summary: Radeon UVD hang/crash Product: Drivers Version: 2.5 Kernel Version: 3.12.6 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: vitalif at yourcmc.ru Regression: No Created attachment 119491 --> https://bugzilla.kernel.org/attachment.cgi?id=119491=edit dmesg logged via netconsole Hi! When I try to use UVD on my laptop Dell Studio XPS 1645 with RV730 chip (Mobility Radeon HD 4670), the GPU hangs and is unable to work correctly. Virtual console switch works, and I even can restart X, but after that the picture is totally corrupt. I also tried to unload radeon by 'echo 0 > /sys/class/vtconsole/vtcon1/bind; rmmod radeon' and got kernel oops. The log is attached. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] of: Add MIPI DSI bus device tree bindings
Hello. Late to the party... On Monday December 2 2013 at 21:05, Thierry Reding wrote: > On Mon, Dec 02, 2013 at 08:57:20PM +0100, Tomasz Figa wrote: > > In general, this looks good to me as a starter, so we could have support > > for DSI bus merged. IMHO we should consider adding some generic bus > > properties in future, though. > > To be honest this looked somewhat minimal to me too at first, and then I > tried to come up with any other properties but couldn't think of any. Of > course anything that we add later on has the potential to break ABI > compatibility. > > A few of the things I had in mind that might be added as properties were > the number of lanes or the video format. But those will already be > implied by the compatible value and therefore don't really belong in the > DT. > > But if anyone can think of other properties that would be useful for DSI > host or peripherals, by all means, let me know. I've been working through the DSI bus patch set in conjunction with this one. There are two properties that are properties of the board rather than the host or the connected panels, so could fit in the DT. The first is the number of lanes connected - the compatible string can only provide the maximum number of lanes. Having said that, the panel will specify how many lanes it uses - if they're not all connected up you'll hopefully have noticed during the board layout... The other property (that may actually be useful) is the maximum HS clock speed. The host and panel drivers will specify one, along with an implicit minimum from the panel driver for the data rate requirement. The board may also impose limits on the clock speed. For burst mode video or command mode some flexibility in bus clock speed is helpful, with the actual used clock rate frequently depending on RF concerns. Bert.
[Bug 72895] Missing trees in flightgear 2.12.1 with r600 driver and mesa 10.0.1
https://bugs.freedesktop.org/show_bug.cgi?id=72895 Michel D?nzer changed: What|Removed |Added Assignee|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org CC||fredrik at kde.org Component|Drivers/Gallium/r600|Mesa core -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131224/d0f001fa/attachment.html>
[Bug 66791] Radeon fails to find vbios on macbook pro 2, 1 (2007) for x1600 using kernel EFI stub
https://bugzilla.kernel.org/show_bug.cgi?id=66791 --- Comment #6 from moonman --- Just a quick update: I managed to get it to work finally, though this is not really an optimal solution. 1. Patched the kernel with this patch: https://bugs.freedesktop.org/attachment.cgi?id=33766 from this bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=26891 2. Extracted the vbios while booted into archlinux live cd in bios mode (by the way the live cd needs to be patched to be booted because it comes with EFI 64bit support and not 32bit - well described how to do it in ArchWiki) 3. Only 1 method worked to extract the bios: echo 1 > /sys/devices/pci:00//rom cat /sys/devices/pci:00//rom > vbios.dump for me id=:00:02.0 The resulted image is 64000 bytes and does not work for loadbios in grub. Really don't know why. Actually there's another method: If you have windows installed you can use aida64 to extract the vbios. GPUZ does not work. Now I can succesfully boot into KDE, BUT only if booted using grub. With EFI Stub I get to console (screen does not stay black anymore), but X server fails to start. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 64801] KMS/R7xx - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
096kB (M) = 15888kB Node 0 DMA32: 16271*4kB (UEMR) 12996*8kB (UE) 4462*16kB (UM) 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 240444kB Node 0 Normal: 4401*4kB (UEMR) 14780*8kB (UEM) 8793*16kB (UEM) 1423*32kB (UM) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 322068kB Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB 1009606 total pagecache pages 968 pages in swap cache Swap cache stats: add 7288, delete 6320, find 34844/35058 Free swap = 4176772kB Total swap = 4194300kB 2088959 pages RAM 60877 pages reserved 1045328 pages shared 1264617 pages non-shared -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131224/8d90a0b4/attachment-0001.html>
