Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
2013/10/4 Olof Johansson o...@lixom.net: On Thu, Oct 3, 2013 at 10:39 AM, Inki Dae inki@samsung.com wrote: 2013/10/3 Sean Paul seanp...@chromium.org: On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote: Can a regulator be used instead of gpio in other board case? No, not to my knowledge. Hm.. plz check it out again. the gpio pin is specific to board, and the the gpio be used as power source trigger could be replaced with a regulator according to board design. So you should consider all possibilities even though there are no other cases yet: other board could use a regulator instead. Take a look at the data sheet, it is publicly available. PD_N is not a power supply input, so modelling it as a regulator makes no sense: If PD_N is LOW, then the device is in Deep power-down completely, even if supply rail is ON; for the device to be able to operate, the PD_N pin must be HIGH. I still think the pin could be replaced with a regulator. But lvds-bridge node has powerdown-gpio property - it say this board will use gpio pin - specific to board. So it seems no problem. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
2013/10/4 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2:
- Changed include from of_i2c.h to i2c.h
- Changed of_find_by_name to of_find_compatible
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..08ca4f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *compat, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_compatible_node(NULL, NULL, compat);
Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
that such tricky isn't needed? Is there any reason you use such tricky
codes?
I think you need to implement the lvds-bridge driver as i2c driver,
and then consider how to take care of this. I mean let's find a better
way how we could take care of the i2c based driver in exynos drm
framework or driver. In all cases, such tricky codes are not good.
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(nxp,ptn3460, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
DRM_ERROR(failed to create encoder\n);
return -EFAULT;
}
+ subdrv-encoder = encoder;
+
+ if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD) {
+ ret = exynos_drm_attach_lcd_bridge(dev, encoder);
+ if (ret)
+ return 0;
+ }
/*
* create and initialize a connector for this sub driver and
@@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
goto err_destroy_encoder;
}
- subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70108] New: [bisected e64633e8c3a5498998a45ab721bf80edca101cf5] regression: bad rendering on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=70108 Priority: medium Bug ID: 70108 Assignee: dri-devel@lists.freedesktop.org Summary: [bisected e64633e8c3a5498998a45ab721bf80edca101cf5] regression: bad rendering on r600g Severity: normal Classification: Unclassified OS: All Reporter: alexandre.f.dem...@gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa I noticed a couple of days ago a regression on some demo applications where the light or shadows wouldn't be rendered correctly. They form lines. This can be observed testing Unigine where light reflecting on water or on the dock will not be rendered correctly. Bisecting gave me the following result: git bisect bad e64633e8c3a5498998a45ab721bf80edca101cf5 is the first bad commit commit e64633e8c3a5498998a45ab721bf80edca101cf5 Author: Marek Olšák marek.ol...@amd.com Date: Sun Sep 22 13:06:27 2013 +0200 r600g,radeonsi: share r600_texture.c The function r600_choose_tiling is new and needs a review. The only change in functionality is that it enables 2D tiling for compressed textures on SI. It was probably accidentally turned off. v2: don't make scanout buffers linear :04 04 138f5235123706d30903e259a8c7651ee53e9fd5 79f8e5d3497c5d2a3c71bb6ba968ecf5fd4c1a1a Msrc I'm using HD 6950 on ArchLinux 64, with latest drm and ddx from git. -- 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 v2 4/5] drm/exynos: Initialize ptn3460 if present
On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2:
- Changed include from of_i2c.h to i2c.h
- Changed of_find_by_name to of_find_compatible
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..08ca4f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *compat, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_compatible_node(NULL, NULL, compat);
Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
that such tricky isn't needed? Is there any reason you use such tricky
codes?
This is what I was explaining earlier today. If the bridge driver is
just an i2c driver, it won't get a pointer to drm_device, and can't
register itself as a drm_bridge or drm_connector. To solve this, you
need the ptn3460_init callback.
If it's an i2c driver with the ptn3460_init callback, where it parses
the dt in probe, then you have a race between the ptn probe and the
ptn init/drm hooks. ie: it's possible drm will initialize and call
disable/post_disable/pre_enable/enable before things have been probed.
To solve this, you need to use some global state and/or locking.
So, to summarize. We can have this of_find_compatible with a init
callback, or we can have an i2c driver + global state/locking + init
callback. I chose the former, since it seemed easier.
If you have a better way to achieve this, I'm definitely interested,
but I saw this as the lesser of two evils.
Sean
I think you need to implement the lvds-bridge driver as i2c driver,
and then consider how to take care of this. I mean let's find a better
way how we could take care of the i2c based driver in exynos drm
framework or driver. In all cases, such tricky codes are not good.
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(nxp,ptn3460, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
DRM_ERROR(failed to create encoder\n);
return -EFAULT;
}
+ subdrv-encoder = encoder;
+
+ if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD) {
+ ret = exynos_drm_attach_lcd_bridge(dev, encoder);
+ if (ret)
+ return 0;
+ }
/*
* create and initialize a connector for this sub driver and
@@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
goto err_destroy_encoder;
}
- subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Build failure after merge of the drm-intel tree
After merging the drm-intel tree into -next an x86 allmodconfig build fails with: In file included from include/linux/kobject.h:29:0, from include/linux/cpufreq.h:16, from drivers/gpu/drm/i915/intel_pm.c:28: drivers/gpu/drm/i915/intel_pm.c: In function ‘intel_pm_init’: drivers/gpu/drm/i915/intel_pm.c:5883:34: error: ‘struct intel_gen6_power_mgmt’ has no member named ‘vlv_work’ INIT_DELAYED_WORK(dev_priv-rps.vlv_work, vlv_rps_timer_work); ^ include/linux/workqueue.h:216:16: note: in definition of macro ‘__INIT_WORK’ __init_work((_work), _onstack);\ ^ include/linux/workqueue.h:244:3: note: in expansion of macro ‘INIT_WORK’ INIT_WORK((_work)-work, (_func)); \ ^ include/linux/workqueue.h:260:2: note: in expansion of macro ‘__INIT_DELAYED_WORK’ __INIT_DELAYED_WORK(_work, _func, 0) ^ drivers/gpu/drm/i915/intel_pm.c:5883:2: note: in expansion of macro ‘INIT_DELAYED_WORK’ INIT_DELAYED_WORK(dev_priv-rps.vlv_work, vlv_rps_timer_work); ^ drivers/gpu/drm/i915/intel_pm.c:5883:34: error: ‘struct intel_gen6_power_mgmt’ has no member named ‘vlv_work’ INIT_DELAYED_WORK(dev_priv-rps.vlv_work, vlv_rps_timer_work); ^ and so on caused by 671952a2a290a (drm/i915: fix rps.vlv_work initialization) in the drm-intel-fixes tree interacting with ac3a48b3036 (drm/i915: Boost RPS frequency for CPU stalls) from the drm-intel tree. I have used the fix below for today: From 4f4dccef92d64393e2a7e867f7c2755c09178c48 Mon Sep 17 00:00:00 2001 From: Mark Brown broo...@linaro.org Date: Thu, 3 Oct 2013 18:10:55 +0100 Subject: [PATCH] drm/i915: Resolve interaction with drm-fixes tree Signed-off-by: Mark Brown broo...@linaro.org --- drivers/gpu/drm/i915/intel_pm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 7cdac0b..0b4de57 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5879,7 +5879,5 @@ void intel_pm_init(struct drm_device *dev) INIT_DELAYED_WORK(dev_priv-rps.delayed_resume_work, intel_gen6_powersave_work); - - INIT_DELAYED_WORK(dev_priv-rps.vlv_work, vlv_rps_timer_work); } -- 1.8.4.rc3 signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] i2c: Remove redundant driver field from the i2c_client struct
On Sun, Sep 29, 2013 at 10:50:58AM +0200, Lars-Peter Clausen wrote: Hi, This series removes the redundant driver field from the i2c_client struct. The field is redundant since the same pointer can be accessed through to_i2c_driver(client-dev.driver). The commit log suggests that the field has been around since forever (since before v2.6.12-rc2) and it looks as if it was simply forgotten to remove it during the conversion of the i2c framework to the generic device driver model. Applied to for-next with great pleasure, thanks! signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/5] ARM: dts: Add fimd display-timings for exynos5250-snow
On Friday, October 04, 2013 7:28 AM, Sean Paul wrote:
This patch adds the internal panel timings to the exynos5250-snow board
dts file.
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2: No difference
arch/arm/boot/dts/exynos5250-snow.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index fd711e2..2a0f0de 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -186,6 +186,23 @@
samsung,vbus-gpio = gpx1 1 0;
};
+ fimd: fimd@1440 {
+ display-timings {
How about adding 'status = okay' as below?
fimd: fimd@1440 {
status = okay;
display-timings {
status of fimd node was disabled by exynos5.dtsi
./arch/arm/boot/dts/exynos5.dtsi
fimd@1440 {
status = disabled;
Best regards,
Jingoo Han
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/5] ARM: dts: Add dp-controller node to exynos5250-snow
On Friday, October 04, 2013 7:28 AM, Sean Paul wrote:
This patch adds the dp-controller node to the exynos5250-snow board dts
file.
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2: Added dp-controller address to node (rebased on linux-next)
arch/arm/boot/dts/exynos5250-snow.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 2a0f0de..f1cf68e 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -186,6 +186,18 @@
samsung,vbus-gpio = gpx1 1 0;
};
+ dp-controller@145B {
+ samsung,color-space = 0;
+ samsung,dynamic-range = 0;
+ samsung,ycbcr-coeff = 0;
+ samsung,color-depth = 1;
+ samsung,link-rate = 0x0a;
+ samsung,lane-count = 2;
+
+ pinctrl-names = default;
+ pinctrl-0 = dp_hpd;
How about adding 'status = okay as below?
pinctrl-names = default;
pinctrl-0 = dp_hpd;
status = okay;
status of dp node was disabled by exynos5.dtsi.
./arch/arm/boot/dts/exynos5.dtsi
dp-controller@145B {
status = disabled;
Best regards,
Jingoo Han
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70110] New: [bisected] regression: assert in r600_bind_sampler_states since 27c054edf0ae92c8c498830e7c7510fa94f5dcfd
https://bugs.freedesktop.org/show_bug.cgi?id=70110 Priority: medium Bug ID: 70110 Assignee: dri-devel@lists.freedesktop.org Summary: [bisected] regression: assert in r600_bind_sampler_states since 27c054edf0ae92c8c498830e7c7510fa94f5dcfd Severity: normal Classification: Unclassified OS: All Reporter: alexandre.f.dem...@gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa ~/projects/display/openGL/tests/tropics_32$ ~/projects/display/test-gallium-32.sh ./1024x768_windowed.sh Launching ./1024x768_windowed.sh r600_state_common.c:399:r600_bind_sampler_states: Assertion `!Only vertex/fragment sampler are implemented.' failed. ./1024x768_windowed.sh: line 13: 24122 Trace/breakpoint trap (core dumped) ./bin/Tropics -video_app opengl -sound_app openal -extern_define RELEASE -system_script tropics/unigine.cpp -engine_config ../data/unigine.cfg -data_path ../ -video_fullscreen 0 -video_mode -1 -video_width 1024 -video_height 768 On HD 6950 First bad commit: 27c054edf0ae92c8c498830e7c7510fa94f5dcfd radeon: don't use old bind_vertex/fragment_sampler_states() hooks Author Brian Paulbri...@vmware.com Author date 9/12/13 5:45 PM Parent i915g: remove old bind_vertex/fragment_sampler_states() h... Child svga: don't hook in old bind_fragment_sampler_states() fu... Branch origin/master (radeonsi/compute: Fix segfault caused by recent refactoring) Follows snb-magic (graw: Add struct pipe_surface forward declaration.) radeon: don't use old bind_vertex/fragment_sampler_states() hooks -- 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 70088] Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 --- Comment #6 from Krzysztof A. Sobiecki sob...@gmail.com --- Created attachment 87098 -- https://bugs.freedesktop.org/attachment.cgi?id=87098action=edit It fixes my crash problem It fixes my crash problem. Maybe code needs more checks for null values? As always my patch is subpar, You shouldn't use it. -- 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 v2 4/5] drm/exynos: Initialize ptn3460 if present
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2:
- Changed include from of_i2c.h to i2c.h
- Changed of_find_by_name to of_find_compatible
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..08ca4f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *compat, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_compatible_node(NULL, NULL, compat);
Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
that such tricky isn't needed? Is there any reason you use such tricky
codes?
This is what I was explaining earlier today. If the bridge driver is
just an i2c driver, it won't get a pointer to drm_device, and can't
register itself as a drm_bridge or drm_connector. To solve this, you
need the ptn3460_init callback.
No, I think you can use sub driver. how about registering to exynos
drm core that driver using exynos_drm_subdrv_register function after
probed? Is there something I am missing?
If it's an i2c driver with the ptn3460_init callback, where it parses
the dt in probe, then you have a race between the ptn probe and the
ptn init/drm hooks. ie: it's possible drm will initialize and call
disable/post_disable/pre_enable/enable before things have been probed.
And also, exynos drm core will call a probe callback of the sub driver
after _drm is initialized_. Is there something I am missing?
To solve this, you need to use some global state and/or locking.
So, to summarize. We can have this of_find_compatible with a init
callback, or we can have an i2c driver + global state/locking + init
callback. I chose the former, since it seemed easier.
If you have a better way to achieve this, I'm definitely interested,
but I saw this as the lesser of two evils.
Sean
I think you need to implement the lvds-bridge driver as i2c driver,
and then consider how to take care of this. I mean let's find a better
way how we could take care of the i2c based driver in exynos drm
framework or driver. In all cases, such tricky codes are not good.
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(nxp,ptn3460, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client,
bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
DRM_ERROR(failed to create encoder\n);
return -EFAULT;
}
+ subdrv-encoder = encoder;
+
+ if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD) {
+ ret = exynos_drm_attach_lcd_bridge(dev, encoder);
+ if (ret)
+ return 0;
+ }
/*
* create and initialize a connector for this sub driver and
@@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
goto err_destroy_encoder;
}
- subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe
linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the
[Bug 69983] [r600g, bisected] Screen corruption in Firefox, World of Warcraft and other apps
https://bugs.freedesktop.org/show_bug.cgi?id=69983 --- Comment #14 from Marc Dietrich marvi...@gmx.de --- confirmed fixed -- 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] drm: Try loading builtin EDIDs first
If the firmware is builtin and userspace is not yet running, we can
stall the boot process for a minute whilst the firmware loader times
out probing for a non-existent connector EDID. This is contrary to the
expectations of providing a builtin EDID!
In the process, we can rearrange the code to make the error handling
more resilient and prevent gcc warning about unitialised variables along
the error paths.
v2: Load builtins first, fix gcc second (Jani) and cosmetics (Ville).
v3: Verify that we do not read beyond the end of the fwdata (Ville)
v4: Restore the lost parenthesis (Jani)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Jani Nikula jani.nik...@linux.intel.com
Reviewed-by: Jani Nikula jani.nik...@linux.intel.com
---
drivers/gpu/drm/drm_edid_load.c | 108
1 file changed, 54 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 271b42bbfb72..75f204bbb888 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -32,7 +32,7 @@ MODULE_PARM_DESC(edid_firmware, Do not probe monitor, use
specified EDID blob
from built-in data or /lib/firmware instead. );
#define GENERIC_EDIDS 5
-static char *generic_edid_name[GENERIC_EDIDS] = {
+static const char *generic_edid_name[GENERIC_EDIDS] = {
edid/1024x768.bin,
edid/1280x1024.bin,
edid/1600x1200.bin,
@@ -40,7 +40,7 @@ static char *generic_edid_name[GENERIC_EDIDS] = {
edid/1920x1080.bin,
};
-static u8 generic_edid[GENERIC_EDIDS][128] = {
+static const u8 generic_edid[GENERIC_EDIDS][128] = {
{
0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
0x31, 0xd8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
@@ -133,63 +133,68 @@ static u8 generic_edid[GENERIC_EDIDS][128] = {
},
};
+static int edid_size(const u8 *edid, int data_size)
+{
+ if (data_size EDID_LENGTH)
+ return 0;
+
+ return (edid[0x7e] + 1) * EDID_LENGTH;
+}
+
static u8 *edid_load(struct drm_connector *connector, const char *name,
const char *connector_name)
{
- const struct firmware *fw;
- struct platform_device *pdev;
- u8 *fwdata = NULL, *edid, *new_edid;
- int fwsize, expected;
- int builtin = 0, err = 0;
+ const struct firmware *fw = NULL;
+ const u8 *fwdata;
+ u8 *edid;
+ int fwsize, builtin;
int i, valid_extensions = 0;
bool print_bad_edid = !connector-bad_edid_counter || (drm_debug
DRM_UT_KMS);
- pdev = platform_device_register_simple(connector_name, -1, NULL, 0);
- if (IS_ERR(pdev)) {
- DRM_ERROR(Failed to register EDID firmware platform device
- for connector \%s\\n, connector_name);
- err = -EINVAL;
- goto out;
- }
-
- err = request_firmware(fw, name, pdev-dev);
- platform_device_unregister(pdev);
-
- if (err) {
- i = 0;
- while (i GENERIC_EDIDS strcmp(name, generic_edid_name[i]))
- i++;
- if (i GENERIC_EDIDS) {
- err = 0;
- builtin = 1;
+ builtin = 0;
+ for (i = 0; i GENERIC_EDIDS; i++) {
+ if (strcmp(name, generic_edid_name[i]) == 0) {
fwdata = generic_edid[i];
fwsize = sizeof(generic_edid[i]);
+ builtin = 1;
+ break;
}
}
+ if (!builtin) {
+ struct platform_device *pdev;
+ int err;
- if (err) {
- DRM_ERROR(Requesting EDID firmware \%s\ failed (err=%d)\n,
- name, err);
- goto out;
- }
+ pdev = platform_device_register_simple(connector_name, -1,
NULL, 0);
+ if (IS_ERR(pdev)) {
+ DRM_ERROR(Failed to register EDID firmware platform
device
+ for connector \%s\\n, connector_name);
+ return ERR_CAST(pdev);
+ }
+
+ err = request_firmware(fw, name, pdev-dev);
+ platform_device_unregister(pdev);
+ if (err) {
+ DRM_ERROR(Requesting EDID firmware \%s\ failed
(err=%d)\n,
+ name, err);
+ return ERR_PTR(err);
+ }
- if (fwdata == NULL) {
- fwdata = (u8 *) fw-data;
+ fwdata = fw-data;
fwsize = fw-size;
}
- expected = (fwdata[0x7e] + 1) * EDID_LENGTH;
- if (expected != fwsize) {
+ if (edid_size(fwdata, fwsize) != fwsize) {
DRM_ERROR(Size of EDID firmware \%s\ is invalid
- (expected %d, got %d)\n, name, expected, (int) fwsize);
-
Re: [PATCH] drm: Try loading builtin EDIDs first
On Fri, 04 Oct 2013, Chris Wilson ch...@chris-wilson.co.uk wrote:
If the firmware is builtin and userspace is not yet running, we can
stall the boot process for a minute whilst the firmware loader times
out probing for a non-existent connector EDID. This is contrary to the
expectations of providing a builtin EDID!
In the process, we can rearrange the code to make the error handling
more resilient and prevent gcc warning about unitialised variables along
the error paths.
v2: Load builtins first, fix gcc second (Jani) and cosmetics (Ville).
v3: Verify that we do not read beyond the end of the fwdata (Ville)
v4: Restore the lost parenthesis (Jani)
Thanks, looks good,
Jani.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Jani Nikula jani.nik...@linux.intel.com
Reviewed-by: Jani Nikula jani.nik...@linux.intel.com
---
drivers/gpu/drm/drm_edid_load.c | 108
1 file changed, 54 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 271b42bbfb72..75f204bbb888 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -32,7 +32,7 @@ MODULE_PARM_DESC(edid_firmware, Do not probe monitor, use
specified EDID blob
from built-in data or /lib/firmware instead. );
#define GENERIC_EDIDS 5
-static char *generic_edid_name[GENERIC_EDIDS] = {
+static const char *generic_edid_name[GENERIC_EDIDS] = {
edid/1024x768.bin,
edid/1280x1024.bin,
edid/1600x1200.bin,
@@ -40,7 +40,7 @@ static char *generic_edid_name[GENERIC_EDIDS] = {
edid/1920x1080.bin,
};
-static u8 generic_edid[GENERIC_EDIDS][128] = {
+static const u8 generic_edid[GENERIC_EDIDS][128] = {
{
0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
0x31, 0xd8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
@@ -133,63 +133,68 @@ static u8 generic_edid[GENERIC_EDIDS][128] = {
},
};
+static int edid_size(const u8 *edid, int data_size)
+{
+ if (data_size EDID_LENGTH)
+ return 0;
+
+ return (edid[0x7e] + 1) * EDID_LENGTH;
+}
+
static u8 *edid_load(struct drm_connector *connector, const char *name,
const char *connector_name)
{
- const struct firmware *fw;
- struct platform_device *pdev;
- u8 *fwdata = NULL, *edid, *new_edid;
- int fwsize, expected;
- int builtin = 0, err = 0;
+ const struct firmware *fw = NULL;
+ const u8 *fwdata;
+ u8 *edid;
+ int fwsize, builtin;
int i, valid_extensions = 0;
bool print_bad_edid = !connector-bad_edid_counter || (drm_debug
DRM_UT_KMS);
- pdev = platform_device_register_simple(connector_name, -1, NULL, 0);
- if (IS_ERR(pdev)) {
- DRM_ERROR(Failed to register EDID firmware platform device
- for connector \%s\\n, connector_name);
- err = -EINVAL;
- goto out;
- }
-
- err = request_firmware(fw, name, pdev-dev);
- platform_device_unregister(pdev);
-
- if (err) {
- i = 0;
- while (i GENERIC_EDIDS strcmp(name, generic_edid_name[i]))
- i++;
- if (i GENERIC_EDIDS) {
- err = 0;
- builtin = 1;
+ builtin = 0;
+ for (i = 0; i GENERIC_EDIDS; i++) {
+ if (strcmp(name, generic_edid_name[i]) == 0) {
fwdata = generic_edid[i];
fwsize = sizeof(generic_edid[i]);
+ builtin = 1;
+ break;
}
}
+ if (!builtin) {
+ struct platform_device *pdev;
+ int err;
- if (err) {
- DRM_ERROR(Requesting EDID firmware \%s\ failed (err=%d)\n,
- name, err);
- goto out;
- }
+ pdev = platform_device_register_simple(connector_name, -1,
NULL, 0);
+ if (IS_ERR(pdev)) {
+ DRM_ERROR(Failed to register EDID firmware platform
device
+ for connector \%s\\n, connector_name);
+ return ERR_CAST(pdev);
+ }
+
+ err = request_firmware(fw, name, pdev-dev);
+ platform_device_unregister(pdev);
+ if (err) {
+ DRM_ERROR(Requesting EDID firmware \%s\ failed
(err=%d)\n,
+ name, err);
+ return ERR_PTR(err);
+ }
- if (fwdata == NULL) {
- fwdata = (u8 *) fw-data;
+ fwdata = fw-data;
fwsize = fw-size;
}
- expected = (fwdata[0x7e] + 1) * EDID_LENGTH;
- if (expected != fwsize) {
+ if (edid_size(fwdata, fwsize) != fwsize) {
DRM_ERROR(Size of EDID firmware \%s\ is invalid
-
[Bug 70073] [r300g] Stop calling draw_prepare_shader_outputs
https://bugs.freedesktop.org/show_bug.cgi?id=70073 Fabio Pedretti fabio@libero.it changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Fabio Pedretti fabio@libero.it --- Done with this commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=52bfe8e0f6bba28606502e538a4ba48247b7b4f6 -- 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 70108] [bisected e64633e8c3a5498998a45ab721bf80edca101cf5] regression: bad rendering on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=70108 --- Comment #1 from Marek Olšák mar...@gmail.com --- This should be fixed by c7d91a6f13d9dafe47cfa948619083258bc47cb0. Can you confirm? -- 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 01/10] drm: Make vblank_disable_allowed bool
From: Ville Syrjälä ville.syrj...@linux.intel.com
vblank_disable_allowed is only ever 0 or 1, so make it a bool.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c| 5 +++--
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 4 ++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 ++--
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/staging/imx-drm/imx-drm-core.c | 4 ++--
include/drm/drmP.h | 2 +-
7 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index f92da0a..81b4c84 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -271,7 +271,8 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
atomic_set(dev-vblank_refcount[i], 0);
}
- dev-vblank_disable_allowed = 0;
+ dev-vblank_disable_allowed = false;
+
return 0;
err:
@@ -1085,7 +1086,7 @@ void drm_vblank_post_modeset(struct drm_device *dev, int
crtc)
if (dev-vblank_inmodeset[crtc]) {
spin_lock_irqsave(dev-vbl_lock, irqflags);
- dev-vblank_disable_allowed = 1;
+ dev-vblank_disable_allowed = true;
spin_unlock_irqrestore(dev-vbl_lock, irqflags);
if (dev-vblank_inmodeset[crtc] 0x2)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 868a14d..1648b40 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -725,11 +725,11 @@ static int fimd_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
drm_dev-irq_enabled = 1;
/*
-* with vblank_disable_allowed = 1, vblank interrupt will be disabled
+* with vblank_disable_allowed = true, vblank interrupt will be disabled
* by drm timer once a current process gives up ownership of
* vblank event.(after drm_vblank_put function is called)
*/
- drm_dev-vblank_disable_allowed = 1;
+ drm_dev-vblank_disable_allowed = true;
/* attach this sub driver to iommu mapping if supported. */
if (is_drm_iommu_supported(drm_dev))
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 4400330..1d7273d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -394,11 +394,11 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
drm_dev-irq_enabled = 1;
/*
-* with vblank_disable_allowed = 1, vblank interrupt will be disabled
+* with vblank_disable_allowed = true, vblank interrupt will be disabled
* by drm timer once a current process gives up ownership of
* vblank event.(after drm_vblank_put function is called)
*/
- drm_dev-vblank_disable_allowed = 1;
+ drm_dev-vblank_disable_allowed = true;
return 0;
}
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index fcb4e9f..aa7c201 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -359,7 +359,7 @@ static int psb_driver_load(struct drm_device *dev, unsigned
long chipset)
drm_irq_install(dev);
- dev-vblank_disable_allowed = 1;
+ dev-vblank_disable_allowed = true;
dev-max_vblank_count = 0xff; /* only 24 bits of frame count */
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index f221631..a209147 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1333,7 +1333,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
/* Always safe in the mode setting case. */
/* FIXME: do pre/post-mode set stuff in core KMS code */
- dev-vblank_disable_allowed = 1;
+ dev-vblank_disable_allowed = true;
if (INTEL_INFO(dev)-num_pipes == 0) {
intel_display_power_put(dev, POWER_DOMAIN_VGA);
return 0;
diff --git a/drivers/staging/imx-drm/imx-drm-core.c
b/drivers/staging/imx-drm/imx-drm-core.c
index a2e52a0..52c29b3 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -423,11 +423,11 @@ static int imx_drm_driver_load(struct drm_device *drm,
unsigned long flags)
goto err_init;
/*
-* with vblank_disable_allowed = 1, vblank interrupt will be disabled
+* with vblank_disable_allowed = true, vblank interrupt will be disabled
* by drm timer once a current process gives up ownership of
* vblank event.(after drm_vblank_put function is called)
*/
- imxdrm-drm-vblank_disable_allowed = 1;
+ imxdrm-drm-vblank_disable_allowed = true;
if (!imx_drm_device_get())
ret = -EINVAL;
diff --git
[PATCH 03/10] drm: Make vblank_enabled bool
From: Ville Syrjälä ville.syrj...@linux.intel.com
vblank_enabled is only ever 0 or 1, so make it a bool.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c | 8
drivers/gpu/drm/omapdrm/omap_irq.c | 2 +-
include/drm/drmP.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 81b4c84..49680a8 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -115,7 +115,7 @@ static void vblank_disable_and_save(struct drm_device *dev,
int crtc)
spin_lock_irqsave(dev-vblank_time_lock, irqflags);
dev-driver-disable_vblank(dev, crtc);
- dev-vblank_enabled[crtc] = 0;
+ dev-vblank_enabled[crtc] = false;
/* No further vblank irq's will be processed after
* this point. Get current hardware vblank count and
@@ -235,7 +235,7 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
if (!dev-vblank_refcount)
goto err;
- dev-vblank_enabled = kcalloc(num_crtcs, sizeof(int), GFP_KERNEL);
+ dev-vblank_enabled = kcalloc(num_crtcs, sizeof(bool), GFP_KERNEL);
if (!dev-vblank_enabled)
goto err;
@@ -412,7 +412,7 @@ int drm_irq_uninstall(struct drm_device *dev)
spin_lock_irqsave(dev-vbl_lock, irqflags);
for (i = 0; i dev-num_crtcs; i++) {
DRM_WAKEUP(dev-vbl_queue[i]);
- dev-vblank_enabled[i] = 0;
+ dev-vblank_enabled[i] = false;
dev-last_vblank[i] =
dev-driver-get_vblank_counter(dev, i);
}
@@ -973,7 +973,7 @@ int drm_vblank_get(struct drm_device *dev, int crtc)
if (ret)
atomic_dec(dev-vblank_refcount[crtc]);
else {
- dev-vblank_enabled[crtc] = 1;
+ dev-vblank_enabled[crtc] = true;
drm_update_vblank_count(dev, crtc);
}
}
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 9263db1..3cbe92c 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -308,7 +308,7 @@ int omap_drm_irq_uninstall(struct drm_device *dev)
spin_lock_irqsave(dev-vbl_lock, irqflags);
for (i = 0; i dev-num_crtcs; i++) {
DRM_WAKEUP(dev-vbl_queue[i]);
- dev-vblank_enabled[i] = 0;
+ dev-vblank_enabled[i] = false;
dev-last_vblank[i] =
dev-driver-get_vblank_counter(dev, i);
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 09b4b33..c25986e 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1167,7 +1167,7 @@ struct drm_device {
atomic_t *vblank_refcount; /* number of users of vblank
interruptsper crtc */
u32 *last_vblank; /* protected by dev-vbl_lock, used */
/* for wraparound handling */
- int *vblank_enabled;/* so we don't call enable more than
+ bool *vblank_enabled; /* so we don't call enable more than
once per disable */
unsigned int *vblank_inmodeset; /* Display driver is setting mode */
u32 *last_vblank_wait; /* Last vblank seqno waited per CRTC */
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/10] drm: Make vblank_inmodeset unsigned
From: Ville Syrjälä ville.syrj...@linux.intel.com
vblank_inmodeset is a bitmask, with only two bits mind you, but better
make it unsigned anyway.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
include/drm/drmP.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index b1aa6fc..09b4b33 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1169,7 +1169,7 @@ struct drm_device {
/* for wraparound handling */
int *vblank_enabled;/* so we don't call enable more than
once per disable */
- int *vblank_inmodeset; /* Display driver is setting mode */
+ unsigned int *vblank_inmodeset; /* Display driver is setting mode */
u32 *last_vblank_wait; /* Last vblank seqno waited per CRTC */
struct timer_list vblank_disable_timer;
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/10] drm: Collect per-crtc vblank stuff to a struct
From: Ville Syrjälä ville.syrj...@linux.intel.com
drm_vblank_init() is too ugly. Make it a bit easier on the eye by
collecting all the per-crtc vblank counters, timestamps etc. to
a structure and just allocate an array of those.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_info.c | 6 +-
drivers/gpu/drm/drm_irq.c | 138 +
drivers/gpu/drm/gma500/psb_irq.c | 22 +++---
drivers/gpu/drm/i915/intel_pm.c| 2 +-
drivers/gpu/drm/omapdrm/omap_irq.c | 6 +-
include/drm/drmP.h | 26 ---
6 files changed, 81 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
index 5329832..7d5a152 100644
--- a/drivers/gpu/drm/drm_info.c
+++ b/drivers/gpu/drm/drm_info.c
@@ -163,13 +163,13 @@ int drm_vblank_info(struct seq_file *m, void *data)
mutex_lock(dev-struct_mutex);
for (crtc = 0; crtc dev-num_crtcs; crtc++) {
seq_printf(m, CRTC %d enable: %d\n,
- crtc, atomic_read(dev-vblank_refcount[crtc]));
+ crtc, atomic_read(dev-vblank[crtc].refcount));
seq_printf(m, CRTC %d counter:%d\n,
crtc, drm_vblank_count(dev, crtc));
seq_printf(m, CRTC %d last wait: %d\n,
- crtc, dev-last_vblank_wait[crtc]);
+ crtc, dev-vblank[crtc].last_wait);
seq_printf(m, CRTC %d in modeset: %d\n,
- crtc, dev-vblank_inmodeset[crtc]);
+ crtc, dev-vblank[crtc].inmodeset);
}
mutex_unlock(dev-struct_mutex);
return 0;
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 49680a8..dea859f 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -43,9 +43,8 @@
#include linux/export.h
/* Access macro for slots in vblank timestamp ringbuffer. */
-#define vblanktimestamp(dev, crtc, count) ( \
- (dev)-_vblank_time[(crtc) * DRM_VBLANKTIME_RBSIZE + \
- ((count) % DRM_VBLANKTIME_RBSIZE)])
+#define vblanktimestamp(dev, crtc, count) \
+ ((dev)-vblank[crtc].time[(count) % DRM_VBLANKTIME_RBSIZE])
/* Retry timestamp calculation up to 3 times to satisfy
* drm_timestamp_precision before giving up.
@@ -89,8 +88,7 @@ int drm_irq_by_busid(struct drm_device *dev, void *data,
*/
static void clear_vblank_timestamps(struct drm_device *dev, int crtc)
{
- memset(dev-_vblank_time[crtc * DRM_VBLANKTIME_RBSIZE], 0,
- DRM_VBLANKTIME_RBSIZE * sizeof(struct timeval));
+ memset(dev-vblank[crtc].time, 0, sizeof(dev-vblank[crtc].time));
}
/*
@@ -115,7 +113,7 @@ static void vblank_disable_and_save(struct drm_device *dev,
int crtc)
spin_lock_irqsave(dev-vblank_time_lock, irqflags);
dev-driver-disable_vblank(dev, crtc);
- dev-vblank_enabled[crtc] = false;
+ dev-vblank[crtc].enabled = false;
/* No further vblank irq's will be processed after
* this point. Get current hardware vblank count and
@@ -130,9 +128,9 @@ static void vblank_disable_and_save(struct drm_device *dev,
int crtc)
* delayed gpu counter increment.
*/
do {
- dev-last_vblank[crtc] = dev-driver-get_vblank_counter(dev,
crtc);
+ dev-vblank[crtc].last = dev-driver-get_vblank_counter(dev,
crtc);
vblrc = drm_get_last_vbltimestamp(dev, crtc, tvblank, 0);
- } while (dev-last_vblank[crtc] != dev-driver-get_vblank_counter(dev,
crtc) (--count) vblrc);
+ } while (dev-vblank[crtc].last != dev-driver-get_vblank_counter(dev,
crtc) (--count) vblrc);
if (!count)
vblrc = 0;
@@ -140,7 +138,7 @@ static void vblank_disable_and_save(struct drm_device *dev,
int crtc)
/* Compute time difference to stored timestamp of last vblank
* as updated by last invocation of drm_handle_vblank() in vblank irq.
*/
- vblcount = atomic_read(dev-_vblank_count[crtc]);
+ vblcount = atomic_read(dev-vblank[crtc].count);
diff_ns = timeval_to_ns(tvblank) -
timeval_to_ns(vblanktimestamp(dev, crtc, vblcount));
@@ -157,7 +155,7 @@ static void vblank_disable_and_save(struct drm_device *dev,
int crtc)
* hope for the best.
*/
if ((vblrc 0) (abs64(diff_ns) 100)) {
- atomic_inc(dev-_vblank_count[crtc]);
+ atomic_inc(dev-vblank[crtc].count);
smp_mb__after_atomic_inc();
}
@@ -178,8 +176,8 @@ static void vblank_disable_fn(unsigned long arg)
for (i = 0; i dev-num_crtcs; i++) {
spin_lock_irqsave(dev-vbl_lock, irqflags);
- if (atomic_read(dev-vblank_refcount[i]) == 0
- dev-vblank_enabled[i]) {
+ if (atomic_read(dev-vblank[i].refcount) == 0
+
[PATCH 00/10] drm: drm_device house cleaning
This series does some house cleaning on struct drm_device. x86-64: pahole before the series: /* size: 1576, cachelines: 25, members: 67 */ /* sum members: 1528, holes: 12, sum holes: 48 */ /* paddings: 3, sum paddings: 11 */ /* last cacheline: 40 bytes */ pahole after the series: /* size: 1296, cachelines: 21, members: 52 */ /* sum members: 1290, holes: 1, sum holes: 2 */ /* padding: 4 */ /* paddings: 3, sum paddings: 11 */ /* last cacheline: 16 bytes */ x86: pahole before the series: /* size: 956, cachelines: 15, members: 67 */ /* sum members: 952, holes: 2, sum holes: 4 */ /* paddings: 3, sum paddings: 7 */ /* last cacheline: 60 bytes */ pahole after the series: /* size: 764, cachelines: 12, members: 52 */ /* sum members: 762, holes: 1, sum holes: 2 */ /* paddings: 3, sum paddings: 7 */ /* last cacheline: 60 bytes */ Ville Syrjälä (10): drm: Make vblank_disable_allowed bool drm: Make vblank_inmodeset unsigned drm: Make vblank_enabled bool drm: Collect per-crtc vblank stuff to a struct drm: Make irq_enabled bool drm: Kill unused stuff from struct drm_device drm: Kill ctx_count from struct drm_device drm: Remove pci_vendor and pci_device from struct drm_device drm: Kill drm perf counter leftovers drm: Pack struct drm_device a bit better drivers/gpu/drm/drm_context.c | 2 - drivers/gpu/drm/drm_drv.c | 6 -- drivers/gpu/drm/drm_fops.c | 3 - drivers/gpu/drm/drm_info.c | 6 +- drivers/gpu/drm/drm_irq.c | 152 ++-- drivers/gpu/drm/drm_lock.c | 3 - drivers/gpu/drm/drm_pci.c | 3 - drivers/gpu/drm/drm_stub.c | 9 -- drivers/gpu/drm/exynos/exynos_drm_fimd.c| 8 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c| 8 +- drivers/gpu/drm/gma500/psb_drv.c| 2 +- drivers/gpu/drm/gma500/psb_drv.h| 8 +- drivers/gpu/drm/gma500/psb_irq.c| 22 ++-- drivers/gpu/drm/i810/i810_dma.c | 11 -- drivers/gpu/drm/i915/i915_dma.c | 11 +- drivers/gpu/drm/i915/i915_drv.h | 36 +++ drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/intel_pm.c | 2 +- drivers/gpu/drm/i915/intel_tv.c | 2 +- drivers/gpu/drm/mga/mga_dma.c | 5 - drivers/gpu/drm/mga/mga_irq.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/arb.c | 8 +- drivers/gpu/drm/nouveau/dispnv04/dfp.c | 4 +- drivers/gpu/drm/nouveau/dispnv04/disp.h | 6 +- drivers/gpu/drm/nouveau/dispnv04/hw.c | 4 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 +- drivers/gpu/drm/nouveau/nouveau_bios.c | 4 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 4 +- drivers/gpu/drm/omapdrm/omap_irq.c | 17 ++-- drivers/gpu/drm/radeon/radeon_bios.c| 6 +- drivers/gpu/drm/radeon/radeon_kms.c | 2 +- drivers/gpu/drm/via/via_mm.c| 2 +- drivers/gpu/host1x/drm/drm.c| 2 +- drivers/staging/imx-drm/imx-drm-core.c | 8 +- include/drm/drmP.h | 62 ++-- 35 files changed, 171 insertions(+), 265 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/10] drm: Make irq_enabled bool
From: Ville Syrjälä ville.syrj...@linux.intel.com
irq_enabled is only ever 0 or 1, so make it a bool.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c| 11 ++-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 4 ++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 ++--
drivers/gpu/drm/mga/mga_irq.c| 2 +-
drivers/gpu/drm/omapdrm/omap_irq.c | 11 ++-
drivers/gpu/host1x/drm/drm.c | 2 +-
drivers/staging/imx-drm/imx-drm-core.c | 4 ++--
include/drm/drmP.h | 2 +-
8 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index dea859f..f9af048 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -293,7 +293,7 @@ int drm_irq_install(struct drm_device *dev)
mutex_unlock(dev-struct_mutex);
return -EBUSY;
}
- dev-irq_enabled = 1;
+ dev-irq_enabled = true;
mutex_unlock(dev-struct_mutex);
DRM_DEBUG(irq=%d\n, drm_dev_to_irq(dev));
@@ -316,7 +316,7 @@ int drm_irq_install(struct drm_device *dev)
if (ret 0) {
mutex_lock(dev-struct_mutex);
- dev-irq_enabled = 0;
+ dev-irq_enabled = false;
mutex_unlock(dev-struct_mutex);
return ret;
}
@@ -330,7 +330,7 @@ int drm_irq_install(struct drm_device *dev)
if (ret 0) {
mutex_lock(dev-struct_mutex);
- dev-irq_enabled = 0;
+ dev-irq_enabled = false;
mutex_unlock(dev-struct_mutex);
if (!drm_core_check_feature(dev, DRIVER_MODESET))
vga_client_register(dev-pdev, NULL, NULL, NULL);
@@ -351,14 +351,15 @@ EXPORT_SYMBOL(drm_irq_install);
int drm_irq_uninstall(struct drm_device *dev)
{
unsigned long irqflags;
- int irq_enabled, i;
+ bool irq_enabled;
+ int i;
if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
return -EINVAL;
mutex_lock(dev-struct_mutex);
irq_enabled = dev-irq_enabled;
- dev-irq_enabled = 0;
+ dev-irq_enabled = false;
mutex_unlock(dev-struct_mutex);
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 1648b40..23da72b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -716,13 +716,13 @@ static int fimd_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
{
/*
* enable drm irq mode.
-* - with irq_enabled = 1, we can use the vblank feature.
+* - with irq_enabled = true, we can use the vblank feature.
*
* P.S. note that we wouldn't use drm irq handler but
* just specific driver own one instead because
* drm framework supports only one irq handler.
*/
- drm_dev-irq_enabled = 1;
+ drm_dev-irq_enabled = true;
/*
* with vblank_disable_allowed = true, vblank interrupt will be disabled
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 1d7273d..8925336 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -385,13 +385,13 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
{
/*
* enable drm irq mode.
-* - with irq_enabled = 1, we can use the vblank feature.
+* - with irq_enabled = true, we can use the vblank feature.
*
* P.S. note that we wouldn't use drm irq handler but
* just specific driver own one instead because
* drm framework supports only one irq handler.
*/
- drm_dev-irq_enabled = 1;
+ drm_dev-irq_enabled = true;
/*
* with vblank_disable_allowed = true, vblank interrupt will be disabled
diff --git a/drivers/gpu/drm/mga/mga_irq.c b/drivers/gpu/drm/mga/mga_irq.c
index 598c281..2b0ceb8 100644
--- a/drivers/gpu/drm/mga/mga_irq.c
+++ b/drivers/gpu/drm/mga/mga_irq.c
@@ -169,5 +169,5 @@ void mga_driver_irq_uninstall(struct drm_device *dev)
/* Disable *all* interrupts */
MGA_WRITE(MGA_IEN, 0);
- dev-irq_enabled = 0;
+ dev-irq_enabled = false;
}
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 261b227..cb85860 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -261,7 +261,7 @@ int omap_drm_irq_install(struct drm_device *dev)
mutex_unlock(dev-struct_mutex);
return -EBUSY;
}
- dev-irq_enabled = 1;
+ dev-irq_enabled = true;
mutex_unlock(dev-struct_mutex);
/* Before installing handler */
@@ -272,7 +272,7 @@ int omap_drm_irq_install(struct drm_device
[PATCH 06/10] drm: Kill unused stuff from struct drm_device
From: Ville Syrjälä ville.syrj...@linux.intel.com
'map_count' and 'work' are never used. Kill them both.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
include/drm/drmP.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f3f6484..c2c577b 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1133,7 +1133,6 @@ struct drm_device {
/** \name Memory management */
/*@{ */
struct list_head maplist; /** Linked list of regions */
- int map_count; /** Number of mappable regions */
struct drm_open_hash map_hash; /** User token hash table for maps */
/** \name Context handle management */
@@ -1160,7 +1159,6 @@ struct drm_device {
int last_context; /** Last current context */
/*@} */
- struct work_struct work;
/** \name VBLANK IRQ support */
/*@{ */
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/10] drm: Kill ctx_count from struct drm_device
From: Ville Syrjälä ville.syrj...@linux.intel.com
The only user of ctx_count is the via driver, and we can replace that
use with list_is_singular().
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_context.c | 2 --
drivers/gpu/drm/drm_fops.c| 1 -
drivers/gpu/drm/via/via_mm.c | 2 +-
include/drm/drmP.h| 1 -
4 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index 224ff96..a4b017b 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -334,7 +334,6 @@ int drm_addctx(struct drm_device *dev, void *data,
mutex_lock(dev-ctxlist_mutex);
list_add(ctx_entry-head, dev-ctxlist);
- ++dev-ctx_count;
mutex_unlock(dev-ctxlist_mutex);
return 0;
@@ -432,7 +431,6 @@ int drm_rmctx(struct drm_device *dev, void *data,
if (pos-handle == ctx-handle) {
list_del(pos-head);
kfree(pos);
- --dev-ctx_count;
}
}
}
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 3f84277..529cf30 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -454,7 +454,6 @@ int drm_release(struct inode *inode, struct file *filp)
list_del(pos-head);
kfree(pos);
- --dev-ctx_count;
}
}
}
diff --git a/drivers/gpu/drm/via/via_mm.c b/drivers/gpu/drm/via/via_mm.c
index 7e3ad87..9278891 100644
--- a/drivers/gpu/drm/via/via_mm.c
+++ b/drivers/gpu/drm/via/via_mm.c
@@ -79,7 +79,7 @@ int via_final_context(struct drm_device *dev, int context)
/* Linux specific until context tracking code gets ported to BSD */
/* Last context, perform cleanup */
- if (dev-ctx_count == 1 dev-dev_private) {
+ if (list_is_singular(dev-ctxlist) dev-dev_private) {
DRM_DEBUG(Last Context\n);
drm_irq_uninstall(dev);
via_cleanup_futex(dev_priv);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c2c577b..b6ceaaa 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1138,7 +1138,6 @@ struct drm_device {
/** \name Context handle management */
/*@{ */
struct list_head ctxlist; /** Linked list of context handles */
- int ctx_count; /** Number of context handles */
struct mutex ctxlist_mutex; /** For ctxlist */
struct idr ctx_idr;
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/10] drm: Remove pci_vendor and pci_device from struct drm_device
From: Ville Syrjälä ville.syrj...@linux.intel.com
We can get the PCI vendor and device IDs via dev-pdev. So we can drop
the duplicated information.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_pci.c | 3 ---
drivers/gpu/drm/gma500/psb_drv.h| 8 +++
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 36 ++---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/intel_tv.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/arb.c | 8 +++
drivers/gpu/drm/nouveau/dispnv04/dfp.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv04/disp.h | 6 ++---
drivers/gpu/drm/nouveau/dispnv04/hw.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bios.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_connector.c | 4 ++--
drivers/gpu/drm/radeon/radeon_bios.c| 6 ++---
drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
include/drm/drmP.h | 2 --
16 files changed, 46 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 1f96cee..05a31c5 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -333,9 +333,6 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct
pci_device_id *ent,
dev-pdev = pdev;
dev-dev = pdev-dev;
- dev-pci_device = pdev-device;
- dev-pci_vendor = pdev-vendor;
-
#ifdef __alpha__
dev-hose = pdev-sysdata;
#endif
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 4535ac7..cad4fa7 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -44,10 +44,10 @@ enum {
CHIP_MFLD_0130 = 3, /* Medfield */
};
-#define IS_PSB(dev) (((dev)-pci_device 0xfffe) == 0x8108)
-#define IS_MRST(dev) (((dev)-pci_device 0xfffc) == 0x4100)
-#define IS_MFLD(dev) (((dev)-pci_device 0xfff8) == 0x0130)
-#define IS_CDV(dev) (((dev)-pci_device 0xfff0) == 0x0be0)
+#define IS_PSB(dev) (((dev)-pdev-device 0xfffe) == 0x8108)
+#define IS_MRST(dev) (((dev)-pdev-device 0xfffc) == 0x4100)
+#define IS_MFLD(dev) (((dev)-pdev-device 0xfff8) == 0x0130)
+#define IS_CDV(dev) (((dev)-pdev-device 0xfff0) == 0x0be0)
/*
* Driver definitions
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a209147..e58feb1 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -931,7 +931,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
value = READ_BREADCRUMB(dev_priv);
break;
case I915_PARAM_CHIPSET_ID:
- value = dev-pci_device;
+ value = dev-pdev-device;
break;
case I915_PARAM_HAS_GEM:
value = 1;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ed8653f..2792540 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1615,39 +1615,39 @@ struct drm_i915_file_private {
#define INTEL_INFO(dev)(to_i915(dev)-info)
-#define IS_I830(dev) ((dev)-pci_device == 0x3577)
-#define IS_845G(dev) ((dev)-pci_device == 0x2562)
+#define IS_I830(dev) ((dev)-pdev-device == 0x3577)
+#define IS_845G(dev) ((dev)-pdev-device == 0x2562)
#define IS_I85X(dev) (INTEL_INFO(dev)-is_i85x)
-#define IS_I865G(dev) ((dev)-pci_device == 0x2572)
+#define IS_I865G(dev) ((dev)-pdev-device == 0x2572)
#define IS_I915G(dev) (INTEL_INFO(dev)-is_i915g)
-#define IS_I915GM(dev) ((dev)-pci_device == 0x2592)
-#define IS_I945G(dev) ((dev)-pci_device == 0x2772)
+#define IS_I915GM(dev) ((dev)-pdev-device == 0x2592)
+#define IS_I945G(dev) ((dev)-pdev-device == 0x2772)
#define IS_I945GM(dev) (INTEL_INFO(dev)-is_i945gm)
#define IS_BROADWATER(dev) (INTEL_INFO(dev)-is_broadwater)
#define IS_CRESTLINE(dev) (INTEL_INFO(dev)-is_crestline)
-#define IS_GM45(dev) ((dev)-pci_device == 0x2A42)
+#define IS_GM45(dev) ((dev)-pdev-device == 0x2A42)
#define IS_G4X(dev)(INTEL_INFO(dev)-is_g4x)
-#define IS_PINEVIEW_G(dev) ((dev)-pci_device == 0xa001)
-#define IS_PINEVIEW_M(dev) ((dev)-pci_device == 0xa011)
+#define IS_PINEVIEW_G(dev) ((dev)-pdev-device == 0xa001)
+#define IS_PINEVIEW_M(dev) ((dev)-pdev-device == 0xa011)
#define IS_PINEVIEW(dev) (INTEL_INFO(dev)-is_pineview)
#define IS_G33(dev)(INTEL_INFO(dev)-is_g33)
-#define IS_IRONLAKE_M(dev) ((dev)-pci_device == 0x0046)
+#define IS_IRONLAKE_M(dev) ((dev)-pdev-device == 0x0046)
#define IS_IVYBRIDGE(dev) (INTEL_INFO(dev)-is_ivybridge)
-#define IS_IVB_GT1(dev)((dev)-pci_device == 0x0156 || \
-
[PATCH 10/10] drm: Pack struct drm_device a bit better
From: Ville Syrjälä ville.syrj...@linux.intel.com
x86-64:
pahole before:
/* size: 1328, cachelines: 21, members: 52 */
/* sum members: 1290, holes: 9, sum holes: 38 */
/* paddings: 3, sum paddings: 11 */
/* last cacheline: 48 bytes */
pahole after:
/* size: 1296, cachelines: 21, members: 52 */
/* sum members: 1290, holes: 1, sum holes: 2 */
/* padding: 4 */
/* paddings: 3, sum paddings: 11 */
/* last cacheline: 16 bytes */
x86:
pahole before:
/* size: 772, cachelines: 13, members: 52 */
/* sum members: 762, holes: 4, sum holes: 10 */
/* paddings: 3, sum paddings: 7 */
/* last cacheline: 4 bytes */
pahole after:
/* size: 764, cachelines: 12, members: 52 */
/* sum members: 762, holes: 1, sum holes: 2 */
/* paddings: 3, sum paddings: 7 */
/* last cacheline: 60 bytes */
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
include/drm/drmP.h | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c72e548..dc84fc0 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1121,6 +1121,8 @@ struct drm_device {
atomic_t buf_alloc; /** Buffer allocation in progress */
/*@} */
+ unsigned int num_crtcs; /** Number of CRTCs on this
device */
+
struct list_head filelist;
/** \name Memory management */
@@ -1146,11 +1148,12 @@ struct drm_device {
/** \name Context support */
/*@{ */
- bool irq_enabled; /** True if irq handler is enabled */
__volatile__ long context_flag; /** Context swapping flag */
int last_context; /** Last current context */
/*@} */
+ bool irq_enabled; /** True if irq handler is enabled */
+
/** \name VBLANK IRQ support */
/*@{ */
@@ -1162,20 +1165,19 @@ struct drm_device {
*/
bool vblank_disable_allowed;
+ /**
+* List of events
+*/
+ spinlock_t event_lock;
+ struct list_head vblank_event_list;
+
/* array of size num_crtcs */
struct drm_vblank_crtc *vblank;
spinlock_t vblank_time_lock;/** Protects vblank count and time
updates during vblank enable/disable */
spinlock_t vbl_lock;
- struct timer_list vblank_disable_timer;
-
u32 max_vblank_count; /** size of vblank counter register */
-
- /**
-* List of events
-*/
- struct list_head vblank_event_list;
- spinlock_t event_lock;
+ struct timer_list vblank_disable_timer;
/*@} */
@@ -1191,7 +1193,6 @@ struct drm_device {
struct usb_device *usbdev;
struct drm_sg_mem *sg; /** Scatter gather memory */
- unsigned int num_crtcs; /** Number of CRTCs on this
device */
void *dev_private; /** device private data */
void *mm_private;
struct address_space *dev_mapping;
@@ -1199,8 +1200,6 @@ struct drm_device {
sigset_t sigmask;
struct drm_driver *driver;
- struct drm_local_map *agp_buffer_map;
- unsigned int agp_buffer_token;
struct drm_minor *control; /** Control node for card */
struct drm_minor *primary; /** render type primary screen
head */
struct drm_minor *render; /** render node for card */
@@ -1215,6 +1214,9 @@ struct drm_device {
int switch_power_state;
atomic_t unplugged; /* device has been unplugged or gone away */
+
+ struct drm_local_map *agp_buffer_map;
+ unsigned int agp_buffer_token;
};
#define DRM_SWITCH_POWER_ON 0
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/10] drm: Kill drm perf counter leftovers
From: Ville Syrjälä ville.syrj...@linux.intel.com
The user of these counters was killed in
commit d79cdc8312689b39c6d83718c1c196af4b3cd18c
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu Aug 8 15:41:32 2013 +0200
drm: no-op out GET_STATS ioctl
so clean up the leftovers as well.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_drv.c | 6 --
drivers/gpu/drm/drm_fops.c | 2 --
drivers/gpu/drm/drm_lock.c | 3 ---
drivers/gpu/drm/drm_stub.c | 9 -
drivers/gpu/drm/i810/i810_dma.c | 11 ---
drivers/gpu/drm/i915/i915_dma.c | 7 ---
drivers/gpu/drm/mga/mga_dma.c | 5 -
include/drm/drmP.h | 7 ---
8 files changed, 50 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index e79d8d9..2c7e715 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -178,17 +178,12 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
*/
static void drm_legacy_dev_reinit(struct drm_device *dev)
{
- int i;
-
if (drm_core_check_feature(dev, DRIVER_MODESET))
return;
atomic_set(dev-ioctl_count, 0);
atomic_set(dev-vma_count, 0);
- for (i = 0; i ARRAY_SIZE(dev-counts); i++)
- atomic_set(dev-counts[i], 0);
-
dev-sigdata.lock = NULL;
dev-context_flag = 0;
@@ -386,7 +381,6 @@ long drm_ioctl(struct file *filp,
return -ENODEV;
atomic_inc(dev-ioctl_count);
- atomic_inc(dev-counts[_DRM_STAT_IOCTLS]);
++file_priv-ioctl_count;
if ((nr = DRM_CORE_IOCTL_COUNT)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 529cf30..b8d45b6 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -113,7 +113,6 @@ int drm_open(struct inode *inode, struct file *filp)
retcode = drm_open_helper(inode, filp, dev);
if (retcode)
goto err_undo;
- atomic_inc(dev-counts[_DRM_STAT_OPENS]);
if (need_setup) {
retcode = drm_setup(dev);
if (retcode)
@@ -515,7 +514,6 @@ int drm_release(struct inode *inode, struct file *filp)
* End inline drm_release
*/
- atomic_inc(dev-counts[_DRM_STAT_CLOSES]);
if (!--dev-open_count) {
if (atomic_read(dev-ioctl_count)) {
DRM_ERROR(Device busy: %d\n,
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index d752c96..f645268 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -86,7 +86,6 @@ int drm_lock(struct drm_device *dev, void *data, struct
drm_file *file_priv)
if (drm_lock_take(master-lock, lock-context)) {
master-lock.file_priv = file_priv;
master-lock.lock_time = jiffies;
- atomic_inc(dev-counts[_DRM_STAT_LOCKS]);
break; /* Got lock */
}
@@ -157,8 +156,6 @@ int drm_unlock(struct drm_device *dev, void *data, struct
drm_file *file_priv)
return -EINVAL;
}
- atomic_inc(dev-counts[_DRM_STAT_UNLOCKS]);
-
if (drm_lock_free(master-lock, lock-context)) {
/* FIXME: Should really bail out here. */
}
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 39d8645..c125061 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -275,15 +275,6 @@ int drm_fill_in_dev(struct drm_device *dev,
return -ENOMEM;
}
- /* the DRM has 6 basic counters */
- dev-counters = 6;
- dev-types[0] = _DRM_STAT_LOCK;
- dev-types[1] = _DRM_STAT_OPENS;
- dev-types[2] = _DRM_STAT_CLOSES;
- dev-types[3] = _DRM_STAT_IOCTLS;
- dev-types[4] = _DRM_STAT_LOCKS;
- dev-types[5] = _DRM_STAT_UNLOCKS;
-
dev-driver = driver;
if (dev-driver-bus-agp_init) {
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index ab1892eb..249fdff 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -944,8 +944,6 @@ static int i810_dma_vertex(struct drm_device *dev, void
*data,
dma-buflist[vertex-idx],
vertex-discard, vertex-used);
- atomic_add(vertex-used, dev-counts[_DRM_STAT_SECONDARY]);
- atomic_inc(dev-counts[_DRM_STAT_DMA]);
sarea_priv-last_enqueue = dev_priv-counter - 1;
sarea_priv-last_dispatch = (int)hw_status[5];
@@ -1105,8 +1103,6 @@ static int i810_dma_mc(struct drm_device *dev, void *data,
i810_dma_dispatch_mc(dev, dma-buflist[mc-idx], mc-used,
mc-last_render);
- atomic_add(mc-used, dev-counts[_DRM_STAT_SECONDARY]);
- atomic_inc(dev-counts[_DRM_STAT_DMA]);
sarea_priv-last_enqueue = dev_priv-counter - 1;
[PATCH 1/3] drm/dp: add helper for checking DP_ENHANCED_FRAME_CAP in DPCD
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
include/drm/drm_dp_helper.h |7 +++
1 file changed, 7 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index ae8dbfb..fdf58fa 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -390,4 +390,11 @@ drm_dp_max_lane_count(u8 dpcd[DP_RECEIVER_CAP_SIZE])
return dpcd[DP_MAX_LANE_COUNT] DP_MAX_LANE_COUNT_MASK;
}
+static inline bool
+drm_dp_enhanced_frame_cap(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ return dpcd[DP_DPCD_REV] = 0x11
+ (dpcd[DP_MAX_LANE_COUNT] DP_ENHANCED_FRAME_CAP);
+}
+
#endif /* _DRM_DP_HELPER_H_ */
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/i915/dp: get rid of intel_dp-link_configuration
It's not really needed, rather just adds another place to hold
intermediate values that could go wrong, and it's not clear that the
training pattern set or training lane set should be written at this
point at all.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c |5 +
drivers/gpu/drm/i915/intel_dp.c | 34 --
drivers/gpu/drm/i915/intel_drv.h |3 ---
3 files changed, 13 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a43ac3a..6d335f8 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -316,9 +316,6 @@ static void intel_ddi_mode_set(struct intel_encoder
*encoder)
DRM_DEBUG_DRIVER(DP audio: write eld information\n);
intel_write_eld(encoder-base, adjusted_mode);
}
-
- intel_dp_init_link_config(intel_dp);
-
} else if (type == INTEL_OUTPUT_HDMI) {
struct intel_hdmi *intel_hdmi =
enc_to_intel_hdmi(encoder-base);
@@ -1222,7 +1219,7 @@ void intel_ddi_prepare_link_retrain(struct drm_encoder
*encoder)
val = DP_TP_CTL_ENABLE | DP_TP_CTL_MODE_SST |
DP_TP_CTL_LINK_TRAIN_PAT1 | DP_TP_CTL_SCRAMBLE_DISABLE;
- if (intel_dp-link_configuration[1] DP_LANE_COUNT_ENHANCED_FRAME_EN)
+ if (drm_dp_enhanced_frame_cap(intel_dp-dpcd))
val |= DP_TP_CTL_ENHANCED_FRAME_ENABLE;
I915_WRITE(DP_TP_CTL(port), val);
POSTING_READ(DP_TP_CTL(port));
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 60118da..bf32eca 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -884,21 +884,6 @@ found:
return true;
}
-void intel_dp_init_link_config(struct intel_dp *intel_dp)
-{
- memset(intel_dp-link_configuration, 0, DP_LINK_CONFIGURATION_SIZE);
- intel_dp-link_configuration[0] = intel_dp-link_bw;
- intel_dp-link_configuration[1] = intel_dp-lane_count;
- intel_dp-link_configuration[8] = DP_SET_ANSI_8B10B;
- /*
-* Check for DPCD version 1.1 and enhanced framing support
-*/
- if (intel_dp-dpcd[DP_DPCD_REV] = 0x11
- (intel_dp-dpcd[DP_MAX_LANE_COUNT] DP_ENHANCED_FRAME_CAP)) {
- intel_dp-link_configuration[1] |=
DP_LANE_COUNT_ENHANCED_FRAME_EN;
- }
-}
-
static void ironlake_set_pll_cpu_edp(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -971,8 +956,6 @@ static void intel_dp_mode_set(struct intel_encoder *encoder)
intel_write_eld(encoder-base, adjusted_mode);
}
- intel_dp_init_link_config(intel_dp);
-
/* Split out the IBX/CPU vs CPT settings */
if (port == PORT_A IS_GEN7(dev) !IS_VALLEYVIEW(dev)) {
@@ -982,7 +965,7 @@ static void intel_dp_mode_set(struct intel_encoder *encoder)
intel_dp-DP |= DP_SYNC_VS_HIGH;
intel_dp-DP |= DP_LINK_TRAIN_OFF_CPT;
- if (intel_dp-link_configuration[1]
DP_LANE_COUNT_ENHANCED_FRAME_EN)
+ if (drm_dp_enhanced_frame_cap(intel_dp-dpcd))
intel_dp-DP |= DP_ENHANCED_FRAMING;
intel_dp-DP |= crtc-pipe 29;
@@ -996,7 +979,7 @@ static void intel_dp_mode_set(struct intel_encoder *encoder)
intel_dp-DP |= DP_SYNC_VS_HIGH;
intel_dp-DP |= DP_LINK_TRAIN_OFF;
- if (intel_dp-link_configuration[1]
DP_LANE_COUNT_ENHANCED_FRAME_EN)
+ if (drm_dp_enhanced_frame_cap(intel_dp-dpcd))
intel_dp-DP |= DP_ENHANCED_FRAMING;
if (crtc-pipe == 1)
@@ -2474,14 +2457,21 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
uint8_t voltage;
int voltage_tries, loop_tries;
uint32_t DP = intel_dp-DP;
+ uint8_t link_config[2];
if (HAS_DDI(dev))
intel_ddi_prepare_link_retrain(encoder);
/* Write the link configuration data */
- intel_dp_aux_native_write(intel_dp, DP_LINK_BW_SET,
- intel_dp-link_configuration,
- DP_LINK_CONFIGURATION_SIZE);
+ link_config[0] = intel_dp-link_bw;
+ link_config[1] = intel_dp-lane_count;
+ if (drm_dp_enhanced_frame_cap(intel_dp-dpcd))
+ link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
+ intel_dp_aux_native_write(intel_dp, DP_LINK_BW_SET, link_config, 2);
+
+ link_config[0] = 0;
+ link_config[1] = DP_SET_ANSI_8B10B;
+ intel_dp_aux_native_write(intel_dp, DP_DOWNSPREAD_CTRL, link_config, 2);
DP |= DP_PORT_EN;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 922c5d7..eaf0003 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++
[PATCH 2/3] drm/radeon/dp: use drm_dp_enhanced_frame_cap()
Signed-off-by: Jani Nikula jani.nik...@intel.com --- drivers/gpu/drm/radeon/atombios_dp.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c index 0088541..fb3ae07 100644 --- a/drivers/gpu/drm/radeon/atombios_dp.c +++ b/drivers/gpu/drm/radeon/atombios_dp.c @@ -690,8 +690,7 @@ static int radeon_dp_link_train_init(struct radeon_dp_link_train_info *dp_info) /* set the lane count on the sink */ tmp = dp_info-dp_lane_count; - if (dp_info-dpcd[DP_DPCD_REV] = 0x11 - dp_info-dpcd[DP_MAX_LANE_COUNT] DP_ENHANCED_FRAME_CAP) + if (drm_dp_enhanced_frame_cap(dp_info-dpcd)) tmp |= DP_LANE_COUNT_ENHANCED_FRAME_EN; radeon_write_dpcd_reg(dp_info-radeon_connector, DP_LANE_COUNT_SET, tmp); -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/i915/dp: get rid of intel_dp-link_configuration
On Fri, Oct 04, 2013 at 03:08:10PM +0300, Jani Nikula wrote:
It's not really needed, rather just adds another place to hold
intermediate values that could go wrong, and it's not clear that the
training pattern set or training lane set should be written at this
point at all.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c |5 +
drivers/gpu/drm/i915/intel_dp.c | 34 --
drivers/gpu/drm/i915/intel_drv.h |3 ---
3 files changed, 13 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index a43ac3a..6d335f8 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -316,9 +316,6 @@ static void intel_ddi_mode_set(struct intel_encoder
*encoder)
DRM_DEBUG_DRIVER(DP audio: write eld information\n);
intel_write_eld(encoder-base, adjusted_mode);
}
-
- intel_dp_init_link_config(intel_dp);
-
} else if (type == INTEL_OUTPUT_HDMI) {
struct intel_hdmi *intel_hdmi =
enc_to_intel_hdmi(encoder-base);
@@ -1222,7 +1219,7 @@ void intel_ddi_prepare_link_retrain(struct drm_encoder
*encoder)
val = DP_TP_CTL_ENABLE | DP_TP_CTL_MODE_SST |
DP_TP_CTL_LINK_TRAIN_PAT1 | DP_TP_CTL_SCRAMBLE_DISABLE;
- if (intel_dp-link_configuration[1] DP_LANE_COUNT_ENHANCED_FRAME_EN)
+ if (drm_dp_enhanced_frame_cap(intel_dp-dpcd))
val |= DP_TP_CTL_ENHANCED_FRAME_ENABLE;
I915_WRITE(DP_TP_CTL(port), val);
POSTING_READ(DP_TP_CTL(port));
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 60118da..bf32eca 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -884,21 +884,6 @@ found:
return true;
}
-void intel_dp_init_link_config(struct intel_dp *intel_dp)
-{
- memset(intel_dp-link_configuration, 0, DP_LINK_CONFIGURATION_SIZE);
- intel_dp-link_configuration[0] = intel_dp-link_bw;
- intel_dp-link_configuration[1] = intel_dp-lane_count;
- intel_dp-link_configuration[8] = DP_SET_ANSI_8B10B;
- /*
- * Check for DPCD version 1.1 and enhanced framing support
- */
- if (intel_dp-dpcd[DP_DPCD_REV] = 0x11
- (intel_dp-dpcd[DP_MAX_LANE_COUNT] DP_ENHANCED_FRAME_CAP)) {
- intel_dp-link_configuration[1] |=
DP_LANE_COUNT_ENHANCED_FRAME_EN;
- }
-}
-
static void ironlake_set_pll_cpu_edp(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -971,8 +956,6 @@ static void intel_dp_mode_set(struct intel_encoder
*encoder)
intel_write_eld(encoder-base, adjusted_mode);
}
- intel_dp_init_link_config(intel_dp);
-
/* Split out the IBX/CPU vs CPT settings */
if (port == PORT_A IS_GEN7(dev) !IS_VALLEYVIEW(dev)) {
@@ -982,7 +965,7 @@ static void intel_dp_mode_set(struct intel_encoder
*encoder)
intel_dp-DP |= DP_SYNC_VS_HIGH;
intel_dp-DP |= DP_LINK_TRAIN_OFF_CPT;
- if (intel_dp-link_configuration[1]
DP_LANE_COUNT_ENHANCED_FRAME_EN)
+ if (drm_dp_enhanced_frame_cap(intel_dp-dpcd))
intel_dp-DP |= DP_ENHANCED_FRAMING;
intel_dp-DP |= crtc-pipe 29;
@@ -996,7 +979,7 @@ static void intel_dp_mode_set(struct intel_encoder
*encoder)
intel_dp-DP |= DP_SYNC_VS_HIGH;
intel_dp-DP |= DP_LINK_TRAIN_OFF;
- if (intel_dp-link_configuration[1]
DP_LANE_COUNT_ENHANCED_FRAME_EN)
+ if (drm_dp_enhanced_frame_cap(intel_dp-dpcd))
intel_dp-DP |= DP_ENHANCED_FRAMING;
if (crtc-pipe == 1)
@@ -2474,14 +2457,21 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
uint8_t voltage;
int voltage_tries, loop_tries;
uint32_t DP = intel_dp-DP;
+ uint8_t link_config[2];
if (HAS_DDI(dev))
intel_ddi_prepare_link_retrain(encoder);
/* Write the link configuration data */
- intel_dp_aux_native_write(intel_dp, DP_LINK_BW_SET,
- intel_dp-link_configuration,
- DP_LINK_CONFIGURATION_SIZE);
+ link_config[0] = intel_dp-link_bw;
+ link_config[1] = intel_dp-lane_count;
+ if (drm_dp_enhanced_frame_cap(intel_dp-dpcd))
+ link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
We didn't care about the non-interoperability crap before, and I
suppose we don't care about it now. Hopefully there isn't an eDP
panel out there that requires it, and hopefully all panels also
respect the spec enough to power up w/ DP_EDP_CONFIGURATION_SET=0x0.
For the series:
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
+ intel_dp_aux_native_write(intel_dp,
[Bug 70053] hard machine hang when switching to battery power with DPM enabled on Trinity APU
https://bugs.freedesktop.org/show_bug.cgi?id=70053 --- Comment #6 from Lucas Stach d...@lynxeye.de --- No this patch (v2) does not solve the problem. -- 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: Flash 11.2 content displays in shades of green and purple only, and in a horizontally compressed space
Am 02.10.2013 21:20, schrieb John Hupp:
On 9/30/2013 7:36 AM, Daniel Vetter wrote:
On Sat, Sep 28, 2013 at 12:49:24PM -0400, John Hupp wrote:
[I emailed the list with this same material on 9/13, but it has
received no response and someone on the Ubuntu kernel team suggested
that I change the email Subject from Re: Moving a bug upstream per
downstream request, emailing the maintainers to the more
descriptive one above.]
When I emailed the maintainers with the report below on 8/15 (and
archived at
http://lists.freedesktop.org/archives/dri-devel/2013-August/043876.html),
a response came on 8/16:
It's a flash bug. They ignore the format of the Window that they
PutImage to. (Worse, they create an image of the right depth or else
X
would reject the PutImage with a BadMatch and then render incorrect
pixel data into it.)
Despite that, someone on the Ubuntu kernel team asserted at a
minimum a non-flash regression exists going from Quantal to Raring,
and urged me to proceed with upstream kernel bisection.
I finally finished that, and arrived at the result:
Still a flash bug. This commit simply enables rgb555 in the kernel,
which
sna likes to use on gen2/3. Flash is just too dense and always
presumes
xrgb. Adding
Section Screen
Identifier igd
DefaultDepth 24
EndSection
to your xorg.conf will work around.
-Daniel
*Thanks! That successfully works around the Flash problem with the
Intel driver/chipsets that I reported on. We have at least 4 of those
machines here.*
Hello John,
which 'special' Flash version are you running?
I see that you have an Celeron so YOU can use the SSE2 enabled version,
which I can't 'cause a have old Athlon/Duron without SSE2.
Do you have to fiddle with
/etc/vdpau_wrapper.cfg
enable_flash_uv_swap=1
disable_flash_pq_bg_color=1
?
I can't get around the green and purple colors, but NO line distortion
on my RV730 AGP, here.
Any hints, Christian?
Thank you for your insistence, John!
-Dieter
57779d06367a915ee03e6cb918d7575f0a46e419 is the first bad commit
commit 57779d06367a915ee03e6cb918d7575f0a46e419
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Wed Oct 31 17:50:14 2012 +0200
drm/i915: Fix display pixel format handling
Fix support for all RGB/BGR pixel formats (except the
16:16:16:16 float
format).
Fix intel_init_framebuffer() to match hardware and driver
limitations:
* RGB332 is not supported at all
* CI8 is supported
* XRGB1555 co. are supported on Gen3 and earlier
* XRGB210101010 co. are supported from Gen4 onwards
* BGR formats are supported from Gen4 onwards
* YUV formats are supported from Gen5 onwards (driver
limitation)
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
:04 04 334e1536b3513d0c329a8bb6360593d12065b71d
bf0996ec13cbee07156c5e9f98dcdee30200e658 M drivers
-
The git bisect log:
git bisect start
# good: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7
git bisect good 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
# bad: [9931faca02c604c22335f5a935a501bb2ace6e20] Linux 3.8-rc3
git bisect bad 9931faca02c604c22335f5a935a501bb2ace6e20
# good: [db5b0ae00712b5176d7405e7a1dd2bfd6e8f5070] Merge tag 'dt' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good db5b0ae00712b5176d7405e7a1dd2bfd6e8f5070
# bad: [3c2e81ef344a90bb0a39d84af6878b4aeff568a2] Merge branch
'drm-next' of git://people.freedesktop.org/~airlied/linux
git bisect bad 3c2e81ef344a90bb0a39d84af6878b4aeff568a2
# good: [d8c532c40721f7507896d202b8cae3b3642d2b0d] Merge branch
'v4l_for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect good d8c532c40721f7507896d202b8cae3b3642d2b0d
# good: [2a74dbb9a86e8102dcd07d284135b4530a84826e] Merge branch
'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
git bisect good 2a74dbb9a86e8102dcd07d284135b4530a84826e
# bad: [124ea297c8f0e0a3a567af0894fdbe05caaf80ec] drm/nouveau: unpin
pushbuffer bo before destroying it
git bisect bad 124ea297c8f0e0a3a567af0894fdbe05caaf80ec
# bad: [12f3382bc0262e981a2e58aca900cbbdbbe66825] drm/i915:
implement WaDisablePSDDualDispatchEnable on IVB VLV
git bisect bad 12f3382bc0262e981a2e58aca900cbbdbbe66825
# good: [20474e90c948545c51da95689b8342a4f3bbaeb6] drm/i915: fix
checks inside ironlake_crtc_{enable, disable}
git bisect good 20474e90c948545c51da95689b8342a4f3bbaeb6
# good: [00c09d70df6b30c980f20facc1db3def3f5a637e] drm/i915: create
the DDI encoder
git bisect good 00c09d70df6b30c980f20facc1db3def3f5a637e
# bad: [a35f267946947b3798827a783d82d3d2aa55697d] drm/i915: remove
IBX code from lpt_enable_pch_transcoder
git bisect bad a35f267946947b3798827a783d82d3d2aa55697d
# bad: [9256aa195d3badd009bf4addee6c3ae39879b8a6] drm/i915: move
encoder-mode_set calls to crtc_mode_set
git
[Bug 70108] [bisected e64633e8c3a5498998a45ab721bf80edca101cf5] regression: bad rendering on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=70108 Alexandre Demers alexandre.f.dem...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Alexandre Demers alexandre.f.dem...@gmail.com --- Yes, indeed, it is fixed by that commit. Thanks. -- 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 v2 4/5] drm/exynos: Initialize ptn3460 if present
On Fri, Oct 4, 2013 at 12:18 AM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2:
- Changed include from of_i2c.h to i2c.h
- Changed of_find_by_name to of_find_compatible
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..08ca4f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *compat, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_compatible_node(NULL, NULL, compat);
Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
that such tricky isn't needed? Is there any reason you use such tricky
codes?
This is what I was explaining earlier today. If the bridge driver is
just an i2c driver, it won't get a pointer to drm_device, and can't
register itself as a drm_bridge or drm_connector. To solve this, you
need the ptn3460_init callback.
No, I think you can use sub driver. how about registering to exynos
drm core that driver using exynos_drm_subdrv_register function after
probed? Is there something I am missing?
The ptn driver isn't exynos-specific, so I don't think making it an
exynos_drm_subdrv is appropriate.
Sean
If it's an i2c driver with the ptn3460_init callback, where it parses
the dt in probe, then you have a race between the ptn probe and the
ptn init/drm hooks. ie: it's possible drm will initialize and call
disable/post_disable/pre_enable/enable before things have been probed.
And also, exynos drm core will call a probe callback of the sub driver
after _drm is initialized_. Is there something I am missing?
To solve this, you need to use some global state and/or locking.
So, to summarize. We can have this of_find_compatible with a init
callback, or we can have an i2c driver + global state/locking + init
callback. I chose the former, since it seemed easier.
If you have a better way to achieve this, I'm definitely interested,
but I saw this as the lesser of two evils.
Sean
I think you need to implement the lvds-bridge driver as i2c driver,
and then consider how to take care of this. I mean let's find a better
way how we could take care of the i2c based driver in exynos drm
framework or driver. In all cases, such tricky codes are not good.
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(nxp,ptn3460, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client,
bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
DRM_ERROR(failed to create encoder\n);
return -EFAULT;
}
+ subdrv-encoder = encoder;
+
+ if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD)
{
+ ret = exynos_drm_attach_lcd_bridge(dev, encoder);
+ if (ret)
+ return 0;
+ }
/*
* create and initialize a connector for this sub driver and
@@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
goto err_destroy_encoder;
}
- subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe
RE: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Friday, October 04, 2013 11:17 PM
To: Inki Dae
Cc: Kukjin Kim; DRI mailing list; linux-samsung-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; linux-
d...@vger.kernel.org; devicet...@vger.kernel.org; Dave Airlie
Subject: Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
On Fri, Oct 4, 2013 at 12:18 AM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file
on
exynos initialization. If ptn node is found, the driver will
initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2:
- Changed include from of_i2c.h to i2c.h
- Changed of_find_by_name to of_find_compatible
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..08ca4f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *compat, struct bridge_init
*bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_compatible_node(NULL, NULL, compat);
Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
that such tricky isn't needed? Is there any reason you use such tricky
codes?
This is what I was explaining earlier today. If the bridge driver is
just an i2c driver, it won't get a pointer to drm_device, and can't
register itself as a drm_bridge or drm_connector. To solve this, you
need the ptn3460_init callback.
No, I think you can use sub driver. how about registering to exynos
drm core that driver using exynos_drm_subdrv_register function after
probed? Is there something I am missing?
The ptn driver isn't exynos-specific, so I don't think making it an
exynos_drm_subdrv is appropriate.
I _really know_ that the ptn driver isn't exynos-specific. I mean that you
can use exynos_drm_subdrv somehow. ie. you can add a new bridge module
specific to exynos, and this module can register its own sub driver at end
of probe. Why do you try to use such tricky codes?
Thanks,
Inki Dae
Sean
If it's an i2c driver with the ptn3460_init callback, where it parses
the dt in probe, then you have a race between the ptn probe and the
ptn init/drm hooks. ie: it's possible drm will initialize and call
disable/post_disable/pre_enable/enable before things have been probed.
And also, exynos drm core will call a probe callback of the sub driver
after _drm is initialized_. Is there something I am missing?
To solve this, you need to use some global state and/or locking.
So, to summarize. We can have this of_find_compatible with a init
callback, or we can have an i2c driver + global state/locking + init
callback. I chose the former, since it seemed easier.
If you have a better way to achieve this, I'm definitely interested,
but I saw this as the lesser of two evils.
Sean
I think you need to implement the lvds-bridge driver as i2c driver,
and then consider how to take care of this. I mean let's find a better
way how we could take care of the i2c based driver in exynos drm
framework or driver. In all cases, such tricky codes are not good.
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(nxp,ptn3460, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client,
bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv
*subdrv)
{
Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
On Fri, Oct 4, 2013 at 11:01 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Friday, October 04, 2013 11:17 PM
To: Inki Dae
Cc: Kukjin Kim; DRI mailing list; linux-samsung-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; linux-
d...@vger.kernel.org; devicet...@vger.kernel.org; Dave Airlie
Subject: Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
On Fri, Oct 4, 2013 at 12:18 AM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file
on
exynos initialization. If ptn node is found, the driver will
initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2:
- Changed include from of_i2c.h to i2c.h
- Changed of_find_by_name to of_find_compatible
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..08ca4f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *compat, struct bridge_init
*bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_compatible_node(NULL, NULL, compat);
Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
that such tricky isn't needed? Is there any reason you use such tricky
codes?
This is what I was explaining earlier today. If the bridge driver is
just an i2c driver, it won't get a pointer to drm_device, and can't
register itself as a drm_bridge or drm_connector. To solve this, you
need the ptn3460_init callback.
No, I think you can use sub driver. how about registering to exynos
drm core that driver using exynos_drm_subdrv_register function after
probed? Is there something I am missing?
The ptn driver isn't exynos-specific, so I don't think making it an
exynos_drm_subdrv is appropriate.
I _really know_ that the ptn driver isn't exynos-specific. I mean that you
can use exynos_drm_subdrv somehow. ie. you can add a new bridge module
specific to exynos, and this module can register its own sub driver at end
of probe. Why do you try to use such tricky codes?
So I create a new exynos_lvds_driver which is an i2c driver. When that
probes, all it does is register that driver as an exynos_drm_subdrv.
Then in the subdrv probe I call into ptn3460_init?
That seems a lot more tricky than just calling ptn3460_init directly...
Sean
Thanks,
Inki Dae
Sean
If it's an i2c driver with the ptn3460_init callback, where it parses
the dt in probe, then you have a race between the ptn probe and the
ptn init/drm hooks. ie: it's possible drm will initialize and call
disable/post_disable/pre_enable/enable before things have been probed.
And also, exynos drm core will call a probe callback of the sub driver
after _drm is initialized_. Is there something I am missing?
To solve this, you need to use some global state and/or locking.
So, to summarize. We can have this of_find_compatible with a init
callback, or we can have an i2c driver + global state/locking + init
callback. I chose the former, since it seemed easier.
If you have a better way to achieve this, I'm definitely interested,
but I saw this as the lesser of two evils.
Sean
I think you need to implement the lvds-bridge driver as i2c driver,
and then consider how to take care of this. I mean let's find a better
way how we could take care of the i2c based driver in exynos drm
framework or driver. In all cases, such tricky codes are not good.
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(nxp,ptn3460,
Re: [PATCH 09/10] drm: Kill drm perf counter leftovers
On Fri, Oct 04, 2013 at 02:53:41PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com The user of these counters was killed in commit d79cdc8312689b39c6d83718c1c196af4b3cd18c Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Thu Aug 8 15:41:32 2013 +0200 drm: no-op out GET_STATS ioctl so clean up the leftovers as well. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com This one will conflict with David's driver setup/teardown shuffling a bit. But looks good. I'm not sold on the last patch to pahole struct drm_device, but the others (patches 1-9) are Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch -- 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 v2 4/5] drm/exynos: Initialize ptn3460 if present
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Saturday, October 05, 2013 12:05 AM
To: Inki Dae
Cc: Kukjin Kim; DRI mailing list; linux-samsung-soc; Linux ARM Kernel;
Linux Kernel Mailing List; linux-...@vger.kernel.org;
devicet...@vger.kernel.org; Dave Airlie
Subject: Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
On Fri, Oct 4, 2013 at 11:01 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Friday, October 04, 2013 11:17 PM
To: Inki Dae
Cc: Kukjin Kim; DRI mailing list; linux-samsung-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org;
linux-
d...@vger.kernel.org; devicet...@vger.kernel.org; Dave Airlie
Subject: Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
On Fri, Oct 4, 2013 at 12:18 AM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae inki@samsung.com
wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree
file
on
exynos initialization. If ptn node is found, the driver will
initialize
the ptn3460 driver and skip creating a DP connector (since the
bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2:
- Changed include from of_i2c.h to i2c.h
- Changed of_find_by_name to of_find_compatible
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..08ca4f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *compat, struct bridge_init
*bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_compatible_node(NULL, NULL,
compat);
Then, shouldn't the lvds-bridge driver be implemented as i2c driver
so
that such tricky isn't needed? Is there any reason you use such
tricky
codes?
This is what I was explaining earlier today. If the bridge driver is
just an i2c driver, it won't get a pointer to drm_device, and can't
register itself as a drm_bridge or drm_connector. To solve this, you
need the ptn3460_init callback.
No, I think you can use sub driver. how about registering to exynos
drm core that driver using exynos_drm_subdrv_register function after
probed? Is there something I am missing?
The ptn driver isn't exynos-specific, so I don't think making it an
exynos_drm_subdrv is appropriate.
I _really know_ that the ptn driver isn't exynos-specific. I mean that
you
can use exynos_drm_subdrv somehow. ie. you can add a new bridge module
specific to exynos, and this module can register its own sub driver at
end
of probe. Why do you try to use such tricky codes?
So I create a new exynos_lvds_driver which is an i2c driver. When that
probes, all it does is register that driver as an exynos_drm_subdrv.
Then in the subdrv probe I call into ptn3460_init?
That seems a lot more tricky than just calling ptn3460_init directly...
Why more tricky? At least the dt binding will be done in device driver.
Anyway, this also is reasonable to me. It seems that we need a bit different
design for such bridge driver.
Basically, exysnos drm fimd driver has one encoder and one connector, and
these are connected each other, and this connector means lcd panel without
any display bus. So if we want to use display bus, it might need to create a
new encoder and connector for the display bus device. It seems that this way
is more reasonable to me.
ie. if we want for image data goes from fimd to lcd panel, we can connect a
existing connector and crtc of fimd, and if fimd to display bus, we can
connect the new connector and the crtc of fimd through setcrtc or setplane.
Of course, for this we would need more works and efforts. Such tricky codes
definitely are not good.
Thanks,
Inki Dae
Sean
Thanks,
Inki Dae
Sean
If it's an i2c driver with the ptn3460_init callback, where it
parses
the dt in probe, then you have a race between the ptn probe and the
ptn init/drm hooks. ie: it's possible drm will initialize and call
[Bug 70110] [bisected] regression: assert in r600_bind_sampler_states since 27c054edf0ae92c8c498830e7c7510fa94f5dcfd
https://bugs.freedesktop.org/show_bug.cgi?id=70110
--- Comment #1 from Alexandre Demers alexandre.f.dem...@gmail.com ---
Easy one: under r600_bind_sampler_states(), there is an assert. Since I'm
building with --enable-debug, I hit it.
if (shader != PIPE_SHADER_VERTEX
shader != PIPE_SHADER_FRAGMENT) {
assert(!Only vertex/fragment sampler are implemented.);
return;
}
I suggest we should/could print out an error message if needed, but it
shouldn't be an assert() since we return just after that without doing anything
if the shader is not of the supported type. In fact, I tested mesa with the
assert commented out and everything was back to the way it used to be, so we
really don't need an assert() there. A R600_ERR() seems to do the trick here:
if (shader != PIPE_SHADER_VERTEX
shader != PIPE_SHADER_FRAGMENT) {
R600_ERR(!Only vertex/fragment sampler are implemented.\n);
return;
}
--
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 70110] [bisected] regression: assert in r600_bind_sampler_states since 27c054edf0ae92c8c498830e7c7510fa94f5dcfd
https://bugs.freedesktop.org/show_bug.cgi?id=70110 --- Comment #2 from Alexandre Demers alexandre.f.dem...@gmail.com --- Created attachment 87133 -- https://bugs.freedesktop.org/attachment.cgi?id=87133action=edit Replace overkill assert by It fixes an unneeded assert preventing some app to launch as they should. Please review and commit. -- 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 70146] New: UVD performance regression on linux-3.12-rc
https://bugs.freedesktop.org/show_bug.cgi?id=70146 Priority: medium Bug ID: 70146 Assignee: dri-devel@lists.freedesktop.org Summary: UVD performance regression on linux-3.12-rc Severity: normal Classification: Unclassified OS: All Reporter: johannes.hi...@fem.tu-ilmenau.de Hardware: Other Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI When playing h.264 videos with UVD support, the video is sluggish and mplayer shows the Your system is too SLOW to play this! message after a few seconds. git bisect points me to: ce3537d57196dfc7094755532e1ffc1af133ca5f is the first bad commit commit ce3537d57196dfc7094755532e1ffc1af133ca5f Author: Alex Deucher alexander.deuc...@amd.com Date: Wed Jul 24 12:12:49 2013 -0400 drm/radeon/dpm: use multiple UVD power states (v3) Use the UVD handle information to determine which which power states to select when using UVD. For example, decoding a single SD stream requires much lower clocks than multiple HD streams. v2: switch to a cleaner dpm/uvd interface v3: change the uvd power state while streams are active if need be Signed-off-by: Alex Deucher alexander.deuc...@amd.com :04 04 d8c5afc839fccfe228d8880817bee5b2a35d0578 af38b8261405bd4212f856499520a50476b50b43 M drivers GPU is a Mobility Radeon HD5470 -- 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 70146] UVD performance regression on linux-3.12-rc
https://bugs.freedesktop.org/show_bug.cgi?id=70146 --- Comment #1 from Rafał Miłecki zaj...@gmail.com --- Fix (well, workaround) was already posted: http://www.spinics.net/lists/dri-devel/msg46099.html [PATCH] drm/radeon/dpm: disable multiple UVD states -- 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 70146] UVD performance regression on linux-3.12-rc
https://bugs.freedesktop.org/show_bug.cgi?id=70146 Johannes Hirte johannes.hi...@fem.tu-ilmenau.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Johannes Hirte johannes.hi...@fem.tu-ilmenau.de --- (In reply to comment #1) Fix (well, workaround) was already posted: http://www.spinics.net/lists/dri-devel/msg46099.html [PATCH] drm/radeon/dpm: disable multiple UVD states Thanks for info. So this should be closed as fixed (for now). -- 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 64582] [r600g/vdpau] Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion `map-l_init_called' failed!
https://bugs.freedesktop.org/show_bug.cgi?id=64582 --- Comment #5 from Johannes Hirte johannes.hi...@fem.tu-ilmenau.de --- I can confirm this with gentoo and libvdpau-0.7 and mesa from git. -- 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 70110] [bisected] regression: assert in r600_bind_sampler_states since 27c054edf0ae92c8c498830e7c7510fa94f5dcfd
https://bugs.freedesktop.org/show_bug.cgi?id=70110 Marek Olšák mar...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Olšák mar...@gmail.com --- Fixed by c04b8d1daba5468a7ea991a65570a41951e2da7d. Closing. -- 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] drm/dp: Clarify automated test constant and add constant for FAUX test pattern
- DP_TEST_LINK_PATTERN is ambiguous, rename to DP_TEST_LINK_VIDEO_PATTERN to clarify - Added DP_TEST_LINK_FAUX_PATTERN to support automated testing of Fast AUX Signed-off-by: Todd Previte tprev...@gmail.com --- include/drm/drm_dp_helper.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index ae8dbfb..34c8202 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -266,9 +266,10 @@ #define DP_TEST_REQUEST0x218 # define DP_TEST_LINK_TRAINING (1 0) -# define DP_TEST_LINK_PATTERN (1 1) +# define DP_TEST_LINK_VIDEO_PATTERN(1 1) # define DP_TEST_LINK_EDID_READ(1 2) # define DP_TEST_LINK_PHY_TEST_PATTERN (1 3) /* DPCD = 1.1 */ +# define DP_TEST_LINK_FAUX_PATTERN (1 4) /* DPCD = 1.2 */ #define DP_TEST_LINK_RATE 0x219 # define DP_LINK_RATE_162 (0x6) -- 1.8.1.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 54867] bug in r300 compiler
https://bugs.freedesktop.org/show_bug.cgi?id=54867 --- Comment #3 from David okias Heidelberger david.heidelber...@ixit.cz --- So, still not pushed in today git, can someone push this small fix? -- 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] gpu: host1x: check relocs after all gathers are consumed
The num_relocs count are passed to the kernel per job, not per gather. For multi-gather jobs, we would previously fail if there were relocs in other gathers aside from the first one. Fix this by simply moving the check until all gathers have been consumed. Signed-off-by: Erik Faye-Lund kusmab...@gmail.com --- drivers/gpu/host1x/job.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c index c4e1050..c9ddff8 100644 --- a/drivers/gpu/host1x/job.c +++ b/drivers/gpu/host1x/job.c @@ -436,10 +436,6 @@ static int validate(struct host1x_firewall *fw, struct host1x_job_gather *g) } } - /* No relocs should remain at this point */ - if (fw-num_relocs) - err = -EINVAL; - out: return err; } @@ -493,6 +489,10 @@ static inline int copy_gathers(struct host1x_job *job, struct device *dev) offset += g-words * sizeof(u32); } + /* No relocs should remain at this point */ + if (fw.num_relocs) + return -EINVAL; + return 0; } -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #12 from darkbasic darkba...@linuxsystems.it --- I noticed something weird: if I start KDE with desktop effects off it is *much* faster and there is corruption in the title bar. On the contrary if I start KDE with desktop effects on and *then* I turn them off nothing changes: it keeps being very slow and there are no signs of corruption in the title bar. Also I noticed it is much faster when I set resolution to 1920x1200 compared to 2560x1600, at least when starting KDE with desktop effects off. -- 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 70009] [r300g, bisected] some wine apps renders black
https://bugs.freedesktop.org/show_bug.cgi?id=70009 --- Comment #7 from Marek Olšák mar...@gmail.com --- Created attachment 87143 -- https://bugs.freedesktop.org/attachment.cgi?id=87143action=edit possible fix Could you please try the attached patch? -- 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 69076] weston+rs690: triangle flickering
https://bugs.freedesktop.org/show_bug.cgi?id=69076 --- Comment #2 from David okias Heidelberger david.heidelber...@ixit.cz --- for GLX seems to be broken between 0f6fce15852d3d6fb5251e42394332a62788ef67 commited 2013-09-05 to 694be9115d43b93610f5386b36117ec9a31ed47c commited 2013-09-12. I'll try find what concretly broken GLX. Maybe similiar thing missing in EGL. -- 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 27407] The new MESA degrades performance on RS690M and x1270 graphs chip.
https://bugs.freedesktop.org/show_bug.cgi?id=27407 David okias Heidelberger david.heidelber...@ixit.cz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #13 from David okias Heidelberger david.heidelber...@ixit.cz --- Performance of this card (and driver too) could be better. Recomended configuration under Gentoo: USE=gallium -classic llvm VIDEO_CARDS=radeon r300 llvm can give you in some applications/games double framerate, so please use it. And reminding, that glxgears isn't benchmark. Bigger value better, but doesnt measure real performance. This is 3 years old bug, so closing as WONTFIX, if someone step up to improve performance, as owner of RS690, i'll be glad :) -- 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 70009] [r300g, bisected] some wine apps renders black
https://bugs.freedesktop.org/show_bug.cgi?id=70009 --- Comment #8 from Pavel Ondračka pavel.ondra...@email.cz --- (In reply to comment #7) Created attachment 87143 [details] [review] possible fix Could you please try the attached patch? The attached patch doesn't help. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69076] weston+rs690: triangle flickering
https://bugs.freedesktop.org/show_bug.cgi?id=69076 --- Comment #3 from David okias Heidelberger david.heidelber...@ixit.cz --- still broken on: 18805b16c8a86ad9de4b5bb9afdce576f528f745 commited 2013-09-06 relevant commits between: 2013-09-06radeon/winsys: pad IBs to a multiple of 8 DWs 2013-09-06gallium, intel: Implements new __DRI_IMAGE_USE_LINEAR and PIPE_BIND_LINEAR flags to enforce no tiling. gallium, intel: Implements new __DRI_IMAGE_USE_LINEAR and PIPE_BIND_LINEAR flags to enforce no tiling. non-releavant: ... i915g ... debug ... docs ... r600g ... i965 .. working: 2013-09-05glsl: propagate max_array_access through function calls -- 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 69076] weston+rs690: triangle flickering
https://bugs.freedesktop.org/show_bug.cgi?id=69076 --- Comment #4 from David okias Heidelberger david.heidelber...@ixit.cz --- Addional information: So, in case non-broken mesa. It need to initialize GLX, then EGL render correctly. It work with broken mesa correctly, when glxgears was started with non-broken mesa which set something to card (registers?) corectly. -- 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
Looking for a RV710 / RV730 / RV740 user with HDMI TV
Hi guys, I wanted to verify/improve HDMI (audio) implementation in radeon for so-called DCE3.2 cards. To achieve that I need a log from fglrx. Is there anyone around using RV710 / RV730 / RV740 who can install fglrx for one day and do few simple tests for me? In case you don't know chipsets: RV710: HD4350, HD4550, HD4570 RV730: HD4650, HD4670 RV740: HD4750, HD4770, Mobility HD4830, Mobility HD4870 Please note that above cards are supported by fglrx legacy only, which means you have to use Xorg server 1.12 or older (1.13 is not supported by fglrx legacy). -- Rafał ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69076] weston+rs690: triangle flickering
https://bugs.freedesktop.org/show_bug.cgi?id=69076 --- Comment #5 from David okias Heidelberger david.heidelber...@ixit.cz --- well, now it seems is not working with revision where it worked well. Seems that it worked was something random. I'll try downgrade to previous 3.9.1 kernel and if it'll be ok. -- 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 69076] weston+rs690: triangle flickering
https://bugs.freedesktop.org/show_bug.cgi?id=69076 --- Comment #6 from David okias Heidelberger david.heidelber...@ixit.cz --- so tested range: kernel 3.9.1 - 3.11.0 mesa 2013-09-05 - today could it be xf86-video-ati? Why it is broken randomly :/ -- 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 70088] Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 --- Comment #7 from Vadim Girlin pt...@yandex.ru --- Created attachment 87148 -- https://bugs.freedesktop.org/attachment.cgi?id=87148action=edit patch This patch should fix this issue. (In reply to comment #6) It fixes my crash problem. Maybe code needs more checks for null values? As always my patch is subpar, You shouldn't use it. Checking for null is not enough in this case, it may prevent segfault but generated shader code would be incorrect anyway, when we have null there it means that something is already broken. -- 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 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #37 from Weber K. weber...@yahoo.com.br --- Hi! Here RESOLVED. Sorry for late response, I needed to upgrade my whole system to current for testing. I have the same new glxgears messages if closed clicking in the close button. If press esc or with pkill then no error in the console. I think this is caused by the way glxgears implement main loop. Thank you very much! -- 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 70088] Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 Krzysztof A. Sobiecki sob...@gmail.com changed: What|Removed |Added Attachment #87098|0 |1 is obsolete|| -- 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 70088] Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 --- Comment #8 from Krzysztof A. Sobiecki sob...@gmail.com --- (In reply to comment #7) Created attachment 87148 [details] [review] patch This patch should fix this issue. (In reply to comment #6) It fixes my crash problem. Maybe code needs more checks for null values? As always my patch is subpar, You shouldn't use it. Checking for null is not enough in this case, it may prevent segfault but generated shader code would be incorrect anyway, when we have null there it means that something is already broken. Yes it fixed the problem. Thank You. When it will be pushed into git I will close this bug. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70042] Major texture flickering in Dota 2 (r600g on HD 6950)
https://bugs.freedesktop.org/show_bug.cgi?id=70042 --- Comment #5 from Alexandre Demers alexandre.f.dem...@gmail.com --- Here is a link to a video exhibiting the corruptions/glitches. https://docs.google.com/file/d/0Bw_tZdWsNa4BN0ZmRy1DMnFKZWs/edit?usp=sharing You'll notice glitches here and there, mostly triangles. On the minimap, on the player's face and on some elements (name or HP), it is really visible. Working on an api trace (I have a trace, working on trimming it down). -- 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 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #144 from Bryan Quigley gquigs+b...@gmail.com --- (In reply to comment #143) Unfortunately, that disables dynamic engine scaling which on your particular board pretty much disables dpm since the voltage and mclk are static :( Well damn.. Any other things to try? (I think I've exhausted all the other places to put return 0; in the discussed functions) -- 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
