[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=63520 --- Comment #6 from PJBrs --- Created attachment 78617 --> https://bugs.freedesktop.org/attachment.cgi?id=78617=edit Last good penumbra output with RADEON_DEBUG=fp,vp -- 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/20130429/78240480/attachment.html>
[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=63520 --- Comment #5 from PJBrs --- Created attachment 78616 --> https://bugs.freedesktop.org/attachment.cgi?id=78616=edit First bad penumbra output with RADEON_DEBUG=fp,vp -- 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/20130429/94125b75/attachment.html>
[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=63520 --- Comment #4 from PJBrs --- I've run the Penumbra Requiem game with RADEON_DEBUG=fp,vp and captured the output. I made two attachments. The file named "Goodlog" is the log with mesa version snb_magic_9030_g342cac7 (commit 342cac71669662abad3435fd13ecf28d073874c3). The file named "badlog" is the output with mesa version snb-magic-9031-g134a0a5 (commit 134a0a5ff88851c971fb95863317f640b5b9fa3a). Let me know if any other information is needed. -- 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/20130429/ea33bf0d/attachment.html>
[PATCH 4/4] ARM: EXYNOS: remove parent device for hdmiphy clock
Hdmiphy clock flows from hdmiphy hw to hdmi ip and mixer. It is commonly
accessed among hdmi and hdmiphy driver. During power cycle, each of these
driver decrements the ref-count and ensures that last user disables the
clock. Setting parrent device to none ensure that both the drivers gets
access to the clock.
Signed-off-by: Rahul Sharma
---
arch/arm/mach-exynos/clock-exynos4.c |1 -
arch/arm/mach-exynos/clock-exynos5.c |1 -
2 files changed, 2 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos4.c
b/arch/arm/mach-exynos/clock-exynos4.c
index 8a8468d..a43afcd 100644
--- a/arch/arm/mach-exynos/clock-exynos4.c
+++ b/arch/arm/mach-exynos/clock-exynos4.c
@@ -562,7 +562,6 @@ static struct clk exynos4_init_clocks_off[] = {
.ctrlbit= (1 << 3),
}, {
.name = "hdmiphy",
- .devname= "exynos4-hdmi",
.enable = exynos4_clk_hdmiphy_ctrl,
.ctrlbit= (1 << 0),
}, {
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),
}, {
--
1.7.10.4
[PATCH 3/4] drm/exynos: hdmi: move hdmiphy callbacks to hdmiphy driver
Hdmiphy callbacks are tighly coupled with hdmi IP callbacks inside
the hdmi driver. With increase in the support of different versions of
hdmiphys, hdmi ip driver expanding with lots of phy related information.
Above movement ensures that phy related code is present and maintained
within the hdmiphy driver.
This also helps in providing clean support for various combinations of hdmi
IPs and hdmiphys through 2 independent set of compatible strings. Earlier
each compatible string represents a combination of hdmi ip and phy. This
forces to use separate compatible string when one of the above block is
changed but the other one is not, which is not proper.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmi.c| 345 +--
drivers/gpu/drm/exynos/exynos_hdmiphy.c | 574 ++-
drivers/gpu/drm/exynos/regs-hdmiphy.h | 61
3 files changed, 645 insertions(+), 335 deletions(-)
create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 520c4af..b03fea9 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -171,7 +171,6 @@ struct hdmi_v14_conf {
};
struct hdmi_conf_regs {
- int pixel_clock;
int cea_video_id;
union {
struct hdmi_v13_conf v13_conf;
@@ -192,7 +191,6 @@ struct hdmi_context {
int irq;
struct i2c_client *ddc_port;
- struct i2c_client *hdmiphy_port;
/* current hdmiphy conf regs */
struct hdmi_conf_regs mode_conf;
@@ -204,180 +202,6 @@ struct hdmi_context {
enum hdmi_type type;
};
-struct hdmiphy_config {
- int pixel_clock;
- u8 conf[32];
-};
-
-/* list of phy config settings */
-static const struct hdmiphy_config hdmiphy_v13_configs[] = {
- {
- .pixel_clock = 2700,
- .conf = {
- 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
- 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
- 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
- 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
- },
- },
- {
- .pixel_clock = 27027000,
- .conf = {
- 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
- 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
- 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
- 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
- },
- },
- {
- .pixel_clock = 74176000,
- .conf = {
- 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef, 0x5B,
- 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3, 0x54, 0xb9,
- 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
- 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00, 0x00, 0x00,
- },
- },
- {
- .pixel_clock = 7425,
- .conf = {
- 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c, 0xf8, 0x40,
- 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1, 0x54, 0xba,
- 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10, 0xe0,
- 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00, 0x00, 0x00,
- },
- },
- {
- .pixel_clock = 14850,
- .conf = {
- 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xf8, 0x40,
- 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1, 0x54, 0xba,
- 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10, 0xE0,
- 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00, 0x00, 0x00,
- },
- },
-};
-
-static const struct hdmiphy_config hdmiphy_v14_configs[] = {
- {
- .pixel_clock = 2520,
- .conf = {
- 0x01, 0x51, 0x2A, 0x75, 0x40, 0x01, 0x00, 0x08,
- 0x82, 0x80, 0xfc, 0xd8, 0x45, 0xa0, 0xac, 0x80,
- 0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
- 0x54, 0xf4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
- },
- },
- {
- .pixel_clock = 2700,
- .conf = {
- 0x01, 0xd1, 0x22, 0x51, 0x40, 0x08, 0xfc, 0x20,
- 0x98, 0xa0, 0xcb, 0xd8, 0x45, 0xa0, 0xac, 0x80,
- 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
- 0x54, 0xe4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
- },
- },
- {
- .pixel_clock = 27027000,
- .conf = {
- 0x01, 0xd1, 0x2d, 0x72, 0x40, 0x64, 0x12, 0x08,
- 0x43, 0xa0, 0x0e, 0xd9, 0x45, 0xa0,
[PATCH 2/4] drm/exynos: hdmi: register hdmiphy driver from common drm hdmi
hdmiphy hardware block is a physically separate device. Hdmiphy driver
is glued inside hdmi driver and acessed through hdmi callbacks. With
increasing diversities in the hdmiphy mapping and configurations, hdmi
driver is expanding with un-related changes.
This patch registers hdmiphy as a independent driver, having own set
of requried callbacks which are called by common drm hdmi, parallel to
hdmi and mixer driver.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 61 +++---
drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 17 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 26 ++---
drivers/gpu/drm/exynos/exynos_hdmi.h |1 -
drivers/gpu/drm/exynos/exynos_hdmiphy.c | 13 ++-
5 files changed, 87 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 7ab5f9f..25fe012 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -32,12 +32,14 @@
/* platform device pointer for common drm hdmi device. */
static struct platform_device *exynos_drm_hdmi_pdev;
-/* Common hdmi subdrv needs to access the hdmi and mixer though context.
-* These should be initialied by the repective drivers */
+/* Common hdmi subdrv needs to access the hdmi, hdmiphy and mixer though
+* context. These should be initialied by the repective drivers */
+static struct exynos_drm_hdmi_context *hdmiphy_ctx;
static struct exynos_drm_hdmi_context *hdmi_ctx;
static struct exynos_drm_hdmi_context *mixer_ctx;
/* these callback points shoud be set by specific drivers. */
+static struct exynos_hdmiphy_ops *hdmiphy_ops;
static struct exynos_hdmi_ops *hdmi_ops;
static struct exynos_mixer_ops *mixer_ops;
@@ -45,6 +47,7 @@ struct platform_driver exynos_drm_common_hdmi_driver;
struct drm_hdmi_context {
struct exynos_drm_subdrvsubdrv;
+ struct exynos_drm_hdmi_context *hdmiphy_ctx;
struct exynos_drm_hdmi_context *hdmi_ctx;
struct exynos_drm_hdmi_context *mixer_ctx;
@@ -59,6 +62,10 @@ int exynos_common_hdmi_register(void)
if (exynos_drm_hdmi_pdev)
return -EEXIST;
+ ret = exynos_hdmiphy_driver_register();
+ if (ret < 0)
+ goto out_hdmiphy;
+
ret = platform_driver_register(_driver);
if (ret < 0)
goto out_hdmi;
@@ -88,6 +95,8 @@ out_common_hdmi:
out_mixer:
platform_driver_unregister(_driver);
out_hdmi:
+ exynos_hdmiphy_driver_unregister();
+out_hdmiphy:
return ret;
}
@@ -99,9 +108,16 @@ void exynos_common_hdmi_unregister(void)
platform_driver_unregister(_drm_common_hdmi_driver);
platform_driver_unregister(_driver);
platform_driver_unregister(_driver);
+ exynos_hdmiphy_driver_unregister();
exynos_drm_hdmi_pdev = NULL;
}
+void exynos_hdmiphy_drv_attach(struct exynos_drm_hdmi_context *ctx)
+{
+ if (ctx)
+ hdmiphy_ctx = ctx;
+}
+
void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx)
{
if (ctx)
@@ -114,6 +130,14 @@ void exynos_mixer_drv_attach(struct
exynos_drm_hdmi_context *ctx)
mixer_ctx = ctx;
}
+void exynos_hdmiphy_ops_register(struct exynos_hdmiphy_ops *ops)
+{
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ if (ops)
+ hdmiphy_ops = ops;
+}
+
void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops)
{
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -164,8 +188,8 @@ static int drm_hdmi_check_mode(struct device *dev,
DRM_DEBUG_KMS("%s\n", __FILE__);
/*
- * Both, mixer and hdmi should be able to handle the requested mode.
- * If any of the two fails, return mode as BAD.
+ * Mixer, hdmi and hdmiphy should be able to handle the requested mode.
+ * If any of the them fails, return mode as BAD.
*/
if (mixer_ops && mixer_ops->check_mode)
@@ -175,7 +199,13 @@ static int drm_hdmi_check_mode(struct device *dev,
return ret;
if (hdmi_ops && hdmi_ops->check_mode)
- return hdmi_ops->check_mode(ctx->hdmi_ctx->ctx, mode);
+ ret = hdmi_ops->check_mode(ctx->hdmi_ctx->ctx, mode);
+
+ if (ret)
+ return ret;
+
+ if (hdmiphy_ops && hdmiphy_ops->check_mode)
+ return hdmiphy_ops->check_mode(ctx->hdmiphy_ctx->ctx, mode);
return 0;
}
@@ -289,6 +319,9 @@ static void drm_hdmi_mode_set(struct device *subdrv_dev,
void *mode)
if (hdmi_ops && hdmi_ops->mode_set)
hdmi_ops->mode_set(ctx->hdmi_ctx->ctx, mode);
+
+ if (hdmiphy_ops && hdmiphy_ops->mode_set)
+ hdmiphy_ops->mode_set(ctx->hdmiphy_ctx->ctx, mode);
}
static void drm_hdmi_get_max_resol(struct device *subdrv_dev,
@@ -308,6 +341,15 @@ static void drm_hdmi_commit(struct device *subdrv_dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
+ if (hdmiphy_ops &&
[PATCH 1/4] drm/exynos: hdmi: move hdmi subsystem registration to drm common hdmi
Exynos hdmi sub-system consists of mixer, hdmi ip, hdmi-phy and hdmi-ddc
components. Currently, drivers for these components are getting registered
in exynos_drm_drv.c, which is meant for registration of drm sub-drivers.
In this patch, registration of drm hdmi sub-driver and device, drivers for
hdmi sub-system components are moved to exynos_drm_hdmi.c. This ensures
limited & relevant exposure of hdmi-sub-system components to exynos_drm_drv.c.
It will also help in handling the hdmi-sub-system diversities within the
exynos-common-hdmi.
Signed-off-by: Rahul Sharma
---
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 | 46 --
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |3 ++
4 files changed, 49 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index ba6d995..4eabb6e 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(_driver);
+ ret = exynos_common_hdmi_register();
if (ret < 0)
goto out_hdmi;
- ret = platform_driver_register(_driver);
- if (ret < 0)
- goto out_mixer;
- ret = platform_driver_register(_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
@@ -436,13 +426,7 @@ out_vidi:
#endif
#ifdef CONFIG_DRM_EXYNOS_HDMI
- exynos_platform_device_hdmi_unregister();
-out_common_hdmi_dev:
- platform_driver_unregister(_drm_common_hdmi_driver);
-out_common_hdmi:
- platform_driver_unregister(_driver);
-out_mixer:
- platform_driver_unregister(_driver);
+ exynos_common_hdmi_unregister();
out_hdmi:
#endif
@@ -483,10 +467,7 @@ static void __exit exynos_drm_exit(void)
#endif
#ifdef CONFIG_DRM_EXYNOS_HDMI
- exynos_platform_device_hdmi_unregister();
- platform_driver_unregister(_drm_common_hdmi_driver);
- platform_driver_unregister(_driver);
- platform_driver_unregister(_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 eaa1966..34aa36d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -319,15 +319,16 @@ 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.
*/
-int exynos_platform_device_hdmi_register(void);
+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);
/*
* this function registers exynos drm ipp platform device.
@@ -340,9 +341,6 @@ int exynos_platform_device_ipp_register(void);
void exynos_platform_device_ipp_unregister(void);
extern struct platform_driver fimd_driver;
-extern struct platform_driver hdmi_driver;
-extern struct platform_driver mixer_driver;
-extern struct platform_driver exynos_drm_common_hdmi_driver;
extern struct platform_driver vidi_driver;
extern struct platform_driver g2d_driver;
extern struct platform_driver fimc_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 060fbe8..7ab5f9f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -41,6 +41,8 @@ static struct exynos_drm_hdmi_context *mixer_ctx;
static struct exynos_hdmi_ops *hdmi_ops;
static struct exynos_mixer_ops *mixer_ops;
+struct platform_driver exynos_drm_common_hdmi_driver;
+
struct drm_hdmi_context {
struct exynos_drm_subdrvsubdrv;
struct exynos_drm_hdmi_context *hdmi_ctx;
@@ -49,29 +51,55 @@ struct drm_hdmi_context {
boolenabled[MIXER_WIN_NR];
};
-int exynos_platform_device_hdmi_register(void)
+int exynos_common_hdmi_register(void)
{
struct platform_device *pdev;
+ int ret;
if (exynos_drm_hdmi_pdev)
return -EEXIST;
+ ret = platform_driver_register(_driver);
+ if (ret
[PATCH 0/4] 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 implementation is tested for: 1) Resolutions supported by exynos4 and 5 hdmi. 2) Runtime PM and S2R scenarions for exynos5. This patch set is dependent on the patch, posted at http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg17905.html This series is based on exynos-drm-next branch at git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git Rahul Sharma (4): drm/exynos: hdmi: move hdmi subsystem registration to drm common hdmi drm/exynos: hdmi: register hdmiphy driver from common drm hdmi drm/exynos: hdmi: move hdmiphy callbacks to hdmiphy driver ARM: EXYNOS: remove parent device for hdmiphy clock arch/arm/mach-exynos/clock-exynos4.c |1 - 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 | 107 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 20 + drivers/gpu/drm/exynos/exynos_hdmi.c | 371 ++- drivers/gpu/drm/exynos/exynos_hdmi.h |1 - drivers/gpu/drm/exynos/exynos_hdmiphy.c | 585 +- drivers/gpu/drm/exynos/regs-hdmiphy.h| 61 10 files changed, 780 insertions(+), 406 deletions(-) create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h -- 1.7.10.4
[PATCH v4] drm/exynos: hdmi: use drm_display_mode to check the supported modes
Hello Rahul,
I looks good to me.
On 2013? 04? 29? 20:14, Rahul Sharma wrote:
> 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.
>
> v4:
> 1) Removed __func__ from DRM_DEBUG_KMS.
>
> v3:
> 1) Replaced check_timing callbacks with check_mode.
> 2) Change the type of second parameter of check_mode callback from void
> pointer paramenter to struct drm_display_mode pointer.
>
> v2:
> 1) Removed convert_to_video_timing().
> 2) Corrected DRM_DEBUG_KMS to print the resolution properly.
>
> Signed-off-by: Rahul Sharma
Acked-by: Seung-Woo Kim
> ---
> drivers/gpu/drm/exynos/exynos_drm_connector.c | 38
> ++---
> drivers/gpu/drm/exynos/exynos_drm_drv.h |4 +--
> drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 +--
> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 17 +--
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h |6 ++--
> drivers/gpu/drm/exynos/exynos_drm_vidi.c |4 +--
> drivers/gpu/drm/exynos/exynos_hdmi.c | 29 +--
> drivers/gpu/drm/exynos/exynos_mixer.c | 17 +--
> 8 files changed, 43 insertions(+), 76 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> index 8bcc13a..ab3c6d4 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(, mode);
> -
> - if (display_ops && display_ops->check_timing)
> - if (!display_ops->check_timing(manager->dev, (void *)))
> + if (display_ops && display_ops->check_mode)
> + if (!display_ops->check_mode(manager->dev, mode))
> ret = MODE_OK;
>
> return ret;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 4606fac..9650b3b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -142,7 +142,7 @@ struct exynos_drm_overlay {
> * @is_connected: check for that display is connected or not.
> * @get_edid: get edid modes from display driver.
> * @get_panel: get panel object from display driver.
> - * @check_timing: check if timing is valid or not.
> + * @check_mode: check if mode is valid or not.
> * @power_on: display device on or off.
> */
> struct exynos_drm_display_ops {
> @@ -151,7 +151,7 @@ struct exynos_drm_display_ops {
> struct edid *(*get_edid)(struct device *dev,
> struct drm_connector *connector);
> void *(*get_panel)(struct device *dev);
> - int (*check_timing)(struct device *dev, void *timing);
> + int (*check_mode)(struct device *dev, struct drm_display_mode *mode);
> int (*power_on)(struct device *dev, int mode);
> };
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index
[PATCH 4/4] ARM: EXYNOS: remove parent device for hdmiphy clock
Hi,
On 04/29/2013 07:04 PM, Sean Paul wrote:
> On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
> wrote:
>> Hdmiphy clock flows from hdmiphy hw to hdmi ip and mixer. It is commonly
>> accessed among hdmi and hdmiphy driver. During power cycle, each of these
>> driver decrements the ref-count and ensures that last user disables the
>> clock. Setting parrent device to none ensure that both the drivers gets
>> access to the clock.
>>
>
> This seems like the wrong solution. I think you should be trying to
> isolate its usage to one driver, instead of removing devname.
And files:
arch/arm/mach-exynos/clock-exynos4.c
arch/arm/mach-exynos/clock-exynos5.c
are not existent in linux-next for some time already. Since 3.10 the
common clock API driver is used. It also shows that very few people
actually test their patches against -next... :(
Regards,
Sylwester
> Sean
>
>> Signed-off-by: Rahul Sharma
>> ---
>> arch/arm/mach-exynos/clock-exynos4.c |1 -
>> arch/arm/mach-exynos/clock-exynos5.c |1 -
>> 2 files changed, 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/clock-exynos4.c
>> b/arch/arm/mach-exynos/clock-exynos4.c
>> index 8a8468d..a43afcd 100644
>> --- a/arch/arm/mach-exynos/clock-exynos4.c
>> +++ b/arch/arm/mach-exynos/clock-exynos4.c
>> @@ -562,7 +562,6 @@ static struct clk exynos4_init_clocks_off[] = {
>> .ctrlbit= (1 << 3),
>> }, {
>> .name = "hdmiphy",
>> - .devname= "exynos4-hdmi",
>> .enable = exynos4_clk_hdmiphy_ctrl,
>> .ctrlbit= (1 << 0),
>> }, {
>> 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),
>> }, {
>> --
>> 1.7.10.4
[PATCH] module: fix mutiple defined issue
> -Original Message- > From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel- > owner at vger.kernel.org] On Behalf Of Russell King - ARM Linux > Sent: Monday, April 29, 2013 6:52 PM > To: Inki Dae > Cc: gregkh at linuxfoundation.org; linux-kernel at vger.kernel.org; dri- > devel at lists.freedesktop.org; linux-arm-kernel at lists.infradead.org > Subject: Re: [PATCH] module: fix mutiple defined issue > > On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote: > > This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE > > > > The issue could be induced when some framework which includes two > > more sub drivers, is built as one moudle because those sub drivers > > could have their own MODULE_DEVICE_TABLE. > > > > And 'struct of_device_id' isn't needed to be determined by type > > argument because the definition of 'of_device_id' should be fixed. > > So this patch makes 'of_devce_id' definition to be fixed and > > only its instance name to be defined by type. > > > > Signed-off-by: Inki Dae > > --- > > include/linux/module.h |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/include/linux/module.h b/include/linux/module.h > > index 46f1ea0..ac5d79f 100644 > > --- a/include/linux/module.h > > +++ b/include/linux/module.h > > @@ -84,7 +84,7 @@ void trim_init_extable(struct module *m); > > > > #ifdef MODULE > > #define MODULE_GENERIC_TABLE(gtype,name) \ > > -extern const struct gtype##_id __mod_##gtype##_table \ > > +extern const struct of_device_id __mod_##gtype##_table \ > >__attribute__ ((unused, alias(__stringify(name > > > > #else /* !MODULE */ > > This patch (a) looks wrong (why would a generic device table be limited > to of_device_id when it could be ISAPNP or something else?) and (b) how > does changing the type fix the "multiple defined issue" ? (c) include > the errors that you're fixing in the commit log. There was my misunderstanding. So please ignore my patch. Some headers in include/linux/ have some kind of device_id structure such as of_device_id, platform_device_id, i2c_device_id, and so on. And these structures should be used properly. This was my missing point. Thanks, Inki Dae > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
to hijack this bug report; just throwing in some extra info that seems related.) - DW -- 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/20130429/918d2ce3/attachment.html>
[PATCH] drm/mgag200: Pass driver specific mga_device in driver functions
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 78d8e91..f988965 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1254,9 +1254,8 @@ static const struct drm_crtc_helper_funcs
mga_helper_funcs = {
};
/* CRTC setup */
-static void mga_crtc_init(struct drm_device *dev)
+static void mga_crtc_init(struct mga_device *mdev)
{
- struct mga_device *mdev = dev->dev_private;
struct mga_crtc *mga_crtc;
int i;
@@ -1267,7 +1266,7 @@ static void mga_crtc_init(struct drm_device *dev)
if (mga_crtc == NULL)
return;
- drm_crtc_init(dev, _crtc->base, _crtc_funcs);
+ drm_crtc_init(mdev->dev, _crtc->base, _crtc_funcs);
drm_mode_crtc_set_gamma_size(_crtc->base, MGAG200_LUT_SIZE);
mdev->mode_info.crtc = mga_crtc;
@@ -1522,7 +1521,7 @@ int mgag200_modeset_init(struct mga_device *mdev)
mdev->dev->mode_config.fb_base = mdev->mc.vram_base;
- mga_crtc_init(mdev->dev);
+ mga_crtc_init(mdev);
encoder = mga_encoder_init(mdev->dev);
if (!encoder) {
--
1.8.1.5
[PATCH] drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_fb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index d2253f6..a5a1f34 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -105,12 +105,9 @@ static int mgag200fb_create_object(struct mga_fbdev
*afbdev,
struct drm_gem_object **gobj_p)
{
struct drm_device *dev = afbdev->helper.dev;
- u32 bpp, depth;
u32 size;
struct drm_gem_object *gobj;
-
int ret = 0;
- drm_fb_get_bpp_depth(mode_cmd->pixel_format, , );
size = mode_cmd->pitches[0] * mode_cmd->height;
ret = mgag200_gem_create(dev, size, true, );
--
1.8.1.5
drm-openchrome status (or will it be in Kernel 3.10?)
Hi James, Linus recently released Kernel 3.9, merge window for Kernel 3.10 has been opened, and the question is whether drm-openchrome will be part of the new Kernel version. Regards, Johannes
[PATCH] drm/radeon: fix UPLL_REF_DIV_MASK definition
Dear Christian, Am Montag, den 29.04.2013, 10:20 +0200 schrieb Christian K?nig: > From: Christian K?nig > > Stupid copy & paste error over all generations. does this fix an error or was this found just by reading the code? Could please you add such information to commit message in the future? That would be awesome. [?] Thanks, Paul
[PATCH] module: fix mutiple defined issue
Hi, > -Original Message- > From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel- > owner at vger.kernel.org] On Behalf Of Uwe Kleine-Konig > Sent: Monday, April 29, 2013 4:35 PM > To: Inki Dae > Cc: gregkh at linuxfoundation.org; linux-kernel at vger.kernel.org; dri- > devel at lists.freedesktop.org; linux-arm-kernel at lists.infradead.org > Subject: Re: [PATCH] module: fix mutiple defined issue > > On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote: > > This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE > s/mutiple/multiple/, still this sentence doesn't sound right. What is > the error message you see? > > > The issue could be induced when some framework which includes two > > more sub drivers, is built as one moudle because those sub drivers > s/moudle/module/ > > > could have their own MODULE_DEVICE_TABLE. > > > > And 'struct of_device_id' isn't needed to be determined by type > > argument because the definition of 'of_device_id' should be fixed. > > So this patch makes 'of_devce_id' definition to be fixed and > > only its instance name to be defined by type. > include/linux/isapnp.h uses: > #define ISAPNP_CARD_TABLE(name) \ > MODULE_GENERIC_TABLE(isapnp_card, name) > > and you changed the table's type with your patch. Ditto for all users of > > MODULE_DEVICE_TABLE(i2c, ...); > MODULE_DEVICE_TABLE(acpi, ...); > MODULE_DEVICE_TABLE(platform, ...); > MODULE_DEVICE_TABLE(pci, ...); > MODULE_DEVICE_TABLE(sdio, ...); > > So I'm pretty sure your patch is wrong and I expect it makes most > defconfigs fail to compile. > It might be my big mistake. Maybe xxx_device_id object was created device tree internally. Right? Will check it out again. So please ignore it. Thanks, Inki Dae > Best regards > Uwe > > > > > Signed-off-by: Inki Dae > > --- > > include/linux/module.h |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/include/linux/module.h b/include/linux/module.h > > index 46f1ea0..ac5d79f 100644 > > --- a/include/linux/module.h > > +++ b/include/linux/module.h > > @@ -84,7 +84,7 @@ void trim_init_extable(struct module *m); > > > > #ifdef MODULE > > #define MODULE_GENERIC_TABLE(gtype,name) \ > > -extern const struct gtype##_id __mod_##gtype##_table \ > > +extern const struct of_device_id __mod_##gtype##_table \ > >__attribute__ ((unused, alias(__stringify(name > > > > #else /* !MODULE */ > > -- > > 1.7.5.4 > > > > > > ___ > > linux-arm-kernel mailing list > > linux-arm-kernel at lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > > -- > Pengutronix e.K. | Uwe Kleine-K?nig| > Industrial Linux Solutions | http://www.pengutronix.de/ | > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] 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.
v4:
1) Removed __func__ from DRM_DEBUG_KMS.
v3:
1) Replaced check_timing callbacks with check_mode.
2) Change the type of second parameter of check_mode callback from void
pointer paramenter to struct drm_display_mode pointer.
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 | 38 ++---
drivers/gpu/drm/exynos/exynos_drm_drv.h |4 +--
drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 +--
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 17 +--
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |6 ++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c |4 +--
drivers/gpu/drm/exynos/exynos_hdmi.c | 29 +--
drivers/gpu/drm/exynos/exynos_mixer.c | 17 +--
8 files changed, 43 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 8bcc13a..ab3c6d4 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(, mode);
-
- if (display_ops && display_ops->check_timing)
- if (!display_ops->check_timing(manager->dev, (void *)))
+ if (display_ops && display_ops->check_mode)
+ if (!display_ops->check_mode(manager->dev, mode))
ret = MODE_OK;
return ret;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4606fac..9650b3b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -142,7 +142,7 @@ struct exynos_drm_overlay {
* @is_connected: check for that display is connected or not.
* @get_edid: get edid modes from display driver.
* @get_panel: get panel object from display driver.
- * @check_timing: check if timing is valid or not.
+ * @check_mode: check if mode is valid or not.
* @power_on: display device on or off.
*/
struct exynos_drm_display_ops {
@@ -151,7 +151,7 @@ struct exynos_drm_display_ops {
struct edid *(*get_edid)(struct device *dev,
struct drm_connector *connector);
void *(*get_panel)(struct device *dev);
- int (*check_timing)(struct device *dev, void *timing);
+ int (*check_mode)(struct device *dev, struct drm_display_mode *mode);
int (*power_on)(struct device *dev, int mode);
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 15e58f5..98bbe1e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -153,7 +153,7 @@ static void *fimd_get_panel(struct device *dev)
return ctx->panel;
}
-static int fimd_check_timing(struct device *dev,
[Bug 63865] radeon_atombios_get_power_modes oops with E-350
https://bugs.freedesktop.org/show_bug.cgi?id=63865 --- Comment #8 from Alex Deucher --- It looks like you are using a bogus unposted vbios image. I think you'll need to bisect. If I had to guess, I'd say it's related to some change in how the pci rom images are fetched. -- 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/20130429/53b7b082/attachment.html>
[PATCH] mgag200 code cleanup patches
Christopher Harvey writes: > I submitted these a while ago, but I think they got lost in the > mailing list. Just wanted to make sure they get a shot at the merge > window. > > thanks, > > Christopher Harvey (3): > drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth > drm/mgag200: Pass driver specific mga_device in driver functions > drm/mgag200: Remove extra variable assigns > > drivers/gpu/drm/mgag200/mgag200_fb.c | 3 --- > drivers/gpu/drm/mgag200/mgag200_main.c | 2 -- > drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++ > 3 files changed, 3 insertions(+), 9 deletions(-) the drm-next branch is what gets merged into merge windows, right? http://cgit.freedesktop.org/~airlied/linux/ --
[Bug 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #3 from Michel D?nzer 2013-04-29 14:41:09 --- (In reply to comment #0) > After upgrading my AMD E-450-based notebook to a newer one (HP 4545s > A4-3300-based) i noticed that in spite of noticeable higher clock rate the > video performance is about 15-20% worse than on E-450. How did you measure that? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] mgag200 code cleanup patches
I submitted these a while ago, but I think they got lost in the mailing list. Just wanted to make sure they get a shot at the merge window. thanks, Christopher Harvey (3): drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth drm/mgag200: Pass driver specific mga_device in driver functions drm/mgag200: Remove extra variable assigns drivers/gpu/drm/mgag200/mgag200_fb.c | 3 --- drivers/gpu/drm/mgag200/mgag200_main.c | 2 -- drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++ 3 files changed, 3 insertions(+), 9 deletions(-) -- 1.8.1.5
[PATCH] module: fix mutiple defined issue
This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE The issue could be induced when some framework which includes two more sub drivers, is built as one moudle because those sub drivers could have their own MODULE_DEVICE_TABLE. And 'struct of_device_id' isn't needed to be determined by type argument because the definition of 'of_device_id' should be fixed. So this patch makes 'of_devce_id' definition to be fixed and only its instance name to be defined by type. Signed-off-by: Inki Dae --- include/linux/module.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/module.h b/include/linux/module.h index 46f1ea0..ac5d79f 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -84,7 +84,7 @@ void trim_init_extable(struct module *m); #ifdef MODULE #define MODULE_GENERIC_TABLE(gtype,name) \ -extern const struct gtype##_id __mod_##gtype##_table \ +extern const struct of_device_id __mod_##gtype##_table \ __attribute__ ((unused, alias(__stringify(name #else /* !MODULE */ -- 1.7.5.4
[Bug 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher 2013-04-29 14:31:27 --- Please attach your dmesg output. -- 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 47351] [KMS: Mobility Radeon HD 6620G] Blank screen on boot
https://bugzilla.kernel.org/show_bug.cgi?id=47351 --- Comment #6 from Alex Deucher 2013-04-29 14:20:38 --- (In reply to comment #5) > I have the same behaviour on my HP 4545s laptop if I try to use discrete video > card (HD7500/7600). I managed to get it work (more or less) on integrated > 7240G, but I get blank screen having tried to switch to discrete video. Can I > provide any additional information to help to resolve the issue? Most hybrid laptops are mux-less meaning there are no displays physically connected to the discrete GPU. For display you have to use the integrated GPU. The discrete GPU can only be used for offscreen rendering. Do display that rendering, it has to be copied to the integrated GPU. There is limited support for this in newer xservers (1.13.x and newer). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[RFC v2] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
Hi Rahul,
2013/4/26 Rahul Sharma
> 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.
>
>
Please separate this patch into 1), 2) and 3) and make it based on
exynos-drm-next.
Thanks,
Inki Dae
> 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 at 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(_driver);
> + ret = exynos_common_hdmi_register();
> if (ret < 0)
> goto out_hdmi;
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto out_mixer;
> - ret = platform_driver_register(_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(_drm_common_hdmi_driver);
> -out_common_hdmi:
> - platform_driver_unregister(_driver);
> -out_mixer:
> - platform_driver_unregister(_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(_drm_common_hdmi_driver);
> - platform_driver_unregister(_driver);
> - platform_driver_unregister(_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
[PATCH v2] drm/exynos: hdmi: use drm_display_mode to check the supported modes
Hello Rahul,
I agree with basic idea of this patch.
However, to avoid confusion, how do you think about fixing all
check_timing as check_mode and its second parameter as mode including
struct exynos_drm_display_ops?
Regards,
- Seung-Woo Kim
On 2013? 04? 26? 23:03, Rahul Sharma wrote:
> 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(, mode);
> -
> if (display_ops && display_ops->check_timing)
> - if (!display_ops->check_timing(manager->dev, (void *)))
> + 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
[Bug 63702] tiling2d in radeon trash vdpau UVD textures
https://bugs.freedesktop.org/show_bug.cgi?id=63702 Christian K?nig changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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/20130429/4df2df41/attachment.html>
[PATCH 4/4] ARM: EXYNOS: remove parent device for hdmiphy clock
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
wrote:
> Hdmiphy clock flows from hdmiphy hw to hdmi ip and mixer. It is commonly
> accessed among hdmi and hdmiphy driver. During power cycle, each of these
> driver decrements the ref-count and ensures that last user disables the
> clock. Setting parrent device to none ensure that both the drivers gets
> access to the clock.
>
This seems like the wrong solution. I think you should be trying to
isolate its usage to one driver, instead of removing devname.
Sean
> Signed-off-by: Rahul Sharma
> ---
> arch/arm/mach-exynos/clock-exynos4.c |1 -
> arch/arm/mach-exynos/clock-exynos5.c |1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/clock-exynos4.c
> b/arch/arm/mach-exynos/clock-exynos4.c
> index 8a8468d..a43afcd 100644
> --- a/arch/arm/mach-exynos/clock-exynos4.c
> +++ b/arch/arm/mach-exynos/clock-exynos4.c
> @@ -562,7 +562,6 @@ static struct clk exynos4_init_clocks_off[] = {
> .ctrlbit= (1 << 3),
> }, {
> .name = "hdmiphy",
> - .devname= "exynos4-hdmi",
> .enable = exynos4_clk_hdmiphy_ctrl,
> .ctrlbit= (1 << 0),
> }, {
> 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),
> }, {
> --
> 1.7.10.4
>
[PATCH 2/4] drm/exynos: hdmi: register hdmiphy driver from common drm hdmi
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
wrote:
> hdmiphy hardware block is a physically separate device. Hdmiphy driver
> is glued inside hdmi driver and acessed through hdmi callbacks. With
> increasing diversities in the hdmiphy mapping and configurations, hdmi
> driver is expanding with un-related changes.
>
> This patch registers hdmiphy as a independent driver, having own set
> of requried callbacks which are called by common drm hdmi, parallel to
> hdmi and mixer driver.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 61
> +++---
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 17 +
> drivers/gpu/drm/exynos/exynos_hdmi.c | 26 ++---
> drivers/gpu/drm/exynos/exynos_hdmi.h |1 -
> drivers/gpu/drm/exynos/exynos_hdmiphy.c | 13 ++-
> 5 files changed, 87 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> index 7ab5f9f..25fe012 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> @@ -32,12 +32,14 @@
> /* platform device pointer for common drm hdmi device. */
> static struct platform_device *exynos_drm_hdmi_pdev;
>
> -/* Common hdmi subdrv needs to access the hdmi and mixer though context.
> -* These should be initialied by the repective drivers */
> +/* Common hdmi subdrv needs to access the hdmi, hdmiphy and mixer though
> +* context. These should be initialied by the repective drivers */
Doesn't conform with Documentation/CodingStyle &
s/initialied/initialized/ & s/repective/respective/
> +static struct exynos_drm_hdmi_context *hdmiphy_ctx;
> static struct exynos_drm_hdmi_context *hdmi_ctx;
> static struct exynos_drm_hdmi_context *mixer_ctx;
>
> /* these callback points shoud be set by specific drivers. */
> +static struct exynos_hdmiphy_ops *hdmiphy_ops;
> static struct exynos_hdmi_ops *hdmi_ops;
> static struct exynos_mixer_ops *mixer_ops;
>
> @@ -45,6 +47,7 @@ struct platform_driver exynos_drm_common_hdmi_driver;
>
> struct drm_hdmi_context {
> struct exynos_drm_subdrvsubdrv;
> + struct exynos_drm_hdmi_context *hdmiphy_ctx;
> struct exynos_drm_hdmi_context *hdmi_ctx;
> struct exynos_drm_hdmi_context *mixer_ctx;
>
> @@ -59,6 +62,10 @@ int exynos_common_hdmi_register(void)
> if (exynos_drm_hdmi_pdev)
> return -EEXIST;
>
> + ret = exynos_hdmiphy_driver_register();
> + if (ret < 0)
> + goto out_hdmiphy;
This isn't consistent with your last patch. In that patch, you exposed
the driver directly through exynos_drm_hdmi.h and registered the
driver directly. Here, you expose a helper function to do it for you.
These should at least work the same way.
> +
> ret = platform_driver_register(_driver);
> if (ret < 0)
> goto out_hdmi;
> @@ -88,6 +95,8 @@ out_common_hdmi:
> out_mixer:
> platform_driver_unregister(_driver);
> out_hdmi:
> + exynos_hdmiphy_driver_unregister();
> +out_hdmiphy:
> return ret;
> }
>
> @@ -99,9 +108,16 @@ void exynos_common_hdmi_unregister(void)
> platform_driver_unregister(_drm_common_hdmi_driver);
> platform_driver_unregister(_driver);
> platform_driver_unregister(_driver);
> + exynos_hdmiphy_driver_unregister();
> exynos_drm_hdmi_pdev = NULL;
> }
>
> +void exynos_hdmiphy_drv_attach(struct exynos_drm_hdmi_context *ctx)
> +{
> + if (ctx)
> + hdmiphy_ctx = ctx;
> +}
> +
I think I've said this before, but in case I haven't, here it goes. If
you didn't platform_driverize all of this stuff, and instead
encapsulated the various functionality in callbacks central to one drm
driver, you wouldn't need to do this kind of thing.
> void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx)
> {
> if (ctx)
> @@ -114,6 +130,14 @@ void exynos_mixer_drv_attach(struct
> exynos_drm_hdmi_context *ctx)
> mixer_ctx = ctx;
> }
>
> +void exynos_hdmiphy_ops_register(struct exynos_hdmiphy_ops *ops)
> +{
> + DRM_DEBUG_KMS("%s\n", __FILE__);
> +
> + if (ops)
> + hdmiphy_ops = ops;
> +}
> +
> void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops)
> {
> DRM_DEBUG_KMS("%s\n", __FILE__);
> @@ -164,8 +188,8 @@ static int drm_hdmi_check_mode(struct device *dev,
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> /*
> - * Both, mixer and hdmi should be able to handle the requested mode.
> - * If any of the two fails, return mode as BAD.
> + * Mixer, hdmi and hdmiphy should be able to handle the requested mode.
> + * If any of the them fails, return mode as BAD.
> */
>
> if (mixer_ops && mixer_ops->check_mode)
> @@ -175,7 +199,13 @@ static int drm_hdmi_check_mode(struct device *dev,
> return ret;
>
> if (hdmi_ops &&
[Bug 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 Nick changed: What|Removed |Added Attachment #100271|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 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 Nick changed: What|Removed |Added Attachment #100261|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 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #1 from Nick 2013-04-29 12:34:50 --- Created an attachment (id=100271) --> (https://bugzilla.kernel.org/attachment.cgi?id=100271) Kernel config -- 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 57281] New: Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 Summary: Radeon: Bad performance and power consumption Product: Drivers Version: 2.5 Kernel Version: 3.8.2-pf 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: ka.nick at mail.ru Regression: No Created an attachment (id=100261) --> (https://bugzilla.kernel.org/attachment.cgi?id=100261) lspci -vv output After upgrading my AMD E-450-based notebook to a newer one (HP 4545s A4-3300-based) i noticed that in spite of noticeable higher clock rate the video performance is about 15-20% worse than on E-450. It also got much hotter initially, which I could cure by passing pcie_aspm=force to the kernel. In spite of this I still have a feeling that it probably eats more power than it should (which I can not prove with numbers, of course) comparing to E-450 (and fglrx) experience. (Yes, I know the proprietary driver performs better in terms of power management, too, but the question is to what extent?) Anyways, it shouldn't underperform the older and weaker model... It also shows the message at boot time: [drm:radeon_acpi_init] *ERROR* Cannot find backlight controller but it seems to work fine after that. (Shall I post another bug on this?) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH 1/2] drm/exynos: exynos_drm_fbdev: Fix incorrect usage of IS_ERR_OR_NULL
exynos_drm_framebuffer_init() does not return NULL. Use IS_ERR instead.
Signed-off-by: Sachin Kamat
---
This series is based on exynos-drm-next branch of Inki Dae's tree:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 68f0045..8f007aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -182,7 +182,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
*helper,
helper->fb = exynos_drm_framebuffer_init(dev, _cmd,
_gem_obj->base);
- if (IS_ERR_OR_NULL(helper->fb)) {
+ if (IS_ERR(helper->fb)) {
DRM_ERROR("failed to create drm framebuffer.\n");
ret = PTR_ERR(helper->fb);
goto err_destroy_gem;
--
1.7.9.5
[PATCH v4] drm/exynos: hdmi: use drm_display_mode to check the supported modes
On Mon, Apr 29, 2013 at 7:14 AM, Rahul Sharma
wrote:
> 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.
>
it seems like you have 2 patches here, one which renames check_timing
to check_mode, and another which removes the fb_videomode usage. I
think it should probably be split.
If you don't split it, I think you could simplify the commit message to:
This patch renames check_timing to check_mode and removes the
unnecessary conversion of drm_display_mode to/from fb_videomode in the
hdmi driver.
> v4:
> 1) Removed __func__ from DRM_DEBUG_KMS.
>
> v3:
> 1) Replaced check_timing callbacks with check_mode.
> 2) Change the type of second parameter of check_mode callback from void
> pointer paramenter to struct drm_display_mode pointer.
>
> 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 | 38
> ++---
> drivers/gpu/drm/exynos/exynos_drm_drv.h |4 +--
> drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 +--
> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 17 +--
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h |6 ++--
> drivers/gpu/drm/exynos/exynos_drm_vidi.c |4 +--
> drivers/gpu/drm/exynos/exynos_hdmi.c | 29 +--
> drivers/gpu/drm/exynos/exynos_mixer.c | 17 +--
> 8 files changed, 43 insertions(+), 76 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> index 8bcc13a..ab3c6d4 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(, mode);
> -
> - if (display_ops && display_ops->check_timing)
> - if (!display_ops->check_timing(manager->dev, (void *)))
> + if (display_ops && display_ops->check_mode)
> + if (!display_ops->check_mode(manager->dev, mode))
> ret = MODE_OK;
>
> return ret;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 4606fac..9650b3b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -142,7 +142,7 @@ struct exynos_drm_overlay {
> * @is_connected: check for that display is connected or not.
> * @get_edid: get edid modes from display driver.
> * @get_panel: get panel object from display driver.
> - * @check_timing: check if timing is valid or not.
> + * @check_mode: check if mode is valid or not.
> * @power_on: display device on or off.
> */
> struct exynos_drm_display_ops {
> @@ -151,7 +151,7 @@ struct exynos_drm_display_ops {
> struct edid *(*get_edid)(struct device *dev,
>
[Bug 47351] [KMS: Mobility Radeon HD 6620G] Blank screen on boot
https://bugzilla.kernel.org/show_bug.cgi?id=47351 --- Comment #5 from Nick 2013-04-29 12:01:07 --- Created an attachment (id=100251) --> (https://bugzilla.kernel.org/attachment.cgi?id=100251) lspci -vv output I have the same behaviour on my HP 4545s laptop if I try to use discrete video card (HD7500/7600). I managed to get it work (more or less) on integrated 7240G, but I get blank screen having tried to switch to discrete video. Can I provide any additional information to help to resolve the issue? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[RFC v2] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
On Mon, Apr 29, 2013 at 10:22 AM, Inki Dae wrote:
>
> Hi Rahul,
>
>
> 2013/4/26 Rahul Sharma
>>
>> 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.
>>
>
> Please separate this patch into 1), 2) and 3) and make it based on
exynos-drm-next.
>
Sure Mr. Dae,
I will post the series.
Regards,
Rahul Sharma.
> Thanks,
> Inki Dae
>
>
>
>>
>> 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 at 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(_driver);
>> + ret = exynos_common_hdmi_register();
>> if (ret < 0)
>> goto out_hdmi;
>> - ret = platform_driver_register(_driver);
>> - if (ret < 0)
>> - goto out_mixer;
>> - ret = platform_driver_register(_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(_drm_common_hdmi_driver);
>> -out_common_hdmi:
>> - platform_driver_unregister(_driver);
>> -out_mixer:
>> - platform_driver_unregister(_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(_drm_common_hdmi_driver);
>> - platform_driver_unregister(_driver);
>> - platform_driver_unregister(_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
[RFC][PATCH] drm/prime: fixed to allocate sg table considering contiguous pages
Hello Rahul,
Thanks for notifying.
As your comment, it is same patch with yours, so just ignore my patch.
Besg Regards,
- Seung-Woo Kim
On 2013? 04? 26? 18:14, Rahul Sharma wrote:
> Hi Seung Woo,
>
> I had posted the same solution at
> http://lists.freedesktop.org/archives/dri-devel/2013-January/034119.html.
> This has been pulled in drm-intel-next.
>
> regards,
> Rahul Sharma.
>
>
>
> On Fri, Apr 26, 2013 at 2:18 PM, Seung-Woo Kim samsung.com>wrote:
>
>> Allocating scatter table with sg_alloc_table() does not consider
>> contiguous pages. Because sg_alloc_table_from_pages() merges
>> contigous pages into a signle scatter entry, this patch fixes to
>> allocate scatter table with it from drm_prime_pages_to_sg().
>>
>> Signed-off-by: Seung-Woo Kim
>> ---
>> drivers/gpu/drm/drm_prime.c |8 ++--
>> 1 files changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
>> index 366910d..8c098a3 100644
>> --- a/drivers/gpu/drm/drm_prime.c
>> +++ b/drivers/gpu/drm/drm_prime.c
>> @@ -401,21 +401,17 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device
>> *dev, void *data,
>> struct sg_table *drm_prime_pages_to_sg(struct page **pages, int nr_pages)
>> {
>> struct sg_table *sg = NULL;
>> - struct scatterlist *iter;
>> - int i;
>> int ret;
>>
>> sg = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
>> if (!sg)
>> goto out;
>>
>> - ret = sg_alloc_table(sg, nr_pages, GFP_KERNEL);
>> + ret = sg_alloc_table_from_pages(sg, pages, nr_pages,
>> + 0, PAGE_SIZE * nr_pages, GFP_KERNEL);
>> if (ret)
>> goto out;
>>
>> - for_each_sg(sg->sgl, iter, nr_pages, i)
>> - sg_set_page(iter, pages[i], PAGE_SIZE, 0);
>> -
>> return sg;
>> out:
>> kfree(sg);
>> --
>> 1.7.4.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
>
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Seung-Woo Kim
Samsung Software R Center
--
[PATCH v2] drm/exynos: hdmi: use drm_display_mode to check the supported modes
,
> > 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,
> > - timing->yres, timing->refresh,
> > - timing->vmode);
> > + DRM_DEBUG_KMS("[WxH at HzI/P at Pixel Clk]: %dx%d@%d%s at %d\n",
> > + mode->hdisplay, mode->vdisplay, mode->vrefresh,
> > + (mode->flags & DRM_MODE_FLAG_INTERLACE) ? "I" : "P",
> > + mode->clock * 1000);
> >
> > - ret = hdmi_find_phy_conf(hdata, timing->pixclock);
> > + ret = hdmi_find_phy_conf(hdata, mode->clock * 1000);
> > if (ret < 0)
> > return ret;
> > return 0;
> > @@ -1643,7 +1642,7 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> > hdmi_set_reg(tg->tg_3d, 1, 0x0);
> > }
> >
> > -static void hdmi_mode_set(void *ctx, void *mode)
> > +static void hdmi_mode_set(void *ctx, struct drm_display_mode *mode)
> > {
> > struct hdmi_context *hdata = ctx;
> > struct drm_display_mode *m = mode;
> > diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> > index f08e251..67c4fd8 100644
> > --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> > +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> > @@ -818,17 +818,17 @@ static void mixer_win_disable(void *ctx, int win)
> > mixer_ctx->win_data[win].enabled = false;
> > }
> >
> > -static int mixer_check_timing(void *ctx, struct fb_videomode *timing)
> > +static int mixer_check_timing(void *ctx, struct drm_display_mode *mode)
> > {
> > u32 w, h;
> >
> > - w = timing->xres;
> > - h = timing->yres;
> > + w = mode->hdisplay;
> > + h = mode->vdisplay;
> >
> > DRM_DEBUG_KMS("%s : xres=%d, yres=%d, refresh=%d, intl=%d\n",
> > - __func__, timing->xres, timing->yres,
> > - timing->refresh, (timing->vmode &
> > - FB_VMODE_INTERLACED) ? true : false);
> > + __func__, mode->hdisplay, mode->vdisplay,
> > + mode->vrefresh, (mode->flags &
> > + DRM_MODE_FLAG_INTERLACE) ? true : false);
> >
> > if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
> > (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
> > @@ -837,6 +837,7 @@ static int mixer_check_timing(void *ctx, struct
> fb_videomode *timing)
> >
> > return -EINVAL;
> > }
> > +
> > static void mixer_wait_for_vblank(void *ctx)
> > {
> > struct mixer_context *mixer_ctx = ctx;
> >
>
> --
> Seung-Woo Kim
> Samsung Software R Center
> --
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130429/3ab62fba/attachment-0001.html>
radeon pm questions
On Sun, Apr 28, 2013 at 9:26 PM, Sylvain BERTRAND wrote: > Hi, > > I have a few questions about radeon pm code: > > > In radeon_atombios.c, radeon_atombios_parse_power_table_6 > function, power_state->v2.nonClockInfoIndex for non_clock_info of > one state is ignored and replaced by the state index, referencing > an iguana bug. > > Is it still buggy from southern island and we must keep ignoring > power_state->v2.nonClockInfoIndex for good and use the state > index to reference the right state description in non clock array > table? nonClockInfoIndex isn't used and produces bogus tables. The index should be used. > > > > The same does happen for the clock info index which can be out of > range. Same treat as above? Yes, although, at this point, it's mostly for safety. You shouldn't see it in practice. > > > > In radeon_atombios.c, radeon_atombios_parse_pplib_clock_info > function, code paths are selected based on DCE generation. The > same happens in radeon_atombios_parse_pplib_non_clock_info > function. Should it rather be the chip family? Or current > powerplay code does deal only with the DCE block?? It should be chip family. I just used the DCE check since it corresponds to the same relevant families. I'll fix that. Alex > > > regards, > > -- > Sylvain > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] module: fix mutiple defined issue
On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote: > This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE > > The issue could be induced when some framework which includes two > more sub drivers, is built as one moudle because those sub drivers > could have their own MODULE_DEVICE_TABLE. > > And 'struct of_device_id' isn't needed to be determined by type > argument because the definition of 'of_device_id' should be fixed. > So this patch makes 'of_devce_id' definition to be fixed and > only its instance name to be defined by type. > > Signed-off-by: Inki Dae > --- > include/linux/module.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/linux/module.h b/include/linux/module.h > index 46f1ea0..ac5d79f 100644 > --- a/include/linux/module.h > +++ b/include/linux/module.h > @@ -84,7 +84,7 @@ void trim_init_extable(struct module *m); > > #ifdef MODULE > #define MODULE_GENERIC_TABLE(gtype,name) \ > -extern const struct gtype##_id __mod_##gtype##_table \ > +extern const struct of_device_id __mod_##gtype##_table \ >__attribute__ ((unused, alias(__stringify(name > > #else /* !MODULE */ This patch (a) looks wrong (why would a generic device table be limited to of_device_id when it could be ISAPNP or something else?) and (b) how does changing the type fix the "multiple defined issue" ? (c) include the errors that you're fixing in the commit log.
[PATCH] drm/radeon: consolidate UVD clock programming
On Mon, Apr 29, 2013 at 5:55 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Instead of duplicating the code over and over again, just use a single
> function to handle the clock calculations.
Applied to by tree.
Alex
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/evergreen.c | 103 +++---
> drivers/gpu/drm/radeon/r600d.h |4 +
> drivers/gpu/drm/radeon/radeon.h | 11 +++
> drivers/gpu/drm/radeon/radeon_uvd.c | 137
> +++
> drivers/gpu/drm/radeon/rv770.c | 110 +---
> drivers/gpu/drm/radeon/si.c | 104 +++---
> 6 files changed, 191 insertions(+), 278 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index 1531f16..105bafb 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -989,62 +989,10 @@ done:
> return r;
> }
>
> -static int evergreen_uvd_calc_post_div(unsigned target_freq,
> - unsigned vco_freq,
> - unsigned *div)
> -{
> - /* target larger than vco frequency ? */
> - if (vco_freq < target_freq)
> - return -1; /* forget it */
> -
> - /* Fclk = Fvco / PDIV */
> - *div = vco_freq / target_freq;
> -
> - /* we alway need a frequency less than or equal the target */
> - if ((vco_freq / *div) > target_freq)
> - *div += 1;
> -
> - /* dividers above 5 must be even */
> - if (*div > 5 && *div % 2)
> - *div += 1;
> -
> - /* out of range ? */
> - if (*div >= 128)
> - return -1; /* forget it */
> -
> - return vco_freq / *div;
> -}
> -
> -static int evergreen_uvd_send_upll_ctlreq(struct radeon_device *rdev)
> -{
> - unsigned i;
> -
> - /* assert UPLL_CTLREQ */
> - WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_CTLREQ_MASK, ~UPLL_CTLREQ_MASK);
> -
> - /* wait for CTLACK and CTLACK2 to get asserted */
> - for (i = 0; i < 100; ++i) {
> - uint32_t mask = UPLL_CTLACK_MASK | UPLL_CTLACK2_MASK;
> - if ((RREG32(CG_UPLL_FUNC_CNTL) & mask) == mask)
> - break;
> - mdelay(10);
> - }
> - if (i == 100)
> - return -ETIMEDOUT;
> -
> - /* deassert UPLL_CTLREQ */
> - WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~UPLL_CTLREQ_MASK);
> -
> - return 0;
> -}
> -
> int evergreen_set_uvd_clocks(struct radeon_device *rdev, u32 vclk, u32 dclk)
> {
> /* start off with something large */
> - int optimal_diff_score = 0x7FF;
> - unsigned optimal_fb_div = 0, optimal_vclk_div = 0;
> - unsigned optimal_dclk_div = 0, optimal_vco_freq = 0;
> - unsigned vco_freq;
> + unsigned fb_div = 0, vclk_div = 0, dclk_div = 0;
> int r;
>
> /* bypass vclk and dclk with bclk */
> @@ -1061,40 +1009,11 @@ int evergreen_set_uvd_clocks(struct radeon_device
> *rdev, u32 vclk, u32 dclk)
> return 0;
> }
>
> - /* loop through vco from low to high */
> - for (vco_freq = 125000; vco_freq <= 25; vco_freq += 100) {
> - unsigned fb_div = vco_freq / rdev->clock.spll.reference_freq
> * 16384;
> - int calc_clk, diff_score, diff_vclk, diff_dclk;
> - unsigned vclk_div, dclk_div;
> -
> - /* fb div out of range ? */
> - if (fb_div > 0x03FF)
> - break; /* it can oly get worse */
> -
> - /* calc vclk with current vco freq. */
> - calc_clk = evergreen_uvd_calc_post_div(vclk, vco_freq,
> _div);
> - if (calc_clk == -1)
> - break; /* vco is too big, it has to stop. */
> - diff_vclk = vclk - calc_clk;
> -
> - /* calc dclk with current vco freq. */
> - calc_clk = evergreen_uvd_calc_post_div(dclk, vco_freq,
> _div);
> - if (calc_clk == -1)
> - break; /* vco is too big, it has to stop. */
> - diff_dclk = dclk - calc_clk;
> -
> - /* determine if this vco setting is better than current
> optimal settings */
> - diff_score = abs(diff_vclk) + abs(diff_dclk);
> - if (diff_score < optimal_diff_score) {
> - optimal_fb_div = fb_div;
> - optimal_vclk_div = vclk_div;
> - optimal_dclk_div = dclk_div;
> - optimal_vco_freq = vco_freq;
> - optimal_diff_score = diff_score;
> - if (optimal_diff_score == 0)
> - break; /* it can't get better than this */
> - }
> - }
> + r = radeon_uvd_calc_upll_dividers(rdev, vclk, dclk, 125000, 25,
> +
[PATCH] drm/radeon: fix UPLL_REF_DIV_MASK definition
On Mon, Apr 29, 2013 at 4:20 AM, Christian K?nig wrote: > From: Christian K?nig > > Stupid copy & paste error over all generations. Applied to my tree. Alex > > Signed-off-by: Christian K?nig > --- > drivers/gpu/drm/radeon/evergreend.h |2 +- > drivers/gpu/drm/radeon/rv770d.h |2 +- > drivers/gpu/drm/radeon/sid.h|2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/evergreend.h > b/drivers/gpu/drm/radeon/evergreend.h > index d9a0054..75c0563 100644 > --- a/drivers/gpu/drm/radeon/evergreend.h > +++ b/drivers/gpu/drm/radeon/evergreend.h > @@ -59,7 +59,7 @@ > # define UPLL_SLEEP_MASK 0x0002 > # define UPLL_BYPASS_EN_MASK 0x0004 > # define UPLL_CTLREQ_MASK 0x0008 > -# define UPLL_REF_DIV_MASK0x001F > +# define UPLL_REF_DIV_MASK0x003F > # define UPLL_VCO_MODE_MASK 0x0200 > # define UPLL_CTLACK_MASK 0x4000 > # define UPLL_CTLACK2_MASK0x8000 > diff --git a/drivers/gpu/drm/radeon/rv770d.h b/drivers/gpu/drm/radeon/rv770d.h > index 6a52b20..85b1626 100644 > --- a/drivers/gpu/drm/radeon/rv770d.h > +++ b/drivers/gpu/drm/radeon/rv770d.h > @@ -45,7 +45,7 @@ > # define UPLL_BYPASS_EN_MASK 0x0004 > # define UPLL_CTLREQ_MASK 0x0008 > # define UPLL_REF_DIV(x) ((x) << 16) > -# define UPLL_REF_DIV_MASK0x001F > +# define UPLL_REF_DIV_MASK0x003F > # define UPLL_CTLACK_MASK 0x4000 > # define UPLL_CTLACK2_MASK0x8000 > #define CG_UPLL_FUNC_CNTL_20x71c > diff --git a/drivers/gpu/drm/radeon/sid.h b/drivers/gpu/drm/radeon/sid.h > index 042b91d..222877b 100644 > --- a/drivers/gpu/drm/radeon/sid.h > +++ b/drivers/gpu/drm/radeon/sid.h > @@ -36,7 +36,7 @@ > # define UPLL_BYPASS_EN_MASK 0x0004 > # define UPLL_CTLREQ_MASK 0x0008 > # define UPLL_VCO_MODE_MASK 0x0600 > -# define UPLL_REF_DIV_MASK0x001F > +# define UPLL_REF_DIV_MASK0x003F > # define UPLL_CTLACK_MASK 0x4000 > # define UPLL_CTLACK2_MASK0x8000 > #defineCG_UPLL_FUNC_CNTL_2 0x638 > -- > 1.7.10.4 >
[PATCH] module: fix mutiple defined issue
On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote: > This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE s/mutiple/multiple/, still this sentence doesn't sound right. What is the error message you see? > The issue could be induced when some framework which includes two > more sub drivers, is built as one moudle because those sub drivers s/moudle/module/ > could have their own MODULE_DEVICE_TABLE. > > And 'struct of_device_id' isn't needed to be determined by type > argument because the definition of 'of_device_id' should be fixed. > So this patch makes 'of_devce_id' definition to be fixed and > only its instance name to be defined by type. include/linux/isapnp.h uses: #define ISAPNP_CARD_TABLE(name) \ MODULE_GENERIC_TABLE(isapnp_card, name) and you changed the table's type with your patch. Ditto for all users of MODULE_DEVICE_TABLE(i2c, ...); MODULE_DEVICE_TABLE(acpi, ...); MODULE_DEVICE_TABLE(platform, ...); MODULE_DEVICE_TABLE(pci, ...); MODULE_DEVICE_TABLE(sdio, ...); So I'm pretty sure your patch is wrong and I expect it makes most defconfigs fail to compile. Best regards Uwe > > Signed-off-by: Inki Dae > --- > include/linux/module.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/linux/module.h b/include/linux/module.h > index 46f1ea0..ac5d79f 100644 > --- a/include/linux/module.h > +++ b/include/linux/module.h > @@ -84,7 +84,7 @@ void trim_init_extable(struct module *m); > > #ifdef MODULE > #define MODULE_GENERIC_TABLE(gtype,name) \ > -extern const struct gtype##_id __mod_##gtype##_table \ > +extern const struct of_device_id __mod_##gtype##_table \ >__attribute__ ((unused, alias(__stringify(name > > #else /* !MODULE */ > -- > 1.7.5.4 > > > ___ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- Pengutronix e.K. | Uwe Kleine-K?nig| Industrial Linux Solutions | http://www.pengutronix.de/ |
[PULL] drm-intel-fixes for 3.10
Hi Dave, Just a few important fixes for 3.10. 3 regression fixes, plus rectified Haswell overclock support (the old code was correct, only docs confusing) and improved DP data m/n selection. Cheers, Daniel The following changes since commit bd080ee57c2173cefdcadc39c7863a76c249d049: drm/i915: fix bpc vs. bpp confusion in intel_crtc_compute_config (2013-04-18 09:43:33 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to 43b27290dd42b40f3f23f49677a7faa5a4eb1eff: drm/i915: correct the calculation of first_pd_entry_in_global_pt (2013-04-27 14:07:16 +0200) Ben Widawsky (1): Revert "drm/i915: Don't overclock on Haswell" Daniel Vetter (1): drm/i915: avoid full modeset when changing the color range properties David M?ller (ELSOFT AG) (1): drm/i915: Fall back to bit banging mode for DVO transmitter detection Ville Syrj?l? (1): drm/i915: Make data/link N value power of two Zhang, Xiong Y (1): drm/i915: correct the calculation of first_pd_entry_in_global_pt drivers/gpu/drm/i915/i915_gem_gtt.c |3 +-- drivers/gpu/drm/i915/i915_reg.h | 12 drivers/gpu/drm/i915/intel_display.c | 26 ++ drivers/gpu/drm/i915/intel_dp.c |8 drivers/gpu/drm/i915/intel_dvo.c | 13 - drivers/gpu/drm/i915/intel_hdmi.c|8 drivers/gpu/drm/i915/intel_pm.c |2 +- drivers/gpu/drm/i915/intel_sdvo.c|8 8 files changed, 60 insertions(+), 20 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=62889 --- Comment #20 from Michel D?nzer --- Are the 32-bit drivers used by Steam up to 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/20130429/65dbe621/attachment-0001.html>
[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=62889 Michel D?nzer changed: What|Removed |Added Attachment #78533|text/plain |image/png mime type|| -- 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/20130429/e566204f/attachment.html>
radeon pm questions
Hi, I have a few questions about radeon pm code: In radeon_atombios.c, radeon_atombios_parse_power_table_6 function, power_state->v2.nonClockInfoIndex for non_clock_info of one state is ignored and replaced by the state index, referencing an iguana bug. Is it still buggy from southern island and we must keep ignoring power_state->v2.nonClockInfoIndex for good and use the state index to reference the right state description in non clock array table? The same does happen for the clock info index which can be out of range. Same treat as above? In radeon_atombios.c, radeon_atombios_parse_pplib_clock_info function, code paths are selected based on DCE generation. The same happens in radeon_atombios_parse_pplib_non_clock_info function. Should it rather be the chip family? Or current powerplay code does deal only with the DCE block?? regards, -- Sylvain
[PATCH] drm/radeon: allocate SA bo in the requested domain
Am 2013-04-25 18:19, schrieb Christian K?nig:
> From: Christian K?nig
>
> This avoid moving the BO directly after allocating it.
>
> Signed-off-by: Christian K?nig
Tested-by: Dieter N?tzel
Regards,
Dieter
> ---
> drivers/gpu/drm/radeon/radeon_sa.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
> b/drivers/gpu/drm/radeon/radeon_sa.c
> index cb80099..0abe5a9 100644
> --- a/drivers/gpu/drm/radeon/radeon_sa.c
> +++ b/drivers/gpu/drm/radeon/radeon_sa.c
> @@ -64,7 +64,7 @@ int radeon_sa_bo_manager_init(struct radeon_device
> *rdev,
> }
>
> r = radeon_bo_create(rdev, size, RADEON_GPU_PAGE_SIZE, true,
> - RADEON_GEM_DOMAIN_CPU, NULL, _manager->bo);
> + domain, NULL, _manager->bo);
> if (r) {
> dev_err(rdev->dev, "(%d) failed to allocate bo for manager\n",
> r);
> return r;
[PATCH] drm/radeon: fix scratch reg handling for UVD fence
Am 2013-04-24 14:12, schrieb Christian K?nig:
> From: Christian K?nig
>
> Also init the scratch reg to zero on the UVD ring.
> This fixes UVD on AGP based cards.
>
> Signed-off-by: Christian K?nig
Tested-by: Dieter N?tzel
RV730 AGP (UVD 2.2) works with radeon.agpmode=8, now.
[ 10.394741] ATOM BIOS: 113
[ 10.394948] [drm] AGP mode requested: 8
[ 10.394960] agpgart-via :00:00.0: AGP 3.5 bridge
[ 10.394989] agpgart-via :00:00.0: putting AGP V3 device into 8x
mode
[ 10.396634] radeon :01:00.0: putting AGP V3 device into 8x mode
[ 10.396649] radeon :01:00.0: GTT: 256M 0xE000 - 0xEFFF
[ 10.396661] radeon :01:00.0: VRAM: 1024M 0xA000 - 0xDFFF
(1024M used)
[ 10.399244] [drm] Detected VRAM RAM=1024M, BAR=256M
[ 10.399254] [drm] RAM width 128bits DDR
[ 10.402125] [TTM] Zone kernel: Available graphics memory: 441924 kiB
[ 10.402133] [TTM] Zone highmem: Available graphics memory: 1033768
kiB
[ 10.402136] [TTM] Initializing pool allocator
[ 10.402198] [drm] radeon: 1024M of VRAM memory ready
[ 10.402202] [drm] radeon: 256M of GTT memory ready.
[ 10.402244] [drm] Supports vblank timestamp caching Rev 1
(10.10.2010).
[ 10.402247] [drm] Driver supports precise vblank timestamp query.
[ 10.402319] [drm] radeon: irq initialized.
[-]
[ 10.524045] [drm] GART: num cpu pages 65536, num gpu pages 65536
[ 10.528182] [drm] Loading RV730 Microcode
[ 10.641945] radeon :01:00.0: WB disabled
[ 10.641964] radeon :01:00.0: fence driver on ring 0 use gpu addr
0xe004 and cpu a
ddr 0xf84c0004
[ 10.641969] radeon :01:00.0: fence driver on ring 3 use gpu addr
0xec0c and cpu addr 0xf84c0c0c
[ 10.642218] radeon :01:00.0: fence driver on ring 5 use gpu addr
0xa005c598 and cpu addr 0xf879c598
[ 10.785565] [drm] ring test on 0 succeeded in 1 usecs
[ 10.785636] [drm] ring test on 3 succeeded in 1 usecs
[ 10.842237] md127:
[ 10.847965] [drm] ring test on 5 succeeded in 1 usecs
[ 10.847976] [drm] UVD initialized successfully.
[ 10.848690] [drm] ib test on ring 0 succeeded in 0 usecs
[ 10.848729] [drm] ib test on ring 3 succeeded in 1 usecs
[ 10.858255] [drm] ib test on ring 5 succeeded
Thank you Christian!
Dieter
> ---
> drivers/gpu/drm/radeon/radeon_fence.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
> b/drivers/gpu/drm/radeon/radeon_fence.c
> index 1a699ce..5b937df 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -767,8 +767,8 @@ int radeon_fence_driver_start_ring(struct
> radeon_device *rdev, int ring)
>
> radeon_scratch_free(rdev, rdev->fence_drv[ring].scratch_reg);
> if (rdev->wb.use_event || !radeon_ring_supports_scratch_reg(rdev,
> >ring[ring])) {
> + rdev->fence_drv[ring].scratch_reg = 0;
> if (ring != R600_RING_TYPE_UVD_INDEX) {
> - rdev->fence_drv[ring].scratch_reg = 0;
> index = R600_WB_EVENT_OFFSET + ring * 4;
> rdev->fence_drv[ring].cpu_addr = >wb.wb[index/4];
> rdev->fence_drv[ring].gpu_addr = rdev->wb.gpu_addr +
[GIT PULL] exynos-drm-next
Hi Dave, This is final pull request for Exynos next and includes device tree support for fimc device, one revert, some code cleanups and fixup. The revert replaces wrong one[1] with correct one[2]. This was my mistake and sorry for this. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg60737.html [2] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg17740.html And there are some patches posted some time ago but those are needed to be reviewed enough so not included this time. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 36d9b1541cedecd59e9d8fff0bbf9b7e9dd9704e: Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2013-04-26 15:42:02 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos exynos-drm-next Inki Dae (2): Revert drm/exynos: prepare FIMD clocks drm/exynos: do not use generic flags to dumb Sachin Kamat (2): drm/exynos: Select VIDEOMODE_HELPERS for FIMD drm/exynos: Remove unnecessary braces in exynos_hdmi.c Sean Paul (1): drm/exynos: Don't blend mixer layer 0 Seung-Woo Kim (3): drm/exynos: fix wrong return check for platform_device_register_simple exynos/drm: hdmi: cleanup for hdmi common device registration drm/exynos: added ipp device registration to drm driver Sylwester Nawrocki (3): drm/exynos: remove redundant devm_kfree() drm/exynos: rework fimc clocks handling drm/exynos: add device tree support for fimc ipp driver Vikas Sajjan (1): drm/exynos: enable FIMD clocks drivers/gpu/drm/exynos/Kconfig |4 +- drivers/gpu/drm/exynos/exynos_drm_drv.c |9 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 12 ++- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 273 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 23 +-- drivers/gpu/drm/exynos/exynos_drm_gem.c |3 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 14 +- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 27 +++ drivers/gpu/drm/exynos/exynos_hdmi.c | 10 +- drivers/gpu/drm/exynos/exynos_mixer.c|8 +- drivers/gpu/drm/exynos/regs-fimc.h |7 +- 11 files changed, 230 insertions(+), 160 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes for 3.10
Hi Dave, Just a few important fixes for 3.10. 3 regression fixes, plus rectified Haswell overclock support (the old code was correct, only docs confusing) and improved DP data m/n selection. Cheers, Daniel The following changes since commit bd080ee57c2173cefdcadc39c7863a76c249d049: drm/i915: fix bpc vs. bpp confusion in intel_crtc_compute_config (2013-04-18 09:43:33 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to 43b27290dd42b40f3f23f49677a7faa5a4eb1eff: drm/i915: correct the calculation of first_pd_entry_in_global_pt (2013-04-27 14:07:16 +0200) Ben Widawsky (1): Revert drm/i915: Don't overclock on Haswell Daniel Vetter (1): drm/i915: avoid full modeset when changing the color range properties David Müller (ELSOFT AG) (1): drm/i915: Fall back to bit banging mode for DVO transmitter detection Ville Syrjälä (1): drm/i915: Make data/link N value power of two Zhang, Xiong Y (1): drm/i915: correct the calculation of first_pd_entry_in_global_pt drivers/gpu/drm/i915/i915_gem_gtt.c |3 +-- drivers/gpu/drm/i915/i915_reg.h | 12 drivers/gpu/drm/i915/intel_display.c | 26 ++ drivers/gpu/drm/i915/intel_dp.c |8 drivers/gpu/drm/i915/intel_dvo.c | 13 - drivers/gpu/drm/i915/intel_hdmi.c|8 drivers/gpu/drm/i915/intel_pm.c |2 +- drivers/gpu/drm/i915/intel_sdvo.c|8 8 files changed, 60 insertions(+), 20 deletions(-) -- 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] module: fix mutiple defined issue
On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote: This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE s/mutiple/multiple/, still this sentence doesn't sound right. What is the error message you see? The issue could be induced when some framework which includes two more sub drivers, is built as one moudle because those sub drivers s/moudle/module/ could have their own MODULE_DEVICE_TABLE. And 'struct of_device_id' isn't needed to be determined by type argument because the definition of 'of_device_id' should be fixed. So this patch makes 'of_devce_id' definition to be fixed and only its instance name to be defined by type. include/linux/isapnp.h uses: #define ISAPNP_CARD_TABLE(name) \ MODULE_GENERIC_TABLE(isapnp_card, name) and you changed the table's type with your patch. Ditto for all users of MODULE_DEVICE_TABLE(i2c, ...); MODULE_DEVICE_TABLE(acpi, ...); MODULE_DEVICE_TABLE(platform, ...); MODULE_DEVICE_TABLE(pci, ...); MODULE_DEVICE_TABLE(sdio, ...); So I'm pretty sure your patch is wrong and I expect it makes most defconfigs fail to compile. Best regards Uwe Signed-off-by: Inki Dae inki@samsung.com --- include/linux/module.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/module.h b/include/linux/module.h index 46f1ea0..ac5d79f 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -84,7 +84,7 @@ void trim_init_extable(struct module *m); #ifdef MODULE #define MODULE_GENERIC_TABLE(gtype,name) \ -extern const struct gtype##_id __mod_##gtype##_table \ +extern const struct of_device_id __mod_##gtype##_table \ __attribute__ ((unused, alias(__stringify(name #else /* !MODULE */ -- 1.7.5.4 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ 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 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Attachment #78533|text/plain |image/png mime type|| -- 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: [PATCH] module: fix mutiple defined issue
Hi, -Original Message- From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- ow...@vger.kernel.org] On Behalf Of Uwe Kleine-Konig Sent: Monday, April 29, 2013 4:35 PM To: Inki Dae Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; dri- de...@lists.freedesktop.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] module: fix mutiple defined issue On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote: This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE s/mutiple/multiple/, still this sentence doesn't sound right. What is the error message you see? The issue could be induced when some framework which includes two more sub drivers, is built as one moudle because those sub drivers s/moudle/module/ could have their own MODULE_DEVICE_TABLE. And 'struct of_device_id' isn't needed to be determined by type argument because the definition of 'of_device_id' should be fixed. So this patch makes 'of_devce_id' definition to be fixed and only its instance name to be defined by type. include/linux/isapnp.h uses: #define ISAPNP_CARD_TABLE(name) \ MODULE_GENERIC_TABLE(isapnp_card, name) and you changed the table's type with your patch. Ditto for all users of MODULE_DEVICE_TABLE(i2c, ...); MODULE_DEVICE_TABLE(acpi, ...); MODULE_DEVICE_TABLE(platform, ...); MODULE_DEVICE_TABLE(pci, ...); MODULE_DEVICE_TABLE(sdio, ...); So I'm pretty sure your patch is wrong and I expect it makes most defconfigs fail to compile. It might be my big mistake. Maybe xxx_device_id object was created device tree internally. Right? Will check it out again. So please ignore it. Thanks, Inki Dae Best regards Uwe Signed-off-by: Inki Dae inki@samsung.com --- include/linux/module.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/module.h b/include/linux/module.h index 46f1ea0..ac5d79f 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -84,7 +84,7 @@ void trim_init_extable(struct module *m); #ifdef MODULE #define MODULE_GENERIC_TABLE(gtype,name) \ -extern const struct gtype##_id __mod_##gtype##_table \ +extern const struct of_device_id __mod_##gtype##_table \ __attribute__ ((unused, alias(__stringify(name #else /* !MODULE */ -- 1.7.5.4 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix UPLL_REF_DIV_MASK definition
From: Christian König christian.koe...@amd.com Stupid copy paste error over all generations. Signed-off-by: Christian König christian.koe...@amd.com --- drivers/gpu/drm/radeon/evergreend.h |2 +- drivers/gpu/drm/radeon/rv770d.h |2 +- drivers/gpu/drm/radeon/sid.h|2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreend.h b/drivers/gpu/drm/radeon/evergreend.h index d9a0054..75c0563 100644 --- a/drivers/gpu/drm/radeon/evergreend.h +++ b/drivers/gpu/drm/radeon/evergreend.h @@ -59,7 +59,7 @@ # define UPLL_SLEEP_MASK 0x0002 # define UPLL_BYPASS_EN_MASK 0x0004 # define UPLL_CTLREQ_MASK 0x0008 -# define UPLL_REF_DIV_MASK0x001F +# define UPLL_REF_DIV_MASK0x003F # define UPLL_VCO_MODE_MASK 0x0200 # define UPLL_CTLACK_MASK 0x4000 # define UPLL_CTLACK2_MASK0x8000 diff --git a/drivers/gpu/drm/radeon/rv770d.h b/drivers/gpu/drm/radeon/rv770d.h index 6a52b20..85b1626 100644 --- a/drivers/gpu/drm/radeon/rv770d.h +++ b/drivers/gpu/drm/radeon/rv770d.h @@ -45,7 +45,7 @@ # define UPLL_BYPASS_EN_MASK 0x0004 # define UPLL_CTLREQ_MASK 0x0008 # define UPLL_REF_DIV(x) ((x) 16) -# define UPLL_REF_DIV_MASK0x001F +# define UPLL_REF_DIV_MASK0x003F # define UPLL_CTLACK_MASK 0x4000 # define UPLL_CTLACK2_MASK0x8000 #define CG_UPLL_FUNC_CNTL_20x71c diff --git a/drivers/gpu/drm/radeon/sid.h b/drivers/gpu/drm/radeon/sid.h index 042b91d..222877b 100644 --- a/drivers/gpu/drm/radeon/sid.h +++ b/drivers/gpu/drm/radeon/sid.h @@ -36,7 +36,7 @@ # define UPLL_BYPASS_EN_MASK 0x0004 # define UPLL_CTLREQ_MASK 0x0008 # define UPLL_VCO_MODE_MASK 0x0600 -# define UPLL_REF_DIV_MASK0x001F +# define UPLL_REF_DIV_MASK0x003F # define UPLL_CTLACK_MASK 0x4000 # define UPLL_CTLACK2_MASK0x8000 #defineCG_UPLL_FUNC_CNTL_2 0x638 -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] module: fix mutiple defined issue
-Original Message- From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux Sent: Monday, April 29, 2013 6:52 PM To: Inki Dae Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; dri- de...@lists.freedesktop.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] module: fix mutiple defined issue On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote: This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE The issue could be induced when some framework which includes two more sub drivers, is built as one moudle because those sub drivers could have their own MODULE_DEVICE_TABLE. And 'struct of_device_id' isn't needed to be determined by type argument because the definition of 'of_device_id' should be fixed. So this patch makes 'of_devce_id' definition to be fixed and only its instance name to be defined by type. Signed-off-by: Inki Dae inki@samsung.com --- include/linux/module.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/module.h b/include/linux/module.h index 46f1ea0..ac5d79f 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -84,7 +84,7 @@ void trim_init_extable(struct module *m); #ifdef MODULE #define MODULE_GENERIC_TABLE(gtype,name) \ -extern const struct gtype##_id __mod_##gtype##_table \ +extern const struct of_device_id __mod_##gtype##_table \ __attribute__ ((unused, alias(__stringify(name #else /* !MODULE */ This patch (a) looks wrong (why would a generic device table be limited to of_device_id when it could be ISAPNP or something else?) and (b) how does changing the type fix the multiple defined issue ? (c) include the errors that you're fixing in the commit log. There was my misunderstanding. So please ignore my patch. Some headers in include/linux/ have some kind of device_id structure such as of_device_id, platform_device_id, i2c_device_id, and so on. And these structures should be used properly. This was my missing point. Thanks, Inki Dae -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: abuse of dumb ioctls in exynos
The reason we (currently) use the dumb buffer interface is because it does pretty much exactly what we need it to, as we only want linear RGB buffers: Except in the cases where it doesn't do what you want, and possibly in the future where it does less of what you want. You've started on a slippery slope, and I'm stopping you before you make things worse. You are going to have to get SoC kernel drivers to add an ioctl that you can use, if you insist on trying to mangle all the different code paths into a single userspace driver, then you are going to take a lot of pain. Its the old helper library vs midlayer, you are inventing a DDX midlayer when you should be inventing a DDX helper library. On Mali probably other tiled-based GPUs, the back buffer only gets written once per frame, when the GPU writes its on-die tile buffer to system memory. As such, we don't need the complicated memory layouts immediate mode renders do to improve cache efficiency, etc. On one 3D core, the problem is the driver seems to be wanted to be used across at least omap and exynos, and I assume others will happen as time progresses. What's more, the 2D hardware typically found on SoCs we're targeting isn't advanced enough to implement all of the EXA operations and frequently falls back to software rendering, which only works with linear RGB buffers. Don't worry about implementing all of EXA, you really probably only want fill/copy for what you are doing. we must therefore allocate from a contiguous ION heap. By allocating via the DUMB interface and specifying a scanout hint, we can leave that decision to the DRM driver and keep userspace entirely generic. The other reason to go with DUMB rather than ION was because ION wasn't upstream. Just ask the drm driver directly, no dumb ioctl, no ion. Not sure what the problem is. Would you mind elaborating a little on this? I assume you're not talking about libkms? What operations would be performed by this driver which would need to be abstracted in userspace which aren't already nicely abstracted by KMS? Once we have a new library of some description, I assume you're suggesting we modify armsoc to use it? That seems a good idea as it also means we can use that to implement the HWComposer HAL on Android and thus use the same driver code can be used with minimal changes on X11, Android, Wayland, Mir and whatever other new window system comes along. That's really the point I'm trying to get to. No not libkms, nothing like it. More as Rob said the drmmode code is probably the truly common code, and just write a DDX per SoC. Really anything else you do is going to lull people into a false sense of how much work there is. Distros want to ship a distro that can support all ARM boards at once, they don't want have 15 armsoc builds with different configure flags. Stop and think about how Linux distro downstream might use this. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/exynos: hdmi: use drm_display_mode to check the supported modes
Hello Rahul,
I looks good to me.
On 2013년 04월 29일 20:14, Rahul Sharma wrote:
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.
v4:
1) Removed __func__ from DRM_DEBUG_KMS.
v3:
1) Replaced check_timing callbacks with check_mode.
2) Change the type of second parameter of check_mode callback from void
pointer paramenter to struct drm_display_mode pointer.
v2:
1) Removed convert_to_video_timing().
2) Corrected DRM_DEBUG_KMS to print the resolution properly.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Acked-by: Seung-Woo Kim sw0312@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 38
++---
drivers/gpu/drm/exynos/exynos_drm_drv.h |4 +--
drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 +--
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 17 +--
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |6 ++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c |4 +--
drivers/gpu/drm/exynos/exynos_hdmi.c | 29 +--
drivers/gpu/drm/exynos/exynos_mixer.c | 17 +--
8 files changed, 43 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 8bcc13a..ab3c6d4 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 display_ops-check_mode)
+ if (!display_ops-check_mode(manager-dev, mode))
ret = MODE_OK;
return ret;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4606fac..9650b3b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -142,7 +142,7 @@ struct exynos_drm_overlay {
* @is_connected: check for that display is connected or not.
* @get_edid: get edid modes from display driver.
* @get_panel: get panel object from display driver.
- * @check_timing: check if timing is valid or not.
+ * @check_mode: check if mode is valid or not.
* @power_on: display device on or off.
*/
struct exynos_drm_display_ops {
@@ -151,7 +151,7 @@ struct exynos_drm_display_ops {
struct edid *(*get_edid)(struct device *dev,
struct drm_connector *connector);
void *(*get_panel)(struct device *dev);
- int (*check_timing)(struct device *dev, void *timing);
+ int (*check_mode)(struct device *dev, struct drm_display_mode *mode);
int (*power_on)(struct device *dev, int mode);
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 15e58f5..98bbe1e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++
[Bug 47351] [KMS: Mobility Radeon HD 6620G] Blank screen on boot
https://bugzilla.kernel.org/show_bug.cgi?id=47351 --- Comment #5 from Nick ka.n...@mail.ru 2013-04-29 12:01:07 --- Created an attachment (id=100251) -- (https://bugzilla.kernel.org/attachment.cgi?id=100251) lspci -vv output I have the same behaviour on my HP 4545s laptop if I try to use discrete video card (HD7500/7600). I managed to get it work (more or less) on integrated 7240G, but I get blank screen having tried to switch to discrete video. Can I provide any additional information to help to resolve the issue? -- 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 57281] New: Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 Summary: Radeon: Bad performance and power consumption Product: Drivers Version: 2.5 Kernel Version: 3.8.2-pf 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: ka.n...@mail.ru Regression: No Created an attachment (id=100261) -- (https://bugzilla.kernel.org/attachment.cgi?id=100261) lspci -vv output After upgrading my AMD E-450-based notebook to a newer one (HP 4545s A4-3300-based) i noticed that in spite of noticeable higher clock rate the video performance is about 15-20% worse than on E-450. It also got much hotter initially, which I could cure by passing pcie_aspm=force to the kernel. In spite of this I still have a feeling that it probably eats more power than it should (which I can not prove with numbers, of course) comparing to E-450 (and fglrx) experience. (Yes, I know the proprietary driver performs better in terms of power management, too, but the question is to what extent?) Anyways, it shouldn't underperform the older and weaker model... It also shows the message at boot time: [drm:radeon_acpi_init] *ERROR* Cannot find backlight controller but it seems to work fine after that. (Shall I post another bug on this?) -- 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 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #1 from Nick ka.n...@mail.ru 2013-04-29 12:34:50 --- Created an attachment (id=100271) -- (https://bugzilla.kernel.org/attachment.cgi?id=100271) Kernel config -- 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 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 Nick ka.n...@mail.ru changed: What|Removed |Added Attachment #100261|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 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 Nick ka.n...@mail.ru changed: What|Removed |Added Attachment #100271|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 63702] tiling2d in radeon trash vdpau UVD textures
https://bugs.freedesktop.org/show_bug.cgi?id=63702 Christian König deathsim...@vodafone.de changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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 1/2] drm/exynos: exynos_drm_fbdev: Fix incorrect usage of IS_ERR_OR_NULL
exynos_drm_framebuffer_init() does not return NULL. Use IS_ERR instead.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
This series is based on exynos-drm-next branch of Inki Dae's tree:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 68f0045..8f007aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -182,7 +182,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
*helper,
helper-fb = exynos_drm_framebuffer_init(dev, mode_cmd,
exynos_gem_obj-base);
- if (IS_ERR_OR_NULL(helper-fb)) {
+ if (IS_ERR(helper-fb)) {
DRM_ERROR(failed to create drm framebuffer.\n);
ret = PTR_ERR(helper-fb);
goto err_destroy_gem;
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/exynos: exynos_drm_ipp: Fix incorrect usage of IS_ERR_OR_NULL
None of these functions actually return a NULL pointer. Hence use
IS_ERR() instead.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 29d2ad3..5c4764a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -222,7 +222,7 @@ static struct exynos_drm_ippdrv *ipp_find_driver(struct
ipp_context *ctx,
/* find ipp driver using idr */
ippdrv = ipp_find_obj(ctx-ipp_idr, ctx-ipp_lock,
ipp_id);
- if (IS_ERR_OR_NULL(ippdrv)) {
+ if (IS_ERR(ippdrv)) {
DRM_ERROR(not found ipp%d driver.\n, ipp_id);
return ippdrv;
}
@@ -388,7 +388,7 @@ static int ipp_find_and_set_property(struct
drm_exynos_ipp_property *property)
DRM_DEBUG_KMS(%s:prop_id[%d]\n, __func__, prop_id);
ippdrv = ipp_find_drv_by_handle(prop_id);
- if (IS_ERR_OR_NULL(ippdrv)) {
+ if (IS_ERR(ippdrv)) {
DRM_ERROR(failed to get ipp driver.\n);
return -EINVAL;
}
@@ -492,7 +492,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev,
void *data,
/* find ipp driver using ipp id */
ippdrv = ipp_find_driver(ctx, property);
- if (IS_ERR_OR_NULL(ippdrv)) {
+ if (IS_ERR(ippdrv)) {
DRM_ERROR(failed to get ipp driver.\n);
return -EINVAL;
}
@@ -521,19 +521,19 @@ int exynos_drm_ipp_set_property(struct drm_device
*drm_dev, void *data,
c_node-state = IPP_STATE_IDLE;
c_node-start_work = ipp_create_cmd_work();
- if (IS_ERR_OR_NULL(c_node-start_work)) {
+ if (IS_ERR(c_node-start_work)) {
DRM_ERROR(failed to create start work.\n);
goto err_clear;
}
c_node-stop_work = ipp_create_cmd_work();
- if (IS_ERR_OR_NULL(c_node-stop_work)) {
+ if (IS_ERR(c_node-stop_work)) {
DRM_ERROR(failed to create stop work.\n);
goto err_free_start;
}
c_node-event_work = ipp_create_event_work();
- if (IS_ERR_OR_NULL(c_node-event_work)) {
+ if (IS_ERR(c_node-event_work)) {
DRM_ERROR(failed to create event work.\n);
goto err_free_stop;
}
@@ -915,7 +915,7 @@ static int ipp_queue_buf_with_run(struct device *dev,
DRM_DEBUG_KMS(%s\n, __func__);
ippdrv = ipp_find_drv_by_handle(qbuf-prop_id);
- if (IS_ERR_OR_NULL(ippdrv)) {
+ if (IS_ERR(ippdrv)) {
DRM_ERROR(failed to get ipp driver.\n);
return -EFAULT;
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] module: fix mutiple defined issue
On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote: This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE The issue could be induced when some framework which includes two more sub drivers, is built as one moudle because those sub drivers could have their own MODULE_DEVICE_TABLE. And 'struct of_device_id' isn't needed to be determined by type argument because the definition of 'of_device_id' should be fixed. So this patch makes 'of_devce_id' definition to be fixed and only its instance name to be defined by type. Signed-off-by: Inki Dae inki@samsung.com --- include/linux/module.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/module.h b/include/linux/module.h index 46f1ea0..ac5d79f 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -84,7 +84,7 @@ void trim_init_extable(struct module *m); #ifdef MODULE #define MODULE_GENERIC_TABLE(gtype,name) \ -extern const struct gtype##_id __mod_##gtype##_table \ +extern const struct of_device_id __mod_##gtype##_table \ __attribute__ ((unused, alias(__stringify(name #else /* !MODULE */ This patch (a) looks wrong (why would a generic device table be limited to of_device_id when it could be ISAPNP or something else?) and (b) how does changing the type fix the multiple defined issue ? (c) include the errors that you're fixing in the commit log. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] 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.
v4:
1) Removed __func__ from DRM_DEBUG_KMS.
v3:
1) Replaced check_timing callbacks with check_mode.
2) Change the type of second parameter of check_mode callback from void
pointer paramenter to struct drm_display_mode pointer.
v2:
1) Removed convert_to_video_timing().
2) Corrected DRM_DEBUG_KMS to print the resolution properly.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 38 ++---
drivers/gpu/drm/exynos/exynos_drm_drv.h |4 +--
drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 +--
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 17 +--
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |6 ++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c |4 +--
drivers/gpu/drm/exynos/exynos_hdmi.c | 29 +--
drivers/gpu/drm/exynos/exynos_mixer.c | 17 +--
8 files changed, 43 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 8bcc13a..ab3c6d4 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 display_ops-check_mode)
+ if (!display_ops-check_mode(manager-dev, mode))
ret = MODE_OK;
return ret;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4606fac..9650b3b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -142,7 +142,7 @@ struct exynos_drm_overlay {
* @is_connected: check for that display is connected or not.
* @get_edid: get edid modes from display driver.
* @get_panel: get panel object from display driver.
- * @check_timing: check if timing is valid or not.
+ * @check_mode: check if mode is valid or not.
* @power_on: display device on or off.
*/
struct exynos_drm_display_ops {
@@ -151,7 +151,7 @@ struct exynos_drm_display_ops {
struct edid *(*get_edid)(struct device *dev,
struct drm_connector *connector);
void *(*get_panel)(struct device *dev);
- int (*check_timing)(struct device *dev, void *timing);
+ int (*check_mode)(struct device *dev, struct drm_display_mode *mode);
int (*power_on)(struct device *dev, int mode);
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 15e58f5..98bbe1e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -153,7 +153,7 @@ static void *fimd_get_panel(struct device *dev)
return ctx-panel;
}
-static int fimd_check_timing(struct device *dev, void
[Bug 47351] [KMS: Mobility Radeon HD 6620G] Blank screen on boot
https://bugzilla.kernel.org/show_bug.cgi?id=47351 --- Comment #6 from Alex Deucher alexdeuc...@gmail.com 2013-04-29 14:20:38 --- (In reply to comment #5) I have the same behaviour on my HP 4545s laptop if I try to use discrete video card (HD7500/7600). I managed to get it work (more or less) on integrated 7240G, but I get blank screen having tried to switch to discrete video. Can I provide any additional information to help to resolve the issue? Most hybrid laptops are mux-less meaning there are no displays physically connected to the discrete GPU. For display you have to use the integrated GPU. The discrete GPU can only be used for offscreen rendering. Do display that rendering, it has to be copied to the integrated GPU. There is limited support for this in newer xservers (1.13.x and newer). -- 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
Re: [PATCH] drm/radeon: fix UPLL_REF_DIV_MASK definition
On Mon, Apr 29, 2013 at 4:20 AM, Christian König deathsim...@vodafone.de wrote: From: Christian König christian.koe...@amd.com Stupid copy paste error over all generations. Applied to my tree. Alex Signed-off-by: Christian König christian.koe...@amd.com --- drivers/gpu/drm/radeon/evergreend.h |2 +- drivers/gpu/drm/radeon/rv770d.h |2 +- drivers/gpu/drm/radeon/sid.h|2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreend.h b/drivers/gpu/drm/radeon/evergreend.h index d9a0054..75c0563 100644 --- a/drivers/gpu/drm/radeon/evergreend.h +++ b/drivers/gpu/drm/radeon/evergreend.h @@ -59,7 +59,7 @@ # define UPLL_SLEEP_MASK 0x0002 # define UPLL_BYPASS_EN_MASK 0x0004 # define UPLL_CTLREQ_MASK 0x0008 -# define UPLL_REF_DIV_MASK0x001F +# define UPLL_REF_DIV_MASK0x003F # define UPLL_VCO_MODE_MASK 0x0200 # define UPLL_CTLACK_MASK 0x4000 # define UPLL_CTLACK2_MASK0x8000 diff --git a/drivers/gpu/drm/radeon/rv770d.h b/drivers/gpu/drm/radeon/rv770d.h index 6a52b20..85b1626 100644 --- a/drivers/gpu/drm/radeon/rv770d.h +++ b/drivers/gpu/drm/radeon/rv770d.h @@ -45,7 +45,7 @@ # define UPLL_BYPASS_EN_MASK 0x0004 # define UPLL_CTLREQ_MASK 0x0008 # define UPLL_REF_DIV(x) ((x) 16) -# define UPLL_REF_DIV_MASK0x001F +# define UPLL_REF_DIV_MASK0x003F # define UPLL_CTLACK_MASK 0x4000 # define UPLL_CTLACK2_MASK0x8000 #define CG_UPLL_FUNC_CNTL_20x71c diff --git a/drivers/gpu/drm/radeon/sid.h b/drivers/gpu/drm/radeon/sid.h index 042b91d..222877b 100644 --- a/drivers/gpu/drm/radeon/sid.h +++ b/drivers/gpu/drm/radeon/sid.h @@ -36,7 +36,7 @@ # define UPLL_BYPASS_EN_MASK 0x0004 # define UPLL_CTLREQ_MASK 0x0008 # define UPLL_VCO_MODE_MASK 0x0600 -# define UPLL_REF_DIV_MASK0x001F +# define UPLL_REF_DIV_MASK0x003F # define UPLL_CTLACK_MASK 0x4000 # define UPLL_CTLACK2_MASK0x8000 #defineCG_UPLL_FUNC_CNTL_2 0x638 -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: consolidate UVD clock programming
On Mon, Apr 29, 2013 at 5:55 AM, Christian König
deathsim...@vodafone.de wrote:
From: Christian König christian.koe...@amd.com
Instead of duplicating the code over and over again, just use a single
function to handle the clock calculations.
Applied to by tree.
Alex
Signed-off-by: Christian König christian.koe...@amd.com
---
drivers/gpu/drm/radeon/evergreen.c | 103 +++---
drivers/gpu/drm/radeon/r600d.h |4 +
drivers/gpu/drm/radeon/radeon.h | 11 +++
drivers/gpu/drm/radeon/radeon_uvd.c | 137
+++
drivers/gpu/drm/radeon/rv770.c | 110 +---
drivers/gpu/drm/radeon/si.c | 104 +++---
6 files changed, 191 insertions(+), 278 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 1531f16..105bafb 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -989,62 +989,10 @@ done:
return r;
}
-static int evergreen_uvd_calc_post_div(unsigned target_freq,
- unsigned vco_freq,
- unsigned *div)
-{
- /* target larger than vco frequency ? */
- if (vco_freq target_freq)
- return -1; /* forget it */
-
- /* Fclk = Fvco / PDIV */
- *div = vco_freq / target_freq;
-
- /* we alway need a frequency less than or equal the target */
- if ((vco_freq / *div) target_freq)
- *div += 1;
-
- /* dividers above 5 must be even */
- if (*div 5 *div % 2)
- *div += 1;
-
- /* out of range ? */
- if (*div = 128)
- return -1; /* forget it */
-
- return vco_freq / *div;
-}
-
-static int evergreen_uvd_send_upll_ctlreq(struct radeon_device *rdev)
-{
- unsigned i;
-
- /* assert UPLL_CTLREQ */
- WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_CTLREQ_MASK, ~UPLL_CTLREQ_MASK);
-
- /* wait for CTLACK and CTLACK2 to get asserted */
- for (i = 0; i 100; ++i) {
- uint32_t mask = UPLL_CTLACK_MASK | UPLL_CTLACK2_MASK;
- if ((RREG32(CG_UPLL_FUNC_CNTL) mask) == mask)
- break;
- mdelay(10);
- }
- if (i == 100)
- return -ETIMEDOUT;
-
- /* deassert UPLL_CTLREQ */
- WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~UPLL_CTLREQ_MASK);
-
- return 0;
-}
-
int evergreen_set_uvd_clocks(struct radeon_device *rdev, u32 vclk, u32 dclk)
{
/* start off with something large */
- int optimal_diff_score = 0x7FF;
- unsigned optimal_fb_div = 0, optimal_vclk_div = 0;
- unsigned optimal_dclk_div = 0, optimal_vco_freq = 0;
- unsigned vco_freq;
+ unsigned fb_div = 0, vclk_div = 0, dclk_div = 0;
int r;
/* bypass vclk and dclk with bclk */
@@ -1061,40 +1009,11 @@ int evergreen_set_uvd_clocks(struct radeon_device
*rdev, u32 vclk, u32 dclk)
return 0;
}
- /* loop through vco from low to high */
- for (vco_freq = 125000; vco_freq = 25; vco_freq += 100) {
- unsigned fb_div = vco_freq / rdev-clock.spll.reference_freq
* 16384;
- int calc_clk, diff_score, diff_vclk, diff_dclk;
- unsigned vclk_div, dclk_div;
-
- /* fb div out of range ? */
- if (fb_div 0x03FF)
- break; /* it can oly get worse */
-
- /* calc vclk with current vco freq. */
- calc_clk = evergreen_uvd_calc_post_div(vclk, vco_freq,
vclk_div);
- if (calc_clk == -1)
- break; /* vco is too big, it has to stop. */
- diff_vclk = vclk - calc_clk;
-
- /* calc dclk with current vco freq. */
- calc_clk = evergreen_uvd_calc_post_div(dclk, vco_freq,
dclk_div);
- if (calc_clk == -1)
- break; /* vco is too big, it has to stop. */
- diff_dclk = dclk - calc_clk;
-
- /* determine if this vco setting is better than current
optimal settings */
- diff_score = abs(diff_vclk) + abs(diff_dclk);
- if (diff_score optimal_diff_score) {
- optimal_fb_div = fb_div;
- optimal_vclk_div = vclk_div;
- optimal_dclk_div = dclk_div;
- optimal_vco_freq = vco_freq;
- optimal_diff_score = diff_score;
- if (optimal_diff_score == 0)
- break; /* it can't get better than this */
- }
- }
+ r = radeon_uvd_calc_upll_dividers(rdev, vclk, dclk, 125000, 25,
+ 16384, 0x03FF, 0, 128, 5,
+
[Bug 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 Alex Deucher alexdeuc...@gmail.com changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher alexdeuc...@gmail.com 2013-04-29 14:31:27 --- Please attach your dmesg output. -- 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 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #3 from Michel Dänzer mic...@daenzer.net 2013-04-29 14:41:09 --- (In reply to comment #0) After upgrading my AMD E-450-based notebook to a newer one (HP 4545s A4-3300-based) i noticed that in spite of noticeable higher clock rate the video performance is about 15-20% worse than on E-450. How did you measure that? -- 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
Re: radeon pm questions
On Sun, Apr 28, 2013 at 9:26 PM, Sylvain BERTRAND sylw...@legeek.net wrote: Hi, I have a few questions about radeon pm code: In radeon_atombios.c, radeon_atombios_parse_power_table_6 function, power_state-v2.nonClockInfoIndex for non_clock_info of one state is ignored and replaced by the state index, referencing an iguana bug. Is it still buggy from southern island and we must keep ignoring power_state-v2.nonClockInfoIndex for good and use the state index to reference the right state description in non clock array table? nonClockInfoIndex isn't used and produces bogus tables. The index should be used. The same does happen for the clock info index which can be out of range. Same treat as above? Yes, although, at this point, it's mostly for safety. You shouldn't see it in practice. In radeon_atombios.c, radeon_atombios_parse_pplib_clock_info function, code paths are selected based on DCE generation. The same happens in radeon_atombios_parse_pplib_non_clock_info function. Should it rather be the chip family? Or current powerplay code does deal only with the DCE block?? It should be chip family. I just used the DCE check since it corresponds to the same relevant families. I'll fix that. Alex regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ 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 #8 from Alex Deucher ag...@yahoo.com --- It looks like you are using a bogus unposted vbios image. I think you'll need to bisect. If I had to guess, I'd say it's related to some change in how the pci rom images are fetched. -- 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 0/4] 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 implementation is tested for: 1) Resolutions supported by exynos4 and 5 hdmi. 2) Runtime PM and S2R scenarions for exynos5. This patch set is dependent on the patch, posted at http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg17905.html This series is based on exynos-drm-next branch at git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git Rahul Sharma (4): drm/exynos: hdmi: move hdmi subsystem registration to drm common hdmi drm/exynos: hdmi: register hdmiphy driver from common drm hdmi drm/exynos: hdmi: move hdmiphy callbacks to hdmiphy driver ARM: EXYNOS: remove parent device for hdmiphy clock arch/arm/mach-exynos/clock-exynos4.c |1 - 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 | 107 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 20 + drivers/gpu/drm/exynos/exynos_hdmi.c | 371 ++- drivers/gpu/drm/exynos/exynos_hdmi.h |1 - drivers/gpu/drm/exynos/exynos_hdmiphy.c | 585 +- drivers/gpu/drm/exynos/regs-hdmiphy.h| 61 10 files changed, 780 insertions(+), 406 deletions(-) create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/exynos: hdmi: move hdmi subsystem registration to drm common hdmi
Exynos hdmi sub-system consists of mixer, hdmi ip, hdmi-phy and hdmi-ddc
components. Currently, drivers for these components are getting registered
in exynos_drm_drv.c, which is meant for registration of drm sub-drivers.
In this patch, registration of drm hdmi sub-driver and device, drivers for
hdmi sub-system components are moved to exynos_drm_hdmi.c. This ensures
limited relevant exposure of hdmi-sub-system components to exynos_drm_drv.c.
It will also help in handling the hdmi-sub-system diversities within the
exynos-common-hdmi.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
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 | 46 --
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |3 ++
4 files changed, 49 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index ba6d995..4eabb6e 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
@@ -436,13 +426,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
@@ -483,10 +467,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 eaa1966..34aa36d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -319,15 +319,16 @@ 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.
*/
-int exynos_platform_device_hdmi_register(void);
+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);
/*
* this function registers exynos drm ipp platform device.
@@ -340,9 +341,6 @@ int exynos_platform_device_ipp_register(void);
void exynos_platform_device_ipp_unregister(void);
extern struct platform_driver fimd_driver;
-extern struct platform_driver hdmi_driver;
-extern struct platform_driver mixer_driver;
-extern struct platform_driver exynos_drm_common_hdmi_driver;
extern struct platform_driver vidi_driver;
extern struct platform_driver g2d_driver;
extern struct platform_driver fimc_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 060fbe8..7ab5f9f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -41,6 +41,8 @@ static struct exynos_drm_hdmi_context *mixer_ctx;
static struct exynos_hdmi_ops *hdmi_ops;
static struct exynos_mixer_ops *mixer_ops;
+struct platform_driver exynos_drm_common_hdmi_driver;
+
struct drm_hdmi_context {
struct exynos_drm_subdrvsubdrv;
struct exynos_drm_hdmi_context *hdmi_ctx;
@@ -49,29 +51,55 @@ struct drm_hdmi_context {
boolenabled[MIXER_WIN_NR];
};
-int exynos_platform_device_hdmi_register(void)
+int exynos_common_hdmi_register(void)
{
struct platform_device *pdev;
+ int ret;
if (exynos_drm_hdmi_pdev)
[PATCH 2/4] drm/exynos: hdmi: register hdmiphy driver from common drm hdmi
hdmiphy hardware block is a physically separate device. Hdmiphy driver
is glued inside hdmi driver and acessed through hdmi callbacks. With
increasing diversities in the hdmiphy mapping and configurations, hdmi
driver is expanding with un-related changes.
This patch registers hdmiphy as a independent driver, having own set
of requried callbacks which are called by common drm hdmi, parallel to
hdmi and mixer driver.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 61 +++---
drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 17 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 26 ++---
drivers/gpu/drm/exynos/exynos_hdmi.h |1 -
drivers/gpu/drm/exynos/exynos_hdmiphy.c | 13 ++-
5 files changed, 87 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 7ab5f9f..25fe012 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -32,12 +32,14 @@
/* platform device pointer for common drm hdmi device. */
static struct platform_device *exynos_drm_hdmi_pdev;
-/* Common hdmi subdrv needs to access the hdmi and mixer though context.
-* These should be initialied by the repective drivers */
+/* Common hdmi subdrv needs to access the hdmi, hdmiphy and mixer though
+* context. These should be initialied by the repective drivers */
+static struct exynos_drm_hdmi_context *hdmiphy_ctx;
static struct exynos_drm_hdmi_context *hdmi_ctx;
static struct exynos_drm_hdmi_context *mixer_ctx;
/* these callback points shoud be set by specific drivers. */
+static struct exynos_hdmiphy_ops *hdmiphy_ops;
static struct exynos_hdmi_ops *hdmi_ops;
static struct exynos_mixer_ops *mixer_ops;
@@ -45,6 +47,7 @@ struct platform_driver exynos_drm_common_hdmi_driver;
struct drm_hdmi_context {
struct exynos_drm_subdrvsubdrv;
+ struct exynos_drm_hdmi_context *hdmiphy_ctx;
struct exynos_drm_hdmi_context *hdmi_ctx;
struct exynos_drm_hdmi_context *mixer_ctx;
@@ -59,6 +62,10 @@ int exynos_common_hdmi_register(void)
if (exynos_drm_hdmi_pdev)
return -EEXIST;
+ ret = exynos_hdmiphy_driver_register();
+ if (ret 0)
+ goto out_hdmiphy;
+
ret = platform_driver_register(hdmi_driver);
if (ret 0)
goto out_hdmi;
@@ -88,6 +95,8 @@ out_common_hdmi:
out_mixer:
platform_driver_unregister(hdmi_driver);
out_hdmi:
+ exynos_hdmiphy_driver_unregister();
+out_hdmiphy:
return ret;
}
@@ -99,9 +108,16 @@ void exynos_common_hdmi_unregister(void)
platform_driver_unregister(exynos_drm_common_hdmi_driver);
platform_driver_unregister(mixer_driver);
platform_driver_unregister(hdmi_driver);
+ exynos_hdmiphy_driver_unregister();
exynos_drm_hdmi_pdev = NULL;
}
+void exynos_hdmiphy_drv_attach(struct exynos_drm_hdmi_context *ctx)
+{
+ if (ctx)
+ hdmiphy_ctx = ctx;
+}
+
void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx)
{
if (ctx)
@@ -114,6 +130,14 @@ void exynos_mixer_drv_attach(struct
exynos_drm_hdmi_context *ctx)
mixer_ctx = ctx;
}
+void exynos_hdmiphy_ops_register(struct exynos_hdmiphy_ops *ops)
+{
+ DRM_DEBUG_KMS(%s\n, __FILE__);
+
+ if (ops)
+ hdmiphy_ops = ops;
+}
+
void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops)
{
DRM_DEBUG_KMS(%s\n, __FILE__);
@@ -164,8 +188,8 @@ static int drm_hdmi_check_mode(struct device *dev,
DRM_DEBUG_KMS(%s\n, __FILE__);
/*
- * Both, mixer and hdmi should be able to handle the requested mode.
- * If any of the two fails, return mode as BAD.
+ * Mixer, hdmi and hdmiphy should be able to handle the requested mode.
+ * If any of the them fails, return mode as BAD.
*/
if (mixer_ops mixer_ops-check_mode)
@@ -175,7 +199,13 @@ static int drm_hdmi_check_mode(struct device *dev,
return ret;
if (hdmi_ops hdmi_ops-check_mode)
- return hdmi_ops-check_mode(ctx-hdmi_ctx-ctx, mode);
+ ret = hdmi_ops-check_mode(ctx-hdmi_ctx-ctx, mode);
+
+ if (ret)
+ return ret;
+
+ if (hdmiphy_ops hdmiphy_ops-check_mode)
+ return hdmiphy_ops-check_mode(ctx-hdmiphy_ctx-ctx, mode);
return 0;
}
@@ -289,6 +319,9 @@ static void drm_hdmi_mode_set(struct device *subdrv_dev,
void *mode)
if (hdmi_ops hdmi_ops-mode_set)
hdmi_ops-mode_set(ctx-hdmi_ctx-ctx, mode);
+
+ if (hdmiphy_ops hdmiphy_ops-mode_set)
+ hdmiphy_ops-mode_set(ctx-hdmiphy_ctx-ctx, mode);
}
static void drm_hdmi_get_max_resol(struct device *subdrv_dev,
@@ -308,6 +341,15 @@ static void drm_hdmi_commit(struct device *subdrv_dev)
DRM_DEBUG_KMS(%s\n, __FILE__);
+
[PATCH 3/4] drm/exynos: hdmi: move hdmiphy callbacks to hdmiphy driver
Hdmiphy callbacks are tighly coupled with hdmi IP callbacks inside
the hdmi driver. With increase in the support of different versions of
hdmiphys, hdmi ip driver expanding with lots of phy related information.
Above movement ensures that phy related code is present and maintained
within the hdmiphy driver.
This also helps in providing clean support for various combinations of hdmi
IPs and hdmiphys through 2 independent set of compatible strings. Earlier
each compatible string represents a combination of hdmi ip and phy. This
forces to use separate compatible string when one of the above block is
changed but the other one is not, which is not proper.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c| 345 +--
drivers/gpu/drm/exynos/exynos_hdmiphy.c | 574 ++-
drivers/gpu/drm/exynos/regs-hdmiphy.h | 61
3 files changed, 645 insertions(+), 335 deletions(-)
create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 520c4af..b03fea9 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -171,7 +171,6 @@ struct hdmi_v14_conf {
};
struct hdmi_conf_regs {
- int pixel_clock;
int cea_video_id;
union {
struct hdmi_v13_conf v13_conf;
@@ -192,7 +191,6 @@ struct hdmi_context {
int irq;
struct i2c_client *ddc_port;
- struct i2c_client *hdmiphy_port;
/* current hdmiphy conf regs */
struct hdmi_conf_regs mode_conf;
@@ -204,180 +202,6 @@ struct hdmi_context {
enum hdmi_type type;
};
-struct hdmiphy_config {
- int pixel_clock;
- u8 conf[32];
-};
-
-/* list of phy config settings */
-static const struct hdmiphy_config hdmiphy_v13_configs[] = {
- {
- .pixel_clock = 2700,
- .conf = {
- 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
- 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
- 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
- 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
- },
- },
- {
- .pixel_clock = 27027000,
- .conf = {
- 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
- 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
- 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
- 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
- },
- },
- {
- .pixel_clock = 74176000,
- .conf = {
- 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef, 0x5B,
- 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3, 0x54, 0xb9,
- 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
- 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00, 0x00, 0x00,
- },
- },
- {
- .pixel_clock = 7425,
- .conf = {
- 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c, 0xf8, 0x40,
- 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1, 0x54, 0xba,
- 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10, 0xe0,
- 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00, 0x00, 0x00,
- },
- },
- {
- .pixel_clock = 14850,
- .conf = {
- 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xf8, 0x40,
- 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1, 0x54, 0xba,
- 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10, 0xE0,
- 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00, 0x00, 0x00,
- },
- },
-};
-
-static const struct hdmiphy_config hdmiphy_v14_configs[] = {
- {
- .pixel_clock = 2520,
- .conf = {
- 0x01, 0x51, 0x2A, 0x75, 0x40, 0x01, 0x00, 0x08,
- 0x82, 0x80, 0xfc, 0xd8, 0x45, 0xa0, 0xac, 0x80,
- 0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
- 0x54, 0xf4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
- },
- },
- {
- .pixel_clock = 2700,
- .conf = {
- 0x01, 0xd1, 0x22, 0x51, 0x40, 0x08, 0xfc, 0x20,
- 0x98, 0xa0, 0xcb, 0xd8, 0x45, 0xa0, 0xac, 0x80,
- 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
- 0x54, 0xe4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
- },
- },
- {
- .pixel_clock = 27027000,
- .conf = {
- 0x01, 0xd1, 0x2d, 0x72, 0x40, 0x64, 0x12, 0x08,
- 0x43,
[PATCH 4/4] ARM: EXYNOS: remove parent device for hdmiphy clock
Hdmiphy clock flows from hdmiphy hw to hdmi ip and mixer. It is commonly
accessed among hdmi and hdmiphy driver. During power cycle, each of these
driver decrements the ref-count and ensures that last user disables the
clock. Setting parrent device to none ensure that both the drivers gets
access to the clock.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/mach-exynos/clock-exynos4.c |1 -
arch/arm/mach-exynos/clock-exynos5.c |1 -
2 files changed, 2 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos4.c
b/arch/arm/mach-exynos/clock-exynos4.c
index 8a8468d..a43afcd 100644
--- a/arch/arm/mach-exynos/clock-exynos4.c
+++ b/arch/arm/mach-exynos/clock-exynos4.c
@@ -562,7 +562,6 @@ static struct clk exynos4_init_clocks_off[] = {
.ctrlbit= (1 3),
}, {
.name = hdmiphy,
- .devname= exynos4-hdmi,
.enable = exynos4_clk_hdmiphy_ctrl,
.ctrlbit= (1 0),
}, {
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),
}, {
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-openchrome status (or will it be in Kernel 3.10?)
Hi James, Linus recently released Kernel 3.9, merge window for Kernel 3.10 has been opened, and the question is whether drm-openchrome will be part of the new Kernel version. Regards, Johannes ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm/exynos: hdmi: use drm_display_mode to check the supported modes
On Mon, Apr 29, 2013 at 7:14 AM, Rahul Sharma rahul.sha...@samsung.com wrote:
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.
it seems like you have 2 patches here, one which renames check_timing
to check_mode, and another which removes the fb_videomode usage. I
think it should probably be split.
If you don't split it, I think you could simplify the commit message to:
This patch renames check_timing to check_mode and removes the
unnecessary conversion of drm_display_mode to/from fb_videomode in the
hdmi driver.
v4:
1) Removed __func__ from DRM_DEBUG_KMS.
v3:
1) Replaced check_timing callbacks with check_mode.
2) Change the type of second parameter of check_mode callback from void
pointer paramenter to struct drm_display_mode pointer.
v2:
1) Removed convert_to_video_timing().
2) Corrected DRM_DEBUG_KMS to print the resolution properly.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 38
++---
drivers/gpu/drm/exynos/exynos_drm_drv.h |4 +--
drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 +--
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 17 +--
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |6 ++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c |4 +--
drivers/gpu/drm/exynos/exynos_hdmi.c | 29 +--
drivers/gpu/drm/exynos/exynos_mixer.c | 17 +--
8 files changed, 43 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 8bcc13a..ab3c6d4 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 display_ops-check_mode)
+ if (!display_ops-check_mode(manager-dev, mode))
ret = MODE_OK;
return ret;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4606fac..9650b3b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -142,7 +142,7 @@ struct exynos_drm_overlay {
* @is_connected: check for that display is connected or not.
* @get_edid: get edid modes from display driver.
* @get_panel: get panel object from display driver.
- * @check_timing: check if timing is valid or not.
+ * @check_mode: check if mode is valid or not.
* @power_on: display device on or off.
*/
struct exynos_drm_display_ops {
@@ -151,7 +151,7 @@ struct exynos_drm_display_ops {
struct edid *(*get_edid)(struct device *dev,
struct drm_connector *connector);
void *(*get_panel)(struct device *dev);
-
Re: [PATCH 1/4] drm/exynos: hdmi: move hdmi subsystem registration to drm common hdmi
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma rahul.sha...@samsung.com wrote: Exynos hdmi sub-system consists of mixer, hdmi ip, hdmi-phy and hdmi-ddc components. Currently, drivers for these components are getting registered in exynos_drm_drv.c, which is meant for registration of drm sub-drivers. In this patch, registration of drm hdmi sub-driver and device, drivers for hdmi sub-system components are moved to exynos_drm_hdmi.c. This ensures limited relevant exposure of hdmi-sub-system components to exynos_drm_drv.c. It will also help in handling the hdmi-sub-system diversities within the exynos-common-hdmi. Signed-off-by: Rahul Sharma rahul.sha...@samsung.com --- 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 | 46 -- drivers/gpu/drm/exynos/exynos_drm_hdmi.h |3 ++ 4 files changed, 49 insertions(+), 39 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index ba6d995..4eabb6e 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 @@ -436,13 +426,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 @@ -483,10 +467,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 eaa1966..34aa36d 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h @@ -319,15 +319,16 @@ 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. */ -int exynos_platform_device_hdmi_register(void); +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); /* * this function registers exynos drm ipp platform device. @@ -340,9 +341,6 @@ int exynos_platform_device_ipp_register(void); void exynos_platform_device_ipp_unregister(void); extern struct platform_driver fimd_driver; -extern struct platform_driver hdmi_driver; -extern struct platform_driver mixer_driver; -extern struct platform_driver exynos_drm_common_hdmi_driver; extern struct platform_driver vidi_driver; extern struct platform_driver g2d_driver; extern struct platform_driver fimc_driver; diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c index 060fbe8..7ab5f9f 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c @@ -41,6 +41,8 @@ static struct exynos_drm_hdmi_context *mixer_ctx; static struct exynos_hdmi_ops *hdmi_ops; static struct exynos_mixer_ops *mixer_ops; +struct platform_driver exynos_drm_common_hdmi_driver; What's the point of even having this driver? It doesn't do anything. You call exynos_common_hdmi_register/unregister in drm_drv anyways. Why not just register the mixer/hdmi/hdmiphy drivers and exynos subdrv in those functions directly? +
Re: [PATCH 2/4] drm/exynos: hdmi: register hdmiphy driver from common drm hdmi
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma rahul.sha...@samsung.com wrote:
hdmiphy hardware block is a physically separate device. Hdmiphy driver
is glued inside hdmi driver and acessed through hdmi callbacks. With
increasing diversities in the hdmiphy mapping and configurations, hdmi
driver is expanding with un-related changes.
This patch registers hdmiphy as a independent driver, having own set
of requried callbacks which are called by common drm hdmi, parallel to
hdmi and mixer driver.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 61
+++---
drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 17 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 26 ++---
drivers/gpu/drm/exynos/exynos_hdmi.h |1 -
drivers/gpu/drm/exynos/exynos_hdmiphy.c | 13 ++-
5 files changed, 87 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 7ab5f9f..25fe012 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -32,12 +32,14 @@
/* platform device pointer for common drm hdmi device. */
static struct platform_device *exynos_drm_hdmi_pdev;
-/* Common hdmi subdrv needs to access the hdmi and mixer though context.
-* These should be initialied by the repective drivers */
+/* Common hdmi subdrv needs to access the hdmi, hdmiphy and mixer though
+* context. These should be initialied by the repective drivers */
Doesn't conform with Documentation/CodingStyle
s/initialied/initialized/ s/repective/respective/
+static struct exynos_drm_hdmi_context *hdmiphy_ctx;
static struct exynos_drm_hdmi_context *hdmi_ctx;
static struct exynos_drm_hdmi_context *mixer_ctx;
/* these callback points shoud be set by specific drivers. */
+static struct exynos_hdmiphy_ops *hdmiphy_ops;
static struct exynos_hdmi_ops *hdmi_ops;
static struct exynos_mixer_ops *mixer_ops;
@@ -45,6 +47,7 @@ struct platform_driver exynos_drm_common_hdmi_driver;
struct drm_hdmi_context {
struct exynos_drm_subdrvsubdrv;
+ struct exynos_drm_hdmi_context *hdmiphy_ctx;
struct exynos_drm_hdmi_context *hdmi_ctx;
struct exynos_drm_hdmi_context *mixer_ctx;
@@ -59,6 +62,10 @@ int exynos_common_hdmi_register(void)
if (exynos_drm_hdmi_pdev)
return -EEXIST;
+ ret = exynos_hdmiphy_driver_register();
+ if (ret 0)
+ goto out_hdmiphy;
This isn't consistent with your last patch. In that patch, you exposed
the driver directly through exynos_drm_hdmi.h and registered the
driver directly. Here, you expose a helper function to do it for you.
These should at least work the same way.
+
ret = platform_driver_register(hdmi_driver);
if (ret 0)
goto out_hdmi;
@@ -88,6 +95,8 @@ out_common_hdmi:
out_mixer:
platform_driver_unregister(hdmi_driver);
out_hdmi:
+ exynos_hdmiphy_driver_unregister();
+out_hdmiphy:
return ret;
}
@@ -99,9 +108,16 @@ void exynos_common_hdmi_unregister(void)
platform_driver_unregister(exynos_drm_common_hdmi_driver);
platform_driver_unregister(mixer_driver);
platform_driver_unregister(hdmi_driver);
+ exynos_hdmiphy_driver_unregister();
exynos_drm_hdmi_pdev = NULL;
}
+void exynos_hdmiphy_drv_attach(struct exynos_drm_hdmi_context *ctx)
+{
+ if (ctx)
+ hdmiphy_ctx = ctx;
+}
+
I think I've said this before, but in case I haven't, here it goes. If
you didn't platform_driverize all of this stuff, and instead
encapsulated the various functionality in callbacks central to one drm
driver, you wouldn't need to do this kind of thing.
void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx)
{
if (ctx)
@@ -114,6 +130,14 @@ void exynos_mixer_drv_attach(struct
exynos_drm_hdmi_context *ctx)
mixer_ctx = ctx;
}
+void exynos_hdmiphy_ops_register(struct exynos_hdmiphy_ops *ops)
+{
+ DRM_DEBUG_KMS(%s\n, __FILE__);
+
+ if (ops)
+ hdmiphy_ops = ops;
+}
+
void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops)
{
DRM_DEBUG_KMS(%s\n, __FILE__);
@@ -164,8 +188,8 @@ static int drm_hdmi_check_mode(struct device *dev,
DRM_DEBUG_KMS(%s\n, __FILE__);
/*
- * Both, mixer and hdmi should be able to handle the requested mode.
- * If any of the two fails, return mode as BAD.
+ * Mixer, hdmi and hdmiphy should be able to handle the requested mode.
+ * If any of the them fails, return mode as BAD.
*/
if (mixer_ops mixer_ops-check_mode)
@@ -175,7 +199,13 @@ static int drm_hdmi_check_mode(struct device *dev,
return ret;
if (hdmi_ops hdmi_ops-check_mode)
- return
Re: [PATCH 4/4] ARM: EXYNOS: remove parent device for hdmiphy clock
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma rahul.sha...@samsung.com wrote:
Hdmiphy clock flows from hdmiphy hw to hdmi ip and mixer. It is commonly
accessed among hdmi and hdmiphy driver. During power cycle, each of these
driver decrements the ref-count and ensures that last user disables the
clock. Setting parrent device to none ensure that both the drivers gets
access to the clock.
This seems like the wrong solution. I think you should be trying to
isolate its usage to one driver, instead of removing devname.
Sean
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/mach-exynos/clock-exynos4.c |1 -
arch/arm/mach-exynos/clock-exynos5.c |1 -
2 files changed, 2 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos4.c
b/arch/arm/mach-exynos/clock-exynos4.c
index 8a8468d..a43afcd 100644
--- a/arch/arm/mach-exynos/clock-exynos4.c
+++ b/arch/arm/mach-exynos/clock-exynos4.c
@@ -562,7 +562,6 @@ static struct clk exynos4_init_clocks_off[] = {
.ctrlbit= (1 3),
}, {
.name = hdmiphy,
- .devname= exynos4-hdmi,
.enable = exynos4_clk_hdmiphy_ctrl,
.ctrlbit= (1 0),
}, {
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),
}, {
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] ARM: EXYNOS: remove parent device for hdmiphy clock
Hi,
On 04/29/2013 07:04 PM, Sean Paul wrote:
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma rahul.sha...@samsung.com
wrote:
Hdmiphy clock flows from hdmiphy hw to hdmi ip and mixer. It is commonly
accessed among hdmi and hdmiphy driver. During power cycle, each of these
driver decrements the ref-count and ensures that last user disables the
clock. Setting parrent device to none ensure that both the drivers gets
access to the clock.
This seems like the wrong solution. I think you should be trying to
isolate its usage to one driver, instead of removing devname.
And files:
arch/arm/mach-exynos/clock-exynos4.c
arch/arm/mach-exynos/clock-exynos5.c
are not existent in linux-next for some time already. Since 3.10 the
common clock API driver is used. It also shows that very few people
actually test their patches against -next... :(
Regards,
Sylwester
Sean
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/mach-exynos/clock-exynos4.c |1 -
arch/arm/mach-exynos/clock-exynos5.c |1 -
2 files changed, 2 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos4.c
b/arch/arm/mach-exynos/clock-exynos4.c
index 8a8468d..a43afcd 100644
--- a/arch/arm/mach-exynos/clock-exynos4.c
+++ b/arch/arm/mach-exynos/clock-exynos4.c
@@ -562,7 +562,6 @@ static struct clk exynos4_init_clocks_off[] = {
.ctrlbit= (1 3),
}, {
.name = hdmiphy,
- .devname= exynos4-hdmi,
.enable = exynos4_clk_hdmiphy_ctrl,
.ctrlbit= (1 0),
}, {
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),
}, {
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] mgag200 code cleanup patches
I submitted these a while ago, but I think they got lost in the mailing list. Just wanted to make sure they get a shot at the merge window. thanks, Christopher Harvey (3): drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth drm/mgag200: Pass driver specific mga_device in driver functions drm/mgag200: Remove extra variable assigns drivers/gpu/drm/mgag200/mgag200_fb.c | 3 --- drivers/gpu/drm/mgag200/mgag200_main.c | 2 -- drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++ 3 files changed, 3 insertions(+), 9 deletions(-) -- 1.8.1.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/gpu/drm/mgag200/mgag200_fb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index d2253f6..a5a1f34 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -105,12 +105,9 @@ static int mgag200fb_create_object(struct mga_fbdev
*afbdev,
struct drm_gem_object **gobj_p)
{
struct drm_device *dev = afbdev-helper.dev;
- u32 bpp, depth;
u32 size;
struct drm_gem_object *gobj;
-
int ret = 0;
- drm_fb_get_bpp_depth(mode_cmd-pixel_format, depth, bpp);
size = mode_cmd-pitches[0] * mode_cmd-height;
ret = mgag200_gem_create(dev, size, true, gobj);
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mgag200: Pass driver specific mga_device in driver functions
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 78d8e91..f988965 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1254,9 +1254,8 @@ static const struct drm_crtc_helper_funcs
mga_helper_funcs = {
};
/* CRTC setup */
-static void mga_crtc_init(struct drm_device *dev)
+static void mga_crtc_init(struct mga_device *mdev)
{
- struct mga_device *mdev = dev-dev_private;
struct mga_crtc *mga_crtc;
int i;
@@ -1267,7 +1266,7 @@ static void mga_crtc_init(struct drm_device *dev)
if (mga_crtc == NULL)
return;
- drm_crtc_init(dev, mga_crtc-base, mga_crtc_funcs);
+ drm_crtc_init(mdev-dev, mga_crtc-base, mga_crtc_funcs);
drm_mode_crtc_set_gamma_size(mga_crtc-base, MGAG200_LUT_SIZE);
mdev-mode_info.crtc = mga_crtc;
@@ -1522,7 +1521,7 @@ int mgag200_modeset_init(struct mga_device *mdev)
mdev-dev-mode_config.fb_base = mdev-mc.vram_base;
- mga_crtc_init(mdev-dev);
+ mga_crtc_init(mdev);
encoder = mga_encoder_init(mdev-dev);
if (!encoder) {
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mgag200: Remove extra variable assigns
These two variables are set again immediately in 'mgag200_modeset_init' Signed-off-by: Christopher Harvey char...@matrox.com --- drivers/gpu/drm/mgag200/mgag200_main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c b/drivers/gpu/drm/mgag200/mgag200_main.c index 64297c7..b762bfb 100644 --- a/drivers/gpu/drm/mgag200/mgag200_main.c +++ b/drivers/gpu/drm/mgag200/mgag200_main.c @@ -234,8 +234,6 @@ int mgag200_driver_load(struct drm_device *dev, unsigned long flags) drm_mode_config_init(dev); dev-mode_config.funcs = (void *)mga_mode_funcs; - dev-mode_config.min_width = 0; - dev-mode_config.min_height = 0; dev-mode_config.preferred_depth = 24; dev-mode_config.prefer_shadow = 1; -- 1.8.1.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
https://bugs.freedesktop.org/show_bug.cgi?id=63935 --- Comment #6 from Dave Witbrodt dawit...@sbcglobal.net --- FWIW, I'm seeing this same firmware issue on a SUMO2 system: [1.305718] [drm] Initialized drm 1.1.0 20060810 [1.305767] [drm] radeon kernel modesetting enabled. [1.305964] [drm] initializing kernel modesetting (SUMO2 0x1002:0x9644 0x1849:0x9640). [1.306030] [drm] register mmio base: 0xFEF0 [1.306064] [drm] register mmio size: 262144 [1.306155] ATOM BIOS: General [1.306231] radeon :00:01.0: VRAM: 256M 0x - 0x0FFF (256M used) [1.306272] radeon :00:01.0: GTT: 512M 0x1000 - 0x2FFF [1.306315] mtrr: type mismatch for c000,1000 old: write-back new: write-combining [1.306355] [drm] Detected VRAM RAM=256M, BAR=256M [1.306389] [drm] RAM width 32bits DDR [1.306520] [TTM] Zone kernel: Available graphics memory: 1885900 kiB [1.306563] [TTM] Initializing pool allocator [1.306601] [TTM] Initializing DMA pool allocator [1.306659] [drm] radeon: 256M of VRAM memory ready [1.306694] [drm] radeon: 512M of GTT memory ready. [1.306730] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [1.306765] [drm] Driver supports precise vblank timestamp query. [1.306839] radeon :00:01.0: irq 41 for MSI/MSI-X [1.306849] radeon :00:01.0: radeon: using MSI. [1.306901] [drm] radeon: irq initialized. [1.307950] [drm] GART: num cpu pages 131072, num gpu pages 131072 [1.309023] [drm] Loading SUMO2 Microcode [1.316957] [drm] PCIE GART of 512M enabled (table at 0x00273000). [1.317116] radeon :00:01.0: WB enabled [1.317148] radeon :00:01.0: fence driver on ring 0 use gpu addr 0x1c00 and cpu addr 0x88012a178c00 [1.317186] radeon :00:01.0: fence driver on ring 3 use gpu addr 0x1c0c and cpu addr 0x88012a178c0c [1.317414] radeon :00:01.0: fence driver on ring 5 use gpu addr 0x00072118 and cpu addr 0xc900106b2118 [1.334080] [drm] ring test on 0 succeeded in 1 usecs [1.334176] [drm] ring test on 3 succeeded in 1 usecs [2.281926] tsc: Refined TSC clocksource calibration: 2695.097 MHz [2.376808] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [3.394476] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [4.412139] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [5.429805] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [6.447468] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [7.465130] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [8.482797] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [9.500460] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 10.518126] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 11.535793] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 11.555786] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!! [ 11.575783] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). [ 11.576227] [drm] ib test on ring 0 succeeded in 0 usecs [ 11.576294] [drm] ib test on ring 3 succeeded in 0 usecs [ 11.577202] [drm] Radeon Display Connectors [ 11.577236] [drm] Connector 0: [ 11.577269] [drm] HDMI-A-1 [ 11.577302] [drm] HPD2 [ 11.577335] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [ 11.578434] [drm] Encoders: [ 11.578467] [drm] DFP1: INTERNAL_UNIPHY2 [ 11.578501] [drm] Connector 1: [ 11.578533] [drm] VGA-1 [ 11.578566] [drm] HPD1 [ 11.578599] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [ 11.578652] [drm] Encoders: [ 11.578685] [drm] CRT1: INTERNAL_UNIPHY2 [ 11.578719] [drm] CRT1: NUTMEG [ 11.595893] [drm] Internal thermal controller without fan control [ 11.595949] [drm] radeon: power management initialized [ 11.660512] [drm] fb mappable at 0xC0375000 [ 11.660542] [drm] vram apper at 0xC000 [ 11.660570] [drm] size 9216000 [ 11.660598] [drm] fb depth is 24 [ 11.660626] [drm]pitch is 7680 [ 11.660828] fbcon: radeondrmfb (fb0) is primary device [ 11.738729] Console: switching to colour frame buffer device 240x75 [ 11.745079] radeon :00:01.0: fb0: radeondrmfb frame buffer device [ 11.745110] radeon :00:01.0: registered panic notifier [ 11.745140] [drm] Initialized radeon 2.33.0 20080528 for :00:01.0 on minor 0 This is on a machine I use as a file server, with no X Windows installed; on my desktop machine (using Juniper), I have successfully built and run the same kernel with the new JUNIPER_rlc.bin and CYPRESS_uvd.bin files (and the old JUNIPER_me.bin and JUNIPER_pfp.bin
Re: [PATCH] mgag200 code cleanup patches
Christopher Harvey char...@matrox.com writes: I submitted these a while ago, but I think they got lost in the mailing list. Just wanted to make sure they get a shot at the merge window. thanks, Christopher Harvey (3): drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth drm/mgag200: Pass driver specific mga_device in driver functions drm/mgag200: Remove extra variable assigns drivers/gpu/drm/mgag200/mgag200_fb.c | 3 --- drivers/gpu/drm/mgag200/mgag200_main.c | 2 -- drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++ 3 files changed, 3 insertions(+), 9 deletions(-) the drm-next branch is what gets merged into merge windows, right? http://cgit.freedesktop.org/~airlied/linux/ -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm-openchrome status (or will it be in Kernel 3.10?)
On Tue, Apr 30, 2013 at 2:17 AM, Johannes Obermayr johannesoberm...@gmx.de wrote: Hi James, Linus recently released Kernel 3.9, merge window for Kernel 3.10 has been opened, and the question is whether drm-openchrome will be part of the new Kernel version. Johannes, you misunderstand merge window. The merge window is for stuff to go from toplevel maintainers to Linus, not for new stuff to appear and be merged. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=63520 --- Comment #4 from PJBrs pj...@floorenpj.xs4all.nl --- I've run the Penumbra Requiem game with RADEON_DEBUG=fp,vp and captured the output. I made two attachments. The file named Goodlog is the log with mesa version snb_magic_9030_g342cac7 (commit 342cac71669662abad3435fd13ecf28d073874c3). The file named badlog is the output with mesa version snb-magic-9031-g134a0a5 (commit 134a0a5ff88851c971fb95863317f640b5b9fa3a). Let me know if any other information is needed. -- 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 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=63520 --- Comment #5 from PJBrs pj...@floorenpj.xs4all.nl --- Created attachment 78616 -- https://bugs.freedesktop.org/attachment.cgi?id=78616action=edit First bad penumbra output with RADEON_DEBUG=fp,vp -- 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 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=63520 --- Comment #6 from PJBrs pj...@floorenpj.xs4all.nl --- Created attachment 78617 -- https://bugs.freedesktop.org/attachment.cgi?id=78617action=edit Last good penumbra output with RADEON_DEBUG=fp,vp -- 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-openchrome status (or will it be in Kernel 3.10?)
Am Dienstag, 30. April 2013, 06:06:22 schrieb Dave Airlie: On Tue, Apr 30, 2013 at 2:17 AM, Johannes Obermayr johannesoberm...@gmx.de wrote: Hi James, Linus recently released Kernel 3.9, merge window for Kernel 3.10 has been opened, and the question is whether drm-openchrome will be part of the new Kernel version. Johannes, you misunderstand merge window. The merge window is for stuff to go from toplevel maintainers to Linus, not for new stuff to appear and be merged. Dave, I know you maintain also a merge window for drm stuff which starts at ~ rc6. But I am unsure when it closes: When Linus opens his merge window or when you forward your main drm pull request to Linus. First case means it is definitely too late for drm-openchrome in 3.10. Second case means there can be hope (depending on James' answer) ... But regarding your answer I assume first case is right. Johannes ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm-openchrome status (or will it be in Kernel 3.10?)
On Tue, Apr 30, 2013 at 7:27 AM, Johannes Obermayr johannesoberm...@gmx.de wrote: Am Dienstag, 30. April 2013, 06:06:22 schrieb Dave Airlie: On Tue, Apr 30, 2013 at 2:17 AM, Johannes Obermayr johannesoberm...@gmx.de wrote: Hi James, Linus recently released Kernel 3.9, merge window for Kernel 3.10 has been opened, and the question is whether drm-openchrome will be part of the new Kernel version. Johannes, you misunderstand merge window. The merge window is for stuff to go from toplevel maintainers to Linus, not for new stuff to appear and be merged. Dave, I know you maintain also a merge window for drm stuff which starts at ~ rc6. But I am unsure when it closes: When Linus opens his merge window or when you forward your main drm pull request to Linus. First case means it is definitely too late for drm-openchrome in 3.10. Second case means there can be hope (depending on James' answer) ... But regarding your answer I assume first case is right. Once Linus opens his window, I won't accept anything major that hasn't been posted to the list for review before. I generally have a lag time of hoovering up on the list stuff, but something like this that has never been posted would have no hope. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
