[PATCH] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
Right now hdmiphy operations and configs are kept inside hdmi driver. hdmiphy
related code is tightly coupled with hdmi ip driver. Physicaly they are
different devices and should be instantiated independently.
In terms of versions/mapping/configurations Hdmi and hdmiphy are independent
of each other. It seems logical to isolate them and maintained independently.
This implementations is tested for:
1) Resolutions supported by exynos4 and 5 hdmi.
2) Runtime PM and S2R scenarions for exynos5.
This patch is dependent on the patch, posted at
http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html
v2:
1) Moved hdmi subsystem registration to drm-common-hdmi.
2) removed __func__ as DRM_DEBUG_KMS print it by default.
3) removed devname from "hdmiphy" clock as it needs to be accessed by hdmi
and hdmiphy driver.
Signed-off-by: Rahul Sharma
---
It is based on exynos-drm-next branch at
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
arch/arm/mach-exynos/clock-exynos5.c |1 -
drivers/gpu/drm/exynos/exynos_drm_drv.c | 25 +-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 14 +-
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 109 +-
drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 20 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 372 ++-
drivers/gpu/drm/exynos/exynos_hdmi.h |1 -
drivers/gpu/drm/exynos/exynos_hdmiphy.c | 585 +-
drivers/gpu/drm/exynos/regs-hdmiphy.h| 61
9 files changed, 783 insertions(+), 405 deletions(-)
create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index b0ea31f..4f39027 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -690,7 +690,6 @@ static struct clk exynos5_init_clocks_off[] = {
.ctrlbit= (1 << 6),
}, {
.name = "hdmiphy",
- .devname= "exynos5-hdmi",
.enable = exynos5_clk_hdmiphy_ctrl,
.ctrlbit= (1 << 0),
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 3da5c2d..2ec8ab1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -331,19 +331,9 @@ static int __init exynos_drm_init(void)
#endif
#ifdef CONFIG_DRM_EXYNOS_HDMI
- ret = platform_driver_register(&hdmi_driver);
+ ret = exynos_common_hdmi_register();
if (ret < 0)
goto out_hdmi;
- ret = platform_driver_register(&mixer_driver);
- if (ret < 0)
- goto out_mixer;
- ret = platform_driver_register(&exynos_drm_common_hdmi_driver);
- if (ret < 0)
- goto out_common_hdmi;
-
- ret = exynos_platform_device_hdmi_register();
- if (ret < 0)
- goto out_common_hdmi_dev;
#endif
#ifdef CONFIG_DRM_EXYNOS_VIDI
@@ -430,13 +420,7 @@ out_vidi:
#endif
#ifdef CONFIG_DRM_EXYNOS_HDMI
- exynos_platform_device_hdmi_unregister();
-out_common_hdmi_dev:
- platform_driver_unregister(&exynos_drm_common_hdmi_driver);
-out_common_hdmi:
- platform_driver_unregister(&mixer_driver);
-out_mixer:
- platform_driver_unregister(&hdmi_driver);
+ exynos_common_hdmi_unregister();
out_hdmi:
#endif
@@ -476,10 +460,7 @@ static void __exit exynos_drm_exit(void)
#endif
#ifdef CONFIG_DRM_EXYNOS_HDMI
- exynos_platform_device_hdmi_unregister();
- platform_driver_unregister(&exynos_drm_common_hdmi_driver);
- platform_driver_unregister(&mixer_driver);
- platform_driver_unregister(&hdmi_driver);
+ exynos_common_hdmi_unregister();
#endif
#ifdef CONFIG_DRM_EXYNOS_VIDI
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4606fac..7e6d070 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -319,20 +319,18 @@ int exynos_drm_subdrv_open(struct drm_device *dev, struct
drm_file *file);
void exynos_drm_subdrv_close(struct drm_device *dev, struct drm_file *file);
/*
- * this function registers exynos drm hdmi platform device. It ensures only one
- * instance of the device is created.
+ * this function registers exynos drm hdmi platform driver and singleton
+ * device. It also registers subdrivers like mixer, hdmi and hdmiphy.
*/
-extern int exynos_platform_device_hdmi_register(void);
+extern int exynos_common_hdmi_register(void);
/*
- * this function unregisters exynos drm hdmi platform device if it exists.
+ * this function unregisters exynos drm hdmi platform driver and device,
+ * subdrivers for mixer, hdmi and hdmiphy.
*/
-void exynos_platform_device_hdmi_unregister(void);
+void exynos_common_hdmi_unregister(void);
extern struct platform_driver fimd_driver;
-extern struct platform_driver hdmi_driver;
-exte
[RFC v2] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
Right now hdmiphy operations and configs are kept inside hdmi driver. hdmiphy
related code is tightly coupled with hdmi ip driver. Physicaly they are
different devices and should be instantiated independently.
In terms of versions/mapping/configurations Hdmi and hdmiphy are independent
of each other. It seems logical to isolate them and maintained independently.
v2:
1) Moved hdmi subsystem registration to drm-common-hdmi.
2) removed __func__ as DRM_DEBUG_KMS print it by default.
3) removed devname from "hdmiphy" clock as it needs to be accessed by hdmi
and hdmiphy driver.
This implementations is tested for:
1) Resolutions supported by exynos4 and 5 hdmi.
2) Runtime PM and S2R scenarions for exynos5.
This patch is dependent on the patch, posted at
http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html
Signed-off-by: Rahul Sharma
---
It is based on exynos-drm-next branch at
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
arch/arm/mach-exynos/clock-exynos5.c |1 -
drivers/gpu/drm/exynos/exynos_drm_drv.c | 25 +-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 14 +-
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 109 +-
drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 20 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 372 ++-
drivers/gpu/drm/exynos/exynos_hdmi.h |1 -
drivers/gpu/drm/exynos/exynos_hdmiphy.c | 585 +-
drivers/gpu/drm/exynos/regs-hdmiphy.h| 61
9 files changed, 783 insertions(+), 405 deletions(-)
create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index b0ea31f..4f39027 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -690,7 +690,6 @@ static struct clk exynos5_init_clocks_off[] = {
.ctrlbit= (1 << 6),
}, {
.name = "hdmiphy",
- .devname= "exynos5-hdmi",
.enable = exynos5_clk_hdmiphy_ctrl,
.ctrlbit= (1 << 0),
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 3da5c2d..2ec8ab1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -331,19 +331,9 @@ static int __init exynos_drm_init(void)
#endif
#ifdef CONFIG_DRM_EXYNOS_HDMI
- ret = platform_driver_register(&hdmi_driver);
+ ret = exynos_common_hdmi_register();
if (ret < 0)
goto out_hdmi;
- ret = platform_driver_register(&mixer_driver);
- if (ret < 0)
- goto out_mixer;
- ret = platform_driver_register(&exynos_drm_common_hdmi_driver);
- if (ret < 0)
- goto out_common_hdmi;
-
- ret = exynos_platform_device_hdmi_register();
- if (ret < 0)
- goto out_common_hdmi_dev;
#endif
#ifdef CONFIG_DRM_EXYNOS_VIDI
@@ -430,13 +420,7 @@ out_vidi:
#endif
#ifdef CONFIG_DRM_EXYNOS_HDMI
- exynos_platform_device_hdmi_unregister();
-out_common_hdmi_dev:
- platform_driver_unregister(&exynos_drm_common_hdmi_driver);
-out_common_hdmi:
- platform_driver_unregister(&mixer_driver);
-out_mixer:
- platform_driver_unregister(&hdmi_driver);
+ exynos_common_hdmi_unregister();
out_hdmi:
#endif
@@ -476,10 +460,7 @@ static void __exit exynos_drm_exit(void)
#endif
#ifdef CONFIG_DRM_EXYNOS_HDMI
- exynos_platform_device_hdmi_unregister();
- platform_driver_unregister(&exynos_drm_common_hdmi_driver);
- platform_driver_unregister(&mixer_driver);
- platform_driver_unregister(&hdmi_driver);
+ exynos_common_hdmi_unregister();
#endif
#ifdef CONFIG_DRM_EXYNOS_VIDI
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4606fac..7e6d070 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -319,20 +319,18 @@ int exynos_drm_subdrv_open(struct drm_device *dev, struct
drm_file *file);
void exynos_drm_subdrv_close(struct drm_device *dev, struct drm_file *file);
/*
- * this function registers exynos drm hdmi platform device. It ensures only one
- * instance of the device is created.
+ * this function registers exynos drm hdmi platform driver and singleton
+ * device. It also registers subdrivers like mixer, hdmi and hdmiphy.
*/
-extern int exynos_platform_device_hdmi_register(void);
+extern int exynos_common_hdmi_register(void);
/*
- * this function unregisters exynos drm hdmi platform device if it exists.
+ * this function unregisters exynos drm hdmi platform driver and device,
+ * subdrivers for mixer, hdmi and hdmiphy.
*/
-void exynos_platform_device_hdmi_unregister(void);
+void exynos_common_hdmi_unregister(void);
extern struct platform_driver fimd_driver;
-extern struct platform_driver hdmi_driver;
-exte
[PATCH v2] drm/exynos: hdmi: use drm_display_mode to check the supported modes
Exynos hdmi driver is using drm_display_mode for setting timing values
for a supported resolution. Conversion to fb_videomode and then comparing
with the mixer/hdmi/phy limits is not required. Instead, drm_display_mode
fields cane be directly compared.
v2:
1) Removed convert_to_video_timing().
2) Corrected DRM_DEBUG_KMS to print the resolution properly.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 36 +
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |6 ++---
drivers/gpu/drm/exynos/exynos_hdmi.c | 15 +--
drivers/gpu/drm/exynos/exynos_mixer.c | 13 -
4 files changed, 18 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 8bcc13a..7259fff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -58,37 +58,6 @@ convert_to_display_mode(struct drm_display_mode *mode,
mode->flags |= DRM_MODE_FLAG_DBLSCAN;
}
-/* convert drm_display_mode to exynos_video_timings */
-static inline void
-convert_to_video_timing(struct fb_videomode *timing,
- struct drm_display_mode *mode)
-{
- DRM_DEBUG_KMS("%s\n", __FILE__);
-
- memset(timing, 0, sizeof(*timing));
-
- timing->pixclock = mode->clock * 1000;
- timing->refresh = drm_mode_vrefresh(mode);
-
- timing->xres = mode->hdisplay;
- timing->right_margin = mode->hsync_start - mode->hdisplay;
- timing->hsync_len = mode->hsync_end - mode->hsync_start;
- timing->left_margin = mode->htotal - mode->hsync_end;
-
- timing->yres = mode->vdisplay;
- timing->lower_margin = mode->vsync_start - mode->vdisplay;
- timing->vsync_len = mode->vsync_end - mode->vsync_start;
- timing->upper_margin = mode->vtotal - mode->vsync_end;
-
- if (mode->flags & DRM_MODE_FLAG_INTERLACE)
- timing->vmode = FB_VMODE_INTERLACED;
- else
- timing->vmode = FB_VMODE_NONINTERLACED;
-
- if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
- timing->vmode |= FB_VMODE_DOUBLE;
-}
-
static int exynos_drm_connector_get_modes(struct drm_connector *connector)
{
struct exynos_drm_connector *exynos_connector =
@@ -168,15 +137,12 @@ static int exynos_drm_connector_mode_valid(struct
drm_connector *connector,
to_exynos_connector(connector);
struct exynos_drm_manager *manager = exynos_connector->manager;
struct exynos_drm_display_ops *display_ops = manager->display_ops;
- struct fb_videomode timing;
int ret = MODE_BAD;
DRM_DEBUG_KMS("%s\n", __FILE__);
- convert_to_video_timing(&timing, mode);
-
if (display_ops && display_ops->check_timing)
- if (!display_ops->check_timing(manager->dev, (void *)&timing))
+ if (!display_ops->check_timing(manager->dev, (void *)mode))
ret = MODE_OK;
return ret;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 6b70944..fd2ff9f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -32,11 +32,11 @@ struct exynos_hdmi_ops {
bool (*is_connected)(void *ctx);
struct edid *(*get_edid)(void *ctx,
struct drm_connector *connector);
- int (*check_timing)(void *ctx, struct fb_videomode *timing);
+ int (*check_timing)(void *ctx, struct drm_display_mode *mode);
int (*power_on)(void *ctx, int mode);
/* manager */
- void (*mode_set)(void *ctx, void *mode);
+ void (*mode_set)(void *ctx, struct drm_display_mode *mode);
void (*get_max_resol)(void *ctx, unsigned int *width,
unsigned int *height);
void (*commit)(void *ctx);
@@ -57,7 +57,7 @@ struct exynos_mixer_ops {
void (*win_disable)(void *ctx, int zpos);
/* display */
- int (*check_timing)(void *ctx, struct fb_videomode *timing);
+ int (*check_timing)(void *ctx, struct drm_display_mode *mode);
};
void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx);
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 93b70e9..aeca603 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -796,18 +796,17 @@ static int hdmi_find_phy_conf(struct hdmi_context *hdata,
u32 pixel_clock)
return -EINVAL;
}
-static int hdmi_check_timing(void *ctx, struct fb_videomode *timing)
+static int hdmi_check_timing(void *ctx, struct drm_display_mode *mode)
{
struct hdmi_context *hdata = ctx;
int ret;
- DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
-
- DRM_DEBUG_KMS("[%d]x[%d] [%d]Hz [%x]\n", timing->xres,
-
[PATCH] drm/tegra: Include header drm/drm.h
Include definitions of used types by including drm/drm.h
Sparse output:
/usr/include/drm/tegra_drm.h:21:
found __[us]{8,16,32,64} type without
#include
Signed-off-by: Emil Goode
---
include/uapi/drm/tegra_drm.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index 6e132a2..73bde4e 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -17,6 +17,8 @@
#ifndef _UAPI_TEGRA_DRM_H_
#define _UAPI_TEGRA_DRM_H_
+#include
+
struct drm_tegra_gem_create {
__u64 size;
__u32 flags;
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: fix multiple definition build error
On 04/26/2013 09:42 PM, Tomasz Figa wrote: On Friday 26 of April 2013 11:48:50 Sylwester Nawrocki wrote: On 04/26/2013 10:20 AM, Inki Dae wrote: Exactly right. it's my mistake. But now it seems that __mode_of_device_table is multi defined at fimd and g2d side so there still is module build error. :( Since all drivers seem to be linked into single a single module, you likely need to create a separate table of struct of_device_id just for the purpose of MODULE_DEVICE_TABLE(of, ...). This table would contain 'compatible' strings for all devices. Or choose of_device_id for just one device and define MODULE_DEVICE_TABLE() for it in some common place, e.g. exynos_drm_drv.c. I believe all devices should be listed though. IMHO, the most proper solution would be to split the module into parent exynos_drm module and per-device submodules, which would depend on the parent module. This way you would be able to load dynamically any submodule you want, without recompiling the modules. Yes, this is how it would have been in a perfect world. Probably something worth to consider for the future, it likely implies a lot of work. OTOH if there is one device for which the driver will always be present in the main module it should be enough to make a single entry MODULE_DEVICE_TABLE including its compatible string to ensure the driver is properly loaded, shouldn't it ? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63997] New: Artifacts on the screen using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 Priority: medium Bug ID: 63997 Assignee: dri-devel@lists.freedesktop.org Summary: Artifacts on the screen using a HD7480D on a A4-5300 APU Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mailbox.s...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: Drivers/Gallium/r600 Product: Mesa I'm trying to use a HD7480D on a cpu A4-5300 APU but I get many artifacts on the screen and I get poor performance (with glxgears using the fglrx driver I get at least 7k fps with the radeon driver fps 1k). I've tried using various kernels starting from 3.4.41 to 3.9 rc8, the radeon driver 7.0 7.1 and git and mesa 9.1 and 9.2_20130404. I also tried the following options: Section "Device" Identifier "Radeon" Driver "radeon" Option "EXAPixmaps" "off" Option "AccelDFS" "off" Option "SwapbuffersWait" "off" Option "ColorTiling2D" "off" Option "ColorTiling" "off" EndSection Plus I've done tests ​from various live distributions to be sure that nothing is wrong on my system (getting the same artifacts). Using nomodeset I get no artifacts on the screen but very low performance (glxgear get about 4 fps). Glamor is disabled. -- 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 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 Mirko changed: What|Removed |Added Summary|Artifacts on the screen |Artifacts using a HD7480D |using a HD7480D on a|on a A4-5300 APU |A4-5300 APU | -- 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 57201] New: [vgaswitcheroo] increased consumption and hangups after hibernating with disabled radeon
https://bugzilla.kernel.org/show_bug.cgi?id=57201 Summary: [vgaswitcheroo] increased consumption and hangups after hibernating with disabled radeon Product: Drivers Version: 2.5 Kernel Version: 3.9-rc8-24-gd7d7271 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: nikoa...@gmail.com CC: nikoa...@gmail.com Regression: No Created an attachment (id=100101) --> (https://bugzilla.kernel.org/attachment.cgi?id=100101) lspci -vv (from the older kernel) After hibernation with disabled radeon and resuming, vgaswitcheroo thinks that discrete card is powered down, but in fact it is not. It consumes power, and attemts to disable it again hangups the system. Steps to reproduce: 1. Start system, switch to intel (if needed), disable unused card (echo DDIS and OFF to /sys/kernel/debug/vgaswitcheroo/switch) 2. Check power consumption (for example, with powertop) 3. Hibernate the system, resume 4. Check power consumption again, notice increase If attempting to re-disable card (echo ON and OFF) echo hang-ups after ON. If you SIGINT echo, whole system will hangup. On the older 3.8.8 kernel the behaviour is somewhat different: 1. Echo ON and OFF, the power consumption will go down. 2. Hibernate the system again, resume. 3. Notice power consumption increase again. 4. Echo ON. And system hangups just like with newer kernel. A workaround is to enable card before hibernation and disable it after resuming --- it works in both kernels. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57201] [vgaswitcheroo] increased consumption and hangups after hibernating with disabled radeon
https://bugzilla.kernel.org/show_bug.cgi?id=57201 --- Comment #1 from Nikolay Amiantov 2013-04-27 14:03:36 --- Created an attachment (id=100111) --> (https://bugzilla.kernel.org/attachment.cgi?id=100111) dmesg with failure from 3.9-rc8 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57201] [vgaswitcheroo] increased consumption and hangups after hibernating with disabled radeon
https://bugzilla.kernel.org/show_bug.cgi?id=57201 --- Comment #2 from Nikolay Amiantov 2013-04-27 14:05:32 --- Created an attachment (id=100121) --> (https://bugzilla.kernel.org/attachment.cgi?id=100121) dmesg after rebooting from failure, 3.9-rc8 Also, after rebooting (with magic-sysrq), the ATI card is not avaliable at all (it doesn't exist in lspci). It can be fixed with poweroff-poweron. Attached dmesg log from this state. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57201] [vgaswitcheroo] increased consumption and hangups after hibernating with disabled radeon
https://bugzilla.kernel.org/show_bug.cgi?id=57201 --- Comment #3 from Nikolay Amiantov 2013-04-27 14:06:26 --- Created an attachment (id=100131) --> (https://bugzilla.kernel.org/attachment.cgi?id=100131) dmesg, 3.8.8 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57201] [vgaswitcheroo] increased consumption and hangups after hibernating with disabled radeon
https://bugzilla.kernel.org/show_bug.cgi?id=57201 Nikolay Amiantov changed: What|Removed |Added Attachment #100101|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63632] mesa +r600 llvm = segfault
https://bugs.freedesktop.org/show_bug.cgi?id=63632 Andy Furniss changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Andy Furniss --- Working with current gits now the patches are in. -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #61 from Alexandre Demers --- I compiled drm-next yesterday (which should be found in kernel 3.10 any day now). I've been able to run piglit r600.test without any problem 2 times (just in case, I rebooted beween each). Is there any thing pushed in there that is expected to 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #62 from Alexandre Demers --- (In reply to comment #60) > The first bisect kernel I try gives me youtube videos that are blocks of > gibberish. What to do about that? > > 3.7.1. crashed like previous kernels (showing text boot screen) but no > messages in the log. > So is that the same problem we're seeing and searching for? Well, I would continue bisecting until you find the first problematic commit that crashes your setup. You may be hitting more than a bug, so keep track (commit and results) of what you see in between in case they are not linked to the same bug. -- 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 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #63 from udo --- Currently running 3.6.0-02886-gd9a8074 and that one help up OK so far for 28 hours. How long to continue before declaring this kernel good? Previous bisect kernel 3.6.0-05487-g24d7b40 was found within 24 hours to have crashed in the bootup textmode screen manner. The 3.8.10 comment is interesting as the changelog does not mention radeon. -- 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 57567] 3.7 radeonfb broken on efivga screens
https://bugs.freedesktop.org/show_bug.cgi?id=57567 --- Comment #64 from Alexandre Demers --- Any of the patchs pushed in drm-next? I've been playing with drm-next since yesterday and display is running fine when setting GRUB_GFXPAYLOAD_LINUX=keep at GRUB's launch. -- 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 57567] 3.7 radeonfb broken on efivga screens
https://bugs.freedesktop.org/show_bug.cgi?id=57567 --- Comment #65 from Alex Deucher --- (In reply to comment #64) > Any of the patchs pushed in drm-next? I've been playing with drm-next since > yesterday and display is running fine when setting > GRUB_GFXPAYLOAD_LINUX=keep at GRUB's launch. Yes. -- 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 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output and a picture of the corruption. -- 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 63979] s3tc not working with radeonsi driver
https://bugs.freedesktop.org/show_bug.cgi?id=63979 --- Comment #4 from Alex Deucher --- Grab Dave's drm-next tree: http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next -- 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 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #2 from Mirko --- Created attachment 78561 --> https://bugs.freedesktop.org/attachment.cgi?id=78561&action=edit Artefacts video This is the video with glxgears running -- 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 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #3 from Mirko --- Created attachment 78562 --> https://bugs.freedesktop.org/attachment.cgi?id=78562&action=edit Xorg log -- 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 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #4 from Mirko --- Created attachment 78563 --> https://bugs.freedesktop.org/attachment.cgi?id=78563&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 63865] radeon_atombios_get_power_modes oops with E-350
https://bugs.freedesktop.org/show_bug.cgi?id=63865 --- Comment #7 from Hieu Hoang --- Created attachment 78569 --> https://bugs.freedesktop.org/attachment.cgi?id=78569&action=edit dmesg of patched kernel With the patch, my monitor goes in to stand by right after modesetting (the power LED is ember instead of blue). dmesg attached. -- 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 63979] s3tc not working with radeonsi driver
https://bugs.freedesktop.org/show_bug.cgi?id=63979 --- Comment #2 from Alexander von Gluck --- airlied mentioned enabling colortiling.. no change. I'm using Linux 3.9rc7 + the latest git libdrm + mesa. 3.10 isn't tagged in any way yet... -- 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/20130427/6bfc2c07/attachment.html>
[Bug 63979] s3tc not working with radeonsi driver
https://bugs.freedesktop.org/show_bug.cgi?id=63979 --- Comment #3 from Jerome Glisse --- You need what's gonna be 3.10, ie Alex next tree and set ColorTiling and ColorTiling2D option in xorg.conf -- 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/20130427/e267a459/attachment-0001.html>
[Bug 63997] New: Artifacts on the screen using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 Priority: medium Bug ID: 63997 Assignee: dri-devel at lists.freedesktop.org Summary: Artifacts on the screen using a HD7480D on a A4-5300 APU Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mailbox.stan at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: Drivers/Gallium/r600 Product: Mesa I'm trying to use a HD7480D on a cpu A4-5300 APU but I get many artifacts on the screen and I get poor performance (with glxgears using the fglrx driver I get at least 7k fps with the radeon driver fps 1k). I've tried using various kernels starting from 3.4.41 to 3.9 rc8, the radeon driver 7.0 7.1 and git and mesa 9.1 and 9.2_20130404. I also tried the following options: Section "Device" Identifier "Radeon" Driver "radeon" Option "EXAPixmaps" "off" Option "AccelDFS" "off" Option "SwapbuffersWait" "off" Option "ColorTiling2D" "off" Option "ColorTiling" "off" EndSection Plus I've done tests ?from various live distributions to be sure that nothing is wrong on my system (getting the same artifacts). Using nomodeset I get no artifacts on the screen but very low performance (glxgear get about 4 fps). Glamor is disabled. -- 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/20130427/5ecc1a93/attachment.html>
[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 Mirko changed: What|Removed |Added Summary|Artifacts on the screen |Artifacts using a HD7480D |using a HD7480D on a|on a A4-5300 APU |A4-5300 APU | -- 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/20130427/bd1e3a73/attachment.html>
[Bug 57201] New: [vgaswitcheroo] increased consumption and hangups after hibernating with disabled radeon
https://bugzilla.kernel.org/show_bug.cgi?id=57201 Summary: [vgaswitcheroo] increased consumption and hangups after hibernating with disabled radeon Product: Drivers Version: 2.5 Kernel Version: 3.9-rc8-24-gd7d7271 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: nikoamia at gmail.com CC: nikoamia at gmail.com Regression: No Created an attachment (id=100101) --> (https://bugzilla.kernel.org/attachment.cgi?id=100101) lspci -vv (from the older kernel) After hibernation with disabled radeon and resuming, vgaswitcheroo thinks that discrete card is powered down, but in fact it is not. It consumes power, and attemts to disable it again hangups the system. Steps to reproduce: 1. Start system, switch to intel (if needed), disable unused card (echo DDIS and OFF to /sys/kernel/debug/vgaswitcheroo/switch) 2. Check power consumption (for example, with powertop) 3. Hibernate the system, resume 4. Check power consumption again, notice increase If attempting to re-disable card (echo ON and OFF) echo hang-ups after ON. If you SIGINT echo, whole system will hangup. On the older 3.8.8 kernel the behaviour is somewhat different: 1. Echo ON and OFF, the power consumption will go down. 2. Hibernate the system again, resume. 3. Notice power consumption increase again. 4. Echo ON. And system hangups just like with newer kernel. A workaround is to enable card before hibernation and disable it after resuming --- it works in both kernels. -- 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 57201] [vgaswitcheroo] increased consumption and hangups after hibernating with disabled radeon
https://bugzilla.kernel.org/show_bug.cgi?id=57201 --- Comment #1 from Nikolay Amiantov 2013-04-27 14:03:36 --- Created an attachment (id=100111) --> (https://bugzilla.kernel.org/attachment.cgi?id=100111) dmesg with failure from 3.9-rc8 -- 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 57201] [vgaswitcheroo] increased consumption and hangups after hibernating with disabled radeon
https://bugzilla.kernel.org/show_bug.cgi?id=57201 --- Comment #2 from Nikolay Amiantov 2013-04-27 14:05:32 --- Created an attachment (id=100121) --> (https://bugzilla.kernel.org/attachment.cgi?id=100121) dmesg after rebooting from failure, 3.9-rc8 Also, after rebooting (with magic-sysrq), the ATI card is not avaliable at all (it doesn't exist in lspci). It can be fixed with poweroff-poweron. Attached dmesg log from this state. -- 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 57201] [vgaswitcheroo] increased consumption and hangups after hibernating with disabled radeon
https://bugzilla.kernel.org/show_bug.cgi?id=57201 --- Comment #3 from Nikolay Amiantov 2013-04-27 14:06:26 --- Created an attachment (id=100131) --> (https://bugzilla.kernel.org/attachment.cgi?id=100131) dmesg, 3.8.8 -- 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 57201] [vgaswitcheroo] increased consumption and hangups after hibernating with disabled radeon
https://bugzilla.kernel.org/show_bug.cgi?id=57201 Nikolay Amiantov changed: What|Removed |Added Attachment #100101|application/octet-stream|text/plain mime type|| -- 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 63632] mesa +r600 llvm = segfault
https://bugs.freedesktop.org/show_bug.cgi?id=63632 Andy Furniss changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Andy Furniss --- Working with current gits now the patches are in. -- 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/20130427/1f28f15c/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #61 from Alexandre Demers --- I compiled drm-next yesterday (which should be found in kernel 3.10 any day now). I've been able to run piglit r600.test without any problem 2 times (just in case, I rebooted beween each). Is there any thing pushed in there that is expected to 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/20130427/956b19ed/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #62 from Alexandre Demers --- (In reply to comment #60) > The first bisect kernel I try gives me youtube videos that are blocks of > gibberish. What to do about that? > > 3.7.1. crashed like previous kernels (showing text boot screen) but no > messages in the log. > So is that the same problem we're seeing and searching for? Well, I would continue bisecting until you find the first problematic commit that crashes your setup. You may be hitting more than a bug, so keep track (commit and results) of what you see in between in case they are not linked to the same bug. -- 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/20130427/117199c0/attachment.html>
[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system
https://bugs.freedesktop.org/show_bug.cgi?id=62959 --- Comment #63 from udo --- Currently running 3.6.0-02886-gd9a8074 and that one help up OK so far for 28 hours. How long to continue before declaring this kernel good? Previous bisect kernel 3.6.0-05487-g24d7b40 was found within 24 hours to have crashed in the bootup textmode screen manner. The 3.8.10 comment is interesting as the changelog does not mention radeon. -- 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/20130427/79d4e203/attachment-0001.html>
[Bug 57567] 3.7 radeonfb broken on efivga screens
https://bugs.freedesktop.org/show_bug.cgi?id=57567 --- Comment #64 from Alexandre Demers --- Any of the patchs pushed in drm-next? I've been playing with drm-next since yesterday and display is running fine when setting GRUB_GFXPAYLOAD_LINUX=keep at GRUB's launch. -- 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/20130427/a2acfbdb/attachment.html>
[Bug 57567] 3.7 radeonfb broken on efivga screens
https://bugs.freedesktop.org/show_bug.cgi?id=57567 --- Comment #65 from Alex Deucher --- (In reply to comment #64) > Any of the patchs pushed in drm-next? I've been playing with drm-next since > yesterday and display is running fine when setting > GRUB_GFXPAYLOAD_LINUX=keep at GRUB's launch. Yes. -- 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/20130427/12bdaf07/attachment.html>
[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output and a picture of the corruption. -- 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/20130427/7941620a/attachment.html>
[Bug 63979] s3tc not working with radeonsi driver
https://bugs.freedesktop.org/show_bug.cgi?id=63979 --- Comment #4 from Alex Deucher --- Grab Dave's drm-next tree: http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next -- 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/20130427/a1c46332/attachment.html>
[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #2 from Mirko --- Created attachment 78561 --> https://bugs.freedesktop.org/attachment.cgi?id=78561&action=edit Artefacts video This is the video with glxgears running -- 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/20130427/bf0cadf9/attachment.html>
[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #3 from Mirko --- Created attachment 78562 --> https://bugs.freedesktop.org/attachment.cgi?id=78562&action=edit Xorg log -- 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/20130427/e748894e/attachment.html>
[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #4 from Mirko --- Created attachment 78563 --> https://bugs.freedesktop.org/attachment.cgi?id=78563&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/20130427/b19418fe/attachment.html>
[PATCH] drm/tegra: Include header drm/drm.h
Hi Thierry,
I don't know this code well but the drm/drm.h has an #if def so that
either linux/types.h is included or the __[us]* types are defined in
a different way with the comment "One of the BSDs".
Also I sent a patch last year to include linux/types.h in exynos_drm.h
but it now includes drm/drm.h instead.
Best regards,
Emil Goode
On Fri, Apr 26, 2013 at 09:22:08PM +0200, Thierry Reding wrote:
> On Fri, Apr 26, 2013 at 07:49:51PM +0200, Emil Goode wrote:
> > Include definitions of used types by including drm/drm.h
> >
> > Sparse output:
> > /usr/include/drm/tegra_drm.h:21:
> > found __[us]{8,16,32,64} type without
> > #include
> >
> > Signed-off-by: Emil Goode
> > ---
> > include/uapi/drm/tegra_drm.h |2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
> > index 6e132a2..73bde4e 100644
> > --- a/include/uapi/drm/tegra_drm.h
> > +++ b/include/uapi/drm/tegra_drm.h
> > @@ -17,6 +17,8 @@
> > #ifndef _UAPI_TEGRA_DRM_H_
> > #define _UAPI_TEGRA_DRM_H_
> >
> > +#include
> > +
>
> sparse complains about linux/types.h not being included, so I wonder if
> it makes more sense to include that instead of drm/drm.h. In fact I have
> a fix that does exactly that in a local branch and was going to put that
> into my fixes branch. It's a bit more lightweight.
>
> On the other hand, some drivers already include drm/drm.h in the public
> header so I don't really have any objections to this patch.
>
> Thierry
