WARNING: at drivers/gpu/drm/i915/intel_display.c:11375 [i915] in 3.19-rc2
On Thu, 01 Jan 2015, Andrey Skvortsov wrote: > Hi, > > this warning does not exist in 3.19-rc1, but it happens every boot in > 3.19-rc2. If you need any other information or data, I would be glad > to help to debug it. Hmm, at a glance I can't find a commit that could be the culprit. Can you bisect between rc1 and rc2 to find the bad commit? Thanks, Jani. > > [ 12.848428] [ cut here ] > [ 12.848479] WARNING: CPU: 1 PID: 328 at > drivers/gpu/drm/i915/intel_display.c:11375 intel_crtc_set_config+0x3de/0xb36 > [i915]() > [ 12.848482] WARN_ON(!set->fb && (set->num_connectors != 0)) > [ 12.848484] Modules linked in: i915(E) drm_kms_helper(E) drm(E) > snd_hda_intel(E) snd_hda_controller(E) i2c_algo_bit(E) snd_hda_codec(E) > i2c_core(E) xhci_pci(E) xhci_hcd(E) ehci_pci(E) ehci_hcd(E) usbcore(E) > snd_hwdep(E) snd_pcm_oss(E) snd_mixer_oss(E) snd_pcm(E) snd_seq_midi(E) > snd_rawmidi(E) snd_seq_midi_event(E) snd_seq(E) snd_timer(E) > snd_seq_device(E) snd(E) video(E) battery(E) ppdev(E) parport_pc(E) > usb_common(E) serio_raw(E) lpc_ich(E) evdev(E) mfd_core(E) soundcore(E) > button(E) acpi_cpufreq(E) processor(E) coretemp(E) lp(E) parport(E) ext3(E) > jbd(E) mbcache(E) sd_mod(E) ata_generic(E) btrfs(E) ata_piix(E) pata_via(E) > libata(E) raid6_pq(E) thermal(E) scsi_mod(E) fan(E) thermal_sys(E) r8169(E) > mii(E) xor(E) zlib_deflate(E) crc32c_generic(E) libcrc32c(E) > [ 12.848531] CPU: 1 PID: 328 Comm: plymouthd Tainted: GE > 3.19.0-rc2-noiommu- #122 > [ 12.848532] Hardware name: System manufacturer System Product Name/P8H67-M > PRO, BIOS 3904 04/27/2013 > [ 12.848533] a06b3002 813c01df > 8800378afcb8 > [ 12.848535] 8103f24b a06685d8 > 88110880 > [ 12.848537] 8800c83c2d00 8800c8ccb160 8800376c1000 > 88011a74e000 > [ 12.848539] Call Trace: > [ 12.848544] [] ? dump_stack+0x4a/0x74 > [ 12.848548] [] ? warn_slowpath_common+0x9e/0xb7 > [ 12.848566] [] ? intel_crtc_set_config+0x3de/0xb36 > [i915] > [ 12.848568] [] ? warn_slowpath_fmt+0x4a/0x4f > [ 12.848584] [] ? intel_crtc_set_config+0x3de/0xb36 > [i915] > [ 12.848586] [] ? __ww_mutex_lock+0x1c/0x91 > [ 12.848598] [] ? drm_mode_set_config_internal+0x53/0xd7 > [drm] > [ 12.848604] [] ? restore_fbdev_mode+0xae/0xca > [drm_kms_helper] > [ 12.848608] [] ? > drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x5a [drm_kms_helper] > [ 12.848627] [] ? intel_fbdev_restore_mode+0x1b/0x41 > [i915] > [ 12.848632] [] ? drm_lastclose+0x3c/0x104 [drm] > [ 12.848637] [] ? drm_release+0x421/0x457 [drm] > [ 12.848639] [] ? __fput+0xdb/0x177 > [ 12.848642] [] ? task_work_run+0x8e/0xa3 > [ 12.848645] [] ? do_notify_resume+0x64/0x7a > [ 12.848647] [] ? int_signal+0x12/0x17 > [ 12.848649] ---[ end trace da6972fb56a05968 ]--- > > -- > Best regards, > Andrey Skvortsov > > Secure e-mail with gnupg: See http://www.gnupg.org/ > PGP Key ID: 0x57A3AEAD > > -- Jani Nikula, Intel Open Source Technology Center
[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support
Hi Ajay, On 17 December 2014 at 09:31, Javier Martinez Canillas < javier.martinez at collabora.co.uk> wrote: > On 12/16/2014 12:37 AM, Laurent Pinchart wrote: > >> You asked Ajay to change his series to use the video port and enpoints > DT > >> bindings instead of phandles, could you please review his latest > version? > >> > >> I guess is now too late for 3.19 since we are in the middle of the merge > >> window but it would be great if this series can at least made it to > 3.20. > > > > I don't have time to review the series in details right now, but I'm > happy > > with the DT bindings, and have no big issue with the rest of the > patches. I > > don't really like the of_drm_find_bridge() concept introduced in 03/14 > but I > > won't nack it given lack of time to implement an alternative proposal. > It's an > > internal API, it can always be reworked later anyway. > > Thanks a lot for taking the time to look at the DT bindings, then I guess > that the series are finally ready to be merged? > > Ajay's series don't apply cleanly anymore because it has been a while since > he posted it but he can rebase on top of 3.19-rc1 once it is released and > re-resend. > Do you have any plans to rebase this so it's ready for merging? Thierry, Daniel, Dave - whose tree would this be best to merge through? Cheers, Daniel -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150102/c6b7c331/attachment.html>
[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support
Hi Daniel, This series is sitting out there since long without any ACKs. If people can ACK this series, I am ready to rebase and send ASAP. Regards, Ajay Kumar On Fri, Jan 2, 2015 at 6:40 PM, Daniel Stone wrote: > Hi Ajay, > > On 17 December 2014 at 09:31, Javier Martinez Canillas > wrote: >> >> On 12/16/2014 12:37 AM, Laurent Pinchart wrote: >> >> You asked Ajay to change his series to use the video port and enpoints >> >> DT >> >> bindings instead of phandles, could you please review his latest >> >> version? >> >> >> >> I guess is now too late for 3.19 since we are in the middle of the >> >> merge >> >> window but it would be great if this series can at least made it to >> >> 3.20. >> > >> > I don't have time to review the series in details right now, but I'm >> > happy >> > with the DT bindings, and have no big issue with the rest of the >> > patches. I >> > don't really like the of_drm_find_bridge() concept introduced in 03/14 >> > but I >> > won't nack it given lack of time to implement an alternative proposal. >> > It's an >> > internal API, it can always be reworked later anyway. >> >> Thanks a lot for taking the time to look at the DT bindings, then I guess >> that the series are finally ready to be merged? >> >> Ajay's series don't apply cleanly anymore because it has been a while >> since >> he posted it but he can rebase on top of 3.19-rc1 once it is released and >> re-resend. > > > Do you have any plans to rebase this so it's ready for merging? > > Thierry, Daniel, Dave - whose tree would this be best to merge through? > > Cheers, > Daniel
[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support
Hi Ajay, On 2 January 2015 at 13:14, Ajay kumar wrote: > This series is sitting out there since long without any ACKs. > If people can ACK this series, I am ready to rebase and send ASAP. > Both Tomi and Laurent have acked this in principle for now in < 548EF081.8090009 at ti.com> and <3197445.qizQc0zeRb at avalon>, so another series would be quite good I think. Cheers, Daniel -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150102/0d2586b0/attachment.html>
WARNING: at drivers/gpu/drm/i915/intel_display.c:11375 [i915] in 3.19-rc2
On Thu, Jan 01, 2015 at 05:22:15PM +0300, Andrey Skvortsov wrote: > Hi, > > this warning does not exist in 3.19-rc1, but it happens every boot in > 3.19-rc2. If you need any other information or data, I would be glad > to help to debug it. mine is also i915, but i am not seeing any warning. if you send me your .config, then i can try booting using that. the current kernel version is : 3.19.0-rc2-next-20141231+ thanks sudip > > [ 12.848428] [ cut here ] > [ 12.848479] WARNING: CPU: 1 PID: 328 at > drivers/gpu/drm/i915/intel_display.c:11375 intel_crtc_set_config+0x3de/0xb36 > [i915]() > [ 12.848649] ---[ end trace da6972fb56a05968 ]--- > > -- > Best regards, > Andrey Skvortsov > > Secure e-mail with gnupg: See http://www.gnupg.org/ > PGP Key ID: 0x57A3AEAD > >
[PATCH v8 0/2] ASoC: tda998x: add a codec to the HDMI transmitter
On 12/30/2014 07:00 PM, Mark Brown wrote: > On Mon, Dec 29, 2014 at 07:37:21PM +0200, Jyri Sarha wrote: >> On 12/29/2014 06:52 PM, Mark Brown wrote: > >>> So, I'm not seeing *any* interest here from any other HDMI users. This >>> is a continuing theme with HDMI patches and is really very concerning, >>> everyone appears to be working in their own bubbles coming up with their >>> own things and ignoring everyone else's work - what little review I'm > >> I have not seen any significant new development since v7 of these patches. >> My comments for v6 were mostly[1] addressed and I can live with these >> changes, even develop this approach further if it gets merged. > > OK, so this sort of feedback is really useful - even a qualified > Reviwed-by is useful. Total silence could mean anything. > >> However, as a general note I see a need for a generic ASoC hdmi codec >> abstraction and I don't think this is generic enough. More of the audio >> specific implementation and HDMI standard specific things should be pushed >> away from the hdmi encoder driver (tda998x in this case) to the generic ASoC >> side hdmi codec driver (or library). > > This is something I'm expecting, yes - what I don't have is a clear > enough picture of how consistent the different hardware is in how it > models these things. > After taking another look the patchesthere is not much functionality that could be moved away from tda998x. It is just that the ASoC side (and tda998x) could do more in terms of HDMI standard, but that is fine because all that stuff can be added later if/when needed. However, instantiating snd_soc_dai_driver etc. in DRM side makes a nasty dependency between DRM and ASoC. All that stuff could be in ASoC side and simple enum/bitfield parameters defining i2s/spdif selection could be passed between DRM and ASoC side. >> [1] I personally do not like the hdmi_get_cdev() approach. I would rather go >> with only a library for registering from ASoC codec component under the HDMI >> encoder device or a completely separate device with only a reference to the >> HDMI encoder. > > It does seem somewhat complicated, yes. I don't know if matches idioms > for DRM somehow? > Me neither. A more straight forward option would be adding an "audio header" to the beginning of hdmi encoders drvdata. However, it would be tempting to add a pointer for drvdata to snd_soc_dai_driver to add audio specific driver data to any device that provides a DAI in addition to other functionality. It could even simplify drivers for some audio only devices with multiple DAIs. Best regards, Jyri
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #222 from fdb4c415 at opayq.com --- I would like to inform you I got the same problem. My box freezes randomly. Keyboard is almost dead, mouse sometimes working (pointer moves, but cannot click on anything) and usually I can only ssh into that box - to reboot it. Sometimes Ctrl-Alt-F1 works and I can log in, but sometimes not. The monitor switches repeatedly: no signal/black screen/no signal/black screen/... In the log I can see quite similar messages: radeon :01:00.0: GPU lockup (waiting for 0x2258 last fence id 0x2255 on ring 0) VM fault (0x04, vmid 1) at page 30481, read from DMA1 (61) I have the latest debian test 64 bit installed: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) x86_64 GNU/Linux and I have: VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde PRO [Radeon HD 7750 / R7 250E] Is there any way to fix it? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150102/35e1e755/attachment.html>
[Bug 84292] [r600] crashes in Tropico 5 with Radeon HD 5xxx
https://bugs.freedesktop.org/show_bug.cgi?id=84292 leonmaxx changed: What|Removed |Added CC||maxx at linnware.com --- Comment #8 from leonmaxx --- Created attachment 111658 --> https://bugs.freedesktop.org/attachment.cgi?id=111658&action=edit Testcase for R600g driver (Linux/x86-64). Just got same bug while testing various landscape rendering techniques. Screen is black and terminal is flooded with messages: EE r600_shader.c:158 r600_pipe_shader_create -translation from TGSI failed ! EE r600_state_common.c:757 r600_shader_select - Failed to build shader variant (type=2) -1 I'm using Linux Mint 17.1 Mate (based on Ubuntu 14.04 LTS), video card is AMD Radeon HD 6650M 2GB. I tested this on mesa 10.1.3 (system's default) and latest 10.5~git (using oibaf's ppa) versions, same story. I prepared a test application, checked it with other drivers to be sure it's working, and it is attached to this comment. If You need any more information feel free to ask me. Thanks, Leon. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150102/d39af08f/attachment.html>
[Bug 84292] [r600] crashes in Tropico 5 with Radeon HD 5xxx
https://bugs.freedesktop.org/show_bug.cgi?id=84292 --- Comment #9 from leonmaxx --- Forgot to say, that I also tested with R600_DEBUG=notiling and R600_DEBUG=llvm: notiling - does not change anything. llvm - crash (memory corruption in glGenerateMipmap()). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150102/9ff8ece2/attachment.html>
[Bug 90621] New: Graphics card locks up fom time to time (*ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD))
https://bugzilla.kernel.org/show_bug.cgi?id=90621 Bug ID: 90621 Summary: Graphics card locks up fom time to time (*ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)) Product: Drivers Version: 2.5 Kernel Version: 3.18.1 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: andros at all-ein.net Regression: No Created attachment 162311 --> https://bugzilla.kernel.org/attachment.cgi?id=162311&action=edit last message in log The System is locking up, not even magic keys work only hard reset. Not often maybe 2 times a week. Screen blackens for a second than gets back again but everything is frozen. I NEVER do Resume or Hibernation or Standby. So this happens occasionally. If you search can find some others who have the same problem starting with 3.17 https://www.google.de/search?q=radeon++fence+driver+on+ring+5+use+gpu+addr++and+cpu+addr++%5Bdrm%3Ar600_ring_test%5D+*ERROR*+radeon%3A+ring+0+test+failed+%28scratch%280x8504%29%3D0xCAFEDEAD%29+ -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 90621] Graphics card locks up fom time to time (*ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD))
https://bugzilla.kernel.org/show_bug.cgi?id=90621 --- Comment #1 from Andre --- Created attachment 162321 --> https://bugzilla.kernel.org/attachment.cgi?id=162321&action=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 86038] [radeonsi] Dreamfall Chapters: heavy visual corruption, large parts of the screen are black in some scenes
https://bugs.freedesktop.org/show_bug.cgi?id=86038 Kai changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Kai --- With my current stack (see below) this bug is fixed. I didn't test it, but could this be related to Marek's fix for the UE4 demos (NaN handling)? Maybe that's a patch you want to backport to the stable branches, then. My current stack (Debian testing as a base) is: GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/61711316f5 libdrm: Git:master/00847fa48b LLVM: SVN:trunk/r224079 (3.6 devel) X.Org: Git:master/6672606420 Linux: Git::drm-next-3.19-wip/f66d9660a0 Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/> > 9e05820da42549ce9c89d147cf1f8e19 hawaii_ce.bin > c8bab593090fc54f239c8d7596c8d846 hawaii_mc.bin > 3618dbb955d8a84970e262bb2e6d2a16 hawaii_me.bin > c000b0fc9ff6582145f66504b0ec9597 hawaii_mec.bin > 0643ad24b3beff2214cce533e094c1b7 hawaii_pfp.bin > ba6054b7d78184a74602fd81607e1386 hawaii_rlc.bin > 11288f635737331b69de9ee82fe04898 hawaii_sdma.bin > 284429675a5560e0fad42aa982965fc2 hawaii_smc.bin libclc: Git:master/0bb35f11b2 DDX: Git:master/c9f8f642fd -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150102/01ccce31/attachment.html>
[Bug 87976] Iceland chips support missing
https://bugs.freedesktop.org/show_bug.cgi?id=87976 Alex Deucher changed: What|Removed |Added Component|Driver/Radeon |DRM/Radeon Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org Product|xorg|DRI QA Contact|xorg-team at lists.x.org | -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150102/21c6ff3d/attachment.html>
[Bug 86038] [radeonsi] Dreamfall Chapters: heavy visual corruption, large parts of the screen are black in some scenes
https://bugs.freedesktop.org/show_bug.cgi?id=86038 --- Comment #20 from Kai --- (In reply to Kai from comment #19) > LLVM: SVN:trunk/r224079 (3.6 devel) Just to set the record straight: I meant r225079. Sorry for the typo. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150102/ff8464b4/attachment.html>
[Bug 90621] Graphics card locks up fom time to time (*ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD))
https://bugzilla.kernel.org/show_bug.cgi?id=90621 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher --- If this is a regression, can you bisect? Also what version of mesa are you using? You might try a newer version of mesa. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 67790] error message on suspend and hibernate: *ERROR* Could not force DPM to low
https://bugs.freedesktop.org/show_bug.cgi?id=67790 --- Comment #4 from Alex Deucher --- The code is shared across several generations of hardware. As long as suspend and resume works ok, it can be ignored. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150102/deb6d460/attachment.html>
[Bug 90451] Dedicated gpu on HP 355 G2 not working correctly (slower than integrated+corrupt display in es2gears)
https://bugzilla.kernel.org/show_bug.cgi?id=90451 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Please attach your dmesg output and xorg log. Note that due to limitations in the current Linux core graphics stack support for hybrid laptops is very sub-optimal. -- You are receiving this mail because: You are watching the assignee of the bug.
Radeon R9 290 problem
I have an AMD Radeon R9 290 video card, and since commit https://github.com/torvalds/linux/commit/96212fe8c27b I cannot boot into the system any more with CONFIG_DRM_RADEON turned on ([m]). These are the symptoms: the screen either reports NO SIGNAL (sometimes all the LEDs, scroll lock, caps lock and num lock start to blink synchronously) - I had a lot of this while bisecting v3.12.0 to v3.13.0, or, in newer kernels, including v3.18, the image just freezes somewhere around "Waiting for uevents to be processed" and nothing more happens on the screen. In both cases I have to use the reboot button. Here's the output of lspci | grep ATI: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii PRO [Radeon R9 290] 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device aac8 Here's my kernel config: https://bpaste.net/show/8c353c80e37e It works in 3.12 series up to 3.12.34 (it is the last version I checked) and doesn't work in 3.13 to v3.18 (b2776bf).
[PATCH] gpu: drm: armada: armada_drv: Remove unused function
Remove the function armada_drm_vbl_event_remove_unlocked() that is not used
anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/armada/armada_drm.h |2 --
drivers/gpu/drm/armada/armada_drv.c | 10 --
2 files changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_drm.h
b/drivers/gpu/drm/armada/armada_drm.h
index ea63c6c..5f6aef0 100644
--- a/drivers/gpu/drm/armada/armada_drm.h
+++ b/drivers/gpu/drm/armada/armada_drm.h
@@ -46,8 +46,6 @@ void armada_drm_vbl_event_add(struct armada_crtc *,
struct armada_vbl_event *);
void armada_drm_vbl_event_remove(struct armada_crtc *,
struct armada_vbl_event *);
-void armada_drm_vbl_event_remove_unlocked(struct armada_crtc *,
- struct armada_vbl_event *);
#define armada_drm_vbl_event_init(_e, _f, _d) do { \
struct armada_vbl_event *__e = _e; \
INIT_LIST_HEAD(&__e->node); \
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index 908e531..f862bae 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -253,16 +253,6 @@ void armada_drm_vbl_event_remove(struct armada_crtc *dcrtc,
}
}
-void armada_drm_vbl_event_remove_unlocked(struct armada_crtc *dcrtc,
- struct armada_vbl_event *evt)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&dcrtc->irq_lock, flags);
- armada_drm_vbl_event_remove(dcrtc, evt);
- spin_unlock_irqrestore(&dcrtc->irq_lock, flags);
-}
-
/* These are called under the vbl_lock. */
static int armada_drm_enable_vblank(struct drm_device *dev, int crtc)
{
--
1.7.10.4
[PATCH] gpu: drm: armada: armada_output: Remove some unused functions
Removes some functions that are not used anywhere:
armada_drm_encoder_mode_fixup() armada_drm_encoder_commit()
armada_drm_encoder_prepare()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/armada/armada_output.c | 16
drivers/gpu/drm/armada/armada_output.h |6 --
2 files changed, 22 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_output.c
b/drivers/gpu/drm/armada/armada_output.c
index abbc309..5a98231 100644
--- a/drivers/gpu/drm/armada/armada_output.c
+++ b/drivers/gpu/drm/armada/armada_output.c
@@ -72,22 +72,6 @@ static const struct drm_connector_funcs
armada_drm_conn_funcs = {
.set_property = armada_drm_connector_set_property,
};
-void armada_drm_encoder_prepare(struct drm_encoder *encoder)
-{
- encoder_helper_funcs(encoder)->dpms(encoder, DRM_MODE_DPMS_OFF);
-}
-
-void armada_drm_encoder_commit(struct drm_encoder *encoder)
-{
- encoder_helper_funcs(encoder)->dpms(encoder, DRM_MODE_DPMS_ON);
-}
-
-bool armada_drm_encoder_mode_fixup(struct drm_encoder *encoder,
- const struct drm_display_mode *mode, struct drm_display_mode *adjusted)
-{
- return true;
-}
-
/* Shouldn't this be a generic helper function? */
int armada_drm_slave_encoder_mode_valid(struct drm_connector *conn,
struct drm_display_mode *mode)
diff --git a/drivers/gpu/drm/armada/armada_output.h
b/drivers/gpu/drm/armada/armada_output.h
index 4126d43..d3a6ce7 100644
--- a/drivers/gpu/drm/armada/armada_output.h
+++ b/drivers/gpu/drm/armada/armada_output.h
@@ -21,12 +21,6 @@ struct armada_output_type {
struct drm_encoder *armada_drm_connector_encoder(struct drm_connector *conn);
-void armada_drm_encoder_prepare(struct drm_encoder *encoder);
-void armada_drm_encoder_commit(struct drm_encoder *encoder);
-
-bool armada_drm_encoder_mode_fixup(struct drm_encoder *encoder,
- const struct drm_display_mode *mode, struct drm_display_mode *adj);
-
int armada_drm_slave_encoder_mode_valid(struct drm_connector *conn,
struct drm_display_mode *mode);
--
1.7.10.4
