[Bug 87278] Packet0 not allowed and GPU fault detected errors with Serious Engine games
radeon :01:00.0: GPU reset succeeded, trying to resume Jan 05 06:29:11 -- kernel: [drm] probing gen 2 caps for device 8086:2e31 = 2212501/0 Jan 05 06:29:11 -- kernel: [drm] PCIE GART of 1024M enabled (table at 0x00277000). Jan 05 06:29:11 -- kernel: radeon :01:00.0: WB enabled Jan 05 06:29:11 -- kernel: radeon :01:00.0: fence driver on ring 0 use gpu addr 0x00010c00 and cpu addr 0x8800db08fc00 Jan 05 06:29:11 -- kernel: radeon :01:00.0: fence driver on ring 1 use gpu addr 0x00010c04 and cpu addr 0x8800db08fc04 Jan 05 06:29:11 -- kernel: radeon :01:00.0: fence driver on ring 2 use gpu addr 0x00010c08 and cpu addr 0x8800db08fc08 Jan 05 06:29:11 -- kernel: radeon :01:00.0: fence driver on ring 3 use gpu addr 0x00010c0c and cpu addr 0x8800db08fc0c Jan 05 06:29:11 -- kernel: radeon :01:00.0: fence driver on ring 4 use gpu addr 0x00010c10 and cpu addr 0x8800db08fc10 Jan 05 06:29:11 -- kernel: radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu addr 0xc900048b5a18 Jan 05 06:29:11 -- kernel: [drm] ring test on 0 succeeded in 3 usecs Jan 05 06:29:11 -- kernel: [drm] ring test on 1 succeeded in 1 usecs Jan 05 06:29:11 -- kernel: [drm] ring test on 2 succeeded in 1 usecs Jan 05 06:29:11 -- kernel: [drm] ring test on 3 succeeded in 6 usecs Jan 05 06:29:11 -- kernel: [drm] ring test on 4 succeeded in 6 usecs Jan 05 06:29:11 -- kernel: [drm] ring test on 5 succeeded in 2 usecs Jan 05 06:29:11 -- kernel: [drm] UVD initialized successfully. Jan 05 06:29:11 -- kernel: switching from power state: Jan 05 06:29:11 -- kernel: ui class: none Jan 05 06:29:11 -- kernel: internal class: boot Jan 05 06:29:11 -- kernel: caps: Jan 05 06:29:11 -- kernel: uvdvclk: 0 dclk: 0 Jan 05 06:29:11 -- kernel: power level 0sclk: 15000 mclk: 15000 vddc: 950 vddci: 950 pcie gen: 1 Jan 05 06:29:11 -- kernel: status: c b ... -- 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/20150105/2535b3b4/attachment.html>
[Bug 87278] Packet0 not allowed and GPU fault detected errors with Serious Engine games
https://bugs.freedesktop.org/show_bug.cgi?id=87278 --- Comment #16 from Arash --- Created attachment 111751 --> https://bugs.freedesktop.org/attachment.cgi?id=111751&action=edit sorry i should've attached 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/20150105/fe208d8d/attachment.html>
[LKP] [PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel
Oded Gabbay writes:
> On 12/24/2014 01:01 AM, Rusty Russell wrote:
>> Oded Gabbay writes:
>>> I didn't say it doesn't always work.
>>> The actual thing that doesn't work is the define symbol_get and only in a
>>> specific case of 32bit kernel AND CONFIG_MODULES is unset AND
>>> CONFIG_RANDOMIZE_BASE is set.
>>> The define in that case is:
>>> #define symbol_get(x) ({ extern typeof(x) x __attribute__((weak)); &(x); })
>>>
>>> Why it doesn't work (doesn't return NULL when symbol doesn't exists) ?
>>
>> Hmm, I'd guess CONFIG_RANDOMIZE_BASE is relocating NULL symbols...
>>
>> No, I can't reproduce this. Please send your .config privately.
>>
>> Here's my test case:
>>
>> diff --git a/init/main.c b/init/main.c
>> index 61b993767db5..a3ee1ec97ec3 100644
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -683,6 +683,12 @@ asmlinkage __visible void __init start_kernel(void)
>>
>> ftrace_init();
>>
>> +{
>> +extern void nonexistent_fn(void);
>> +printk("symbol_get(nonexistent_fn) = %p\n",
>> + symbol_get(nonexistent_fn));
>> +}
>> +
>> /* Do the rest non-__init'ed, we're now alive */
>> rest_init();
>> }
>>
>> Thanks,
>> Rusty.
>>
> Hi Rusty,
>
> Attached is the bad config file. (config-bad)
> I have narrowed the changes you need to do to the config file in order to
> reproduce this bug.
> The base assumption is a 32-bit kernel and without modules support. Rest of
> the
> config file is pretty standard, IMO.
> Then, its not enough to enable CONFIG_RANDOMIZE_BASE like I wrote in my
> original
> post. You need also to unset CONFIG_HIBERNATION.
Indeed, thanks; your config breaks as reported. With CONFIG_HIBERNATION
the kernel offset is 0, so we don't see this.
Kees, as far as I can tell you need another 0-terminated vmlinux.relocs
section for weak symbols. These should not be relocated if already 0.
Put this somewhere to test. It fails for x86_64, too:
diff --git a/init/main.c b/init/main.c
index 61b993767db5..c9e0195c792a 100644
--- a/init/main.c
+++ b/init/main.c
@@ -683,6 +683,12 @@ asmlinkage __visible void __init start_kernel(void)
ftrace_init();
+ {
+ extern void __attribute__((weak)) nonexistent_fn(void);
+ printk("nonexistent_fn = %p\n", nonexistent_fn);
+ BUG_ON(nonexistent_fn != NULL);
+ }
+
/* Do the rest non-__init'ed, we're now alive */
rest_init();
}
Cheers,
Rusty.
[RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support
On Sun, Dec 21, 2014 at 02:40:24PM +, Cheng, Yao wrote: > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] > > Sent: Thursday, December 18, 2014 19:21 > > To: Thierry Reding > > Cc: Cheng, Yao; intel-gfx at lists.freedesktop.org; dri- > > devel at lists.freedesktop.org; Kelley, Sean V; Chehab, John; > > emil.l.velikov at gmail.com; Jiang, Fei > > Subject: Re: [RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support > > > > On Thu, Dec 18, 2014 at 11:04 AM, Thierry Reding > gmail.com> > > wrote: > > >> I double checked the symptom and found it was a deadlock on > > drm_global_mutex. > > >> When i915_driver_load() registers the platform device while ipvr module > > is in the system, ipvr's probe() function tries to lock drm_global_mutex > > which > > was already held by i915. > > >> I think either of the following 2 actions need to be moved to a bottom > > >> half > > e.g. a work queue: > > >> platform_device_add () call in i915_ved.c (called during > > i915_driver_load()) > > >> drm_dev_register() call during ipvr's probe() Which one makes > > >> more sense? pls kindly advise (I personally prefer the former one.). > > > > > > Yes, that's somewhat ugly, but I don't see a way around that. I'd also > > > think that moving platform_device_add() to a workqueue would be the > > > best option here. > > > > Or we simply kill drm_global_mutex for platform drivers that don't use the - > > >probe hook. It should work when they have a correct order betwen > > drm_dev_alloc and _register and all the code in between. So just ditch the - > > >load callback in teh ipvr driver and rework the load sequence as suggested > > somewhere else and this is fixed already. No need for bottom halfs I think. > > Daniel, sorry I didn't quite understand "platform drivers that don't use > the probe hook". For initialization, the ipvr platform driver's probe() > is called in following 2 possible paths: > 1. ipvr installed before i915. In this case, ipvr's probe() is called > inside i915_driver_load() and falls into the drm_global_mutex dead lock. > 2. i915 installed before ipvr. In this case, ipvr's probe() is called > without drm_global_mutex held by i915 and no dead lock issue. > If we kill drm_global_mutex, will path 2 run into issue? And in your > suggestion, how to rework the load sequence? Do you mean calling ipvr's > load() callback directly during platform driver probe()? Hm right it's not that simple really. What we need in more detail is: - Move the mutex_lock(&drm_global_mutex) out of drm_dev_register into all the callers. If a driver has a ->load() callback it most likely is racy with the usual load ordering issues. - Rework ipvr to no longer have a ->load callback. Insteaed use the following sequence (in the platform ->probe callback): drm_dev_alloc(); ipvr_load(); drm_dev_register(); With that ordering we don't need the additional guarantees that drm_global_mutex provides and we can avoid to take that lock around drm_dev_registrer() call in the ipvr code. This should resolve the deadlock I hope. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH RFC v7 16/21] drm: panel: Add support for Himax HX8369A MIPI DSI panel
On Tue, Dec 30, 2014 at 11:34:06AM +0800, Liu Ying wrote: > This patch adds support for Himax HX8369A MIPI DSI panel. > > Reviewed-by: Andrzej Hajda > Signed-off-by: Liu Ying > --- > v6->v7: > * Address Andrzej Hajda's following comments. > * Simplify the return logic in hx8369a_dcs_write(). > * Replace the macro hx8369a_dsi_init_helper() with a function array to > improve >the code quality. > * Handle error cases during getting gpios in probe(). > * Add 'Reviewed-by: Andrzej Hajda '. If you only update one patch in a big series it's imo better to just resend that one to avoid spamming the mailing list with noise. Imo it also helps to keep the discussion all nicely grouped together. In any case please give a short overview of what changed in the cover letter when resending the entire series so that people don't have to go through all the invidual patches. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 90741] Radeon: System pauses on TAHITI
https://bugzilla.kernel.org/show_bug.cgi?id=90741 --- Comment #2 from Michel Dänzer --- Does it still happen with a 3.19-rc kernel? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 90741] Radeon: System pauses on TAHITI
https://bugzilla.kernel.org/show_bug.cgi?id=90741 Maarten Lankhorst changed: What|Removed |Added CC||bugs at mblankhorst.nl --- Comment #3 from Maarten Lankhorst --- Ok so that commit introduces the bad behavior, does commit 39e7f6f84b3a3aa4520504473f2e2bac1f949ffa "drm/radeon: use rcu waits in some ioctls" or commit "drm/ttm: use rcu in core ttm" change the bad behavior in any way? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 88043] Star Conflict locks up AMD BARTS
https://bugs.freedesktop.org/show_bug.cgi?id=88043 Bug ID: 88043 Summary: Star Conflict locks up AMD BARTS Product: Mesa Version: git Hardware: Other OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: EoD at xmw.de Created attachment 111753 --> https://bugs.freedesktop.org/attachment.cgi?id=111753&action=edit dmesg output during the lockup Every time I am trying to start the free-to-play game "Star Conflict" via Steam it locks up as soon as a match has been started. I was only able to shutdown the computer via ssh, no input device did work. -- 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/20150105/7e0f3b02/attachment.html>
[Bug 88043] Star Conflict locks up AMD BARTS
https://bugs.freedesktop.org/show_bug.cgi?id=88043 --- Comment #1 from EoD --- Created attachment 111754 --> https://bugs.freedesktop.org/attachment.cgi?id=111754&action=edit glxinfo output -- 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/20150105/666e1c48/attachment.html>
[Bug 84292] [r600] crashes in Tropico 5 with Radeon HD 5xxx
https://bugs.freedesktop.org/show_bug.cgi?id=84292 --- Comment #10 from Michel Dänzer --- (In reply to leonmaxx from comment #8) > Just got same bug while testing various landscape rendering techniques. Please file your own report about that. BTW, don't expect others to download random executables and run them on their systems. If you can't provide the source code for your test application, maybe you can generate an apitrace which reproduces the problem. Or, even just attaching the stderr output from running the app with R600_DEBUG=vs,gs,ps might be useful. -- 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/20150105/bcf05fcc/attachment-0001.html>
[PATCH RFC v7 16/21] drm: panel: Add support for Himax HX8369A MIPI DSI panel
Hi Daniel, On 01/05/2015 04:54 PM, Daniel Vetter wrote: > On Tue, Dec 30, 2014 at 11:34:06AM +0800, Liu Ying wrote: >> This patch adds support for Himax HX8369A MIPI DSI panel. >> >> Reviewed-by: Andrzej Hajda >> Signed-off-by: Liu Ying >> --- >> v6->v7: >> * Address Andrzej Hajda's following comments. >> * Simplify the return logic in hx8369a_dcs_write(). >> * Replace the macro hx8369a_dsi_init_helper() with a function array to >> improve >> the code quality. >> * Handle error cases during getting gpios in probe(). >> * Add 'Reviewed-by: Andrzej Hajda '. > > If you only update one patch in a big series it's imo better to just > resend that one to avoid spamming the mailing list with noise. Imo it also > helps to keep the discussion all nicely grouped together. Thanks for your suggestion. I would try to make people happy about the way the series is submitted for review. > > In any case please give a short overview of what changed in the cover > letter when resending the entire series so that people don't have to go > through all the invidual patches. Yes, absolutely. I gave short overviews of what changed in the very beginning of the cover letters from v2 to v8 and I will do this in every necessary follow-up version. Regards, Liu Ying > -Daniel >
[Intel-gfx] [PATCH] drm: Make drm_read() more robust against multithreaded races
On Fri, Dec 05, 2014 at 09:42:35AM +0100, Takashi Iwai wrote: > At Thu, 4 Dec 2014 21:03:25 +, > Chris Wilson wrote: > > > > The current implementation of drm_read() faces a number of issues: > > > > 1. Upon an error, it consumes the event which may lead to the client > > blocking. > > 2. Upon an error, it forgets about events already copied > > 3. If it fails to copy a single event with O_NONBLOCK it falls into a > > infinite loop of reporting EAGAIN. > > 3. There is a race between multiple waiters and blocking reads of the > > events list. > > > > Here, we inline drm_dequeue_event() into drm_read() so that we can take > > the spinlock around the list walking and event copying, and importantly > > reorder the error handling to avoid the issues above. > > > > Cc: Takashi Iwai > > Reviewed-by: Takashi Iwai Merged to drm-misc with the tag for the drm_read testcase added. Thanks for the patch&reivew. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
drm/nouveau: dont switch vt on suspend
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 3ed12a8cfc91..a4a586807903 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -370,6 +370,7 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
ret = -ENOMEM;
goto out_unlock;
}
+ info->skip_vt_switch = 1;
ret = fb_alloc_cmap(&info->cmap, 256, 0);
if (ret) {
[PULL] topic/atomic-core
Hi Dave, Updated pull request for atomic-core because Tvrtko Ursulin reported an Oopseable fumble for which I've squashed in a fixup patch. Plus one refinement for the handling of the atomic per-file caps. Below the blabla from the orignal pull request. Next batch of atomic work. Most important is the propertification from Rob and the nth iteration of the actual atomic ioctl originally from Ville. Big differences compared to earlier revisions: - Core properties are now fully handled by the core, drivers can only handle driver-specific properties. - Atomic props&ioctl are opt-in per file_priv, userspace needs to explicitly ask for it (like universal plane support). - For now all hidden behind the atomic module option until this has settled a bit. - Atomic modesets are currently not possible since the exact abi for how to handle the mode property is still under discussion. Besides this some cleanup patches from me and the addition of per-object state to global state backpointers to simplify drivers. Other oustanding things not yet in here I'm aware of (besides the mode prop issue mentioned above): - dpms handling (still working on that) - Thierry's atomic helper patch to add plane_funcs->atomic_disable as an optional hook. Many drivers (tegra, exynos, i915) seem to want this. Note that there was a conflict with my drm misc branch so there's a merge in here. The diff looks sane when you merge topic/core-stuff before this branch here. There's also one bugfix from Rob in here for which I've sent you a pull request for 3.19 already, too. Cheers, Daniel The following changes since commit 4e0cd68115620bc3236ff4e58e4c073948629b41: drm: sti: fix module compilation issue (2014-12-15 17:07:57 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/atomic-core-2015-01-05 for you to fetch changes up to 179f158ccf15fb9425f53d589d1b48eab90449a6: drm: Ensure universal_planes is set for atomic (2015-01-05 13:55:30 +0100) Ben Widawsky (1): drm/cache: Use wbinvd helpers Daniel Vetter (6): drm/atomic-helper: Export both plane and modeset check helpers drm/atomic-helper: Again check modeset *before* plane states drm/atomic: Introduce state->obj backpointers Merge branch 'topic/core-stuff' into topic/atomic-core drm/atomic: Hide drm.ko internal interfaces drm: Ensure universal_planes is set for atomic Laurent Pinchart (1): drm/doc: Document drm_add_modes_noedid() usage Matt Roper (1): drm/plane-helper: Test for plane disable earlier Rob Clark (15): drm: bit of spell-check / editorializing. drm/atomic: fix potential null ptr on plane enable drm: allow property validation for refcnted props drm: store property instead of id in obj attachment drm: get rid of direct property value access drm: add atomic_set_property wrappers drm: add atomic_get_property drm: tweak getconnector locking drm: refactor getproperties/getconnector drm: add atomic properties drm/atomic: atomic_check functions drm: small property creation cleanup drm/atomic: atomic plane properties drm/atomic: atomic connector properties drm: Atomic modeset ioctl Thierry Reding (13): drm/armada: Remove dummy ->load_lut() implementation drm/bochs: Remove dummy ->load_lut() implementation drm/msm: Remove dummy ->load_lut() implementation drm/sti: Remove dummy ->load_lut() implementation drm/tegra: Remove dummy ->load_lut() implementation drm: Miscellaneous checkpatch whitespace cleanups drm: Prefer kcalloc() over kzalloc() with multiply drm: Prefer kmalloc_array() over kmalloc() with multiply drm: Do not assign in if condition drm: Remove unneeded braces for single statement blocks drm: Remove useless else block drm: Prefer sizeof(type) over sizeof type drm/info: Remove unused code Documentation/DocBook/drm.tmpl| 91 +++- drivers/gpu/drm/armada/armada_crtc.c | 5 - drivers/gpu/drm/bochs/bochs_kms.c | 5 - drivers/gpu/drm/drm_atomic.c | 730 +- drivers/gpu/drm/drm_atomic_helper.c | 108 - drivers/gpu/drm/drm_cache.c | 13 +- drivers/gpu/drm/drm_crtc.c| 428 +++--- drivers/gpu/drm/drm_crtc_helper.c | 2 + drivers/gpu/drm/drm_crtc_internal.h | 6 + drivers/gpu/drm/drm_drv.c | 4 + drivers/gpu/drm/drm_info.c| 24 - drivers/gpu/drm/drm_internal.h| 1 - drivers/gpu/drm/drm_ioctl.c | 13 + drivers/gpu/drm/drm_irq.c | 11 +- drivers/gpu/drm/drm_plane_helper.c| 18 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 5 - drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 5 - drivers/gpu/drm/msm/mdp/mdp5/
[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 #3 from Andre --- Currently using mesa 10.2.8 Will try to install mesa 10.3.5-r1 now. The error didn't occur since writing this bug. So it's not very often but i will try. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support
On Fri, Jan 02, 2015 at 01:10:14PM +, Daniel Stone wrote: > 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? The plan is for me to take the bridge patches through the drm/panel tree. I'm going to look at these patches again later this week but from a very quick peek there don't seem to be any major issues left. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150105/93ebed52/attachment-0001.sig>
[PATCH 1/2] drm/radeon: Assign VMID to PASID for IH in non-HWS mode
From: Ben Goz This patch fixes a bug in kgd_set_pasid_vmid_mapping(), where the function only updated the ATC registers (IOMMU) with the new VMID <--> PASID mapping, but didn't update the IH (Interrupt) registers. The bug only occurs when using non-HWS mode. In HWS mode, the CP automatically does the VMID <--> PASID mapping. Signed-off-by: Ben Goz Signed-off-by: Oded Gabbay --- drivers/gpu/drm/radeon/cikd.h | 2 ++ drivers/gpu/drm/radeon/radeon_kfd.c | 4 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h index ba85986..03003f8 100644 --- a/drivers/gpu/drm/radeon/cikd.h +++ b/drivers/gpu/drm/radeon/cikd.h @@ -2156,4 +2156,6 @@ #define ATC_VM_APERTURE1_HIGH_ADDR 0x330Cu #define ATC_VM_APERTURE1_LOW_ADDR 0x3304u +#define IH_VMID_0_LUT 0x3D40u + #endif diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c b/drivers/gpu/drm/radeon/radeon_kfd.c index a55afba..8bf87f1 100644 --- a/drivers/gpu/drm/radeon/radeon_kfd.c +++ b/drivers/gpu/drm/radeon/radeon_kfd.c @@ -390,6 +390,10 @@ static int kgd_set_pasid_vmid_mapping(struct kgd_dev *kgd, unsigned int pasid, cpu_relax(); write_register(kgd, ATC_VMID_PASID_MAPPING_UPDATE_STATUS, 1U << vmid); + /* Mapping vmid to pasid also for IH block */ + write_register(kgd, IH_VMID_0_LUT + vmid * sizeof(uint32_t), + pasid_mapping); + return 0; } -- 1.9.1
[PATCH 2/2] drm/amdkfd: unmap VMID<-->PASID when relesing VMID (non-HWS)
From: Ben Goz
This patch fixes a bug where deallocate_vmid() didn't actually unmap the
VMID<-->PASID mapping (in the registers).
That can cause undefined behavior.
This bug only occurs in non-HWS mode.
Signed-off-by: Ben Goz
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 3b08ed6..9c8961d 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -161,6 +161,9 @@ static void deallocate_vmid(struct device_queue_manager
*dqm,
{
int bit = qpd->vmid - KFD_VMID_START_OFFSET;
+ /* Release the vmid mapping */
+ set_pasid_vmid_mapping(dqm, 0, qpd->vmid);
+
set_bit(bit, (unsigned long *)&dqm->vmid_bitmap);
qpd->vmid = 0;
q->properties.vmid = 0;
--
1.9.1
[PATCH v2 2/3] drm/panel: add s6e63j0x03 LCD panel driver
On Wed, Dec 31, 2014 at 07:41:43PM +0900, Inki Dae wrote: > Hi Thierry, > > Ping~. > > Or is it ok to pick up this patch to my tree, exynos-drm-next? It > doesn't seem to care for a long time. I don't seem to have a copy of the v2 2/3 patch. All I found in my inbox is the v2 0/3 cover-letter. Please resend with me in Cc so that I can properly review (and apply) the patch. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150105/bdf2775f/attachment.sig>
[PATCH 4/5] gpu: host1x: Provide a proper struct bus_type
On Tue, Dec 23, 2014 at 03:30:20PM +0800, Mark Zhang wrote: > On 12/19/2014 11:24 PM, Thierry Reding wrote: > > From: Thierry Reding > > > > Previously the struct bus_type exported by the host1x infrastructure was > > only a very basic skeleton. Turn that implementation into a more full- > > fledged bus to support proper probe ordering and power management. > > > > Note that the bus infrastructure needs to be available before any of the > > drivers can be registered, so the bus needs to be registered before the > > host1x module. Otherwise drivers could be registered before the module > > is loaded and trigger a BUG_ON() in driver_register(). To ensure the bus > > infrastructure is always there, always build the code into the kernel > > when enabled and register it with a postcore initcall. > > > > So this means there is no chance that host1x can be built as a kernel > module, right? I'm fine with that, just asking. No, it means that not all of host1x can be built as a module. The host1x bus infrastructure will always be built-in when TEGRA_HOST1X is enabled. > > Signed-off-by: Thierry Reding > > --- > [...] > > diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile > > index c1189f004441..a3e667a1b6f5 100644 > > --- a/drivers/gpu/host1x/Makefile > > +++ b/drivers/gpu/host1x/Makefile > > @@ -1,5 +1,4 @@ > > host1x-y = \ > > - bus.o \ > > syncpt.o \ > > dev.o \ > > intr.o \ > > @@ -13,3 +12,5 @@ host1x-y = \ > > hw/host1x04.o > > > > obj-$(CONFIG_TEGRA_HOST1X) += host1x.o > > + > > +obj-y += bus.o > > I didn't get it, why we need to do this? If CONFIG_TEGRA_HOST1X=m, then obj-$(CONFIG_TEGRA_HOST1X) builds the bus.o into a module. But we want it to always be built-in. The build system will descend into the drivers/gpu/host1x directory only if the TEGRA_HOST1X symbol is selected (either =y or =m), therefore obj-y here will result in bus.o being built-in whether the rest of host1x is built as a module or built-in. > > diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c > > index 0b52f0ea8871..28630a5e9397 100644 > > --- a/drivers/gpu/host1x/bus.c > > +++ b/drivers/gpu/host1x/bus.c > > @@ -72,13 +72,14 @@ static void host1x_subdev_del(struct host1x_subdev > > *subdev) > [...] > > > > static inline struct host1x_device *to_host1x_device(struct device *dev) > > > > The change looks good to me. Just one thing I feel not comfortable: > "struct host1x_device" is not a real device, it represents the drm > device actually. The real tegra host1x device is represented by "struct > host1x". But the name "host1x_device" makes people confusing, I mean, it > will make people thinking it's the real "tegra host1x" device then bring > the reading difficulty. The reason behind that name is that host1x provides a bus (real to some degree, but also virtual). host1x is the device that provides the bus whereas a host1x_device is a "device" on the "host1x" bus. That's just like an i2c_client is a "client" on the "I2C" bus. Or an spi_device is a "device" on the "SPI" bus. > Why don't we change this to something like "drm_device" or > "tegra_drm_device"? Other devices can be host1x devices. Some time ago work was being done on a driver for the CSI/VI hardware (for camera or video input). The idea was that it would also be instantiated as a host1x_device in some other subsystem (V4L2 at the time). The functionality here is generic and in no way DRM specific. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150105/1c562035/attachment.sig>
[PATCH 5/5] drm/tegra: Add minimal power management
On Tue, Dec 23, 2014 at 03:32:43PM +0800, Mark Zhang wrote: > +1 Does that translate into a "Reviewed-by" or "Tested-by"? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150105/5d0bea8f/attachment.sig>
[PATCH 0/2] Change order of linkage in kernel makefiles for amdkfd
dependency. > >>BTW, my first try at solving this was to use probe deferral (using > >>workqueue), but the feedback I got from Christian and Dave was that moving > >>iommu/ linkage before gpu/ was a much more simpler solution. > >To clarify my position, I believe changing the link order can be a worthwhile > >optimization, but I'm uncertain about the long term viability of that change > >as a fix. Probe deferral has been introduced because not all probe ordering > >issues can be fixed through link ordering, so we should fix the problem > >properly. > > > >This being said, if modifying the link order can help for now without > >introducing negative side effects, it would only postpone the real fix, so > >I'm > >not opposed to it. > > Yeah, that sounds like the right approach to me as well. I don't think that's a good approach at all. It doesn't encode the dependency anywhere. All you have is some Makefile that lists a bunch of directories. What happens if anybody was to change that order for some other reason? If you're not Cc'ed on the patch and nobody else NAK's it because they are accidentally aware of the dependency that patch is going to break radeon. > In general I would prefer that modules compiled into the kernel load > by the order of their symbol dependency just like standalone modules > do. That I generally agree with. But it can't be a replacement for properly describing the runtime dependencies between modules. There can be other reasons than link order that influence probe ordering. What if the IOMMU driver for some reason gains deferred probe support and therefore doesn't succeed on the first probe? Or only sometimes. Properly describing the dependency is the only way to prevent any of that. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150105/4198124d/attachment-0001.sig>
[PATCH 4/5] gpu: host1x: Provide a proper struct bus_type
On Fri, Dec 19, 2014 at 10:24 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Previously the struct bus_type exported by the host1x infrastructure was
> only a very basic skeleton. Turn that implementation into a more full-
> fledged bus to support proper probe ordering and power management.
>
> Note that the bus infrastructure needs to be available before any of the
> drivers can be registered, so the bus needs to be registered before the
> host1x module. Otherwise drivers could be registered before the module
> is loaded and trigger a BUG_ON() in driver_register(). To ensure the bus
> infrastructure is always there, always build the code into the kernel
> when enabled and register it with a postcore initcall.
>
> Signed-off-by: Thierry Reding
This is a nice improvement.
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/tegra/drm.c | 4 +-
> drivers/gpu/host1x/Makefile | 3 +-
> drivers/gpu/host1x/bus.c| 115
> +++-
> drivers/gpu/host1x/bus.h| 3 --
> drivers/gpu/host1x/dev.c| 9 +---
> include/linux/host1x.h | 18 +--
> 6 files changed, 102 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index e549afeece1f..272c2dca3536 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -908,7 +908,9 @@ static const struct of_device_id host1x_drm_subdevs[] = {
> };
>
> static struct host1x_driver host1x_drm_driver = {
> - .name = "drm",
> + .driver = {
> + .name = "drm",
> + },
> .probe = host1x_drm_probe,
> .remove = host1x_drm_remove,
> .subdevs = host1x_drm_subdevs,
> diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
> index c1189f004441..a3e667a1b6f5 100644
> --- a/drivers/gpu/host1x/Makefile
> +++ b/drivers/gpu/host1x/Makefile
> @@ -1,5 +1,4 @@
> host1x-y = \
> - bus.o \
> syncpt.o \
> dev.o \
> intr.o \
> @@ -13,3 +12,5 @@ host1x-y = \
> hw/host1x04.o
>
> obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
> +
> +obj-y += bus.o
> diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
> index 0b52f0ea8871..28630a5e9397 100644
> --- a/drivers/gpu/host1x/bus.c
> +++ b/drivers/gpu/host1x/bus.c
> @@ -72,13 +72,14 @@ static void host1x_subdev_del(struct host1x_subdev
> *subdev)
> /**
> * host1x_device_parse_dt() - scan device tree and add matching subdevices
> */
> -static int host1x_device_parse_dt(struct host1x_device *device)
> +static int host1x_device_parse_dt(struct host1x_device *device,
> + struct host1x_driver *driver)
> {
> struct device_node *np;
> int err;
>
> for_each_child_of_node(device->dev.parent->of_node, np) {
> - if (of_match_node(device->driver->subdevs, np) &&
> + if (of_match_node(driver->subdevs, np) &&
> of_device_is_available(np)) {
> err = host1x_subdev_add(device, np);
> if (err < 0)
> @@ -109,17 +110,12 @@ static void host1x_subdev_register(struct host1x_device
> *device,
> mutex_unlock(&device->clients_lock);
> mutex_unlock(&device->subdevs_lock);
>
> - /*
> -* When all subdevices have been registered, the composite device is
> -* ready to be probed.
> -*/
> if (list_empty(&device->subdevs)) {
> - err = device->driver->probe(device);
> + err = device_add(&device->dev);
> if (err < 0)
> - dev_err(&device->dev, "probe failed for %ps: %d\n",
> - device->driver, err);
> + dev_err(&device->dev, "failed to add: %d\n", err);
> else
> - device->bound = true;
> + device->registered = true;
> }
> }
>
> @@ -127,18 +123,16 @@ static void __host1x_subdev_unregister(struct
> host1x_device *device,
>struct host1x_subdev *subdev)
> {
> struct host1x_client *client = subdev->client;
> - int err;
>
> /*
> * If all subdevices have been activated, we're about to remove the
> * first active subdevice, so unload the driver first.
> */
> - if (list_empty(&device->subdevs) && device->bound) {
> - err = device->driver->remove(device);
> - if (err < 0)
> - dev_err(&device->dev, "remove failed: %d\n", err);
> -
> - device->bound = false;
> + if (list_empty(&device->subdevs)) {
> + if (device->registered) {
> + device->registered = false;
> + device_del(&device->dev);
> + }
> }
>
> /*
> @@ -265,19 +259,65 @@ static int host1x_del_client(struct host1x *host1x,
> return -ENODEV;
> }
[PATCH 5/5] drm/tegra: Add minimal power management
On Fri, Dec 19, 2014 at 10:24 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> For now only disable the KMS hotplug polling helper logic upon suspend
> and re-enable it on resume.
>
> Signed-off-by: Thierry Reding
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/tegra/drm.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index 272c2dca3536..16c44b9abbd8 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -889,6 +889,30 @@ static int host1x_drm_remove(struct host1x_device *dev)
> return 0;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int host1x_drm_suspend(struct device *dev)
> +{
> + struct drm_device *drm = dev_get_drvdata(dev);
> +
> + drm_kms_helper_poll_disable(drm);
> +
> + return 0;
> +}
> +
> +static int host1x_drm_resume(struct device *dev)
> +{
> + struct drm_device *drm = dev_get_drvdata(dev);
> +
> + drm_kms_helper_poll_enable(drm);
> +
> + return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops host1x_drm_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(host1x_drm_suspend, host1x_drm_resume)
> +};
> +
> static const struct of_device_id host1x_drm_subdevs[] = {
> { .compatible = "nvidia,tegra20-dc", },
> { .compatible = "nvidia,tegra20-hdmi", },
> @@ -910,6 +934,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
> static struct host1x_driver host1x_drm_driver = {
> .driver = {
> .name = "drm",
> + .pm = &host1x_drm_pm_ops,
> },
> .probe = host1x_drm_probe,
> .remove = host1x_drm_remove,
> --
> 2.1.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH try2 incomplete] drm/nouveau: dont switch vt on suspend
Seems the first try was incomplete and because of no_console_suspend in my
cmdline I never noticed.
This patch is still incomplete, it seems Xorg returns with a black screen after
suspend, but
after a vt switch this is cleared. At least the cursor works now...
I'm open for feedback on the black X.org issue and if this approach for fixing
cursor is sane. :-)
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index f8042433752b..f972e9c1a23a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -570,7 +570,8 @@ nouveau_display_suspend(struct drm_device *dev, bool
runtime)
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
if (nv_crtc->cursor.nvbo) {
- nouveau_bo_unmap(nv_crtc->cursor.nvbo);
+ if (nv_crtc->cursor.set_offset)
+ nouveau_bo_unmap(nv_crtc->cursor.nvbo);
nouveau_bo_unpin(nv_crtc->cursor.nvbo);
}
}
@@ -604,7 +605,7 @@ nouveau_display_resume(struct drm_device *dev, bool runtime)
continue;
ret = nouveau_bo_pin(nv_crtc->cursor.nvbo, TTM_PL_FLAG_VRAM,
true);
- if (!ret)
+ if (!ret && nv_crtc->cursor.set_offset)
ret = nouveau_bo_map(nv_crtc->cursor.nvbo);
if (ret)
NV_ERROR(drm, "Could not pin/map cursor.\n");
@@ -637,7 +638,9 @@ nouveau_display_resume(struct drm_device *dev, bool runtime)
if (!nv_crtc->cursor.nvbo)
continue;
- nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->bo.offset);
+
+ if (nv_crtc->cursor.set_offset)
+ nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->bo.offset);
nv_crtc->cursor.set_pos(nv_crtc, nv_crtc->cursor_saved_x,
nv_crtc->cursor_saved_y);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 3ed12a8cfc91..d6e6958bc5f8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -370,6 +370,7 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
ret = -ENOMEM;
goto out_unlock;
}
+ info->skip_vt_switch = 1;
ret = fb_alloc_cmap(&info->cmap, 256, 0);
if (ret) {
@@ -487,30 +488,17 @@ static const struct drm_fb_helper_funcs
nouveau_fbcon_helper_funcs = {
.fb_probe = nouveau_fbcon_create,
};
-static void
-nouveau_fbcon_set_suspend_work(struct work_struct *work)
-{
- struct nouveau_fbdev *fbcon = container_of(work, typeof(*fbcon), work);
- console_lock();
- nouveau_fbcon_accel_restore(fbcon->dev);
- nouveau_fbcon_zfill(fbcon->dev, fbcon);
- fb_set_suspend(fbcon->helper.fbdev, FBINFO_STATE_RUNNING);
- console_unlock();
-}
-
void
nouveau_fbcon_set_suspend(struct drm_device *dev, int state)
{
struct nouveau_drm *drm = nouveau_drm(dev);
if (drm->fbcon) {
- if (state == FBINFO_STATE_RUNNING) {
- schedule_work(&drm->fbcon->work);
- return;
- }
- flush_work(&drm->fbcon->work);
console_lock();
+ if (state == FBINFO_STATE_RUNNING)
+ nouveau_fbcon_accel_restore(dev);
fb_set_suspend(drm->fbcon->helper.fbdev, state);
- nouveau_fbcon_accel_save_disable(dev);
+ if (state != FBINFO_STATE_RUNNING)
+ nouveau_fbcon_accel_save_disable(dev);
console_unlock();
}
}
@@ -531,7 +519,6 @@ nouveau_fbcon_init(struct drm_device *dev)
if (!fbcon)
return -ENOMEM;
- INIT_WORK(&fbcon->work, nouveau_fbcon_set_suspend_work);
fbcon->dev = dev;
drm->fbcon = fbcon;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.h
b/drivers/gpu/drm/nouveau/nouveau_fbcon.h
index 6208e70e4a1c..1e2e9e27a03b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.h
@@ -36,7 +36,6 @@ struct nouveau_fbdev {
struct nouveau_framebuffer nouveau_fb;
struct list_head fbdev_list;
struct drm_device *dev;
- struct work_struct work;
unsigned int saved_flags;
struct nvif_object surf2d;
struct nvif_object clip;
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index 490b90866baf..47f6d73e584c 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -125,7 +125,6 @@ nv50_pioc_create(struct nvif_object *disp, const u32
*oclass, u8 head,
struct
[PATCH v2] drm/radeon: Fix kernel panic with HDMI w/o SAD
On Sat, Jan 3, 2015 at 5:09 AM, Takashi Iwai wrote:
> A BUG_ON() call in dce3_2_afmt_write_sad_regs() is triggered when a
> HDMI monitor without audio is plugged:
I have a slightly different fix already queued up:
http://lists.freedesktop.org/archives/dri-devel/2014-December/073672.html
Alex
>
> kernel BUG at ../drivers/gpu/drm/radeon/dce3_1_afmt.c:110!
> invalid opcode: [#1] PREEMPT SMP
> CPU: 2 PID: 967 Comm: Xorg Tainted: PO 3.16.7-7-desktop #1
> Hardware name: System manufacturer System Product Name/M4A77T, BIOS 2401
> 05/18/2011
> task: 8800cea86350 ti: 8800c188 task.ti: 8800c188
> RIP: 0010:[] dce3_1_hdmi_setmode+0x570/0x5a0 [radeon]
> Call Trace:
> [] drm_crtc_helper_set_mode+0x346/0x520 [drm_kms_helper]
> [] drm_crtc_helper_set_config+0x8a8/0xad0 [drm_kms_helper]
> [] radeon_crtc_set_config+0x3f/0x110 [radeon]
> [] drm_mode_set_config_internal+0x61/0xe0 [drm]
> [] restore_fbdev_mode+0xab/0xd0 [drm_kms_helper]
> [] drm_fb_helper_restore_fbdev_mode_unlocked+0x1e/0x30
> [drm_kms_helper]
> [] drm_fb_helper_set_par+0x22/0x60 [drm_kms_helper]
> [] drm_fb_helper_hotplug_event+0x8b/0xe0 [drm_kms_helper]
> [] drm_fb_helper_set_par+0x3a/0x60 [drm_kms_helper]
> [] fb_set_var+0x15e/0x3b0
> [] fbcon_blank+0x1cb/0x2b0
> [] do_unblank_screen+0xa1/0x1b0
> [] complete_change_console+0x53/0xe0
> [] vt_ioctl+0xf49/0x10d0
> [] tty_ioctl+0x26c/0xb70
> [] do_vfs_ioctl+0x2e7/0x4c0
> [] SyS_ioctl+0x81/0xa0
> [] system_call_fastpath+0x1a/0x1f
> [<7f2fae8c6397>] 0x7f2fae8c6396
>
> Actually the BUG_ON() check is wrong, since sads may be NULL when
> sad_count is zero. This patch removes the BUG_ON() and adds the
> proper NULL initialization of sads.
>
> Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=911356
> Cc:
> Signed-off-by: Takashi Iwai
> ---
> drivers/gpu/drm/radeon/dce3_1_afmt.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c
> b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> index 2fe8cfc966d9..7ca23f45829e 100644
> --- a/drivers/gpu/drm/radeon/dce3_1_afmt.c
> +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> @@ -72,7 +72,7 @@ static void dce3_2_afmt_write_sad_regs(struct drm_encoder
> *encoder)
> struct radeon_device *rdev = encoder->dev->dev_private;
> struct drm_connector *connector;
> struct radeon_connector *radeon_connector = NULL;
> - struct cea_sad *sads;
> + struct cea_sad *sads = NULL;
> int i, sad_count;
>
> static const u16 eld_reg_to_type[][2] = {
> @@ -107,7 +107,6 @@ static void dce3_2_afmt_write_sad_regs(struct drm_encoder
> *encoder)
> DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> return;
> }
> - BUG_ON(!sads);
>
> for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> u32 value = 0;
> --
> 2.2.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch] drm/radeon: integer underflow in radeon_cp_dispatch_texture()
On Tue, Dec 23, 2014 at 4:56 AM, Dan Carpenter
wrote:
> The test:
>
> if (size > RADEON_MAX_TEXTURE_SIZE) {
>
> "size" is an integer and it's controled by the user so it can be
> negative and the test can underflow. Later we use "size" in:
>
> dwords = size / 4;
> ...
> RADEON_COPY_MT(buffer, data, (int)(dwords * sizeof(u32)));
>
> It causes memory corruption to copy a negative size buffer.
>
> Signed-off-by: Dan Carpenter
Applied to my fixes tree. thanks!
Alex
> ---
> Static checkers complain about the integer overflows here, and there are
> many real overflows but they appear harmless.
>
> diff --git a/drivers/gpu/drm/radeon/radeon_state.c
> b/drivers/gpu/drm/radeon/radeon_state.c
> index 535403e..15aee72 100644
> --- a/drivers/gpu/drm/radeon/radeon_state.c
> +++ b/drivers/gpu/drm/radeon/radeon_state.c
> @@ -1703,7 +1703,7 @@ static int radeon_cp_dispatch_texture(struct drm_device
> * dev,
> u32 format;
> u32 *buffer;
> const u8 __user *data;
> - int size, dwords, tex_width, blit_width, spitch;
> + unsigned int size, dwords, tex_width, blit_width, spitch;
> u32 height;
> int i;
> u32 texpitch, microtile;
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/radeon: Fix kernel panic with HDMI w/o SAD
At Mon, 5 Jan 2015 12:07:52 -0500,
Alex Deucher wrote:
>
> On Sat, Jan 3, 2015 at 5:09 AM, Takashi Iwai wrote:
> > A BUG_ON() call in dce3_2_afmt_write_sad_regs() is triggered when a
> > HDMI monitor without audio is plugged:
>
> I have a slightly different fix already queued up:
> http://lists.freedesktop.org/archives/dri-devel/2014-December/073672.html
Oh, that's identical with my v1 patch :) But, with that fix, an error
message will be shown at each time you plug such a monitor, right?
This doesn't look right, so I revised the patch.
Also, can we skip the register write completely? I thought of a case
like we replug a monitor from the one with audio to another without
audio...
thanks,
Takashi
>
> Alex
>
> >
> > kernel BUG at ../drivers/gpu/drm/radeon/dce3_1_afmt.c:110!
> > invalid opcode: [#1] PREEMPT SMP
> > CPU: 2 PID: 967 Comm: Xorg Tainted: PO 3.16.7-7-desktop #1
> > Hardware name: System manufacturer System Product Name/M4A77T, BIOS 2401
> > 05/18/2011
> > task: 8800cea86350 ti: 8800c188 task.ti: 8800c188
> > RIP: 0010:[] dce3_1_hdmi_setmode+0x570/0x5a0 [radeon]
> > Call Trace:
> > [] drm_crtc_helper_set_mode+0x346/0x520 [drm_kms_helper]
> > [] drm_crtc_helper_set_config+0x8a8/0xad0
> > [drm_kms_helper]
> > [] radeon_crtc_set_config+0x3f/0x110 [radeon]
> > [] drm_mode_set_config_internal+0x61/0xe0 [drm]
> > [] restore_fbdev_mode+0xab/0xd0 [drm_kms_helper]
> > [] drm_fb_helper_restore_fbdev_mode_unlocked+0x1e/0x30
> > [drm_kms_helper]
> > [] drm_fb_helper_set_par+0x22/0x60 [drm_kms_helper]
> > [] drm_fb_helper_hotplug_event+0x8b/0xe0
> > [drm_kms_helper]
> > [] drm_fb_helper_set_par+0x3a/0x60 [drm_kms_helper]
> > [] fb_set_var+0x15e/0x3b0
> > [] fbcon_blank+0x1cb/0x2b0
> > [] do_unblank_screen+0xa1/0x1b0
> > [] complete_change_console+0x53/0xe0
> > [] vt_ioctl+0xf49/0x10d0
> > [] tty_ioctl+0x26c/0xb70
> > [] do_vfs_ioctl+0x2e7/0x4c0
> > [] SyS_ioctl+0x81/0xa0
> > [] system_call_fastpath+0x1a/0x1f
> > [<7f2fae8c6397>] 0x7f2fae8c6396
> >
> > Actually the BUG_ON() check is wrong, since sads may be NULL when
> > sad_count is zero. This patch removes the BUG_ON() and adds the
> > proper NULL initialization of sads.
> >
> > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=911356
> > Cc:
> > Signed-off-by: Takashi Iwai
> > ---
> > drivers/gpu/drm/radeon/dce3_1_afmt.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c
> > b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> > index 2fe8cfc966d9..7ca23f45829e 100644
> > --- a/drivers/gpu/drm/radeon/dce3_1_afmt.c
> > +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> > @@ -72,7 +72,7 @@ static void dce3_2_afmt_write_sad_regs(struct drm_encoder
> > *encoder)
> > struct radeon_device *rdev = encoder->dev->dev_private;
> > struct drm_connector *connector;
> > struct radeon_connector *radeon_connector = NULL;
> > - struct cea_sad *sads;
> > + struct cea_sad *sads = NULL;
> > int i, sad_count;
> >
> > static const u16 eld_reg_to_type[][2] = {
> > @@ -107,7 +107,6 @@ static void dce3_2_afmt_write_sad_regs(struct
> > drm_encoder *encoder)
> > DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> > return;
> > }
> > - BUG_ON(!sads);
> >
> > for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> > u32 value = 0;
> > --
> > 2.2.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[Bug 87682] Horizontal lines in radeon driver on kernel 3.15 and upwards
https://bugs.freedesktop.org/show_bug.cgi?id=87682 Alex Deucher changed: What|Removed |Added Component|Drivers/Gallium/r600|DRM/Radeon Version|git |unspecified Product|Mesa|DRI -- 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/20150105/12569990/attachment.html>
[Bug 87682] Horizontal lines in radeon driver on kernel 3.15 and upwards
https://bugs.freedesktop.org/show_bug.cgi?id=87682 --- Comment #4 from Alex Deucher --- Possibly related to https://bugzilla.kernel.org/show_bug.cgi?id=83461 -- 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/20150105/ccf59d1d/attachment.html>
[PATCH] drm/amd: Fixing typos in kfd<->kgd interface
On Thu, Jan 1, 2015 at 9:52 AM, Oded Gabbay wrote:
> From: Ben Goz
>
> Signed-off-by: Ben Goz
> Reviewed-by: Oded Gabbay
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c| 2 +-
> drivers/gpu/drm/amd/include/kgd_kfd_interface.h | 2 +-
> drivers/gpu/drm/radeon/radeon_kfd.c | 6 +++---
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
> index adc3147..4c3828c 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
> @@ -184,7 +184,7 @@ static bool is_occupied(struct mqd_manager *mm, void *mqd,
> uint32_t queue_id)
> {
>
> - return kfd2kgd->hqd_is_occupies(mm->dev->kgd, queue_address,
> + return kfd2kgd->hqd_is_occupied(mm->dev->kgd, queue_address,
> pipe_id, queue_id);
>
> }
> diff --git a/drivers/gpu/drm/amd/include/kgd_kfd_interface.h
> b/drivers/gpu/drm/amd/include/kgd_kfd_interface.h
> index 47b5519..96a5122 100644
> --- a/drivers/gpu/drm/amd/include/kgd_kfd_interface.h
> +++ b/drivers/gpu/drm/amd/include/kgd_kfd_interface.h
> @@ -183,7 +183,7 @@ struct kfd2kgd_calls {
> int (*hqd_load)(struct kgd_dev *kgd, void *mqd, uint32_t pipe_id,
> uint32_t queue_id, uint32_t __user *wptr);
>
> - bool (*hqd_is_occupies)(struct kgd_dev *kgd, uint64_t queue_address,
> + bool (*hqd_is_occupied)(struct kgd_dev *kgd, uint64_t queue_address,
> uint32_t pipe_id, uint32_t queue_id);
>
> int (*hqd_destroy)(struct kgd_dev *kgd, uint32_t reset_type,
> diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c
> b/drivers/gpu/drm/radeon/radeon_kfd.c
> index d3e78b4..12c43df 100644
> --- a/drivers/gpu/drm/radeon/radeon_kfd.c
> +++ b/drivers/gpu/drm/radeon/radeon_kfd.c
> @@ -72,7 +72,7 @@ static int kgd_init_pipeline(struct kgd_dev *kgd, uint32_t
> pipe_id,
> static int kgd_hqd_load(struct kgd_dev *kgd, void *mqd, uint32_t pipe_id,
> uint32_t queue_id, uint32_t __user *wptr);
>
> -static bool kgd_hqd_is_occupies(struct kgd_dev *kgd, uint64_t queue_address,
> +static bool kgd_hqd_is_occupied(struct kgd_dev *kgd, uint64_t queue_address,
> uint32_t pipe_id, uint32_t queue_id);
>
> static int kgd_hqd_destroy(struct kgd_dev *kgd, uint32_t reset_type,
> @@ -92,7 +92,7 @@ static const struct kfd2kgd_calls kfd2kgd = {
> .init_memory = kgd_init_memory,
> .init_pipeline = kgd_init_pipeline,
> .hqd_load = kgd_hqd_load,
> - .hqd_is_occupies = kgd_hqd_is_occupies,
> + .hqd_is_occupied = kgd_hqd_is_occupied,
> .hqd_destroy = kgd_hqd_destroy,
> .get_fw_version = get_fw_version
> };
> @@ -529,7 +529,7 @@ static int kgd_hqd_load(struct kgd_dev *kgd, void *mqd,
> uint32_t pipe_id,
> return 0;
> }
>
> -static bool kgd_hqd_is_occupies(struct kgd_dev *kgd, uint64_t queue_address,
> +static bool kgd_hqd_is_occupied(struct kgd_dev *kgd, uint64_t queue_address,
> uint32_t pipe_id, uint32_t queue_id)
> {
> uint32_t act;
> --
> 1.9.1
>
[PATCH v2] drm/radeon: Fix kernel panic with HDMI w/o SAD
On Mon, Jan 5, 2015 at 12:23 PM, Takashi Iwai wrote:
> At Mon, 5 Jan 2015 12:07:52 -0500,
> Alex Deucher wrote:
>>
>> On Sat, Jan 3, 2015 at 5:09 AM, Takashi Iwai wrote:
>> > A BUG_ON() call in dce3_2_afmt_write_sad_regs() is triggered when a
>> > HDMI monitor without audio is plugged:
>>
>> I have a slightly different fix already queued up:
>> http://lists.freedesktop.org/archives/dri-devel/2014-December/073672.html
>
> Oh, that's identical with my v1 patch :) But, with that fix, an error
> message will be shown at each time you plug such a monitor, right?
> This doesn't look right, so I revised the patch.
Yes, but if the monitor claims to support audio, it should supply
SADs. If it doesn't, the driver has no way of knowing what type of
audio the monitor supports. I'm fine with removing the error message
or making it debug only however.
>
> Also, can we skip the register write completely? I thought of a case
> like we replug a monitor from the one with audio to another without
> audio...
Changing the monitor will generally trigger a full probe and modeset
again anyway. The register writes are just there to pass the audio
information supported by the monitor along to the audio driver.
Alex
>
>
> thanks,
>
> Takashi
>
>>
>> Alex
>>
>> >
>> > kernel BUG at ../drivers/gpu/drm/radeon/dce3_1_afmt.c:110!
>> > invalid opcode: [#1] PREEMPT SMP
>> > CPU: 2 PID: 967 Comm: Xorg Tainted: PO 3.16.7-7-desktop #1
>> > Hardware name: System manufacturer System Product Name/M4A77T, BIOS 2401
>> > 05/18/2011
>> > task: 8800cea86350 ti: 8800c188 task.ti: 8800c188
>> > RIP: 0010:[] dce3_1_hdmi_setmode+0x570/0x5a0 [radeon]
>> > Call Trace:
>> > [] drm_crtc_helper_set_mode+0x346/0x520
>> > [drm_kms_helper]
>> > [] drm_crtc_helper_set_config+0x8a8/0xad0
>> > [drm_kms_helper]
>> > [] radeon_crtc_set_config+0x3f/0x110 [radeon]
>> > [] drm_mode_set_config_internal+0x61/0xe0 [drm]
>> > [] restore_fbdev_mode+0xab/0xd0 [drm_kms_helper]
>> > [] drm_fb_helper_restore_fbdev_mode_unlocked+0x1e/0x30
>> > [drm_kms_helper]
>> > [] drm_fb_helper_set_par+0x22/0x60 [drm_kms_helper]
>> > [] drm_fb_helper_hotplug_event+0x8b/0xe0
>> > [drm_kms_helper]
>> > [] drm_fb_helper_set_par+0x3a/0x60 [drm_kms_helper]
>> > [] fb_set_var+0x15e/0x3b0
>> > [] fbcon_blank+0x1cb/0x2b0
>> > [] do_unblank_screen+0xa1/0x1b0
>> > [] complete_change_console+0x53/0xe0
>> > [] vt_ioctl+0xf49/0x10d0
>> > [] tty_ioctl+0x26c/0xb70
>> > [] do_vfs_ioctl+0x2e7/0x4c0
>> > [] SyS_ioctl+0x81/0xa0
>> > [] system_call_fastpath+0x1a/0x1f
>> > [<7f2fae8c6397>] 0x7f2fae8c6396
>> >
>> > Actually the BUG_ON() check is wrong, since sads may be NULL when
>> > sad_count is zero. This patch removes the BUG_ON() and adds the
>> > proper NULL initialization of sads.
>> >
>> > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=911356
>> > Cc:
>> > Signed-off-by: Takashi Iwai
>> > ---
>> > drivers/gpu/drm/radeon/dce3_1_afmt.c | 3 +--
>> > 1 file changed, 1 insertion(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c
>> > b/drivers/gpu/drm/radeon/dce3_1_afmt.c
>> > index 2fe8cfc966d9..7ca23f45829e 100644
>> > --- a/drivers/gpu/drm/radeon/dce3_1_afmt.c
>> > +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
>> > @@ -72,7 +72,7 @@ static void dce3_2_afmt_write_sad_regs(struct
>> > drm_encoder *encoder)
>> > struct radeon_device *rdev = encoder->dev->dev_private;
>> > struct drm_connector *connector;
>> > struct radeon_connector *radeon_connector = NULL;
>> > - struct cea_sad *sads;
>> > + struct cea_sad *sads = NULL;
>> > int i, sad_count;
>> >
>> > static const u16 eld_reg_to_type[][2] = {
>> > @@ -107,7 +107,6 @@ static void dce3_2_afmt_write_sad_regs(struct
>> > drm_encoder *encoder)
>> > DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
>> > return;
>> > }
>> > - BUG_ON(!sads);
>> >
>> > for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
>> > u32 value = 0;
>> > --
>> > 2.2.0
>> >
>> > ___
>> > dri-devel mailing list
>> > dri-devel at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
[PATCH v2] drm/radeon: Fix kernel panic with HDMI w/o SAD
At Mon, 5 Jan 2015 12:48:05 -0500,
Alex Deucher wrote:
>
> On Mon, Jan 5, 2015 at 12:23 PM, Takashi Iwai wrote:
> > At Mon, 5 Jan 2015 12:07:52 -0500,
> > Alex Deucher wrote:
> >>
> >> On Sat, Jan 3, 2015 at 5:09 AM, Takashi Iwai wrote:
> >> > A BUG_ON() call in dce3_2_afmt_write_sad_regs() is triggered when a
> >> > HDMI monitor without audio is plugged:
> >>
> >> I have a slightly different fix already queued up:
> >> http://lists.freedesktop.org/archives/dri-devel/2014-December/073672.html
> >
> > Oh, that's identical with my v1 patch :) But, with that fix, an error
> > message will be shown at each time you plug such a monitor, right?
> > This doesn't look right, so I revised the patch.
>
> Yes, but if the monitor claims to support audio, it should supply
> SADs. If it doesn't, the driver has no way of knowing what type of
> audio the monitor supports.
IMO, we may assume that the monitor has no audio at all if sad_count =
0. Or are there any monitors that do support audio even without
SAD...?
> I'm fine with removing the error message
> or making it debug only however.
If sad_count = 0 is an invalid state that shouldn't happen, then
printing an error is correct behavior. So, the question comes to the
point whether sad_count = 0 is a sane value or not.
> > Also, can we skip the register write completely? I thought of a case
> > like we replug a monitor from the one with audio to another without
> > audio...
>
> Changing the monitor will generally trigger a full probe and modeset
> again anyway. The register writes are just there to pass the audio
> information supported by the monitor along to the audio driver.
OK, thanks for clarification.
In anyway, I still think we should kill BUG_ON() there. But this can
be a separate patch, of course.
Takashi
>
> Alex
>
> >
> >
> > thanks,
> >
> > Takashi
> >
> >>
> >> Alex
> >>
> >> >
> >> > kernel BUG at ../drivers/gpu/drm/radeon/dce3_1_afmt.c:110!
> >> > invalid opcode: [#1] PREEMPT SMP
> >> > CPU: 2 PID: 967 Comm: Xorg Tainted: PO 3.16.7-7-desktop #1
> >> > Hardware name: System manufacturer System Product Name/M4A77T, BIOS
> >> > 240105/18/2011
> >> > task: 8800cea86350 ti: 8800c188 task.ti: 8800c188
> >> > RIP: 0010:[] dce3_1_hdmi_setmode+0x570/0x5a0 [radeon]
> >> > Call Trace:
> >> > [] drm_crtc_helper_set_mode+0x346/0x520
> >> > [drm_kms_helper]
> >> > [] drm_crtc_helper_set_config+0x8a8/0xad0
> >> > [drm_kms_helper]
> >> > [] radeon_crtc_set_config+0x3f/0x110 [radeon]
> >> > [] drm_mode_set_config_internal+0x61/0xe0 [drm]
> >> > [] restore_fbdev_mode+0xab/0xd0 [drm_kms_helper]
> >> > []
> >> > drm_fb_helper_restore_fbdev_mode_unlocked+0x1e/0x30 [drm_kms_helper]
> >> > [] drm_fb_helper_set_par+0x22/0x60 [drm_kms_helper]
> >> > [] drm_fb_helper_hotplug_event+0x8b/0xe0
> >> > [drm_kms_helper]
> >> > [] drm_fb_helper_set_par+0x3a/0x60 [drm_kms_helper]
> >> > [] fb_set_var+0x15e/0x3b0
> >> > [] fbcon_blank+0x1cb/0x2b0
> >> > [] do_unblank_screen+0xa1/0x1b0
> >> > [] complete_change_console+0x53/0xe0
> >> > [] vt_ioctl+0xf49/0x10d0
> >> > [] tty_ioctl+0x26c/0xb70
> >> > [] do_vfs_ioctl+0x2e7/0x4c0
> >> > [] SyS_ioctl+0x81/0xa0
> >> > [] system_call_fastpath+0x1a/0x1f
> >> > [<7f2fae8c6397>] 0x7f2fae8c6396
> >> >
> >> > Actually the BUG_ON() check is wrong, since sads may be NULL when
> >> > sad_count is zero. This patch removes the BUG_ON() and adds the
> >> > proper NULL initialization of sads.
> >> >
> >> > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=911356
> >> > Cc:
> >> > Signed-off-by: Takashi Iwai
> >> > ---
> >> > drivers/gpu/drm/radeon/dce3_1_afmt.c | 3 +--
> >> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c
> >> > b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> >> > index 2fe8cfc966d9..7ca23f45829e 100644
> >> > --- a/drivers/gpu/drm/radeon/dce3_1_afmt.c
> >> > +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c
> >> > @@ -72,7 +72,7 @@ static void dce3_2_afmt_write_sad_regs(struct
> >> > drm_encoder *encoder)
> >> > struct radeon_device *rdev = encoder->dev->dev_private;
> >> > struct drm_connector *connector;
> >> > struct radeon_connector *radeon_connector = NULL;
> >> > - struct cea_sad *sads;
> >> > + struct cea_sad *sads = NULL;
> >> > int i, sad_count;
> >> >
> >> > static const u16 eld_reg_to_type[][2] = {
> >> > @@ -107,7 +107,6 @@ static void dce3_2_afmt_write_sad_regs(struct
> >> > drm_encoder *encoder)
> >> > DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> >> > return;
> >> > }
> >> > - BUG_ON(!sads);
> >> >
> >> > for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> >> > u32 value = 0;
> >> > --
> >> > 2.2.0
> >> >
> >> > ___
> >> > dri-devel mailing list
> >> > dri-devel at lists.freedesktop.org
[PATCH v2] drm/radeon: Fix kernel panic with HDMI w/o SAD
On Mon, Jan 5, 2015 at 1:16 PM, Takashi Iwai wrote: > At Mon, 5 Jan 2015 12:48:05 -0500, > Alex Deucher wrote: >> >> On Mon, Jan 5, 2015 at 12:23 PM, Takashi Iwai wrote: >> > At Mon, 5 Jan 2015 12:07:52 -0500, >> > Alex Deucher wrote: >> >> >> >> On Sat, Jan 3, 2015 at 5:09 AM, Takashi Iwai wrote: >> >> > A BUG_ON() call in dce3_2_afmt_write_sad_regs() is triggered when a >> >> > HDMI monitor without audio is plugged: >> >> >> >> I have a slightly different fix already queued up: >> >> http://lists.freedesktop.org/archives/dri-devel/2014-December/073672.html >> > >> > Oh, that's identical with my v1 patch :) But, with that fix, an error >> > message will be shown at each time you plug such a monitor, right? >> > This doesn't look right, so I revised the patch. >> >> Yes, but if the monitor claims to support audio, it should supply >> SADs. If it doesn't, the driver has no way of knowing what type of >> audio the monitor supports. > > IMO, we may assume that the monitor has no audio at all if sad_count = > 0. Or are there any monitors that do support audio even without > SAD...? I don't remember off hand. We'd need to check the CEA edid extension spec. The radeon hdmi code should be restructured a bit to enable hdmi features in a more fine grained way. If the monitor supports hdmi, we try and enable audio in addition to the other hdmi packets. We should be using drm_detect_monitor_audio() to decide whether to enable audio features. We have some patches internally which cleans a lot of this up that should be available soon. > >> I'm fine with removing the error message >> or making it debug only however. > > If sad_count = 0 is an invalid state that shouldn't happen, then > printing an error is correct behavior. So, the question comes to the > point whether sad_count = 0 is a sane value or not. > >> > Also, can we skip the register write completely? I thought of a case >> > like we replug a monitor from the one with audio to another without >> > audio... >> >> Changing the monitor will generally trigger a full probe and modeset >> again anyway. The register writes are just there to pass the audio >> information supported by the monitor along to the audio driver. > > OK, thanks for clarification. > > > In anyway, I still think we should kill BUG_ON() there. But this can > be a separate patch, of course. Yeah, agreed. Alex > > > Takashi > >> >> Alex >> >> > >> > >> > thanks, >> > >> > Takashi >> > >> >> >> >> Alex >> >> >> >> > >> >> > kernel BUG at ../drivers/gpu/drm/radeon/dce3_1_afmt.c:110! >> >> > invalid opcode: [#1] PREEMPT SMP >> >> > CPU: 2 PID: 967 Comm: Xorg Tainted: PO 3.16.7-7-desktop #1 >> >> > Hardware name: System manufacturer System Product Name/M4A77T, BIOS >> >> > 240105/18/2011 >> >> > task: 8800cea86350 ti: 8800c188 task.ti: 8800c188 >> >> > RIP: 0010:[] dce3_1_hdmi_setmode+0x570/0x5a0 [radeon] >> >> > Call Trace: >> >> > [] drm_crtc_helper_set_mode+0x346/0x520 >> >> > [drm_kms_helper] >> >> > [] drm_crtc_helper_set_config+0x8a8/0xad0 >> >> > [drm_kms_helper] >> >> > [] radeon_crtc_set_config+0x3f/0x110 [radeon] >> >> > [] drm_mode_set_config_internal+0x61/0xe0 [drm] >> >> > [] restore_fbdev_mode+0xab/0xd0 [drm_kms_helper] >> >> > [] >> >> > drm_fb_helper_restore_fbdev_mode_unlocked+0x1e/0x30 [drm_kms_helper] >> >> > [] drm_fb_helper_set_par+0x22/0x60 [drm_kms_helper] >> >> > [] drm_fb_helper_hotplug_event+0x8b/0xe0 >> >> > [drm_kms_helper] >> >> > [] drm_fb_helper_set_par+0x3a/0x60 [drm_kms_helper] >> >> > [] fb_set_var+0x15e/0x3b0 >> >> > [] fbcon_blank+0x1cb/0x2b0 >> >> > [] do_unblank_screen+0xa1/0x1b0 >> >> > [] complete_change_console+0x53/0xe0 >> >> > [] vt_ioctl+0xf49/0x10d0 >> >> > [] tty_ioctl+0x26c/0xb70 >> >> > [] do_vfs_ioctl+0x2e7/0x4c0 >> >> > [] SyS_ioctl+0x81/0xa0 >> >> > [] system_call_fastpath+0x1a/0x1f >> >> > [<7f2fae8c6397>] 0x7f2fae8c6396 >> >> > >> >> > Actually the BUG_ON() check is wrong, since sads may be NULL when >> >> > sad_count is zero. This patch removes the BUG_ON() and adds the >> >> > proper NULL initialization of sads. >> >> > >> >> > Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=911356 >> >> > Cc: >> >> > Signed-off-by: Takashi Iwai >> >> > --- >> >> > drivers/gpu/drm/radeon/dce3_1_afmt.c | 3 +-- >> >> > 1 file changed, 1 insertion(+), 2 deletions(-) >> >> > >> >> > diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c >> >> > b/drivers/gpu/drm/radeon/dce3_1_afmt.c >> >> > index 2fe8cfc966d9..7ca23f45829e 100644 >> >> > --- a/drivers/gpu/drm/radeon/dce3_1_afmt.c >> >> > +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c >> >> > @@ -72,7 +72,7 @@ static void dce3_2_afmt_write_sad_regs(struct >> >> > drm_encoder *encoder) >> >> > struct radeon_device *rdev = encoder->dev->dev_private; >> >> > struct drm_connector *connector; >> >> > struct radeon_connector *radeon_connector = NULL; >> >> > - struct cea_sad *sads; >> >>
[Bug 85204] [Radeon HD 5650] return from sleep state failed
8:16:26 acer kernel: [drm] UVD initialized successfully. Jan 5 18:53:07 acer kernel: [drm] ring test on 5 succeeded in 1 usecs Jan 5 18:53:07 acer kernel: [drm] UVD initialized successfully. Jan 5 18:53:08 acer kernel: [drm] ib test on ring 0 succeeded in 0 usecs Jan 5 18:53:08 acer kernel: [drm] ib test on ring 3 succeeded in 0 usecs Jan 5 18:16:27 acer kernel: [drm] ib test on ring 0 succeeded in 0 usecs Jan 5 18:16:27 acer kernel: [drm] ib test on ring 3 succeeded in 0 usecs -- 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/20150105/2aa107a9/attachment-0001.html>
[PATCH 1/2] drm/radeon: Assign VMID to PASID for IH in non-HWS mode
On Mon, Jan 5, 2015 at 8:52 AM, Oded Gabbay wrote: > From: Ben Goz > > This patch fixes a bug in kgd_set_pasid_vmid_mapping(), where the function > only updated the ATC registers (IOMMU) with the new VMID <--> PASID mapping, > but didn't update the IH (Interrupt) registers. > > The bug only occurs when using non-HWS mode. In HWS mode, the CP automatically > does the VMID <--> PASID mapping. > > Signed-off-by: Ben Goz > Signed-off-by: Oded Gabbay I'm not too familiar with how these registers work. I'm assuming they are just scratch registers that either the fw or the driver has to update depending on the scheduling model? For the series: Acked-by: Alex Deucher > --- > drivers/gpu/drm/radeon/cikd.h | 2 ++ > drivers/gpu/drm/radeon/radeon_kfd.c | 4 > 2 files changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h > index ba85986..03003f8 100644 > --- a/drivers/gpu/drm/radeon/cikd.h > +++ b/drivers/gpu/drm/radeon/cikd.h > @@ -2156,4 +2156,6 @@ > #define ATC_VM_APERTURE1_HIGH_ADDR 0x330Cu > #define ATC_VM_APERTURE1_LOW_ADDR 0x3304u > > +#define IH_VMID_0_LUT 0x3D40u > + > #endif > diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c > b/drivers/gpu/drm/radeon/radeon_kfd.c > index a55afba..8bf87f1 100644 > --- a/drivers/gpu/drm/radeon/radeon_kfd.c > +++ b/drivers/gpu/drm/radeon/radeon_kfd.c > @@ -390,6 +390,10 @@ static int kgd_set_pasid_vmid_mapping(struct kgd_dev > *kgd, unsigned int pasid, > cpu_relax(); > write_register(kgd, ATC_VMID_PASID_MAPPING_UPDATE_STATUS, 1U << vmid); > > + /* Mapping vmid to pasid also for IH block */ > + write_register(kgd, IH_VMID_0_LUT + vmid * sizeof(uint32_t), > + pasid_mapping); > + > return 0; > } > > -- > 1.9.1 >
[Bug 90741] Radeon: System pauses on TAHITI
https://bugzilla.kernel.org/show_bug.cgi?id=90741 --- Comment #4 from Gustaw Smolarczyk --- There seems to be no substantial difference in 3.19-rc2, 39e7f6f84b3a3aa4520504473f2e2bac1f949ffa or 472db7ab3093bf2a2999f6b5aa64a030466d6f92. The only thing (that may be subjective) is that there seems to be a bit less pauses in final 3.18 and later. (did not bisect that, may be totally subjective) Also of importance can be that I am using 2 GPUs (discrete AMD TAHITI and integrated Intel gen7 (IVB)) in randr 1.4 offloading configuration: xrandr --setprovideroutputsource Intel radeon xrandr --output HDMI2 --mode 1280x1024 --rate 60 --right-of DVI-0 Where: DVI-0 is my main monitor and is connected to TAHITI HDMI2 is my secondary monitor and is connected to IVB The OpenGL window is on the main monitor If that may be the source of these problems, I could disable the second monitor along with the iGPU in order to test that hypothesis. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 85204] [Radeon HD 5650] return from sleep state failed
https://bugs.freedesktop.org/show_bug.cgi?id=85204 --- Comment #15 from Alex Deucher --- Please take the bisect to completion. -- 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/20150105/ce0aee38/attachment.html>
[Bug 85204] [Radeon HD 5650] return from sleep state failed
https://bugs.freedesktop.org/show_bug.cgi?id=85204 --- Comment #16 from Johannes Hirte --- (In reply to Alex Deucher from comment #15) > Please take the bisect to completion. Will do so. This will take some time. From observation it needs more suspend/resume-cycles for every step closer to the bad commit. 3.18 fails in the first place every time, for 3.18.0-rc1-5-g031d705 it took more than 10 trials to trigger the bug. -- 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/20150105/7d57264a/attachment.html>
