[Bug 62967] Game Dungeon Defenders crash my whole system.
https://bugs.freedesktop.org/show_bug.cgi?id=62967 Alex Deucher changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|9.0 Component|DRM/Radeon |Drivers/Gallium/r600 --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. Is this a regression? Does a newer version of mesa fix the issue? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62976] UEFI + SUMO [6550D] freeze after loading radeon
https://bugs.freedesktop.org/show_bug.cgi?id=62976 --- Comment #2 from Alex Deucher --- Are you booting with grub? Does removing GRUB_GFXPAYLOAD_LINUX=keep from your grub config help? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/tilcdc: LCD panels clocks initialization and earlier backlight initialization
On Mon, Apr 1, 2013 at 7:31 AM, Hiremath, Vaibhav wrote:
>
>> -Original Message-
>> From: devicetree-discuss [mailto:devicetree-discuss-
>> bounces+hvaibhav=ti@lists.ozlabs.org] On Behalf Of Michal Bachraty
>> Sent: Thursday, March 28, 2013 11:02 PM
>> To: dri-devel@lists.freedesktop.org; devicetree-
>> disc...@lists.ozlabs.org
>> Cc: robdcl...@gmail.com; k...@dominion.thruhere.net
>> Subject: drm/tilcdc: LCD panels clocks initialization and earlier
>> backlight initialization
>>
>> Hi,
>>
>> I'm trying to use tilcdc driver for KWH050TG08 LCD panel connected to
>> AM335x
>> processor (3.9 rc1 kernel). I have prepared DT bindings for that
>> (listed
>> bellow). I see fb0 device but I have no clocks going from cpu to LCD.
>> My
>> clocks for LCD seems not properly to be set ...
>>
>> virt_2500_ck 1 12500
>> sys_clkin_ck8 19 2500
>>dpll_disp_ck 0 12500
>> dpll_disp_m2_ck 0 12500
>> lcd_gclk 0 12500
>>
>> and tilcdc_crtc is not called. I also set lcd_gclk to 300MHz, but I got
>> same
>> result. The question is there any way how to properly set clocks for
>> LCD?
>>
> Not sure about the LCDC DRM driver, but I just tested clk_set_rate()
> For lcdc_gclk clock and it is working for me. I could able to set
> 300MHz freq on my BeagleBone platform, with below code -
>
fwiw, tilcdc drm driver won't set clocks until you do modeset, as it
is setting them based on the requested pixel clock. As opposed to
setting it once at boot time.
Michal, you may want to add 'drm.debug=7' in your bootargs, and send
the bootlog. That should set some light about whether it is even
trying to modeset but failing, or some other issue.
BR,
-R
>
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c
> index e54a480..443fb26 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -11,6 +11,7 @@
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> */
> +#include
> #include
> #include
> #include
> @@ -37,6 +38,8 @@ static struct of_device_id omap_dt_match_table[] __initdata
> = {
>
> static void __init omap_generic_init(void)
> {
> + struct clk *clk;
> +
> omap_sdrc_init(NULL, NULL);
>
> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> @@ -49,6 +52,15 @@ static void __init omap_generic_init(void)
> omap4_panda_display_init_of();
> else if (of_machine_is_compatible("ti,omap4-sdp"))
> omap_4430sdp_display_init_of();
> +
> + clk = clk_get(NULL, "lcd_gclk");
> + if (IS_ERR(clk))
> + printk("Can not get lcd_gclk clock\n");
> +
> + printk("%s:%d gclk_rate - %lu\n", __func__, __LINE__,
> clk_get_rate(clk));
> + clk_set_rate(clk, 3);
> + printk("%s:%d clk_rate - %lu\n", __func__, __LINE__,
> clk_get_rate(clk));
> + clk_put(clk);
> }
>
> #ifdef CONFIG_SOC_OMAP2420
>
>
> Thanks,
> Vaibhav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62976] UEFI + SUMO [6550D] freeze after loading radeon
https://bugs.freedesktop.org/show_bug.cgi?id=62976 --- Comment #3 from David Heidelberger --- No, directly from GPT USB: http://wiki.gentoo.org/wiki/UEFI_Gentoo_Quick_Install_Guide -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62967] Game Dungeon Defenders crash my whole system.
https://bugs.freedesktop.org/show_bug.cgi?id=62967 --- Comment #2 from Thomas Lindroth --- There is an upstream bug about this problem here. https://bugzilla.icculus.org/show_bug.cgi?id=5895 Seems like it runs fine on the closed drivers. The game freeze for several seconds during the intro as the game does about 6000 calls to glCompileShader. Here is an apitrace of the intro. https://dl.dropbox.com/s/ynibt38hhdlyu1r/DungeonDefenders-x86.trace.bz2 glretrace will segfault while playing it back in r600_dri.so during a call to glDrawRangeElements. I couldn't get a backtrace because of corrupt stack. Playing back the trace with softpipe will not segfault but it will have the drawing errors. Mesa-9.1 and git from a few days ago both got the problem. 3.8.4 kernel, juniper hardware. Option "ColorTiling" "true" Option "ColorTiling2D" "true" Option "SwapbuffersWait" "false" Option "EnablePageFlip" "true" -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62997] New: GPU fault unless R600_DEBUG=nodma
https://bugs.freedesktop.org/show_bug.cgi?id=62997 Priority: medium Bug ID: 62997 Assignee: dri-devel@lists.freedesktop.org Summary: GPU fault unless R600_DEBUG=nodma Severity: major Classification: Unclassified OS: Linux (All) Reporter: udo...@xs4all.nl Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Ever since booting into kernel.org 3.8.4 on my AMD A10-5800K (ARUBA graphics), running git mesa and git xf86-video-ati, I get short uptimes (15 minutes, around one hour max) due to crashes. The logs mention stuff like: [ 1332.480233] radeon :00:01.0: GPU fault detected: 146 0x0134710c [ 1332.480243] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0813 [ 1332.480250] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0407100C Watching youtube `helps` triggering the issue as it appears. (correlates, no real causation yet) Having R600_DEBUG=nodma in the environment solves the problem. Occasionally I see a GPU lockup, if that is related: [29648.098135] disk 0, wo:0, o:1, dev:sda2 [29648.098140] disk 1, wo:0, o:1, dev:sdb2 [29648.098142] disk 2, wo:0, o:1, dev:sdc2 [29648.098145] disk 3, wo:0, o:1, dev:sdd2 [68707.166021] radeon :00:01.0: GPU fault detected: 146 0x0d4c2604 [68707.166030] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x08D4 [68707.166043] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0C026004 [70621.378798] radeon :00:01.0: GPU fault detected: 146 0x013c710c [70621.378808] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0813 [70621.378815] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0C07100C [70621.378837] radeon :00:01.0: GPU fault detected: 147 0x0f0c7102 [70621.378843] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [70621.378848] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [70621.378854] radeon :00:01.0: GPU fault detected: 147 0x0f1c7102 [70621.378859] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [70621.378864] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [70631.857918] radeon :00:01.0: GPU lockup CP stall for more than 1msec [70631.857927] radeon :00:01.0: GPU lockup (waiting for 0x007e1fe5 last fence id 0x007e1fe3) [70631.858436] radeon :00:01.0: sa_manager is not empty, clearing anyway [70631.859755] radeon :00:01.0: Saved 951 dwords of commands on ring 0. [70631.859761] radeon :00:01.0: GPU softreset: 0x0003 [70631.859766] radeon :00:01.0: VM_CONTEXT0_PROTECTION_FAULT_ADDR 0x [70631.859770] radeon :00:01.0: VM_CONTEXT0_PROTECTION_FAULT_STATUS 0x [70631.859774] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [70631.859778] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [70631.867299] radeon :00:01.0: GRBM_STATUS = 0xA2703828 [70631.867305] radeon :00:01.0: GRBM_STATUS_SE0 = 0x1D07 [70631.867309] radeon :00:01.0: GRBM_STATUS_SE1 = 0x0007 [70631.867313] radeon :00:01.0: SRBM_STATUS = 0x2040 [70631.867317] radeon :00:01.0: R_008674_CP_STALLED_STAT1 = 0x [70631.867321] radeon :00:01.0: R_008678_CP_STALLED_STAT2 = 0x00018000 [70631.867325] radeon :00:01.0: R_00867C_CP_BUSY_STAT = 0x8006 [70631.867328] radeon :00:01.0: R_008680_CP_STAT = 0x80038647 [70631.867332] radeon :00:01.0: GRBM_SOFT_RESET=0xDF7B [70631.867386] radeon :00:01.0: GRBM_STATUS = 0x3828 [70631.867390] radeon :00:01.0: GRBM_STATUS_SE0 = 0x0007 [70631.867393] radeon :00:01.0: GRBM_STATUS_SE1 = 0x0007 [70631.867397] radeon :00:01.0: SRBM_STATUS = 0x2040 [70631.867400] radeon :00:01.0: R_008674_CP_STALLED_STAT1 = 0x [70631.867404] radeon :00:01.0: R_008678_CP_STALLED_STAT2 = 0x [70631.867408] radeon :00:01.0: R_00867C_CP_BUSY_STAT = 0x [70631.867411] radeon :00:01.0: R_008680_CP_STAT = 0x [70631.883681] radeon :00:01.0: GPU reset succeeded, trying to resume [70631.916445] [drm] PCIE GART of 512M enabled (table at 0x0004). [70631.916534] radeon :00:01.0: WB enabled [70631.916536] radeon :00:01.0: fence driver on ring 0 use gpu addr 0x3c00 and cpu addr 0x880235891c00 [70631.916538] radeon :00:01.0: fence driver on ring 1 use gpu addr 0x3c04 and cpu addr 0x880235891c04 [70631.916
[Bug 62997] GPU fault unless R600_DEBUG=nodma
https://bugs.freedesktop.org/show_bug.cgi?id=62997 --- Comment #1 from udo --- Created attachment 77277 --> https://bugs.freedesktop.org/attachment.cgi?id=77277&action=edit Xorg.0.log with R600_DEBUG=nodma -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62997] GPU fault unless R600_DEBUG=nodma
https://bugs.freedesktop.org/show_bug.cgi?id=62997 --- Comment #2 from udo --- Created attachment 77278 --> https://bugs.freedesktop.org/attachment.cgi?id=77278&action=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=62889 --- Comment #6 from Alexander von Gluck --- Created attachment 77279 --> https://bugs.freedesktop.org/attachment.cgi?id=77279&action=edit software packages attaching related software package versions. A version number means a stable upstream version, a date stamp means that it was a build of the latest git code from that date. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/exynos: enable FIMD clocks
While migrating to common clock framework (CCF), found that the FIMD clocks
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.
By calling clk_prepare_enable() for FIMD clocks fixes the issue.
this patch also replaces clk_disable() with clk_disable_unprepare()
during exit.
Signed-off-by: Vikas Sajjan
---
Changes since v2:
- moved clk_prepare_enable() and clk_disable_unprepare() from
fimd_probe() to fimd_clock() as suggested by Inki Dae
Changes since v1:
- added error checking for clk_prepare_enable() and also replaced
clk_disable() with clk_disable_unprepare() during exit.
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..f2400c8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -799,18 +799,18 @@ static int fimd_clock(struct fimd_context *ctx, bool
enable)
if (enable) {
int ret;
- ret = clk_enable(ctx->bus_clk);
+ ret = clk_prepare_enable(ctx->bus_clk);
if (ret < 0)
return ret;
- ret = clk_enable(ctx->lcd_clk);
+ ret = clk_prepare_enable(ctx->lcd_clk);
if (ret < 0) {
- clk_disable(ctx->bus_clk);
+ clk_disable_unprepare(ctx->bus_clk);
return ret;
}
} else {
- clk_disable(ctx->lcd_clk);
- clk_disable(ctx->bus_clk);
+ clk_disable_unprepare(ctx->lcd_clk);
+ clk_disable_unprepare(ctx->bus_clk);
}
return 0;
@@ -981,8 +981,8 @@ static int fimd_remove(struct platform_device *pdev)
if (ctx->suspended)
goto out;
- clk_disable(ctx->lcd_clk);
- clk_disable(ctx->bus_clk);
+ clk_disable_unprepare(ctx->lcd_clk);
+ clk_disable_unprepare(ctx->bus_clk);
pm_runtime_set_suspended(dev);
pm_runtime_put_sync(dev);
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/exynos: enable FIMD clocks
On 1 April 2013 14:13, Vikas Sajjan wrote:
> While migrating to common clock framework (CCF), found that the FIMD clocks
s/found/we found/
> were pulled down by the CCF.
> If CCF finds any clock(s) which has NOT been claimed by any of the
> drivers, then such clock(s) are PULLed low by CCF.
>
> By calling clk_prepare_enable() for FIMD clocks fixes the issue.
s/By calling/Calling/
and
s/the/this
> this patch also replaces clk_disable() with clk_disable_unprepare()
s/this/This
> during exit.
Sorry but your log doesn't say what you are doing. You are just adding
relevant calls to clk_prepare/unprepare() before calling clk_enable/disable.
> Signed-off-by: Vikas Sajjan
> ---
> Changes since v2:
> - moved clk_prepare_enable() and clk_disable_unprepare() from
> fimd_probe() to fimd_clock() as suggested by Inki Dae
>
> Changes since v1:
> - added error checking for clk_prepare_enable() and also replaced
> clk_disable() with clk_disable_unprepare() during exit.
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 9537761..f2400c8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -799,18 +799,18 @@ static int fimd_clock(struct fimd_context *ctx, bool
> enable)
> if (enable) {
> int ret;
>
> - ret = clk_enable(ctx->bus_clk);
> + ret = clk_prepare_enable(ctx->bus_clk);
> if (ret < 0)
> return ret;
>
> - ret = clk_enable(ctx->lcd_clk);
> + ret = clk_prepare_enable(ctx->lcd_clk);
> if (ret < 0) {
> - clk_disable(ctx->bus_clk);
> + clk_disable_unprepare(ctx->bus_clk);
> return ret;
> }
> } else {
> - clk_disable(ctx->lcd_clk);
> - clk_disable(ctx->bus_clk);
> + clk_disable_unprepare(ctx->lcd_clk);
> + clk_disable_unprepare(ctx->bus_clk);
> }
>
> return 0;
> @@ -981,8 +981,8 @@ static int fimd_remove(struct platform_device *pdev)
> if (ctx->suspended)
> goto out;
>
> - clk_disable(ctx->lcd_clk);
> - clk_disable(ctx->bus_clk);
> + clk_disable_unprepare(ctx->lcd_clk);
> + clk_disable_unprepare(ctx->bus_clk);
You are doing things at the right place but i have a suggestion. Are you doing
anything in your clk_prepare() atleast for this device? Probably not.
If not, then its better to call clk_prepare/unprepare only once at probe/remove
and keep clk_enable/disable calls as is.
--
viresh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: drm/tilcdc: LCD panels clocks initialization and earlier backlight initialization
> -Original Message-
> From: devicetree-discuss [mailto:devicetree-discuss-
> bounces+hvaibhav=ti@lists.ozlabs.org] On Behalf Of Michal Bachraty
> Sent: Thursday, March 28, 2013 11:02 PM
> To: dri-devel@lists.freedesktop.org; devicetree-
> disc...@lists.ozlabs.org
> Cc: robdcl...@gmail.com; k...@dominion.thruhere.net
> Subject: drm/tilcdc: LCD panels clocks initialization and earlier
> backlight initialization
>
> Hi,
>
> I'm trying to use tilcdc driver for KWH050TG08 LCD panel connected to
> AM335x
> processor (3.9 rc1 kernel). I have prepared DT bindings for that
> (listed
> bellow). I see fb0 device but I have no clocks going from cpu to LCD.
> My
> clocks for LCD seems not properly to be set ...
>
> virt_2500_ck 1 12500
> sys_clkin_ck8 19 2500
>dpll_disp_ck 0 12500
> dpll_disp_m2_ck 0 12500
> lcd_gclk 0 12500
>
> and tilcdc_crtc is not called. I also set lcd_gclk to 300MHz, but I got
> same
> result. The question is there any way how to properly set clocks for
> LCD?
>
Not sure about the LCDC DRM driver, but I just tested clk_set_rate()
For lcdc_gclk clock and it is working for me. I could able to set
300MHz freq on my BeagleBone platform, with below code -
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index e54a480..443fb26 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -11,6 +11,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -37,6 +38,8 @@ static struct of_device_id omap_dt_match_table[] __initdata =
{
static void __init omap_generic_init(void)
{
+ struct clk *clk;
+
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
@@ -49,6 +52,15 @@ static void __init omap_generic_init(void)
omap4_panda_display_init_of();
else if (of_machine_is_compatible("ti,omap4-sdp"))
omap_4430sdp_display_init_of();
+
+ clk = clk_get(NULL, "lcd_gclk");
+ if (IS_ERR(clk))
+ printk("Can not get lcd_gclk clock\n");
+
+ printk("%s:%d gclk_rate - %lu\n", __func__, __LINE__,
clk_get_rate(clk));
+ clk_set_rate(clk, 3);
+ printk("%s:%d clk_rate - %lu\n", __func__, __LINE__, clk_get_rate(clk));
+ clk_put(clk);
}
#ifdef CONFIG_SOC_OMAP2420
Thanks,
Vaibhav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [drm] exynos: hdmi: Remove fecal color
This patch makes the driver less shitty.
Signed-off-by: Edward Smietana
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 6d63f90..e11372c 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1269,7 +1269,7 @@ static void hdmi_conf_init(struct hdmi_context *hdata)
}
if (hdata->type == HDMI_TYPE13) {
- /* choose bluescreen (fecal) color */
+ /* choose bluescreen (brown) color */
hdmi_reg_writeb(hdata, HDMI_V13_BLUE_SCREEN_0, 0x12);
hdmi_reg_writeb(hdata, HDMI_V13_BLUE_SCREEN_1, 0x34);
hdmi_reg_writeb(hdata, HDMI_V13_BLUE_SCREEN_2, 0x56);
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-r
On Sun, Mar 31, 2013 at 9:55 PM, Jiri Kosina wrote: > On Thu, 21 Mar 2013, Daniel Vetter wrote: > >> Indeed, this is pretty useful and allowed me to quickly reproduce that >> phantom irq on my gm45. Thanks to module reloading we can even reset the >> kernel's irq disabling logic and so test different tricks quickly without >> rebooting. Really useful. > > Daniel, > > out of curiosity, have you been able to make some sense of the phantom > legacy IRQs on GM45 systems, or are we just staying with my original > bandaid (disabling GMBUS IRQs), declaring GM45 broken in this respect? I've played around with dummy-irq on my own gm45 and afaict every gmbus interrupt generates both an msi and a legacy pci interrupt when msi is enabled. Everything else (= other interrupt sources) seems to work as expected, and disabling msi also papers over the issue. There's also scary comments in our gm45 irq handler that we need msi to paper over some other races. So I've decided that I don't want to dwell any longer in this particular dungeon and that your bandaid (of just disabling this mess) is the real fix. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path
On Sun, 31 Mar 2013, Michal Hocko wrote: On Sat 30-03-13 18:26:53, Ilija Hadzic wrote: This looks a bit like a hack and it doesn't look right, conceptually. If the call fails, it should restore things as if nothing has ever happened and overwriting old_mapping is not going to do the trick. OK, I thought this is what the patch does as it falls back to &inode->i_data which is the default mapping for all inodes or it uses what used to be in device mapping. I am obviously not familiar with the drm code but it feels a bit strange that the device mapping can be different than inode's resp. file's one The reason for this is explained in commit message associated with 949c4a34. In summary, the device's mapping is that of the inode associated with the first opener. Before 949c4a34, subsequent openers would have to come in through exactly the same inode that the first opener came in (otherwise the open call would fail). So if a user did something like: start X, remove /dev/dri/cardN file, mknod the same file again, the applications started after such an action would stop working. Also, using the GPU from chroot-ed environment was not possible if there was another opener from different root. The 949c4a34, removed this restriction, but introduced a problem with VmWare GPU drivers, which fdb40a08. However, fdb40a08 introduced the bug that you have reported. The problem that I have with your proposed fix is that if the first opener fails, it can set the device's mapping to that of the inode that was never used and never opened (and could even be removed later down the road). and even more confusing that inode and file are saved separately. I was trying to quickly get out the patch that was safe in terms of introducing new breakage. So the "conservative" thing to do (without having to think through all possible scenarios) was to restore each of the three pointers from their own temporary variable. Thinking about it, you are probably right that file descriptor's and inode's mapping pointer are equal when open call is entered so we could use one variable. However, you still need a separate variable to store the device's mapping pointer because that one can be different. Attached is a v2 of the patch, for reference. I would appreciate if the original reporter or you tested it in lieu of your proposed patch and let me know if it fixes your issue. -- Ilija From 7e3c832158e2552e5e106a588e2b9e61c35b68f2 Mon Sep 17 00:00:00 2001 From: Ilija Hadzic Date: Sat, 30 Mar 2013 18:20:35 -0400 Subject: [PATCH] drm: correctly restore mappings if drm_open fails If first drm_open fails, the error-handling path will incorrectly restore inode's mapping to NULL. This can cause the crash later on. Fix by separately storing away mapping pointers that drm_open can touch and restore each from its own respective variable if the call fails. Reference: http://lists.freedesktop.org/archives/dri-devel/2013-March/036564.html v2: use one variable to store file and inode mapping since they are the same at the function entry; also fix spelling mistakes in commit message. Reported-by: Marco Munderloh Signed-off-by: Ilija Hadzic Cc: Michal Hocko Cc: sta...@vger.kernel.org Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/drm_fops.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index 13fdcd1..429e07d 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -123,6 +123,7 @@ int drm_open(struct inode *inode, struct file *filp) int retcode = 0; int need_setup = 0; struct address_space *old_mapping; + struct address_space *old_imapping; minor = idr_find(&drm_minors_idr, minor_id); if (!minor) @@ -137,6 +138,7 @@ int drm_open(struct inode *inode, struct file *filp) if (!dev->open_count++) need_setup = 1; mutex_lock(&dev->struct_mutex); + old_imapping = inode->i_mapping; old_mapping = dev->dev_mapping; if (old_mapping == NULL) dev->dev_mapping = &inode->i_data; @@ -159,8 +161,8 @@ int drm_open(struct inode *inode, struct file *filp) err_undo: mutex_lock(&dev->struct_mutex); - filp->f_mapping = old_mapping; - inode->i_mapping = old_mapping; + filp->f_mapping = old_imapping; + inode->i_mapping = old_imapping; iput(container_of(dev->dev_mapping, struct inode, i_data)); dev->dev_mapping = old_mapping; mutex_unlock(&dev->struct_mutex); -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62226] Build Fails with LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=62226 --- Comment #5 from Niels Ole Salscheider --- The problem seems to be that the build system picks the already installed libllvmradeon9.2.0.so (from /usr/lib64) instead of the one that has just been built. A workaround is to uninstall mesa before compiling and installing the new version. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62226] Build Fails with LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=62226 --- Comment #6 from Tom Stellard --- Created attachment 77291 --> https://bugs.freedesktop.org/attachment.cgi?id=77291&action=edit Build libradeonllvm as static library Does this patch help? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62226] Build Fails with LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=62226 --- Comment #7 from Serkan Hosca --- (In reply to comment #6) > Created attachment 77291 [details] [review] > Build libradeonllvm as static library > > Does this patch help? Yes, the patch fixes the build -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62226] Build Fails with LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=62226 --- Comment #8 from Johannes Obermayr --- I am against this sort of patches. Because autotools are stupid the second line should be the right attempt: libradeonsi_la_LDFLAGS = -Wl,--no-undefined -shared -avoid-version \ -L../radeon \ $(LLVM_LDFLAGS) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62226] Build Fails with LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=62226 --- Comment #9 from Tom Stellard --- (In reply to comment #8) > I am against this sort of patches. > Can you explain why? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62226] Build Fails with LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=62226 Johannes Obermayr changed: What|Removed |Added CC||andreas.boll@gmail.com, ||johannesoberm...@gmx.de --- Comment #10 from Johannes Obermayr --- (In reply to comment #9) > (In reply to comment #8) > > I am against this sort of patches. > > > > Can you explain why? Because you are working against aboll and me - we want to build as much '-shared' as possible (and also distributions [should] want to do so): http://lists.freedesktop.org/archives/mesa-dev/2013-March/036449.html http://lists.freedesktop.org/archives/mesa-dev/2013-March/036493.html Also this statement is wrong: "This library was originally changed to a shared object to work around linker error in egl_static.so, but these appear to be fixed now." It was changed to be built '-shared' because there were and possibly be troubles with crashing egl things if r600 AND radeonsi were built together (see on #dri-devel from mid december 2012 [MrCooper, jobermayr]) You should also see the conditional there. If it makes sense and is required (r600 AND radeonsi) it is shared. If it doesn't (r600 XOR radeonsi) it is static. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #21 from korg...@yandex.com --- I can also confirm this bug. Software: Archlinux standard installation. Linux 3.8.4-1-ARCH #1 SMP PREEMPT Wed Mar 20 22:10:25 CET 2013 x86_64 GNU/Linux KDE: 4.10.1 (no widgets, other than the task panel) Kwin: 4.10.1 (standard OpenGL effects installed) Org X Server 1.14.0 Release Date: 2013-03-05 X Protocol Version 11, Revision 0 Build Operating System: Linux 3.8.2-1-ARCH x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=xyz ro init=/usr/lib/systemd/systemd Build Date: 09 March 2013 11:43:05AM Current version of pixman: 0.28.2 mesa: 9.1.1-1 (standard Arch package) I also tried a git version from AUR repository (same crashes): OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV770 OpenGL version string: 3.0 Mesa 9.2.0 (git-135bb3c) OpenGL shading language version string: 1.30 Driver: R600G GPU class: R700 OpenGL version: 3.0 GLSL version: 1.30 Mesa version: 9.2 X server version: 1.14 Linux kernel version: 3.8.4 Direct rendering: yes Requires strict binding:no GLSL shaders: yes Texture NPOT support: yes Virtual Machine:no Application::crashHandler() called with signal 7; recent crashes: 1 Xorg.conf: empty Hardware: Intel i7 920 ATI RV790 [Radeon HD 4890] 1GB VRAM Monitor 1: 1920x1200 (DVI) - image as background Monitor 2: 1920x1080 (HDMI) - image as background Two virtual desktops configured. How to reproduce: just log in into KDM. When the standard KDE desktop is displayed the first Kwin crash (caused by r600 crash) has occurred and its errors is already being displayed. Kwin is re-spawned and everything seems to be normal for some minutes. Then it crashes again and then again, and again until kwin and the desktop are dead definitively. It doesn't seem to matter what applications are being used or if the second monitor is on or off. The crashes happens all the same. I didn't try to downgrade either the kernel or xorg, but I'm sure those crashes started to happen after the latest kernel upgrade to 3.8.x. Here is the backtrace, which seems to confirm the general suspicion of a texture-handling problem: Thread 1 (Thread 0x7fb64bdb6780 (LWP 734)): [KCrash Handler] #5 0x7fb64b59859b in __memset_sse2 () from /usr/lib/libc.so.6 #6 0x7fb59a42b40a in r600_texture_create_object () from /usr/lib/xorg/modules/dri/r600_dri.so #7 0x7fb59a42b6e7 in r600_texture_create () from /usr/lib/xorg/modules/dri/r600_dri.so #8 0x7fb59a43fbb5 in dri2_allocate_textures () from /usr/lib/xorg/modules/dri/r600_dri.so #9 0x7fb59a43e695 in dri_st_framebuffer_validate () from /usr/lib/xorg/modules/dri/r600_dri.so #10 0x7fb59a43e8ce in dri_set_tex_buffer2 () from /usr/lib/xorg/modules/dri/r600_dri.so #11 0x7fb64b989343 in KWin::GlxTexture::loadTexture(unsigned long const&, QSize const&, int) () from /usr/lib/libkdeinit4_kwin.so #12 0x7fb64b9810f5 in KWin::SceneOpenGL::Window::bindTexture() () from /usr/lib/libkdeinit4_kwin.so #13 0x7fb64b987a0e in KWin::SceneOpenGL::Window::performPaint(int, QRegion, KWin::WindowPaintData) () from /usr/lib/libkdeinit4_kwin.so #14 0x7fb64b9804bf in KWin::SceneOpenGL2::performPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #15 0x7fb64b98065d in KWin::SceneOpenGL2::finalDrawWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #16 0x7fb64b994275 in KWin::EffectsHandlerImpl::drawWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #17 0x7fb64b9738ea in KWin::Scene::finalPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #18 0x7fb64b994517 in KWin::EffectsHandlerImpl::paintWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #19 0x7fb64b9764ad in KWin::Scene::paintWindow(KWin::Scene::Window*, int, QRegion, KWin::WindowQuadList) () from /usr/lib/libkdeinit4_kwin.so #20 0x7fb64b9757df in KWin::Scene::paintSimpleScreen(int, QRegion) () from /usr/lib/libkdeinit4_kwin.so #21 0x7fb64b97382e in KWin::Scene::finalPaintScreen(int, QRegion, KWin::ScreenPaintData&) () from /usr/lib/libkdeinit4_kwin.so #22 0x7fb64b9946e0 in KWin::EffectsHandlerImpl::paintScreen(int, QRegion, KWin::ScreenPaintData&) () from /usr/lib/libkdeinit4_kwin.so #23 0x7fb64b974bc8 in KWin::Scene::paintScreen(int*, QRegion*) () from /usr/lib/libkdeinit4_kwin.so #24 0x7fb64b983f4e in KWin::SceneOpenGL::paint(QRegion, QList)
linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_dp.c between commit 9d1a455b0ca1 ("") from
Linus' tree and commit 965e0c489f36 ("drm/i915: introduce
pipe_config->dither|pipe_bpp") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_dp.c
index d7d4afe,92a7c62..000
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@@ -850,10 -792,10 +802,10 @@@ intel_dp_set_m_n(struct drm_crtc *crtc
* the number of bytes_per_pixel post-LUT, which we always
* set up for 8-bits of R/G/B, or 3 bytes total.
*/
- intel_link_compute_m_n(intel_crtc->bpp, lane_count,
+ intel_link_compute_m_n(intel_crtc->config.pipe_bpp, lane_count,
- mode->clock, adjusted_mode->clock, &m_n);
+ target_clock, adjusted_mode->clock, &m_n);
- if (IS_HASWELL(dev)) {
+ if (HAS_DDI(dev)) {
I915_WRITE(PIPE_DATA_M1(cpu_transcoder),
TU_SIZE(m_n.tu) | m_n.gmch_m);
I915_WRITE(PIPE_DATA_N1(cpu_transcoder), m_n.gmch_n);
pgpO3TQ64geyj.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tilcdc: Disable building as module
Attempts to compile tilcdc as module results in: drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here make[5]: [drivers/gpu/drm/tilcdc/tilcdc.o] Error 1 (ignored) It appears it was never even tried to build it as module, or the problem would have been seen. So running this driver as module was never really tested. Disable it. If really needed, the code wil require some structural changes and in-depth testing, which can and should be done separately. Cc: Rob Clark Signed-off-by: Guenter Roeck --- drivers/gpu/drm/tilcdc/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig index d24d040..6ddb729 100644 --- a/drivers/gpu/drm/tilcdc/Kconfig +++ b/drivers/gpu/drm/tilcdc/Kconfig @@ -1,5 +1,5 @@ config DRM_TILCDC - tristate "DRM Support for TI LCDC Display Controller" + bool "DRM Support for TI LCDC Display Controller" depends on DRM && OF && ARM select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER -- 1.7.9.7 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH]gpu:drm: Add missing dependency on DRM KMS/FB CMA helper
Commit 2e3b3c42f06ff6801b3d7839757bbdb231619083 (Add DRM KMS/FB CMA helper) add a kbuild entry, config DRM_KMS_CMA_HELPER, in DRM's Kconfig without dependence on DRM, it cause DRM's kconfig can't be show in a submenu. This patch fix it. Signed-off-by: Wang YanQing --- drivers/gpu/drm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 1e82882..28e3cb4 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -63,6 +63,7 @@ config DRM_GEM_CMA_HELPER config DRM_KMS_CMA_HELPER bool + depends on DRM select DRM_GEM_CMA_HELPER select FB_SYS_FILLRECT select FB_SYS_COPYAREA -- 1.7.12.4.dirty ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: change the method for getting the interrupt resource of FIMD
Hi Mr. Inki Dae,
Can you please review this patch.?
On Wed, Mar 13, 2013 at 4:22 PM, Vikas Sajjan wrote:
> Replaces the "platform_get_resource() for IORESOURCE_IRQ" with
> platform_get_resource_byname().
> Both in exynos4 and exynos5, FIMD IP has 3 interrupts in the order: "fifo",
> "vsync", and "lcd_sys".
> But The FIMD driver expects the "vsync" interrupt to be mentioned as the
> 1st parameter in the FIMD DT node. So to meet this expectation of the
> driver, the FIMD DT node was forced to be made by keeping "vsync" as the
> 1st paramter.
> For example in exynos4, the FIMD DT node has interrupt numbers
> mentioned as <11, 1> <11, 0> <11, 2> keeping "vsync" as the 1st paramter.
>
> This patch fixes the above mentioned "hack" of re-ordering of the
> FIMD interrupt numbers by getting interrupt resource of FIMD by using
> platform_get_resource_byname().
>
> Signed-off-by: Vikas Sajjan
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 1ea173a..cd79d38 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -945,7 +945,7 @@ static int fimd_probe(struct platform_device *pdev)
> return -ENXIO;
> }
>
> - res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> + res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "vsync");
> if (!res) {
> dev_err(dev, "irq request failed.\n");
> return -ENXIO;
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62976] UEFI + SUMO [6550D] freeze after loading radeon
https://bugs.freedesktop.org/show_bug.cgi?id=62976 --- Comment #2 from Alex Deucher --- Are you booting with grub? Does removing GRUB_GFXPAYLOAD_LINUX=keep from your grub config help? -- 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/20130401/6a82cd34/attachment.html>
drm/tilcdc: LCD panels clocks initialization and earlier backlight initialization
On Mon, Apr 1, 2013 at 7:31 AM, Hiremath, Vaibhav wrote:
>
>> -Original Message-
>> From: devicetree-discuss [mailto:devicetree-discuss-
>> bounces+hvaibhav=ti.com at lists.ozlabs.org] On Behalf Of Michal Bachraty
>> Sent: Thursday, March 28, 2013 11:02 PM
>> To: dri-devel at lists.freedesktop.org; devicetree-
>> discuss at lists.ozlabs.org
>> Cc: robdclark at gmail.com; koen at dominion.thruhere.net
>> Subject: drm/tilcdc: LCD panels clocks initialization and earlier
>> backlight initialization
>>
>> Hi,
>>
>> I'm trying to use tilcdc driver for KWH050TG08 LCD panel connected to
>> AM335x
>> processor (3.9 rc1 kernel). I have prepared DT bindings for that
>> (listed
>> bellow). I see fb0 device but I have no clocks going from cpu to LCD.
>> My
>> clocks for LCD seems not properly to be set ...
>>
>> virt_2500_ck 1 12500
>> sys_clkin_ck8 19 2500
>>dpll_disp_ck 0 12500
>> dpll_disp_m2_ck 0 12500
>> lcd_gclk 0 12500
>>
>> and tilcdc_crtc is not called. I also set lcd_gclk to 300MHz, but I got
>> same
>> result. The question is there any way how to properly set clocks for
>> LCD?
>>
> Not sure about the LCDC DRM driver, but I just tested clk_set_rate()
> For lcdc_gclk clock and it is working for me. I could able to set
> 300MHz freq on my BeagleBone platform, with below code -
>
fwiw, tilcdc drm driver won't set clocks until you do modeset, as it
is setting them based on the requested pixel clock. As opposed to
setting it once at boot time.
Michal, you may want to add 'drm.debug=7' in your bootargs, and send
the bootlog. That should set some light about whether it is even
trying to modeset but failing, or some other issue.
BR,
-R
>
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c
> index e54a480..443fb26 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -11,6 +11,7 @@
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> */
> +#include
> #include
> #include
> #include
> @@ -37,6 +38,8 @@ static struct of_device_id omap_dt_match_table[] __initdata
> = {
>
> static void __init omap_generic_init(void)
> {
> + struct clk *clk;
> +
> omap_sdrc_init(NULL, NULL);
>
> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> @@ -49,6 +52,15 @@ static void __init omap_generic_init(void)
> omap4_panda_display_init_of();
> else if (of_machine_is_compatible("ti,omap4-sdp"))
> omap_4430sdp_display_init_of();
> +
> + clk = clk_get(NULL, "lcd_gclk");
> + if (IS_ERR(clk))
> + printk("Can not get lcd_gclk clock\n");
> +
> + printk("%s:%d gclk_rate - %lu\n", __func__, __LINE__,
> clk_get_rate(clk));
> + clk_set_rate(clk, 3);
> + printk("%s:%d clk_rate - %lu\n", __func__, __LINE__,
> clk_get_rate(clk));
> + clk_put(clk);
> }
>
> #ifdef CONFIG_SOC_OMAP2420
>
>
> Thanks,
> Vaibhav
[Bug 62976] UEFI + SUMO [6550D] freeze after loading radeon
https://bugs.freedesktop.org/show_bug.cgi?id=62976 --- Comment #3 from David Heidelberger --- No, directly from GPT USB: http://wiki.gentoo.org/wiki/UEFI_Gentoo_Quick_Install_Guide -- 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/20130401/e4fa7375/attachment-0001.html>
[Bug 62967] Game Dungeon Defenders crash my whole system.
https://bugs.freedesktop.org/show_bug.cgi?id=62967 --- Comment #2 from Thomas Lindroth --- There is an upstream bug about this problem here. https://bugzilla.icculus.org/show_bug.cgi?id=5895 Seems like it runs fine on the closed drivers. The game freeze for several seconds during the intro as the game does about 6000 calls to glCompileShader. Here is an apitrace of the intro. https://dl.dropbox.com/s/ynibt38hhdlyu1r/DungeonDefenders-x86.trace.bz2 glretrace will segfault while playing it back in r600_dri.so during a call to glDrawRangeElements. I couldn't get a backtrace because of corrupt stack. Playing back the trace with softpipe will not segfault but it will have the drawing errors. Mesa-9.1 and git from a few days ago both got the problem. 3.8.4 kernel, juniper hardware. Option "ColorTiling" "true" Option "ColorTiling2D" "true" Option "SwapbuffersWait" "false" Option "EnablePageFlip" "true" -- 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/20130401/a58d5889/attachment.html>
[Bug 62997] New: GPU fault unless R600_DEBUG=nodma
[70631.916540] radeon :00:01.0: fence driver on ring 2 use gpu addr 0x3c08 and cpu addr 0x880235891c08 [70631.916541] radeon :00:01.0: fence driver on ring 3 use gpu addr 0x3c0c and cpu addr 0x880235891c0c [70631.916543] radeon :00:01.0: fence driver on ring 4 use gpu addr 0x3c10 and cpu addr 0x880235891c10 [70631.935206] [drm] ring test on 0 succeeded in 3 usecs [70631.935264] [drm] ring test on 3 succeeded in 2 usecs [70631.935271] [drm] ring test on 4 succeeded in 1 usecs [70631.949531] [drm] ib test on ring 0 succeeded in 0 usecs [70631.950057] [drm] ib test on ring 3 succeeded in 0 usecs [70631.950576] [drm] ib test on ring 4 succeeded in 1 usecs -- 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/20130401/b6fc6f8d/attachment.html>
[Bug 62997] GPU fault unless R600_DEBUG=nodma
https://bugs.freedesktop.org/show_bug.cgi?id=62997 --- Comment #1 from udo --- Created attachment 77277 --> https://bugs.freedesktop.org/attachment.cgi?id=77277&action=edit Xorg.0.log with R600_DEBUG=nodma -- 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/20130401/f8c51bc9/attachment.html>
[Bug 62997] GPU fault unless R600_DEBUG=nodma
https://bugs.freedesktop.org/show_bug.cgi?id=62997 --- Comment #2 from udo --- Created attachment 77278 --> https://bugs.freedesktop.org/attachment.cgi?id=77278&action=edit dmesg -- 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/20130401/d4cad7f2/attachment.html>
[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=62889 --- Comment #6 from Alexander von Gluck --- Created attachment 77279 --> https://bugs.freedesktop.org/attachment.cgi?id=77279&action=edit software packages attaching related software package versions. A version number means a stable upstream version, a date stamp means that it was a build of the latest git code from that date. -- 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/20130401/09f69986/attachment-0001.html>
[PATCH v3] drm/exynos: enable FIMD clocks
While migrating to common clock framework (CCF), found that the FIMD clocks
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.
By calling clk_prepare_enable() for FIMD clocks fixes the issue.
this patch also replaces clk_disable() with clk_disable_unprepare()
during exit.
Signed-off-by: Vikas Sajjan
---
Changes since v2:
- moved clk_prepare_enable() and clk_disable_unprepare() from
fimd_probe() to fimd_clock() as suggested by Inki Dae
Changes since v1:
- added error checking for clk_prepare_enable() and also replaced
clk_disable() with clk_disable_unprepare() during exit.
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..f2400c8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -799,18 +799,18 @@ static int fimd_clock(struct fimd_context *ctx, bool
enable)
if (enable) {
int ret;
- ret = clk_enable(ctx->bus_clk);
+ ret = clk_prepare_enable(ctx->bus_clk);
if (ret < 0)
return ret;
- ret = clk_enable(ctx->lcd_clk);
+ ret = clk_prepare_enable(ctx->lcd_clk);
if (ret < 0) {
- clk_disable(ctx->bus_clk);
+ clk_disable_unprepare(ctx->bus_clk);
return ret;
}
} else {
- clk_disable(ctx->lcd_clk);
- clk_disable(ctx->bus_clk);
+ clk_disable_unprepare(ctx->lcd_clk);
+ clk_disable_unprepare(ctx->bus_clk);
}
return 0;
@@ -981,8 +981,8 @@ static int fimd_remove(struct platform_device *pdev)
if (ctx->suspended)
goto out;
- clk_disable(ctx->lcd_clk);
- clk_disable(ctx->bus_clk);
+ clk_disable_unprepare(ctx->lcd_clk);
+ clk_disable_unprepare(ctx->bus_clk);
pm_runtime_set_suspended(dev);
pm_runtime_put_sync(dev);
--
1.7.9.5
[PATCH v3] drm/exynos: enable FIMD clocks
On 1 April 2013 14:13, Vikas Sajjan wrote:
> While migrating to common clock framework (CCF), found that the FIMD clocks
s/found/we found/
> were pulled down by the CCF.
> If CCF finds any clock(s) which has NOT been claimed by any of the
> drivers, then such clock(s) are PULLed low by CCF.
>
> By calling clk_prepare_enable() for FIMD clocks fixes the issue.
s/By calling/Calling/
and
s/the/this
> this patch also replaces clk_disable() with clk_disable_unprepare()
s/this/This
> during exit.
Sorry but your log doesn't say what you are doing. You are just adding
relevant calls to clk_prepare/unprepare() before calling clk_enable/disable.
> Signed-off-by: Vikas Sajjan
> ---
> Changes since v2:
> - moved clk_prepare_enable() and clk_disable_unprepare() from
> fimd_probe() to fimd_clock() as suggested by Inki Dae samsung.com>
> Changes since v1:
> - added error checking for clk_prepare_enable() and also replaced
> clk_disable() with clk_disable_unprepare() during exit.
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 9537761..f2400c8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -799,18 +799,18 @@ static int fimd_clock(struct fimd_context *ctx, bool
> enable)
> if (enable) {
> int ret;
>
> - ret = clk_enable(ctx->bus_clk);
> + ret = clk_prepare_enable(ctx->bus_clk);
> if (ret < 0)
> return ret;
>
> - ret = clk_enable(ctx->lcd_clk);
> + ret = clk_prepare_enable(ctx->lcd_clk);
> if (ret < 0) {
> - clk_disable(ctx->bus_clk);
> + clk_disable_unprepare(ctx->bus_clk);
> return ret;
> }
> } else {
> - clk_disable(ctx->lcd_clk);
> - clk_disable(ctx->bus_clk);
> + clk_disable_unprepare(ctx->lcd_clk);
> + clk_disable_unprepare(ctx->bus_clk);
> }
>
> return 0;
> @@ -981,8 +981,8 @@ static int fimd_remove(struct platform_device *pdev)
> if (ctx->suspended)
> goto out;
>
> - clk_disable(ctx->lcd_clk);
> - clk_disable(ctx->bus_clk);
> + clk_disable_unprepare(ctx->lcd_clk);
> + clk_disable_unprepare(ctx->bus_clk);
You are doing things at the right place but i have a suggestion. Are you doing
anything in your clk_prepare() atleast for this device? Probably not.
If not, then its better to call clk_prepare/unprepare only once at probe/remove
and keep clk_enable/disable calls as is.
--
viresh
drm/tilcdc: LCD panels clocks initialization and earlier backlight initialization
> -Original Message-
> From: devicetree-discuss [mailto:devicetree-discuss-
> bounces+hvaibhav=ti.com at lists.ozlabs.org] On Behalf Of Michal Bachraty
> Sent: Thursday, March 28, 2013 11:02 PM
> To: dri-devel at lists.freedesktop.org; devicetree-
> discuss at lists.ozlabs.org
> Cc: robdclark at gmail.com; koen at dominion.thruhere.net
> Subject: drm/tilcdc: LCD panels clocks initialization and earlier
> backlight initialization
>
> Hi,
>
> I'm trying to use tilcdc driver for KWH050TG08 LCD panel connected to
> AM335x
> processor (3.9 rc1 kernel). I have prepared DT bindings for that
> (listed
> bellow). I see fb0 device but I have no clocks going from cpu to LCD.
> My
> clocks for LCD seems not properly to be set ...
>
> virt_2500_ck 1 12500
> sys_clkin_ck8 19 2500
>dpll_disp_ck 0 12500
> dpll_disp_m2_ck 0 12500
> lcd_gclk 0 12500
>
> and tilcdc_crtc is not called. I also set lcd_gclk to 300MHz, but I got
> same
> result. The question is there any way how to properly set clocks for
> LCD?
>
Not sure about the LCDC DRM driver, but I just tested clk_set_rate()
For lcdc_gclk clock and it is working for me. I could able to set
300MHz freq on my BeagleBone platform, with below code -
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index e54a480..443fb26 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -11,6 +11,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -37,6 +38,8 @@ static struct of_device_id omap_dt_match_table[] __initdata =
{
static void __init omap_generic_init(void)
{
+ struct clk *clk;
+
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
@@ -49,6 +52,15 @@ static void __init omap_generic_init(void)
omap4_panda_display_init_of();
else if (of_machine_is_compatible("ti,omap4-sdp"))
omap_4430sdp_display_init_of();
+
+ clk = clk_get(NULL, "lcd_gclk");
+ if (IS_ERR(clk))
+ printk("Can not get lcd_gclk clock\n");
+
+ printk("%s:%d gclk_rate - %lu\n", __func__, __LINE__,
clk_get_rate(clk));
+ clk_set_rate(clk, 3);
+ printk("%s:%d clk_rate - %lu\n", __func__, __LINE__, clk_get_rate(clk));
+ clk_put(clk);
}
#ifdef CONFIG_SOC_OMAP2420
Thanks,
Vaibhav
[PATCH] [drm] exynos: hdmi: Remove fecal color
This patch makes the driver less shitty.
Signed-off-by: Edward Smietana
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 6d63f90..e11372c 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1269,7 +1269,7 @@ static void hdmi_conf_init(struct hdmi_context *hdata)
}
if (hdata->type == HDMI_TYPE13) {
- /* choose bluescreen (fecal) color */
+ /* choose bluescreen (brown) color */
hdmi_reg_writeb(hdata, HDMI_V13_BLUE_SCREEN_0, 0x12);
hdmi_reg_writeb(hdata, HDMI_V13_BLUE_SCREEN_1, 0x34);
hdmi_reg_writeb(hdata, HDMI_V13_BLUE_SCREEN_2, 0x56);
--
1.8.1.5
[PATCH] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1]
On Sun, Mar 31, 2013 at 9:55 PM, Jiri Kosina wrote: > On Thu, 21 Mar 2013, Daniel Vetter wrote: > >> Indeed, this is pretty useful and allowed me to quickly reproduce that >> phantom irq on my gm45. Thanks to module reloading we can even reset the >> kernel's irq disabling logic and so test different tricks quickly without >> rebooting. Really useful. > > Daniel, > > out of curiosity, have you been able to make some sense of the phantom > legacy IRQs on GM45 systems, or are we just staying with my original > bandaid (disabling GMBUS IRQs), declaring GM45 broken in this respect? I've played around with dummy-irq on my own gm45 and afaict every gmbus interrupt generates both an msi and a legacy pci interrupt when msi is enabled. Everything else (= other interrupt sources) seems to work as expected, and disabling msi also papers over the issue. There's also scary comments in our gm45 irq handler that we need msi to paper over some other races. So I've decided that I don't want to dwell any longer in this particular dungeon and that your bandaid (of just disabling this mess) is the real fix. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path
On Sun, 31 Mar 2013, Michal Hocko wrote: > On Sat 30-03-13 18:26:53, Ilija Hadzic wrote: >> This looks a bit like a hack and it doesn't look right, >> conceptually. If the call fails, it should restore things as if >> nothing has ever happened and overwriting old_mapping is not going to >> do the trick. > > OK, I thought this is what the patch does as it falls back to > &inode->i_data which is the default mapping for all inodes or it uses > what used to be in device mapping. > > I am obviously not familiar with the drm code but it feels a bit strange > that the device mapping can be different than inode's resp. file's one The reason for this is explained in commit message associated with 949c4a34. In summary, the device's mapping is that of the inode associated with the first opener. Before 949c4a34, subsequent openers would have to come in through exactly the same inode that the first opener came in (otherwise the open call would fail). So if a user did something like: start X, remove /dev/dri/cardN file, mknod the same file again, the applications started after such an action would stop working. Also, using the GPU from chroot-ed environment was not possible if there was another opener from different root. The 949c4a34, removed this restriction, but introduced a problem with VmWare GPU drivers, which fdb40a08. However, fdb40a08 introduced the bug that you have reported. The problem that I have with your proposed fix is that if the first opener fails, it can set the device's mapping to that of the inode that was never used and never opened (and could even be removed later down the road). > and even more confusing that inode and file are saved separately. > I was trying to quickly get out the patch that was safe in terms of introducing new breakage. So the "conservative" thing to do (without having to think through all possible scenarios) was to restore each of the three pointers from their own temporary variable. Thinking about it, you are probably right that file descriptor's and inode's mapping pointer are equal when open call is entered so we could use one variable. However, you still need a separate variable to store the device's mapping pointer because that one can be different. Attached is a v2 of the patch, for reference. I would appreciate if the original reporter or you tested it in lieu of your proposed patch and let me know if it fixes your issue. -- Ilija -- next part --
[Bug 62226] Build Fails with LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=62226 --- Comment #5 from Niels Ole Salscheider --- The problem seems to be that the build system picks the already installed libllvmradeon9.2.0.so (from /usr/lib64) instead of the one that has just been built. A workaround is to uninstall mesa before compiling and installing the new version. -- 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/20130401/bcbf9ec5/attachment.html>
[Bug 62226] Build Fails with LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=62226 --- Comment #6 from Tom Stellard --- Created attachment 77291 --> https://bugs.freedesktop.org/attachment.cgi?id=77291&action=edit Build libradeonllvm as static library Does this patch help? -- 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/20130401/ea3c1b5f/attachment.html>
[Bug 62226] Build Fails with LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=62226 --- Comment #7 from Serkan Hosca --- (In reply to comment #6) > Created attachment 77291 [details] [review] > Build libradeonllvm as static library > > Does this patch help? Yes, the patch fixes the build -- 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/20130401/06dea384/attachment.html>
[Bug 62226] Build Fails with LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=62226 --- Comment #8 from Johannes Obermayr --- I am against this sort of patches. Because autotools are stupid the second line should be the right attempt: libradeonsi_la_LDFLAGS = -Wl,--no-undefined -shared -avoid-version \ -L../radeon \ $(LLVM_LDFLAGS) -- 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/20130401/88627c7d/attachment.html>
[Bug 62226] Build Fails with LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=62226 --- Comment #9 from Tom Stellard --- (In reply to comment #8) > I am against this sort of patches. > Can you explain why? -- 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/20130401/b6d1150a/attachment.html>
[Bug 62226] Build Fails with LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=62226 Johannes Obermayr changed: What|Removed |Added CC||andreas.boll.dev at gmail.com, ||johannesobermayr at gmx.de --- Comment #10 from Johannes Obermayr --- (In reply to comment #9) > (In reply to comment #8) > > I am against this sort of patches. > > > > Can you explain why? Because you are working against aboll and me - we want to build as much '-shared' as possible (and also distributions [should] want to do so): http://lists.freedesktop.org/archives/mesa-dev/2013-March/036449.html http://lists.freedesktop.org/archives/mesa-dev/2013-March/036493.html Also this statement is wrong: "This library was originally changed to a shared object to work around linker error in egl_static.so, but these appear to be fixed now." It was changed to be built '-shared' because there were and possibly be troubles with crashing egl things if r600 AND radeonsi were built together (see on #dri-devel from mid december 2012 [MrCooper, jobermayr]) You should also see the conditional there. If it makes sense and is required (r600 AND radeonsi) it is shared. If it doesn't (r600 XOR radeonsi) it is static. -- 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/20130401/ac687e49/attachment.html>
[PATCH] drm/tilcdc: Disable building as module
Attempts to compile tilcdc as module results in: drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here make[5]: [drivers/gpu/drm/tilcdc/tilcdc.o] Error 1 (ignored) It appears it was never even tried to build it as module, or the problem would have been seen. So running this driver as module was never really tested. Disable it. If really needed, the code wil require some structural changes and in-depth testing, which can and should be done separately. Cc: Rob Clark Signed-off-by: Guenter Roeck --- drivers/gpu/drm/tilcdc/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig index d24d040..6ddb729 100644 --- a/drivers/gpu/drm/tilcdc/Kconfig +++ b/drivers/gpu/drm/tilcdc/Kconfig @@ -1,5 +1,5 @@ config DRM_TILCDC - tristate "DRM Support for TI LCDC Display Controller" + bool "DRM Support for TI LCDC Display Controller" depends on DRM && OF && ARM select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER -- 1.7.9.7
[Bug 62967] Game Dungeon Defenders crash my whole system.
https://bugs.freedesktop.org/show_bug.cgi?id=62967 Alex Deucher changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|9.0 Component|DRM/Radeon |Drivers/Gallium/r600 --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. Is this a regression? Does a newer version of mesa fix the issue? -- 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/20130401/31e3b473/attachment.html>
[Bug 43276] Screen black after suspending/resuming Toshiba Satellite C675D-S7109 laptop
https://bugzilla.kernel.org/show_bug.cgi?id=43276 Dan Furlani changed: What|Removed |Added Kernel Version|3.4.0-030400rc6-generic |3.9.0-rc4 Summary|Resume fails after |Screen black after |suspending Toshiba |suspending/resuming Toshiba |Satellite C675D-S7109 |Satellite C675D-S7109 |laptop |laptop -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 56031] New: Enabling radeon HDMI audio causes video corruption in unsupported hardware
https://bugzilla.kernel.org/show_bug.cgi?id=56031 Summary: Enabling radeon HDMI audio causes video corruption in unsupported hardware Product: Drivers Version: 2.5 Kernel Version: 3.8 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: darktjm at gmail.com Regression: Yes I changed laptops from an r600 to an aruba, and accidentally left radeon.audio=1 in my kernel parameters. This caused the external screen to be shifted right a bit and a pink stripe on the left. This is due to change f92e70cae880e3540d0c1dddc64825b70f963703 which does not filter out DCE6 (since it is currently unsupported for HDMI) as it should. The patch I have attached adds this restriction, but it might be better if somewhere early in the device initialization radeon_audio were just set to 0 if unsupported. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 62882] Lockup after attempt to enable discrete Radeon GPU on Linux 3.9rc4
https://bugs.freedesktop.org/show_bug.cgi?id=62882 runetmember at gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from runetmember at gmail.com --- Tested with proprietary driver - issues reproducible (GPU not power-up without reboot) so probably problems with hardware or maybe BIOS. -- 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/20130401/167b7d48/attachment.html>
[Bug 56041] New: Disabling LCD on ARUBA causes hotplug loop
https://bugzilla.kernel.org/show_bug.cgi?id=56041 Summary: Disabling LCD on ARUBA causes hotplug loop Product: Drivers Version: 2.5 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: darktjm at gmail.com Regression: No My hardware: a Gateway/Acer laptop with Radeon HD 7640G. Disabling the LCD (xrandr --output eDP --off) while the external display is being used causes some sort of hotplug event loop. 100% of one CPU's worth of CPU time is consumed, and X freezes every few seconds. For now, I have worked around by commenting out "queue_hotplug = true" in evergreen.c (case 0). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 45641] Screen goes black randomly
https://bugs.freedesktop.org/show_bug.cgi?id=45641 --- Comment #18 from John --- I tried the patch today but got another black screen already. I have an 4670 by the way, not sure if the patch was made for that one or not... Thanks -- 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/20130401/14d51018/attachment.html>
[Bug 62976] New: UEFI + SUMO [6550D] freeze after loading radeon
https://bugs.freedesktop.org/show_bug.cgi?id=62976 Priority: medium Bug ID: 62976 Assignee: dri-devel at lists.freedesktop.org Summary: UEFI + SUMO [6550D] freeze after loading radeon Severity: normal Classification: Unclassified OS: Linux (All) Reporter: d.okias at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI HW: Motheboard asus f1a75-v pro, cpu a3870k. Kernel 3.8.5, direct boot from BIOS. EFI framebuffer OK. radeon DRM - nothing displayed, only some strong garbage in center (100% width, 2/3 height). EFI fb + radeon DRM: some messages, freeze on "takeover from EFI" -- 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/20130401/a982decd/attachment.html>
[Bug 62976] UEFI + SUMO [6550D] freeze after loading radeon
https://bugs.freedesktop.org/show_bug.cgi?id=62976 --- Comment #1 from okias --- Created attachment 77262 --> https://bugs.freedesktop.org/attachment.cgi?id=77262&action=edit dmesg_with_EFI_FB.txt -- 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/20130401/970bd268/attachment.html>
