dri-devel May 2014

dri-devel@lists.freedesktop.org

140 participants
970 discussions

[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces
by Andrzej Hajda 05 May '14

05 May '14

Generic framework for tracking internal interfaces ================================================== Summary ------- interface_tracker is a generic framework which allows to track appearance and disappearance of different interfaces provided by kernel/driver code inside the kernel. Examples of such interfaces: clocks, phys, regulators, drm_panel... Interface is specified by a pair of object pointer and interface type. Object type depends on interface type, for example interface type drm_panel determines that object is a device_node. Object pointer is used to distinguish different interfaces of the same type and should identify object the interface is bound to. For example it could be DT node, struct device,... The framework provides two functions for interface providers which should be called just after interface becomes available or just before interface removal. Interface consumers can register callback which will be called when requested interface changes its state, if during callback registration the interface is already up, notification will be sent also. The framework allows nesting calls, for example it is possible to signal one interface in tracker callback of another interface. It is done by putting every request into the queue. If the queue is empty before adding the request, the queue will be processed after, if there is already another request in the queue it means the queue is already processed by different thread so no additional action is required. With this pattern only spinlock is necessary to protect the queue. However in case of removal of either callback or interface caller should be sure that his request has been processed so framework waits until the queue becomes empty, it is done using completion mechanism. The framework functions should not be called in atomic context. Callbacks should be aware that they can be called in any time between registration and de-registration, so they should use synchronization mechanisms carefully. Callbacks should also avoid to perform time consuming tasks, the framework serializes them, so it could stall other callbacks. Use cases --------- The interface is very generic, there are many situations it can be useful: 1. Replacement for subsystem specific methods of publishing/unpublishing interfaces. Currently many frameworks allows only querying for presence of given interface. In such cases client can defer probing or implement interface polling, which is usually subobtimal. Additionally subsystems often do not provide methods to signal to the consumers that they are about to be destroyed. 2. Monitoring for different interfaces provided by the same object. An example should explain it better. Lets assume in device tree drm crtc device node have video link to another node, so it knows only that there is something connected to its RGB output. It can be a RGB panel (drm_panel framework), it can be an image enhancer (SoC specific framework) or it can be some signal converter (drm_encoder, drm_bridge, drm_encoder_slave...). Driver have only phandle to another node. Currently it is difficult to handle such situations in a generic way. interface_tracker should make it simple: crtc should monitor all supported interface types that appears at the device_node pointed by the phandle. Potential use cases ------------------- Points mentioned above were the reasons for writing this framework. During development I have realized that this framework can be also useful for other tasks. 3. Replacement for deferred probing - if for some reason driver do not wants to defer but it requires given resources it can use interface_tracker. It should be possible to create an helper which will wait for appearance of all interfaces from a given list, and 'continue' probe only when all resources becomes available. 4. Replacement or helper for subsystem specific solutions: - V4L2 subdev async registration, - component framework. Both frameworks solves a problem of tracking sub-components (un-)registration by master device, it should be possible to do the same with interface_tracker framework. Some additional helpers can be convienent to make the implementation easier. 5. Cure the situation with sysfs 'unbind' property. Currently many drivers are providers of different resources/interfaces: regulators, clocks, phys, V4L2 subdevs, ... They are usually protected from module unloading by getting module reference, but there is no protection from driver unbinding using sysfs method: echo 'device' >/sys/bus/.../drivers/.../unbind. After unbind consumer stays with the pointer to non-existing object, next time it tries to use it system usually crashes. interface_tracker do not add any protection, but it adds a way to signal to the consumer that given resource will disappear. It allows to handle such situations more gently. Potential issues/extensions --------------------------- 1. Scalability - the framework serializes all tasks and callbacks. In case there are no many users it should not be a problem. If the number of users grows there are different options to consider: - run callbacks in parallel, I guess async_schedule_domain can be helpfull, - partition trackers, for example per interface types - different interface types will use different internal queues/lists. 2. Complication of code - asynchronous programming usually seems to be more complicated. Adding some helpers could make it less painfull. 3. Object comparison - currently object pointers are compared by value, it could be desirable to allow also other ways of comparison, for example string comparison. It is not a problem to extend the framework. TODO ---- 1. Testing - the patchset have not been tested yet with multiple users. 2. Add tracker support in other frameworks - currently there is only drm_panel. I plan also to add something more complicated, for example use it in exynos_drm to track components. If there is positive feedback I can try to add also other frameworks. 3. devm_* registration. 4. Helpers - as the situation 'wait for number interfaces before continue' seems to be quite common, some helper to easy handling it could be useful. Final remarks ------------- Primarily I have planned notifications for DRM panels. Next I have realized something similar would be necessary for drm_bridge. Discussions with other developers showed to me that it could be useful in many other areas. I am not sure if other developers agree with adding it to things like regulators, clocks, phys, but I will be glad if it can be used at least with drm_panel. Regards Andrzej Andrzej Hajda (4): drivers/base: add interface tracker framework drm/panel: add interface tracker support drm/exynos/dpi: add interface tracker support drm/panel/ld9040: do not power off panel on removal drivers/base/Makefile | 2 +- drivers/base/interface_tracker.c | 307 ++++++++++++++++++++++++++++++++ drivers/gpu/drm/drm_panel.c | 5 + drivers/gpu/drm/exynos/exynos_drm_dpi.c | 58 ++++-- drivers/gpu/drm/panel/panel-ld9040.c | 1 - include/linux/interface_tracker.h | 29 +++ 6 files changed, 389 insertions(+), 13 deletions(-) create mode 100644 drivers/base/interface_tracker.c create mode 100644 include/linux/interface_tracker.h -- 1.8.3.2

4 10

[Bug 74631] Suspend-to-ram fails
by bugzilla-daemon＠bugzilla.kernel.org 05 May '14

05 May '14

https://bugzilla.kernel.org/show_bug.cgi?id=74631 --- Comment #2 from tigrangab(a)gmail.com --- I may be able to, but not for a couple weeks unfortunately. -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[PATCH] drm/exynos: add phy settings for RB resolutions
by Shirish S 05 May '14

05 May '14

This patch adds support for the below mentioned pixel clocks in Exynos5250. Without them, following display modes won’t be supported: 71 MHz - 1280x800@60Hz RB 73.25 MHz - 800x600@120Hz RB 88.75 MHz - 1440x900@60Hz RB 115.5 MHz - 1024x768@120Hz RB 119 MHz - 1680x1050@60Hz RB Signed-off-by: Shirish S <s.shirish(a)samsung.com> --- V2: Incorporated review comments drivers/gpu/drm/exynos/exynos_hdmi.c | 45 ++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index 12fdf55..406d89d 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -304,6 +304,24 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] = { }, }, { + .pixel_clock = 71000000, + .conf = { + 0x01, 0x91, 0x1e, 0x15, 0x40, 0x3c, 0xce, 0x08, + 0x04, 0x20, 0xb2, 0xd8, 0x45, 0xa0, 0xac, 0x80, + 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86, + 0x54, 0xad, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80, + }, + }, + { + .pixel_clock = 73250000, + .conf = { + 0x01, 0xd1, 0x1f, 0x15, 0x40, 0x18, 0xe9, 0x08, + 0x02, 0xa0, 0xb7, 0xd8, 0x45, 0xa0, 0xac, 0x80, + 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86, + 0x54, 0xa8, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80, + }, + }, + { .pixel_clock = 74176000, .conf = { 0x01, 0xd1, 0x3e, 0x35, 0x40, 0x5b, 0xde, 0x08, @@ -331,6 +349,15 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] = { }, }, { + .pixel_clock = 88750000, + .conf = { + 0x01, 0x91, 0x25, 0x17, 0x40, 0x30, 0xfe, 0x08, + 0x06, 0x20, 0xde, 0xd8, 0x45, 0xa0, 0xac, 0x80, + 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86, + 0x54, 0x8a, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80, + }, + }, + { .pixel_clock = 106500000, .conf = { 0x01, 0xd1, 0x2c, 0x12, 0x40, 0x0c, 0x09, 0x08, @@ -349,6 +376,24 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] = { }, }, { + .pixel_clock = 115500000, + .conf = { + 0x01, 0xd1, 0x30, 0x1a, 0x40, 0x40, 0x10, 0x04, + 0x04, 0xa0, 0x21, 0xd9, 0x45, 0xa0, 0xac, 0x80, + 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86, + 0x54, 0xaa, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80, + }, + }, + { + .pixel_clock = 119000000, + .conf = { + 0x01, 0x91, 0x32, 0x14, 0x40, 0x60, 0xd8, 0x08, + 0x06, 0x20, 0x2a, 0xd9, 0x45, 0xa0, 0xac, 0x80, + 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86, + 0x54, 0x9d, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80, + }, + }, + { .pixel_clock = 146250000, .conf = { 0x01, 0xd1, 0x3d, 0x15, 0x40, 0x18, 0xfd, 0x08, -- 1.7.10.4

5 8

[PATCH] drm/exynos: update phy settings for RB resolutions
by Shirish S 05 May '14

05 May '14

This patch updates phy settings of the below mentioned pixel clocks in Exynos5250 and removes support for 88.75MHz, for it is not supported. 71 MHz - 1280x800@60Hz RB 73.25 MHz - 800x600@120Hz RB 115.5 MHz - 1024x768@120Hz RB 119 MHz - 1680x1050@60Hz RB Signed-off-by: Shirish S <s.shirish(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_hdmi.c | 33 ++++++++++++--------------------- 1 file changed, 12 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index 9a6d652..7f14faf 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -319,18 +319,18 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] = { { .pixel_clock = 71000000, .conf = { - 0x01, 0x91, 0x1e, 0x15, 0x40, 0x3c, 0xce, 0x08, - 0x04, 0x20, 0xb2, 0xd8, 0x45, 0xa0, 0xac, 0x80, - 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86, + 0x01, 0xd1, 0x3b, 0x35, 0x40, 0x0c, 0x04, 0x08, + 0x85, 0xa0, 0x63, 0xd9, 0x45, 0xa0, 0xac, 0x80, + 0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86, 0x54, 0xad, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80, }, }, { .pixel_clock = 73250000, .conf = { - 0x01, 0xd1, 0x1f, 0x15, 0x40, 0x18, 0xe9, 0x08, - 0x02, 0xa0, 0xb7, 0xd8, 0x45, 0xa0, 0xac, 0x80, - 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86, + 0x01, 0xd1, 0x3d, 0x35, 0x40, 0x18, 0x02, 0x08, + 0x83, 0xa0, 0x6e, 0xd9, 0x45, 0xa0, 0xac, 0x80, + 0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86, 0x54, 0xa8, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80, }, }, @@ -362,15 +362,6 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] = { }, }, { - .pixel_clock = 88750000, - .conf = { - 0x01, 0x91, 0x25, 0x17, 0x40, 0x30, 0xfe, 0x08, - 0x06, 0x20, 0xde, 0xd8, 0x45, 0xa0, 0xac, 0x80, - 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86, - 0x54, 0x8a, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80, - }, - }, - { .pixel_clock = 106500000, .conf = { 0x01, 0xd1, 0x2c, 0x12, 0x40, 0x0c, 0x09, 0x08, @@ -391,18 +382,18 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] = { { .pixel_clock = 115500000, .conf = { - 0x01, 0xd1, 0x30, 0x1a, 0x40, 0x40, 0x10, 0x04, - 0x04, 0xa0, 0x21, 0xd9, 0x45, 0xa0, 0xac, 0x80, - 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86, + 0x01, 0xd1, 0x30, 0x12, 0x40, 0x40, 0x10, 0x08, + 0x80, 0x80, 0x21, 0xd9, 0x45, 0xa0, 0xac, 0x80, + 0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86, 0x54, 0xaa, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80, }, }, { .pixel_clock = 119000000, .conf = { - 0x01, 0x91, 0x32, 0x14, 0x40, 0x60, 0xd8, 0x08, - 0x06, 0x20, 0x2a, 0xd9, 0x45, 0xa0, 0xac, 0x80, - 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86, + 0x01, 0xd1, 0x32, 0x1a, 0x40, 0x30, 0xd8, 0x08, + 0x04, 0xa0, 0x2a, 0xd9, 0x45, 0xa0, 0xac, 0x80, + 0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86, 0x54, 0x9d, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80, }, }, -- 1.7.9.5

1 0

[Bug 73911] Color Banding on radeon
by bugzilla-daemon＠freedesktop.org 04 May '14

04 May '14

https://bugs.freedesktop.org/show_bug.cgi?id=73911 --- Comment #25 from M132 <marcel132132(a)gmail.com> --- It looks like Catalyst uses some kind of "dynamic" dithering, like NVIDIA's proprietary drivers, which generates different noise everytime the screen is refreshed, so isn't really noticeable. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 73911] Color Banding on radeon
by bugzilla-daemon＠freedesktop.org 04 May '14

04 May '14

https://bugs.freedesktop.org/show_bug.cgi?id=73911 --- Comment #24 from Paula Breton <paula(a)parashep.com> --- (In reply to comment #23) > My laptop with A8-4500m is also affected. With fglrx colors are fine, but I > can see little amount of noise (dithering?). With open source drivers, there > is no noise. the noise is definitely dithering, since dithering accomplishes colour blending using patterns similar to noise. it shouldn't be so noticeable in general use, but, trying to accomplish smooth gradients with only 1/4 of the colour values per channel is difficult. haven't been able to sort this out, catalyst isn't really an acceptable alternative. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 73911] Color Banding on radeon
by bugzilla-daemon＠freedesktop.org 04 May '14

04 May '14

https://bugs.freedesktop.org/show_bug.cgi?id=73911 --- Comment #23 from M132 <marcelekprecelek.k(a)gmail.com> --- My laptop with A8-4500m is also affected. With fglrx colors are fine, but I can see little amount of noise (dithering?). With open source drivers, there is no noise. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 75471] New: Black screen with frequency out of range with kernel 3.15-rc3 on radeon RS880
by bugzilla-daemon＠bugzilla.kernel.org 04 May '14

04 May '14

https://bugzilla.kernel.org/show_bug.cgi?id=75471 Bug ID: 75471 Summary: Black screen with frequency out of range with kernel 3.15-rc3 on radeon RS880 Product: Drivers Version: 2.5 Kernel Version: 3.15-rc3 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: tasev.stefanoska(a)skynet.be Regression: No Created attachment 135071 --> https://bugzilla.kernel.org/attachment.cgi?id=135071&action=edit dmesg broken 3.15-rc3 kernel I just have a black screen with frequency out of range on the monitor with the kernel 3.15-rc3.The system boot normaly but after 3 seconds wen it should display the splash screen comme the frequency out of range on the monitor, but the boot process continue in the dark as normal and the system is responsive. Everything work fine in 3.15-rc1 and rc2 kernels. I'm running Kubuntu 12.04 Precise. I have a RS880 motherboard with : 01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS880 [Radeon HD 4200]. After bisecting the first bad commit found : first bad commit 24315814239a3fdb306244c99bd076bc79db4ade Auteur: Christian König <christian.koenig(a)amd.com> 2014-04-19 18:57:14 Auteur du commit: Christian König <christian.koenig(a)amd.com> 2014-04-19 18:57:14 Parent: 76e6dcece841faebbee78895780e8209ff40d922 (drm/radeon: disable dpm on rv770 by default) Branche: master, remotes/origin/master Suit: v3.15-rc1 Précède: v3.15-rc3 drm/radeon: use fixed PPL ref divider if needed Signed-off-by: Christian König <christian.koenig(a)amd.com> ------------------- drivers/gpu/drm/radeon/radeon_display.c ------------------- index 2f7cbb9..e6c3c54 100644 @@ -880,7 +880,12 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll, ref_div_min = pll->reference_div; else ref_div_min = pll->min_ref_div; - ref_div_max = pll->max_ref_div; + + if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV && + pll->flags & RADEON_PLL_USE_REF_DIV) + ref_div_max = pll->reference_div; + else + ref_div_max = pll->max_ref_div; /* determine allowed post divider range */ if (pll->flags & RADEON_PLL_USE_POST_DIV) { But sadly reverting the patch and rebuild the kernel doesn't fix the issue. Attached are dmesg with drm_debug=0xe for the 3.15rc3 (broken) and 3.15-rc2 kernels, and also the bisect.log. -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

[Bug 75211] New: Division error in radeon_compute_pll_avivo (X hang)
by bugzilla-daemon＠bugzilla.kernel.org 03 May '14

03 May '14

https://bugzilla.kernel.org/show_bug.cgi?id=75211 Bug ID: 75211 Summary: Division error in radeon_compute_pll_avivo (X hang) Product: Drivers Version: 2.5 Kernel Version: 3.15-rc3 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: bugspam(a)moreofthesa.me.uk Regression: No I'm seeing a divide error during X startup, causing X to hang (requiring reboot to clear). The trigger is a commit in xserver git: commit 4c3932620c29c91dfbbc8eb09c84efcaa7ec873e Author: Keith Packard <keithp(a)keithp.com> Date: Fri Apr 25 08:22:15 2014 -0700 hw/xfree86: Restore API compatibility for cursor loading functions The effect is this: divide error: 0000 [#1] PREEMPT SMP Modules linked in: [...] CPU: 0 PID: 6579 Comm: Xorg Not tainted 3.15.0-rc3 #2 Hardware name: Gigabyte Technology Co., Ltd. GA-870A-UD3/GA-870A-UD3, BIOS F5 08/01/2011 task: ffff8800b12d1850 ti: ffff88021b08e000 task.ti: ffff88021b08e000 RIP: 0010:[<ffffffff812513d0>] [<ffffffff812513d0>] radeon_compute_pll_avivo+0xb6/0x324 RSP: 0018:ffff88021b08fa08 EFLAGS: 00010246 RAX: 00000000000927c0 RBX: ffff880236dc8210 RCX: 0000000000124f80 RDX: 0000000000000000 RSI: 00000000000927c0 RDI: 0000000000000400 RBP: ffff8800bd6d2c00 R08: ffff88021b08fb08 R09: ffff88021b08fb00 R10: 0000000000000000 R11: 0000000000000000 R12: ffff880236dc8000 R13: 0000000000000000 R14: 0000000000004ff6 R15: 00000000000003ff FS: 00007f39298d1980(0000) GS:ffff88023fc00000(0000) knlGS:00000000e7063b40 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f392a5d3000 CR3: 000000021b00b000 CR4: 00000000000007f0 Stack: 0000cf3700000004 ffff88021b08fa88 0000002800000000 ffff88021b08fb04 0000000000000000 0000000000000002 ffff88021b08fafc 000000000000cf0c ffff88021b08fb00 ffffffff81227da9 0000001e00000004 ffff8802364e6c00 Call Trace: [<ffffffff81227da9>] ? drm_detect_hdmi_monitor+0x54/0x69 [<ffffffff8123ed95>] ? atombios_crtc_mode_set+0x100/0x593 [<ffffffff812d6725>] ? class_dev_iter_next+0xc/0x33 [<ffffffff812d68ed>] ? class_for_each_device+0x8a/0x9f [<ffffffff81213ccd>] ? drm_crtc_helper_set_mode+0x2a3/0x424 [<ffffffff812145a5>] ? drm_crtc_helper_set_config+0x601/0x853 [<ffffffff81250650>] ? radeon_crtc_set_config+0x3e/0xd9 [<ffffffff81222183>] ? drm_mode_set_config_internal+0x48/0xc0 [<ffffffff81224843>] ? drm_mode_setcrtc+0x3d3/0x487 [<ffffffff81250dac>] ? radeon_crtc_load_lut+0x275/0x630 [<ffffffff81219f06>] ? drm_ioctl+0x337/0x3a6 [<ffffffff81224470>] ? drm_mode_setplane+0x325/0x325 [<ffffffff81468fcc>] ? _raw_spin_unlock_irqrestore+0xf/0x21 [<ffffffff81234864>] ? radeon_drm_ioctl+0x42/0x6e [<ffffffff810b10a7>] ? do_vfs_ioctl+0x356/0x420 [<ffffffff810b8747>] ? __fget+0x64/0x6c [<ffffffff810b11a4>] ? SyS_ioctl+0x33/0x58 [<ffffffff81469ca6>] ? system_call_fastpath+0x1a/0x1f Code: 09 8b 6b 08 89 6c 24 20 eb 5f 80 e5 20 74 08 8b 73 1c 8b 4b 20 eb 06 8b 73 14 8b 4b 18 85 ff 74 06 6b f6 0a 6b c9 0a 31 d2 89 f0 <41> f7 f5 89 c2 8d 68 01 41 0f af d5 39 f2 8b 53 30 0f 43 e8 89 RIP [<ffffffff812513d0>] radeon_compute_pll_avivo+0xb6/0x324 RSP <ffff88021b08fa08> Graphics card is R7 260X; two monitors (both 1080p) are attached, one via HDMI-0 and one via DVI-0 (as reported by xrandr). It may be relevant that as part of my user-specific X startup scripts, the HDMI-attached monitor (AOC I2367F) has its frame rate set to 50Hz. -- You are receiving this mail because: You are watching the assignee of the bug.

1 10

[PATCH TRIVIAL] drm/tilcdc: Fix clock retrieval error handling
by Nikolai Kondrashov 03 May '14

03 May '14

Check the validity of the immediately returned display clock, instead of the functional clock already verified previously. Signed-off-by: Nikolai Kondrashov <spbnick(a)gmail.com> --- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c index 171a820..f10bc56 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c @@ -200,7 +200,7 @@ static int tilcdc_load(struct drm_device *dev, unsigned long flags) } priv->disp_clk = clk_get(dev->dev, "dpll_disp_ck"); - if (IS_ERR(priv->clk)) { + if (IS_ERR(priv->disp_clk)) { dev_err(dev->dev, "failed to get display clock\n"); ret = -ENODEV; goto fail; -- 1.9.2

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2014