[Bug 84981] Random crashes related to radeon.
https://bugzilla.kernel.org/show_bug.cgi?id=84981 --- Comment #3 from Apostolos B. --- one more: Oct 04 01:31:42 mainland kernel: general protection fault: [#1] PREEMPT SMP Oct 04 01:31:42 mainland kernel: Modules linked in: vboxdrv(O) btrfs xor raid6_pq uas usb_storage mousedev cfg80211 hid_logitech_dj hid_generic rfkill usbhid hid w83627ehf hwmon_vid snd_hda_codec_realtek snd_hda_codec_ Oct 04 01:31:42 mainland kernel: crc_itu_t ehci_pci i8042 serio ext4 crc16 mbcache jbd2 ehci_hcd xhci_hcd sr_mod usbcore cdrom usb_common sd_mod crc_t10dif crct10dif_common ahci libahci libata scsi_mod radeon hwmon i2 Oct 04 01:31:42 mainland kernel: CPU: 2 PID: 405 Comm: Xorg.bin Tainted: G O 3.16.3-1-ARCH #1 Oct 04 01:31:42 mainland kernel: Hardware name: /DZ77BH-55K, BIOS BHZ7710H.86A.0094.2012.1101.1115 11/01/2012 Oct 04 01:31:42 mainland kernel: task: 88031b3d3d20 ti: 880315818000 task.ti: 880315818000 Oct 04 01:31:42 mainland kernel: RIP: 0010:[] [] kmem_cache_alloc_trace+0x6f/0x170 Oct 04 01:31:42 mainland kernel: RSP: 0018:88031581ba90 EFLAGS: 00010286 Oct 04 01:31:42 mainland kernel: RAX: RBX: 88031bfa1538 RCX: 66779902 Oct 04 01:31:42 mainland kernel: RDX: 66779882 RSI: 00d0 RDI: a0107728 Oct 04 01:31:42 mainland kernel: RBP: 88031581bac0 R08: 000173a0 R09: Oct 04 01:31:42 mainland kernel: R10: a0168480 R11: 88031581bde8 R12: 687475612065636e Oct 04 01:31:42 mainland kernel: R13: 00d0 R14: 88031581bca0 R15: 880322803b00 Oct 04 01:31:42 mainland kernel: FS: 7f17932798c0() GS:88032f28() knlGS: Oct 04 01:31:42 mainland kernel: CS: 0010 DS: ES: CR0: 80050033 Oct 04 01:31:42 mainland kernel: CR2: 7f1787196000 CR3: 7f914000 CR4: 001407e0 Oct 04 01:31:42 mainland kernel: Stack: Oct 04 01:31:42 mainland kernel: 0038 88031bfa1538 Oct 04 01:31:42 mainland kernel: 88031581bca0 88031581bca0 88031581bbc8 a0107728 Oct 04 01:31:42 mainland kernel: 0001 8142436c 88031bfa 88031581bca0 Oct 04 01:31:42 mainland kernel: Call Trace: Oct 04 01:31:42 mainland kernel: [] radeon_sa_bo_new+0x78/0x4c0 [radeon] Oct 04 01:31:42 mainland kernel: [] ? skb_free_head+0x6c/0x80 Oct 04 01:31:42 mainland kernel: [] ? kmem_cache_free+0x199/0x1d0 Oct 04 01:31:42 mainland kernel: [] ? kfree_skbmem+0x37/0xa0 Oct 04 01:31:42 mainland kernel: [] ? __kmalloc+0x2e/0x1c0 Oct 04 01:31:42 mainland kernel: [] ? radeon_cs_parser_init.part.1+0x11a/0x500 [radeon] Oct 04 01:31:42 mainland kernel: [] radeon_ib_get+0x33/0xe0 [radeon] Oct 04 01:31:42 mainland kernel: [] radeon_cs_ioctl+0xe6/0x800 [radeon] Oct 04 01:31:42 mainland kernel: [] drm_ioctl+0x1df/0x680 [drm] Oct 04 01:31:42 mainland kernel: [] ? __do_page_fault+0x2ec/0x600 Oct 04 01:31:42 mainland kernel: [] radeon_drm_ioctl+0x4c/0x80 [radeon] Oct 04 01:31:42 mainland kernel: [] do_vfs_ioctl+0x2d0/0x4b0 Oct 04 01:31:42 mainland kernel: [] ? __fget+0x6e/0xb0 Oct 04 01:31:42 mainland kernel: [] SyS_ioctl+0x81/0xa0 Oct 04 01:31:42 mainland kernel: [] system_call_fastpath+0x16/0x1b Oct 04 01:31:42 mainland kernel: Code: 0f 84 c6 00 00 00 4c 8b 20 4d 85 e4 0f 84 da 00 00 00 48 83 78 10 00 0f 84 cf 00 00 00 49 63 47 20 48 8d 8a 80 00 00 00 4d 8b 07 <49> 8b 1c 04 4c 89 e0 65 49 0f c7 08 0f 94 c0 84 Oct 04 01:31:42 mainland kernel: RIP [] kmem_cache_alloc_trace+0x6f/0x170 Oct 04 01:31:42 mainland kernel: RSP Oct 04 01:31:42 mainland kernel: general protection fault: [#2] PREEMPT SMP Oct 04 01:31:42 mainland kernel: Modules linked in: vboxdrv(O) btrfs xor raid6_pq uas usb_storage mousedev cfg80211 hid_logitech_dj hid_generic rfkill usbhid hid w83627ehf hwmon_vid snd_hda_codec_realtek snd_hda_codec_ Oct 04 01:31:42 mainland kernel: crc_itu_t ehci_pci i8042 serio ext4 crc16 mbcache jbd2 ehci_hcd xhci_hcd sr_mod usbcore cdrom usb_common sd_mod crc_t10dif crct10dif_common ahci libahci libata scsi_mod radeon hwmon i2 Oct 04 01:31:42 mainland kernel: CPU: 2 PID: 405 Comm: Xorg.bin Tainted: G O 3.16.3-1-ARCH #1 Oct 04 01:31:42 mainland kernel: Hardware name: /DZ77BH-55K, BIOS BHZ7710H.86A.0094.2012.1101.1115 11/01/2012 Oct 04 01:31:42 mainland kernel: task: 88031b3d3d20 ti: 880315818000 task.ti: 880315818000 Oct 04 01:31:42 mainland kernel: RIP: 0010:[] [] kmem_cache_alloc_trace+0x6f/0x170 Oct 04 01:31:42 mainland kernel: RSP: 0018:88031581b608 EFLAGS: 00010086 Oct 04 01:31:42 mainland kernel: RAX: RBX: 88031b59 RCX: 66779902 Oct 04 01:31:42 mainland kernel: RDX: 66779882 RSI: 80d0 RDI: a0025d77 Oct 04 01:31:42 mainland kernel: RBP: 88031581b638 R08: 000173a0 R09: Oct 04 01:31:42 mainland kernel: R10:
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #12 from Jos? Su?rez --- I compiled 3.17rc7 with the packet0 patch. You can find a dmesg log just above this message. Running firefox with RADEON_DUMP_CS=1 didn't produce any dump. Is it because I need the mesa dbg packages (not currently installed)? I guess it should appear on the console output, right? Or is it writen to a file? (Sorry about those noob questions. First time debugging this kind of problem...) -- 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/20141003/5ae5a5b4/attachment.html>
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #11 from Jos? Su?rez --- Created attachment 107281 --> https://bugs.freedesktop.org/attachment.cgi?id=107281=edit Dmesg while hitting a packet0 -- 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/20141003/7aae55b9/attachment.html>
[PATCH v2 1/2] drm/nouveau/fb/nv50: Add PFB writes
(This is a v2 of patch "drm/nouveau/disp/nv50: Add PFB writes")
This fix a GPU lockup on 9400M (NVAC) when using acceleration, see
https://bugs.freedesktop.org/show_bug.cgi?id=27501
v2:
- Move code to subdev/fb/nv50.c as suggested by Roy Spliet;
- Remove arbitrary writes to 100c18/100c24 as suggested by Roy Spliet;
- Replace write to 100c1c of arbitrary value by the address of a scratch page
as proposed by Ilia Mirkin;
- Remove enabling of bits 16 and 0 as they don't yield in any changes.
Signed-off-by: Pierre Moreau
---
drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c
b/drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c
index 4150b0d..5c84d13 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c
@@ -289,6 +289,17 @@ nv50_fb_init(struct nouveau_object *object)
if (ret)
return ret;
+ /* Not a clue what this is exactly. Without enabling bit 1 of
+* 100c14, system will lockup while initialising the card
+* (#27501)
+*/
+ if (nv_device(priv)->chipset == 0xac) {
+ if ((nv_rd32(priv, 0x100c14) & 0x0002) == 0x) {
+ nv_wr32(priv, 0x100c1c, priv->r100c08 >> 8);
+ nv_mask(priv, 0x100c14, 0x, 0x0002);
+ }
+ }
+
/* Not a clue what this is exactly. Without pointing it at a
* scratch page, VRAM->GART blits with M2MF (as in DDX DFS)
* cause IOMMU "read from address 0" errors (rh#561267)
--
2.1.2
[PATCH RFC 0/4] drm/core: restore suspend/resume calbacks in KMS drm drivers
On Fri, Oct 03, 2014 at 01:39:21PM +0200, Daniel Vetter wrote: > On Fri, Oct 3, 2014 at 11:42 AM, Andrzej Hajda wrote: > > But this is an issue closely connected with component framework. > > Component framework separates master component probe and drm device > > initialization. As a result PM ops which are synchronized with probe > > (via device_lock) > > are no more synchronized with drm initialization which is usually called > > from > > .bind callback. > > Now I'm confused. component->bind and drm initialization is about > driver load, but all this code here is about system suspend/resume > really. So I'm rather confused what problem you actually want to fix > .. The component *helper* will disconnect the bind of the master device from its probe if the components aren't already known. If all the components are known at the point the master device probes, the master device lock will be held (since we'll be operating within the master device's probe function.) The issue here is that while the master device is being probed, the per-device lock is held. Beneath that lock there are locks in the component helper which will be taken, and thus will end up depending upon the per-device lock. This means that we pretty much can not guarantee synchronisation between PM on the master device and the component helper calling the bind callback - if we tried to take the per-device lock here, we would either deadlock, or we would end up with AB-BA lock dependencies. What we /could/ do is expose lock/unlock functions from the component helper so that PM implementations can synchronise with binds - or I could look at whether we could integrate the component helper into the device model. I suspect the latter would not be met with enthusiasm as it would mean adding bloat to the driver core structures, which would not be needed in 99% of cases. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.
[RFC] Explicit synchronization for Nouveau
ce to wait for (one for each > > > > > buffer) and an out fence. The later can easily be implemented by > > > > > extending struct drm_event, which means not a single driver code > line > > > > > needs to be changed for this. > > > > > > > > > > - For de-staging android syncpts we need to de-clutter the internal > > > > > interfaces and also review all the ioctls exposed. Like you say > it > > > > > should be just the userspace interface for struct drm_fence. > Also, it > > > > > needs testcases and preferrably manpages. > > > > > > > > This all sounds very similar to what we'd like to do! Maybe we can > move > > > > forward with these parts, and continue to attach fences at submit > until we have > > > > a satisfactory solution for the pinning problem? > > > > > > Yeah, that's our plan for i915 too. First add explicit fences, then > figure > > > out whether we need to be better at neutering the implicit fences, in > case > > > and only where it really gets in the way. > > > > > > > I'd like to understand what are the concrete steps to de-stage struct > > > > sync_fence, since that's the first thing that needs to be done. For > example, > > > > what do you mean by "de-cluttering the internal interfaces"? Just > that we'd > > > > move the sync_fence parts from drivers/staging/android/sync.c to, > say, > > > > drivers/dma-buf/sync-fence.c ? Would we still leave a copy of the > existing > > > > full driver to staging/android? > > > > > > Yeah I guess that would be an approach. Personally I think we should > also > > > have basic ioctl testcase for all the ioctls exposed by syncpt fds. And > > > reviewing the kerneldoc for the driver-internal interfaces (which > includes > > > removing everything that's no made obsolete by struct fence). Bonus > points > > > for documenting the ioctls. We could throw the test binary into libdrm > > > maybe, there's a bunch other like it already there. > > > > > > I'm not sure whether/how much google has already for this. > > > > The simplest way to add tests is if we allow user space to create and > trigger > > fences. We don't want to enable that from kernel by default, because > that > > opens possibilities for deadlocks (e.g. a process could deadlock a > compositor > > by passing a fence that it never triggers). Android sync driver solves > this by > > having a separate CONFIG_SW_SYNC_USER that can be used for testing. > > > > Here's a simple test by Google: > > > https://android.googlesource.com/platform/system/core/+/master/libsync/sync_test.c > > Hm, usually we expose such test interfaces through debugfs - that way > production system won't ever ship with it (since there's too many exploits > in there, especially with secure boot). But since you need it for > validation tests (at least for the i915 suite) it should always be there > when you need it. > > Exposing this as a configurable driver in dev is imo a no-go. But we > should be able to easily convert this into a few debugfs files, so not too > much fuzz hopefully. > > > And this is their userspace wrapper lib: > > > https://android.googlesource.com/platform/system/core/+/master/libsync/sync.c > > > https://android.googlesource.com/platform/system/core/+/master/libsync/include/sync/sync.h > > > > Would that go to libdrm now...? > > Imo it would make sense. At least we kinda want to use fences outside of > Android, and a separate library project feels like overkill. > > > > Aside: Will you be at XDC or linux plumbers? Either would be a perfect > > > place to discuss plans and ideas - I'll attend both. > > > > I wasn't going to, but let's see. The former is pretty soon and the > latter is > > sold out. At least Andy Ritger from Nvidia is coming to XDC for sure, > and he's > > been involved in our internal discussions around these topics. So I > suggest you > > have a chat with him at least! :) > > I'll definitely have a chat (and some beers) with Andy, been a while I've > last seen him ;-) > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141003/2ec9b33e/attachment-0001.html>
[PATCH RFC 0/4] drm/core: restore suspend/resume calbacks in KMS drm drivers
On Fri, Oct 3, 2014 at 11:42 AM, Andrzej Hajda wrote: > On 10/03/2014 10:31 AM, Daniel Vetter wrote: >> On Fri, Oct 03, 2014 at 10:24:09AM +0200, Andrzej Hajda wrote: >>> The main intent of this patchset is to allow use of suspend/resume drm >>> driver >>> callbacks in KMS drivers, as these callbacks seems to me the best place >>> to implement suspend/resume functionality in drm driver. >>> Implementing this functionality in master component driver PM ops is >>> problematic >>> as those callbacks can be called asynchronously regardless of >>> state/existence of >>> drm device, thus it would require additional synchronization mechanism. >>> >>> Callbacks re-enabling requires small changes in i915 and exynos driver. >>> The patchset contains also fix of exynos resume callback. >> Nack. >> >> Like completely and totally. The drm core has really no business doing >> hardware stuff, which includes runtime pm, system suspend and all that >> nonsense. It' an interface between userspace and drivers, with a big >> library to back it all up. Everything else just repeats the old midlayer >> mistake. > > Hmm, I have just tried to reuse the existing infrastructure, I did not see > any sign "do not touch, this is a mistake". Now I see it, thanks :) As a rule of thumb, if you see a !DRIVER_MODESET check anywhere, then that's a clear sign that you're wandering off the light and into the dangerous parts of what drm was like age dark ages ;-) >> If you driver needs this, do it there. Also, the component framework is >> probably the solution you're looking for. And if there are synchronization >> issues with that then we need to fix those instead of reinventing yet >> another half-assed broken wheel. > > But this is an issue closely connected with component framework. > Component framework separates master component probe and drm device > initialization. As a result PM ops which are synchronized with probe > (via device_lock) > are no more synchronized with drm initialization which is usually called > from > .bind callback. Now I'm confused. component->bind and drm initialization is about driver load, but all this code here is about system suspend/resume really. So I'm rather confused what problem you actually want to fix .. >> Aside: With David Herrmann's latest patches to de-midlayer the drm >> init/teardown sequence the driver is in full control of when the drm data >> structures get allocate, initialized and registered. If you convert to >> that plus the component framework I'm pretty sure your problem is solved. > > I will look closer at it but as I described above it is rather matter of > separation > of master component and drm device initialization. > > My idea was to avoid creation of new synchronization mechanism and to > reuse the > existing ones which seems to fit perfectly to the scenario, but if there > is big NO for it > another solution should be found. > > Anyway I guess the problem exists for all drivers having component > framework and suspend: > exynos, msm and incoming rockchip. It sounds like the component framework needs to be teached to work with system suspend/resume. I guess either we need to have clever abuse of deferred probing to make sure that the master device is probed first and so in the correct place in the system/resume sequence. Or the master framework needs to grow pm_ops itself so that the state associated with the logical componentized framework can be saved/restored. So master pm_ops would save/restore kms state, and all the components would just save/restore any additional (register, clock, whatever) state that each componnent driver would need. But I'm not really an expert here, so adding more people. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #45 from Alex Deucher --- I pinged the IP review teams again this week. Sorry for the delay. -- 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/20141003/bc7ab433/attachment-0001.html>
[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init
https://bugzilla.kernel.org/show_bug.cgi?id=85491 --- Comment #6 from Alex Deucher --- (In reply to Zermond from comment #5) > (In reply to Alex Deucher from comment #4) > > Can you narrow down when the problem started? Even better, can you bisect? > > As soon as I updated the kernel. At version 3.11, everything was fine with > version 3.16 of the problem. Can you narrow it down any more than that? Does 3.12 work ok? 3.13? etc. -- You are receiving this mail because: You are watching the assignee of the bug.
About "Automatic" for "Broadcast RGB" in i915
http://lists.freedesktop.org/archives/dri-devel/2013-January/033572.html Dear All, Please, never do pointless stuff like that. I don't know what exactly are written in the "CEA guidelines" mentioned in the above posts (AFAIK one cannot get a copy of them for free legally), but no one should follow some "guidelines" like that when it make zero sense. Unlike colorspace, literally it's impossible to detect what RGB ranges can a monitor takes, so having an "Automatic" mechanism for it is very likely to be insane. Worsestill, using modes to determine the range is absurd. What does that imply? It implies within a same product line of monitors, models with different physical size (which is likely to have different optimal resolutions) should use different rgb ranges, and the range should also varies when we switch resolution ourselves. The only reason I can think of for those guidelines to exists is, it makes consumer products send limited range signal when it's likely video playback (coz that's how most video is stored), and full range for other usage (such as gameplay). But this mechanism could hardly apply to PC. IMO keeping Full as a default and allow Limited as an option is the only sane way for PC, especially when better HDTV nowadays is starting to accept full RGB range signal. But if you guys think that, people with some cheaper HDTV or some awkward PC monitors which doesn't even do what's aka "PC Level" should get more care, just make Limited as default then. But please, don't deceive users with some fake Automatic option/fix like that. It sucks. Regards, Tom Yan P.S. I am not a programmer or tech expert here, if there's anything wrong in this mail, I'm glad that you point it out to me.
[PATCH RFC 0/4] drm/core: restore suspend/resume calbacks in KMS drm drivers
On 10/03/2014 10:31 AM, Daniel Vetter wrote: > On Fri, Oct 03, 2014 at 10:24:09AM +0200, Andrzej Hajda wrote: >> The main intent of this patchset is to allow use of suspend/resume drm driver >> callbacks in KMS drivers, as these callbacks seems to me the best place >> to implement suspend/resume functionality in drm driver. >> Implementing this functionality in master component driver PM ops is >> problematic >> as those callbacks can be called asynchronously regardless of >> state/existence of >> drm device, thus it would require additional synchronization mechanism. >> >> Callbacks re-enabling requires small changes in i915 and exynos driver. >> The patchset contains also fix of exynos resume callback. > Nack. > > Like completely and totally. The drm core has really no business doing > hardware stuff, which includes runtime pm, system suspend and all that > nonsense. It' an interface between userspace and drivers, with a big > library to back it all up. Everything else just repeats the old midlayer > mistake. Hmm, I have just tried to reuse the existing infrastructure, I did not see any sign "do not touch, this is a mistake". Now I see it, thanks :) > > If you driver needs this, do it there. Also, the component framework is > probably the solution you're looking for. And if there are synchronization > issues with that then we need to fix those instead of reinventing yet > another half-assed broken wheel. But this is an issue closely connected with component framework. Component framework separates master component probe and drm device initialization. As a result PM ops which are synchronized with probe (via device_lock) are no more synchronized with drm initialization which is usually called from .bind callback. > > Aside: With David Herrmann's latest patches to de-midlayer the drm > init/teardown sequence the driver is in full control of when the drm data > structures get allocate, initialized and registered. If you convert to > that plus the component framework I'm pretty sure your problem is solved. I will look closer at it but as I described above it is rather matter of separation of master component and drm device initialization. My idea was to avoid creation of new synchronization mechanism and to reuse the existing ones which seems to fit perfectly to the scenario, but if there is big NO for it another solution should be found. Anyway I guess the problem exists for all drivers having component framework and suspend: exynos, msm and incoming rockchip. Regards Andrzej > > Thanks, Daniel
[pull] radeon drm-next-3.18
Hi Dave, It looks like you missed my last 3.18 pull from 9/24. This one includes those patches and a few more on top. The additional patches are: - Maarten's radeon fence updates - Some additional debugging output >From the previous pull request: - Re-enable some dpm features that were previously disabled due to a bug that was fixed in 3.16 - Make some arrays static - re-arrange some audio code to properly reflect connected status in the audio driver The following changes since commit 7a42e83d36d2d0a68622320900dc4e880b1d920a: Merge branch 'for-airlied-next' of git://people.freedesktop.org/~mlankhorst/linux into drm-next (2014-10-01 19:27:38 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-3.18 for you to fetch changes up to 369283bfbd953a5d34c919746b3587737c0a47c8: drm/radeon/kv: add uvd/vce info to dpm debugfs output (2014-10-03 09:19:18 -0400) Alex Deucher (15): drm/radeon: fix register name to match internal name drm/radeon: consolidate duplicate encode is digital function drm/radeon: consolidate r600_audio.c into r600_hdmi.c drm/radeon: split audio enable between eg and r600 (v2) drm/radeon: disable audio when we disable hdmi (v2) drm/radeon/dpm: drop clk/voltage dependency filters for NI drm/radeon/dpm: drop clk/voltage dependency filters for SI drm/radeon/dpm: drop clk/voltage dependency filters for CI drm/radeon/dpm: drop clk/voltage dependency filters for BTC drm/radeon: drop btc_get_max_clock_from_voltage_dependency_table drm/radeon: remove unecessary includes drm/radeon/si: print full CS when we hit a packet 0 drm/radeon/cik: write gfx ucode version to ucode addr reg drm/radeon/ci: add uvd/vce info to dpm debugfs output drm/radeon/kv: add uvd/vce info to dpm debugfs output Maarten Lankhorst (3): drm/radeon: cope with foreign fences inside display drm/radeon: cope with foreign fences inside the reservation object drm/radeon: export reservation_object from dmabuf to ttm Michele Curti (2): drm/radeon/atombios: declare connector convert tables as static drm/radeon/combios: declare legacy_connector_convert as static drivers/gpu/drm/radeon/Makefile| 2 +- drivers/gpu/drm/radeon/atombios_encoders.c | 23 drivers/gpu/drm/radeon/btc_dpm.c | 51 --- drivers/gpu/drm/radeon/btc_dpm.h | 2 - drivers/gpu/drm/radeon/ci_dpm.c| 30 + drivers/gpu/drm/radeon/cik.c | 23 ++-- drivers/gpu/drm/radeon/cik_sdma.c | 2 +- drivers/gpu/drm/radeon/dce3_1_afmt.c | 4 +- drivers/gpu/drm/radeon/dce6_afmt.c | 6 +- drivers/gpu/drm/radeon/evergreen.c | 7 +- drivers/gpu/drm/radeon/evergreen_dma.c | 2 +- drivers/gpu/drm/radeon/evergreen_hdmi.c| 49 ++- drivers/gpu/drm/radeon/kv_dpm.c| 2 + drivers/gpu/drm/radeon/ni_dpm.c| 24 drivers/gpu/drm/radeon/r600.c | 6 +- drivers/gpu/drm/radeon/r600_audio.c| 207 - drivers/gpu/drm/radeon/r600_dma.c | 2 +- drivers/gpu/drm/radeon/r600_hdmi.c | 172 +++- drivers/gpu/drm/radeon/r600d.h | 17 +++ drivers/gpu/drm/radeon/radeon.h| 13 +- drivers/gpu/drm/radeon/radeon_asic.h | 1 - drivers/gpu/drm/radeon/radeon_atombios.c | 6 +- drivers/gpu/drm/radeon/radeon_benchmark.c | 4 +- drivers/gpu/drm/radeon/radeon_combios.c| 2 +- drivers/gpu/drm/radeon/radeon_cs.c | 28 +++- drivers/gpu/drm/radeon/radeon_device.c | 2 +- drivers/gpu/drm/radeon/radeon_display.c| 30 +++-- drivers/gpu/drm/radeon/radeon_encoders.c | 21 +++ drivers/gpu/drm/radeon/radeon_fence.c | 9 ++ drivers/gpu/drm/radeon/radeon_gart.c | 2 +- drivers/gpu/drm/radeon/radeon_gem.c| 2 +- drivers/gpu/drm/radeon/radeon_mode.h | 1 + drivers/gpu/drm/radeon/radeon_object.c | 8 +- drivers/gpu/drm/radeon/radeon_object.h | 1 + drivers/gpu/drm/radeon/radeon_prime.c | 5 +- drivers/gpu/drm/radeon/radeon_ring.c | 2 +- drivers/gpu/drm/radeon/radeon_sa.c | 2 +- drivers/gpu/drm/radeon/radeon_semaphore.c | 29 +++- drivers/gpu/drm/radeon/radeon_test.c | 5 +- drivers/gpu/drm/radeon/radeon_ttm.c| 2 +- drivers/gpu/drm/radeon/radeon_uvd.c| 3 +- drivers/gpu/drm/radeon/radeon_vce.c| 3 +- drivers/gpu/drm/radeon/radeon_vm.c | 9 +- drivers/gpu/drm/radeon/rv770.c | 1 - drivers/gpu/drm/radeon/rv770_dma.c | 2 +- drivers/gpu/drm/radeon/si.c| 8 +- drivers/gpu/drm/radeon/si_dma.c| 2 +- drivers/gpu/drm/radeon/si_dpm.c| 24 drivers/gpu/drm/radeon/sid.h | 2 +- 49 files
[PULL] drm-intel-next-fixes for 3.18
Hi Dave, Bunch of fixes for 3.18. Major parts: - ppgtt fixes (but full ppgtt is for 3.19) from Chris, Michel, ... - hdmi pixel replication fixes (Clint Taylor) - leftover i830M patches from Ville - small things all over I'll be travelling the next two weeks (xdc) but should be around a few days each week to herd patches. And for critical stuff Jani can send you a pull. Cheers, Daniel The following changes since commit 8337486a8fda53e5f46b3cb2b4eb3272608348cb: Merge branch 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev into drm-next (2014-09-18 21:53:47 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2014-10-03 for you to fetch changes up to ebb69c95175609990af708ec90c46530f5a2c819: drm/i915: Enable pixel replicated modes on BDW and HSW. (2014-10-01 10:01:41 +0200) Chris Wilson (7): drm/i915/hdmi, dp: Do not dereference the encoder in the connector destroy drm/i915: Objects on the unbound list may still have an active reference drm/i915: Drop any active reference before unbinding drm/i915: Wrap -EIO send-vblank event for failed pageflip in spinlock drm/i915: HSW always use GGTT selector for secure batches drm/i915: Match GTT space sanity checker with implementation drm/i915: Do not store the error pointer for a failed userptr registration Clint Taylor (1): drm/i915: Enable pixel replicated modes on BDW and HSW. Daniel Vetter (3): drm/i915: Don't reinit hpd interrupts after gpu reset drm/i915: Extend BIOS stolen mem handling to all platform Revert "drm/i915/bdw: BDW Software Turbo" Deepak S (1): drm/i915: add cherryview specfic forcewake in execlists_elsp_write Jani Nikula (2): drm/i915/dp: add missing \n in the TPS3 debug message drm/i915/edp: use lane count and link rate from DPCD for eDP Michel Thierry (1): drm/i915: fix another use-after-free in i915_gem_evict_everything Mika Kuoppala (1): drm/i915/bdw: Cleanup pre prod workarounds Rodrigo Vivi (1): drm/i915: Use EIO instead of EAGAIN for sink CRC error. Tvrtko Ursulin (1): drm/i915: Do not leak pages when freeing userptr objects Ville Syrj?l? (3): drm/i915: Fix DVO 2x clock enable on 830M drm/i915: Limit the watermark to at least 8 entries on gen2/3 drm/i915: Don't spam dmesg with rps messages on vlv/chv drivers/gpu/drm/i915/i915_debugfs.c | 34 + drivers/gpu/drm/i915/i915_drv.c | 2 - drivers/gpu/drm/i915/i915_drv.h | 28 +--- drivers/gpu/drm/i915/i915_gem.c | 134 ++--- drivers/gpu/drm/i915/i915_gem_evict.c | 4 +- drivers/gpu/drm/i915/i915_gem_stolen.c | 13 +- drivers/gpu/drm/i915/i915_gem_userptr.c | 31 ++-- drivers/gpu/drm/i915/i915_irq.c | 21 --- drivers/gpu/drm/i915/i915_reg.h | 15 +- drivers/gpu/drm/i915/intel_display.c| 73 +++-- drivers/gpu/drm/i915/intel_dp.c | 36 ++--- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- drivers/gpu/drm/i915/intel_lrc.c| 29 +++- drivers/gpu/drm/i915/intel_pm.c | 254 +++- drivers/gpu/drm/i915/intel_ringbuffer.c | 20 +-- 15 files changed, 297 insertions(+), 399 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PULL] topic/core-stuff
Hi Dave, Two leftover core patches for 3.18, Clint found one more troublesome hdmi mode and some cleanup patch from Andrzej. Cheers, Daniel The following changes since commit 7a42e83d36d2d0a68622320900dc4e880b1d920a: Merge branch 'for-airlied-next' of git://people.freedesktop.org/~mlankhorst/linux into drm-next (2014-10-01 19:27:38 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/core-stuff-2014-10-03 for you to fetch changes up to 1bcecfacde6269dc6cee9a098bc454222d441ff9: drm/core: use helper to check driver features (2014-10-03 10:38:56 +0200) Andrzej Hajda (1): drm/core: use helper to check driver features Clint Taylor (1): drm/edid: Add missing interlaced flag to 576i at 100 modes. drivers/gpu/drm/drm_drv.c | 4 ++-- drivers/gpu/drm/drm_edid.c | 4 ++-- drivers/gpu/drm/drm_fops.c | 8 drivers/gpu/drm/drm_gem.c | 6 +++--- 4 files changed, 11 insertions(+), 11 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/core: use helper to check driver features
On Thu, Oct 02, 2014 at 04:15:26PM +0200, David Herrmann wrote:
> Hi
>
> On Tue, Sep 30, 2014 at 4:49 PM, Andrzej Hajda wrote:
> > The patch replaces direct access to driver_features field
> > by calls to helper function.
> >
> > Signed-off-by: Andrzej Hajda
>
> Looks good:
>
> Reviewed-by: David Herrmann
>
> CC'ing Daniel, he'll put it in his drm-core-stuff branch.
Already happened, but I've added your r-b now too.
-Daniel
>
> Thanks
> David
>
> > ---
> > drivers/gpu/drm/drm_drv.c | 4 ++--
> > drivers/gpu/drm/drm_fops.c | 8
> > drivers/gpu/drm/drm_gem.c | 6 +++---
> > 3 files changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 6a11902..2b30430 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -598,7 +598,7 @@ struct drm_device *drm_dev_alloc(struct drm_driver
> > *driver,
> > goto err_ht;
> > }
> >
> > - if (driver->driver_features & DRIVER_GEM) {
> > + if (drm_core_check_feature(dev, DRIVER_GEM)) {
> > ret = drm_gem_init(dev);
> > if (ret) {
> > DRM_ERROR("Cannot initialize graphics execution
> > manager (GEM)\n");
> > @@ -628,7 +628,7 @@ static void drm_dev_release(struct kref *ref)
> > {
> > struct drm_device *dev = container_of(ref, struct drm_device, ref);
> >
> > - if (dev->driver->driver_features & DRIVER_GEM)
> > + if (drm_core_check_feature(dev, DRIVER_GEM))
> > drm_gem_destroy(dev);
> >
> > drm_legacy_ctxbitmap_cleanup(dev);
> > diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> > index 3e66946..ed7bc68 100644
> > --- a/drivers/gpu/drm/drm_fops.c
> > +++ b/drivers/gpu/drm/drm_fops.c
> > @@ -171,7 +171,7 @@ static int drm_open_helper(struct file *filp, struct
> > drm_minor *minor)
> > init_waitqueue_head(>event_wait);
> > priv->event_space = 4096; /* set aside 4k for event buffer */
> >
> > - if (dev->driver->driver_features & DRIVER_GEM)
> > + if (drm_core_check_feature(dev, DRIVER_GEM))
> > drm_gem_open(dev, priv);
> >
> > if (drm_core_check_feature(dev, DRIVER_PRIME))
> > @@ -256,7 +256,7 @@ out_close:
> > out_prime_destroy:
> > if (drm_core_check_feature(dev, DRIVER_PRIME))
> > drm_prime_destroy_file_private(>prime);
> > - if (dev->driver->driver_features & DRIVER_GEM)
> > + if (drm_core_check_feature(dev, DRIVER_GEM))
> > drm_gem_release(dev, priv);
> > put_pid(priv->pid);
> > kfree(priv);
> > @@ -408,10 +408,10 @@ int drm_release(struct inode *inode, struct file
> > *filp)
> >
> > drm_events_release(file_priv);
> >
> > - if (dev->driver->driver_features & DRIVER_MODESET)
> > + if (drm_core_check_feature(dev, DRIVER_MODESET))
> > drm_fb_release(file_priv);
> >
> > - if (dev->driver->driver_features & DRIVER_GEM)
> > + if (drm_core_check_feature(dev, DRIVER_GEM))
> > drm_gem_release(dev, file_priv);
> >
> > drm_legacy_ctxbitmap_flush(dev, file_priv);
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index eb5dd67..b2c7bab 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -580,7 +580,7 @@ drm_gem_close_ioctl(struct drm_device *dev, void *data,
> > struct drm_gem_close *args = data;
> > int ret;
> >
> > - if (!(dev->driver->driver_features & DRIVER_GEM))
> > + if (!drm_core_check_feature(dev, DRIVER_GEM))
> > return -ENODEV;
> >
> > ret = drm_gem_handle_delete(file_priv, args->handle);
> > @@ -607,7 +607,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
> > struct drm_gem_object *obj;
> > int ret;
> >
> > - if (!(dev->driver->driver_features & DRIVER_GEM))
> > + if (!drm_core_check_feature(dev, DRIVER_GEM))
> > return -ENODEV;
> >
> > obj = drm_gem_object_lookup(dev, file_priv, args->handle);
> > @@ -660,7 +660,7 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data,
> > int ret;
> > u32 handle;
> >
> > - if (!(dev->driver->driver_features & DRIVER_GEM))
> > + if (!drm_core_check_feature(dev, DRIVER_GEM))
> > return -ENODEV;
> >
> > mutex_lock(>object_name_lock);
> > --
> > 1.9.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH RFC 0/4] drm/core: restore suspend/resume calbacks in KMS drm drivers
On Fri, Oct 03, 2014 at 10:24:09AM +0200, Andrzej Hajda wrote: > The main intent of this patchset is to allow use of suspend/resume drm driver > callbacks in KMS drivers, as these callbacks seems to me the best place > to implement suspend/resume functionality in drm driver. > Implementing this functionality in master component driver PM ops is > problematic > as those callbacks can be called asynchronously regardless of state/existence > of > drm device, thus it would require additional synchronization mechanism. > > Callbacks re-enabling requires small changes in i915 and exynos driver. > The patchset contains also fix of exynos resume callback. Nack. Like completely and totally. The drm core has really no business doing hardware stuff, which includes runtime pm, system suspend and all that nonsense. It' an interface between userspace and drivers, with a big library to back it all up. Everything else just repeats the old midlayer mistake. If you driver needs this, do it there. Also, the component framework is probably the solution you're looking for. And if there are synchronization issues with that then we need to fix those instead of reinventing yet another half-assed broken wheel. Aside: With David Herrmann's latest patches to de-midlayer the drm init/teardown sequence the driver is in full control of when the drm data structures get allocate, initialized and registered. If you convert to that plus the component framework I'm pretty sure your problem is solved. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v7 0/2] ASoC: tda998x: add a codec to the HDMI transmitter
The NXP TDA998x HDMI transmitter may transmit audio to the HDMI link from 2 different sources, I2S and S/PDIF. This patch set adds an interface between the HDMI transmitter and the HDMI CODEC. The interface is used by the TDA998x driver to update the audio constraints from the display characteristics (EDID) and by the audio subsystem to connect the chosen audio source to the HDMI link. v7: - remove the change of the K predivider (Jyri Sarha) - add S24_3LE and S32_LE as possible audio formats (Jyri Sarha) - don't move the struct priv2 definition and use the slave encoder private data as the device private data (Russell King) - remove the useless request_module (Russell King/Mark Brown) - don't lock the HDMI module (Russell King) - use platform_device_unregister to remove the codec (Russell King) v6: - extend the HDMI CODEC instead of using a specific CODEC v5: - use the TDA998x private data instead of a specific area for the CODEC interface - the CODEC is TDA998x specific (Mark Brown) v4: - remove all the TDA998x specific stuff from the CODEC - move the EDID scan from the CODEC to the TDA998x - move the CODEC to sound/soc (Mark Brown) - update the audio_sample_rate from the EDID (Andrew Jackson) v3: fix bad rate (Andrew Jackson) v2: check double stream start (Mark Brown) Jean-Francois Moine (2): ASoC: codecs: Add a transmitter interface to the HDMI CODEC drm/i2c: tda998x: Use the HDMI audio CODEC .../devicetree/bindings/drm/i2c/tda998x.txt| 18 ++ drivers/gpu/drm/i2c/Kconfig| 1 + drivers/gpu/drm/i2c/tda998x_drv.c | 264 - include/sound/hdmi.h | 20 ++ sound/soc/codecs/hdmi.c| 176 +- 5 files changed, 460 insertions(+), 19 deletions(-) create mode 100644 include/sound/hdmi.h -- 2.1.1
[PATCH v7 2/2] drm/i2c: tda998x: Use the HDMI audio CODEC
This patch interfaces the HDMI transmitter with the audio system.
Signed-off-by: Jean-Francois Moine
---
.../devicetree/bindings/drm/i2c/tda998x.txt| 18 ++
drivers/gpu/drm/i2c/Kconfig| 1 +
drivers/gpu/drm/i2c/tda998x_drv.c | 264 -
3 files changed, 270 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
index e9e4bce..e50e7cd 100644
--- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
+++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
@@ -17,6 +17,20 @@ Optional properties:
- video-ports: 24 bits value which defines how the video controller
output is wired to the TDA998x input - default: <0x230145>
+ - audio-ports: must contain one or two values selecting the source
+ in the audio port.
+ The source type is given by the corresponding entry in
+ the audio-port-names property.
+
+ - audio-port-names: must contain entries matching the entries in
+ the audio-ports property.
+ Each value may be "i2s" or "spdif", giving the type of
+ the audio source.
+
+ - #sound-dai-cells: must be set to <1> for use with the simple-card.
+ The TDA998x audio CODEC always defines two DAIs.
+ The DAI 0 is the S/PDIF input and the DAI 1 is the I2S input.
+
Example:
tda998x: hdmi-encoder {
@@ -26,4 +40,8 @@ Example:
interrupts = <27 2>;/* falling edge */
pinctrl-0 = <_camera>;
pinctrl-names = "default";
+
+ audio-ports = <0x04>, <0x03>;
+ audio-port-names = "spdif", "i2s";
+ #sound-dai-cells = <1>;
};
diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 4d341db..42ca744 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -22,6 +22,7 @@ config DRM_I2C_SIL164
config DRM_I2C_NXP_TDA998X
tristate "NXP Semiconductors TDA998X HDMI encoder"
default m if DRM_TILCDC
+ select SND_SOC_HDMI_CODEC
help
Support for NXP Semiconductors TDA998X HDMI encoders.
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index d476279..e558e1e 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -20,12 +20,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
@@ -44,6 +46,16 @@ struct tda998x_priv {
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
struct drm_encoder *encoder;
+
+ /* audio variables */
+ struct platform_device *pdev_codec;
+ u8 audio_ports[2];
+
+ u8 max_channels;/* EDID parameters */
+ u8 rate_mask;
+ u8 fmt;
+
+ int audio_sample_format;
};
#define to_tda998x_priv(x) ((struct tda998x_priv
*)to_encoder_slave(x)->slave_priv)
@@ -624,6 +636,8 @@ tda998x_write_avi(struct tda998x_priv *priv, struct
drm_display_mode *mode)
sizeof(buf));
}
+/* audio functions */
+
static void tda998x_audio_mute(struct tda998x_priv *priv, bool on)
{
if (on) {
@@ -639,12 +653,11 @@ static void
tda998x_configure_audio(struct tda998x_priv *priv,
struct drm_display_mode *mode, struct tda998x_encoder_params *p)
{
- uint8_t buf[6], clksel_aip, clksel_fs, cts_n, adiv;
+ uint8_t buf[6], clksel_aip, clksel_fs, cts_n, adiv, aclk;
uint32_t n;
/* Enable audio ports */
reg_write(priv, REG_ENA_AP, p->audio_cfg);
- reg_write(priv, REG_ENA_ACLK, p->audio_clk_cfg);
/* Set audio input source */
switch (p->audio_format) {
@@ -653,6 +666,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
clksel_aip = AIP_CLKSEL_AIP_SPDIF;
clksel_fs = AIP_CLKSEL_FS_FS64SPDIF;
cts_n = CTS_N_M(3) | CTS_N_K(3);
+ aclk = 0; /* no clock */
break;
case AFMT_I2S:
@@ -660,6 +674,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
clksel_aip = AIP_CLKSEL_AIP_I2S;
clksel_fs = AIP_CLKSEL_FS_ACLK;
cts_n = CTS_N_M(3) | CTS_N_K(3);
+ aclk = 1; /* clock enable */
break;
default:
@@ -671,6 +686,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_LAYOUT |
AIP_CNTRL_0_ACR_MAN); /* auto CTS */
reg_write(priv, REG_CTS_N, cts_n);
+ reg_write(priv, REG_ENA_ACLK, aclk);
/*
* Audio input somehow depends on HDMI line rate which is
@@ -727,6 +743,137 @@ tda998x_configure_audio(struct tda998x_priv *priv,
[PATCH RFC 4/4] drm/exynos: correct connector->dpms field before resuming
During system suspend after connector switch off its dpms field
is set to connector previous dpms state. To properly resume dpms field
should be set to its actual state (off) before resuming to previous dpms state.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index dca20b15..6746c5a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -191,8 +191,12 @@ static int exynos_drm_resume(struct drm_device *dev)
drm_modeset_lock_all(dev);
list_for_each_entry(connector, >mode_config.connector_list, head) {
- if (connector->funcs->dpms)
- connector->funcs->dpms(connector, connector->dpms);
+ if (connector->funcs->dpms) {
+ int old_dpms = connector->dpms;
+
+ connector->dpms = DRM_MODE_DPMS_OFF;
+ connector->funcs->dpms(connector, old_dpms);
+ }
}
drm_modeset_unlock_all(dev);
--
1.9.1
[PATCH RFC 3/4] drm/exynos: remove master component PM callbacks
The patch removes master PM callbacks as their functionality
is already duplicated by suspend/resume drm callbacks.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index cf19e60..dca20b15 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -342,34 +342,6 @@ static struct drm_driver exynos_drm_driver = {
.minor = DRIVER_MINOR,
};
-#ifdef CONFIG_PM_SLEEP
-static int exynos_drm_sys_suspend(struct device *dev)
-{
- struct drm_device *drm_dev = dev_get_drvdata(dev);
- pm_message_t message;
-
- if (pm_runtime_suspended(dev) || !drm_dev)
- return 0;
-
- message.event = PM_EVENT_SUSPEND;
- return exynos_drm_suspend(drm_dev, message);
-}
-
-static int exynos_drm_sys_resume(struct device *dev)
-{
- struct drm_device *drm_dev = dev_get_drvdata(dev);
-
- if (pm_runtime_suspended(dev) || !drm_dev)
- return 0;
-
- return exynos_drm_resume(drm_dev);
-}
-#endif
-
-static const struct dev_pm_ops exynos_drm_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(exynos_drm_sys_suspend, exynos_drm_sys_resume)
-};
-
int exynos_drm_component_add(struct device *dev,
enum exynos_drm_device_type dev_type,
enum exynos_drm_output_type out_type)
@@ -634,7 +606,6 @@ static struct platform_driver exynos_drm_platform_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "exynos-drm",
- .pm = _drm_pm_ops,
},
};
--
1.9.1
[PATCH RFC 2/4] drm/core: re-enable suspend/resume callbacks for KMS drivers
Implementing suspend/resume functionality in componentized drm drivers using master component PM callbacks is problematic because those callbacks can be called asynchronously regardless of existence/state of drm device. The patch re-enables suspend/resume drm driver callbacks in drivers with modeset feature enabled. These callback can be used to implement suspend/resume functionality in more convenient way. The patch should not affect behavior of existing drm drivers. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/drm_sysfs.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c index cc3d6d6..206afc4 100644 --- a/drivers/gpu/drm/drm_sysfs.c +++ b/drivers/gpu/drm/drm_sysfs.c @@ -45,7 +45,6 @@ static int __drm_class_suspend(struct device *dev, pm_message_t state) struct drm_device *drm_dev = drm_minor->dev; if (drm_minor->type == DRM_MINOR_LEGACY && - !drm_core_check_feature(drm_dev, DRIVER_MODESET) && drm_dev->driver->suspend) return drm_dev->driver->suspend(drm_dev, state); } @@ -86,7 +85,6 @@ static int drm_class_resume(struct device *dev) struct drm_device *drm_dev = drm_minor->dev; if (drm_minor->type == DRM_MINOR_LEGACY && - !drm_core_check_feature(drm_dev, DRIVER_MODESET) && drm_dev->driver->resume) return drm_dev->driver->resume(drm_dev); } -- 1.9.1
[PATCH RFC 1/4] drm/i915: set PM callbacks only if modeset is turned off
Currently suspend and resume callbacks are called only if driver have
modeset feature disabled.
This patch moves the check directly to i915 driver, it will allow to
remove the check from the core in the future.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/i915_drv.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3870c73..481f62f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1617,10 +1617,6 @@ static struct drm_driver driver = {
.postclose = i915_driver_postclose,
.set_busid = drm_pci_set_busid,
- /* Used in place of i915_pm_ops for non-DRIVER_MODESET */
- .suspend = i915_suspend,
- .resume = i915_resume_legacy,
-
.device_is_agp = i915_driver_device_is_agp,
.master_create = i915_master_create,
.master_destroy = i915_master_destroy,
@@ -1684,6 +1680,8 @@ static int __init i915_init(void)
if (!(driver.driver_features & DRIVER_MODESET)) {
driver.get_vblank_timestamp = NULL;
+ driver.suspend = i915_suspend;
+ driver.resume = i915_resume_legacy;
#ifndef CONFIG_DRM_I915_UMS
/* Silently fail loading to not upset userspace. */
DRM_DEBUG_DRIVER("KMS and UMS disabled.\n");
--
1.9.1
[PATCH RFC 0/4] drm/core: restore suspend/resume calbacks in KMS drm drivers
The main intent of this patchset is to allow use of suspend/resume drm driver callbacks in KMS drivers, as these callbacks seems to me the best place to implement suspend/resume functionality in drm driver. Implementing this functionality in master component driver PM ops is problematic as those callbacks can be called asynchronously regardless of state/existence of drm device, thus it would require additional synchronization mechanism. Callbacks re-enabling requires small changes in i915 and exynos driver. The patchset contains also fix of exynos resume callback. Regards Andrzej Andrzej Hajda (4): drm/i915: set PM callbacks only if modeset is turned off drm/core: re-enable suspend/resume callbacks for KMS drivers drm/exynos: remove master component PM callbacks drm/exynos: correct connector->dpms field before resuming drivers/gpu/drm/drm_sysfs.c | 2 -- drivers/gpu/drm/exynos/exynos_drm_drv.c | 37 ++--- drivers/gpu/drm/i915/i915_drv.c | 6 ++ 3 files changed, 8 insertions(+), 37 deletions(-) -- 1.9.1
[PATCH v7 1/2] ASoC: codecs: Add a transmitter interface to the HDMI CODEC
The audio constraints of the HDMI interface are defined by the EDID
which is sent by the connected device.
The HDMI transmitters may have one or many audio sources.
This patch adds two functions to the HDMI CODEC:
- it updates the audio constraints from the EDID,
- it gives the audio source type to the HDMI transmitter
on start of audio streaming.
Signed-off-by: Jean-Francois Moine
---
include/sound/hdmi.h| 20 ++
sound/soc/codecs/hdmi.c | 176 ++--
2 files changed, 190 insertions(+), 6 deletions(-)
create mode 100644 include/sound/hdmi.h
diff --git a/include/sound/hdmi.h b/include/sound/hdmi.h
new file mode 100644
index 000..49062c7
--- /dev/null
+++ b/include/sound/hdmi.h
@@ -0,0 +1,20 @@
+#ifndef SND_HDMI_H
+#define SND_HDMI_H
+
+#include
+
+/* platform_data */
+struct hdmi_data {
+ int (*get_audio)(struct device *dev,
+int *max_channels,
+int *rate_mask,
+int *fmt);
+ void (*audio_switch)(struct device *dev,
+int port_index,
+unsigned sample_rate,
+int sample_format);
+ int ndais;
+ struct snd_soc_dai_driver *dais;
+ struct snd_soc_codec_driver *driver;
+};
+#endif
diff --git a/sound/soc/codecs/hdmi.c b/sound/soc/codecs/hdmi.c
index 1087fd5..0309d98 100644
--- a/sound/soc/codecs/hdmi.c
+++ b/sound/soc/codecs/hdmi.c
@@ -22,9 +22,148 @@
#include
#include
#include
+#include
+#include
#define DRV_NAME "hdmi-audio-codec"
+struct hdmi_priv {
+ struct hdmi_data hdmi_data;
+ struct snd_pcm_hw_constraint_list rate_constraints;
+};
+
+static int hdmi_dev_match(struct device *dev, void *data)
+{
+ return !strcmp(dev_name(dev), (char *) data);
+}
+
+/* get the codec device */
+static struct device *hdmi_get_cdev(struct device *dev)
+{
+ struct device *cdev;
+
+ cdev = device_find_child(dev,
+DRV_NAME,
+hdmi_dev_match);
+ if (!cdev)
+ dev_err(dev, "Cannot get codec device");
+ else
+ put_device(cdev);
+ return cdev;
+}
+
+static int hdmi_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ struct device *cdev;
+ struct hdmi_priv *priv;
+ struct snd_pcm_hw_constraint_list *rate_constraints;
+ int ret, max_channels, rate_mask, fmt;
+ u64 formats;
+ static const u32 hdmi_rates[] = {
+ 32000, 44100, 48000, 88200, 96000, 176400, 192000
+ };
+
+ cdev = hdmi_get_cdev(dai->dev);
+ if (!cdev)
+ return -ENODEV;
+ priv = dev_get_drvdata(cdev);
+
+ /* get the EDID values and the rate constraints buffer */
+ ret = priv->hdmi_data.get_audio(dai->dev,
+ _channels, _mask, );
+ if (ret < 0)
+ return ret; /* no screen */
+
+ /* convert the EDID values to audio constraints */
+ rate_constraints = >rate_constraints;
+ rate_constraints->list = hdmi_rates;
+ rate_constraints->count = ARRAY_SIZE(hdmi_rates);
+ rate_constraints->mask = rate_mask;
+ snd_pcm_hw_constraint_list(runtime, 0,
+ SNDRV_PCM_HW_PARAM_RATE,
+ rate_constraints);
+
+ formats = 0;
+ if (fmt & 1)
+ formats |= SNDRV_PCM_FMTBIT_S16_LE;
+ if (fmt & 2)
+ formats |= SNDRV_PCM_FMTBIT_S20_3LE;
+ if (fmt & 4)
+ formats |= SNDRV_PCM_FMTBIT_S24_LE |
+ SNDRV_PCM_FMTBIT_S24_3LE |
+ SNDRV_PCM_FMTBIT_S32_LE;
+ snd_pcm_hw_constraint_mask64(runtime,
+ SNDRV_PCM_HW_PARAM_FORMAT,
+ formats);
+
+ snd_pcm_hw_constraint_minmax(runtime,
+ SNDRV_PCM_HW_PARAM_CHANNELS,
+ 1, max_channels);
+ return 0;
+}
+
+static int hdmi_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+ struct device *cdev;
+ struct hdmi_priv *priv;
+
+ cdev = hdmi_get_cdev(dai->dev);
+ if (!cdev)
+ return -ENODEV;
+ priv = dev_get_drvdata(cdev);
+
+ priv->hdmi_data.audio_switch(dai->dev, dai->id,
+params_rate(params),
+params_format(params));
+ return 0;
+}
+
+static void hdmi_shutdown(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct device *cdev;
+ struct hdmi_priv *priv;
+
+ cdev =
[Bug 84627] (bisected) 32bit corruption with PIPE_USAGE_STREAM reverted
https://bugs.freedesktop.org/show_bug.cgi?id=84627 --- Comment #1 from smoki --- OK bisected kernel fast, by lucky guessing :) So for the kernel it is: 02376d8282b88f07d0716da6155094c8760b1a13 drm/radeon: Allow write-combined CPU mappings of BOs in GTT (v2) v2: fix rebase onto drm-fixes -- 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/20141003/68cc686a/attachment.html>
[Bug 84627] New: (bisected) 32bit corruption with PIPE_USAGE_STREAM reverted
https://bugs.freedesktop.org/show_bug.cgi?id=84627 Bug ID: 84627 Summary: (bisected) 32bit corruption with PIPE_USAGE_STREAM reverted Product: Mesa Version: git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: smoki00790 at gmail.com As Michel asks me here https://bugs.freedesktop.org/show_bug.cgi?id=82050#add_comment > (In reply to comment #65) > Keep in mind that revert broke 32bit complitely, lot of corruption :) >I haven't been able to reproduce that. If you still can, please file a bug for >>it, as there's nothing preventing the kernel from using GTT instead of VRAM >when >the latter is full. So i can reproduce it today too on 32bit (64bit is not affected, at least not by corruption) drm-next-3.18 kernel, 3.17.rc7, current mesa git and reverted this: http://lists.freedesktop.org/archives/mesa-dev/2014-August/066746.html For the mesa part, i already bisected that it starts at (might be same reason as bug 83436, but let alone that one for now): http://cgit.freedesktop.org/mesa/mesa/commit/?id=07c65b85eada8dd34019763b6e82ed4257a9b4a6 For the kernel part not bisected yet, but it is somewhere in between 3.16 and 3.17-rc1, so hopefully i will bisect that maybe today :) -- 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/20141003/46da9514/attachment.html>
[git pull] drm i915 and nouveau fixes
Hi Linus, Nothing too major or scary, one i915 regression fix, nouveau has a tmds regression fix, along with a regression fix for the runtime pm code for optimus laptops not restoring the display hw correctly. Dave. The following changes since commit fe82dcec644244676d55a1384c958d5f67979adb: Linux 3.17-rc7 (2014-09-28 14:29:07 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to eee0815dabbdd7d584bea8275f5758d25c97cb9b: Merge tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel into drm-fixes (2014-10-03 11:38:16 +1000) Ben Skeggs (4): drm/nv50/disp: fix dpms regression on certain boards drm/nouveau: fix regression on original nv50 board drm/nouveau: punt fbcon resume out to a workqueue drm/nouveau: make sure display hardware is reinitialised on runtime resume Chris Wilson (1): drm/i915: Flush the PTEs after updating them before suspend Dave Airlie (2): Merge branch 'linux-3.17' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Merge tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel into drm-fixes drivers/gpu/drm/i915/i915_gem_gtt.c | 14 ++- drivers/gpu/drm/nouveau/core/engine/disp/nv50.c | 3 +- drivers/gpu/drm/nouveau/nouveau_chan.c | 7 +++- drivers/gpu/drm/nouveau/nouveau_display.c | 23 ++- drivers/gpu/drm/nouveau/nouveau_display.h | 5 +-- drivers/gpu/drm/nouveau/nouveau_drm.c | 51 +++-- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 23 --- drivers/gpu/drm/nouveau/nouveau_fbcon.h | 1 + 8 files changed, 65 insertions(+), 62 deletions(-)
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #10 from Alexandre Demers --- (In reply to Jos? Su?rez from comment #9) > I have been trying linux 3.16 with the packet0 patch and after some testing > I haven't got any Packet0 message in the dmesg log. So I guess it must be > related to the 3.17 rc's. I don't remember getting similar crashes just by > watching youtube videos in firefox with previous kernels. > > I will try to build 3.17 rc6 (which was the version that gave the Packet0 > logs and system hangs) with the Packet 0 patch and report back. > > @Alexandre: Can you try linux 3.16 and see if it works properly for you? built and testing. I'll report ASAP. -- 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/20141003/bc5ec67b/attachment-0001.html>
[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init
https://bugzilla.kernel.org/show_bug.cgi?id=85491 --- Comment #5 from Zermond --- (In reply to Alex Deucher from comment #4) > Can you narrow down when the problem started? Even better, can you bisect? As soon as I updated the kernel. At version 3.11, everything was fine with version 3.16 of the problem. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 84614] radeon gpu crash /kernel crash when using dynamic light in borderlands 2
https://bugs.freedesktop.org/show_bug.cgi?id=84614 --- Comment #2 from Paulo Dias --- how can i do that? the kernel freezes and not even sysrq keys work anymore, i need to power off the pc. -- 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/20141003/058fa762/attachment.html>
[Bug 84614] radeon gpu crash /kernel crash when using dynamic light in borderlands 2
https://bugs.freedesktop.org/show_bug.cgi?id=84614 Michel D?nzer changed: What|Removed |Added Component|DRM/Radeon |Drivers/Gallium/radeonsi Version|DRI CVS |git Product|DRI |Mesa --- Comment #1 from Michel D?nzer --- Probably a radeonsi issue. Can you try creating an apitrace which reproduces the problem? -- 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/20141003/e190b1e9/attachment.html>
[Bug 84614] New: radeon gpu crash /kernel crash when using dynamic light in borderlands 2
] radeon :03:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x02008001 Oct 2 21:14:42 kerberos kernel: [ 719.975178] VM fault (0x01, vmid 1) at page 196085842, read from TC (8) Oct 2 21:14:42 kerberos kernel: [ 719.975227] radeon :03:00.0: GPU fault detected: 147 0x0a420801 Oct 2 21:14:42 kerberos kernel: [ 719.975230] radeon :03:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0BB00852 Oct 2 21:14:42 kerberos kernel: [ 719.975232] radeon :03:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x02008001 llvm 5.2, kernel 3.17 rc7, latest microcode, mesa 10.4 git from oibaf ppa, same for radeon driver. -- 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/20141003/b5db7a40/attachment-0001.html>
