[Bug 70654] [DPM] Mobility 4570: power_dpm_force_performance_level is reset to auto when UVD is used
https://bugs.freedesktop.org/show_bug.cgi?id=70654 --- Comment #1 from Mohammad AlSaleh --- To clarify: Using UVD resets the value. It stays reset afterwards. -- 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/20131019/0f19f4f4/attachment.html>
[Bug 70654] New: [DPM] Mobility 4570: power_dpm_force_performance_level is reset to auto when UVD is used
https://bugs.freedesktop.org/show_bug.cgi?id=70654 Priority: medium Bug ID: 70654 Assignee: dri-devel at lists.freedesktop.org Summary: [DPM] Mobility 4570: power_dpm_force_performance_level is reset to auto when UVD is used Severity: normal Classification: Unclassified OS: Linux (All) Reporter: CE.Mohammad.AlSaleh at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI I set power_dpm_force_performance_level to 'high' to avoid occational noise artifacts on my monitor. When UVD/VDPAU is used, the value is reset to 'auto'. -- 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/20131019/ef70d5ec/attachment.html>
How to change radeon power state
On Sat, Oct 19, 2013 at 8:36 PM, Daniel Mota Leite wrote: > Hi > > i've a one ATI/AMD RV630 card with kernel 3.11.5 and dpm enabled. > All works fine, but minor annoying problem. The dpm is choosing a power > state that isn't the best... > > This is my card : > > 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV > 630 XT AGP [Radeon HD 2600 XT AGP] > > Here is the dpm output: > > [ 12.358738] == power state 0 == > [ 12.358796] ui class: none > [ 12.358895] internal class: boot > [ 12.359069] caps: video > [ 12.359209] uvdvclk: 0 dclk: 0 > [ 12.359266] power level 0sclk: 8 mclk: 7 vddc: 1200 > [ 12.359326] power level 1sclk: 8 mclk: 7 vddc: 1200 > [ 12.359386] power level 2sclk: 8 mclk: 7 vddc: 1200 > [ 12.359445] status: c r b > [ 12.359671] == power state 1 == > [ 12.359726] ui class: performance > [ 12.359824] internal class: ovrdrv > [ 12.359965] caps: video > [ 12.360109] uvdvclk: 0 dclk: 0 > [ 12.360166] power level 0sclk: 15000 mclk: 42000 vddc: 1050 > [ 12.360226] power level 1sclk: 2 mclk: 5 vddc: 1080 > [ 12.360285] power level 2sclk: 4 mclk: 7 vddc: 1100 > [ 12.360344] status: > [ 12.360442] == power state 2 == > [ 12.360497] ui class: none > [ 12.360594] internal class: none > [ 12.360734] caps: video > [ 12.360873] uvdvclk: 0 dclk: 0 > [ 12.360930] power level 0sclk: 2 mclk: 5 vddc: 1080 > [ 12.360990] power level 1sclk: 3 mclk: 5 vddc: 1100 > [ 12.361056] power level 2sclk: 8 mclk: 7 vddc: 1200 > [ 12.361115] status: > [ 12.361415] switching from power state: > [ 12.361471] ui class: none > [ 12.361568] internal class: boot > [ 12.361708] caps: video > [ 12.361847] uvdvclk: 0 dclk: 0 > [ 12.361903] power level 0sclk: 8 mclk: 7 vddc: 1200 > [ 12.361963] power level 1sclk: 8 mclk: 7 vddc: 1200 > [ 12.362029] power level 2sclk: 8 mclk: 7 vddc: 1200 > [ 12.362088] status: c b > [ 12.362303] switching to power state: > [ 12.362359] ui class: performance > [ 12.362457] internal class: ovrdrv > [ 12.362596] caps: video > [ 12.362735] uvdvclk: 0 dclk: 0 > [ 12.362792] power level 0sclk: 15000 mclk: 42000 vddc: 1050 > [ 12.362853] power level 1sclk: 2 mclk: 5 vddc: 1080 > [ 12.362913] power level 2sclk: 4 mclk: 7 vddc: 1100 > [ 12.362972] status: r > > > > As you can see, the driver choose the performance profile, but > that one is limited to 400MHz, half of what this card can do. Of course i > want to be able jump the GPU to 800MHz. So is there any easy way > to choose the power state 2 instead of power state 1? > > > Also, when in using tvtime on a second head, the dpm jumps the gpu > clock to the max, yet i would like to use the middle speed. tvtime doesn't > require that much resources (even low can do it!). Yet i found no way to > force the middle power level. i can "echo high" and "echo low" to > power_dpm_force_performance_level but trying "mid", "middle" fail. > Is there any support to use the middle power level? We'll probably need to add a quirk for your card. Can you send me the output of lspci -vnn for the GPU? Alex > > Thanks in advance. > higuita > -- > Naturally the common people don't want war... but after all it is the > leaders of a country who determine the policy, and it is always a > simple matter to drag the people along, whether it is a democracy, or > a fascist dictatorship, or a parliament, or a communist dictatorship. > Voice or no voice, the people can always be brought to the bidding of > the leaders. That is easy. All you have to do is tell them they are > being attacked, and denounce the pacifists for lack of patriotism and > exposing the country to danger. It works the same in every country. >-- Hermann Goering, Nazi and war criminal, 1883-1946 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[Bug 61941] Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1
https://bugzilla.kernel.org/show_bug.cgi?id=61941 --- Comment #6 from Ilya Tumaykin --- Disabling dynamic_pcie_gen2 also doesn't help. Will try mclk_ss next. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 61941] Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1
https://bugzilla.kernel.org/show_bug.cgi?id=61941 --- Comment #5 from Ilya Tumaykin --- Disabling voltage control doesn't help. i.e. I still have this issue after the following change: - pi->voltage_control = - radeon_atom_is_voltage_gpio(rdev, SET_VOLTAGE_TYPE_ASIC_VDDC, 0); + pi->voltage_control = false; +// radeon_atom_is_voltage_gpio(rdev, SET_VOLTAGE_TYPE_ASIC_VDDC, 0); I will try to disable dynamic_pcie_gen2 this time. -- You are receiving this mail because: You are watching the assignee of the bug.
MmioTrace: Using the Instruction Decoder, etc.
Oh, messed up the registers in the example. Should be like this: If some original function of the driver contained, say, mov 0xabcd (%rax), %rsi mov %rdx, 0xbeeffeed (%rsi) that will be transformed to something like lea 0xabcd (%rax), %rbx mov %rbx, mov 0xabcd (%rax), %rsi lea 0xbeeffeed (%rsi), %rbx mov %rbx, mov %rdx, 0xbeeffeed (%rsi) ... Regards, Eugene -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131019/90d24e40/attachment.html>
MmioTrace: Using the Instruction Decoder, etc.
Hi, > Ah, you are not using the ftrace framework nor relayfs? Mmiotrace used to be relayfs at one point and then converted to ftrace. Yes, I considered these when I started working on KernelStrider but finally borrowed ideas from Perf and implemented them. A mmapped ring buffer does its job well and has a higher throughput than Ftrace in my case. > Are you saying that you intercept function calls, and *never* rely > on page faulting? The system intercepts both function calls *and* memory operations made by the driver itself. Yes, it never relies on page faulting. > Does that mean that if a driver does the ugly thing and > dereferences an iomem pointer directly, you won't catch that? It will be caught. What my system actually does is as follows. When the target kernel module has been loaded into memory but before it has begun its initialization, KernelStrider processes it, function after function. It creates an instrumented variant of each function in the module mapping space and places a jump at the beginning of the original function to point to the instrumented one. After instrumentation is done, the target driver may start executing. If some original function of the driver contained, say, mov 0xabcd (%rax), %rsi mov %rbx, 0xbeeffeed (%rsi) that will be transformed to something like lea 0xabcd (%rax), %rbx mov %rbx, mov 0xabcd (%rax), %rsi lea 0xbeeffeed (%rsi), %rbx mov %rbx, mov %rbx, 0xbeeffeed (%rsi) ... That is, the address which is about to be accessed is determined and stored in 'local_storage', a special memory structure. At the end of the block of instructions, the information from the local storage is sent to the output system. So the addresses and sizes of the accessed memory areas as well as the types of the accesses (read/write/update) will be available for reading from the user space. It is actually more complex than that (KernelStrider has to deal with register allocation, relocations and other things) but the principle is as I described. The function calls are processed too so that we can set our own handlers to execute at the beginning of a function and right before its exit. Yes, the functions like read[bwql]() and write[bwlq]() are usually inline but they pose no problem: on x86 they compile to ordinary MOV instructions and the like which are handled as I described above. The instrumented code will access the ioremapped area the same way as the original code would, no need for single-stepping or emulation in this case. What I wrote in my previous letter is that there is a special case when the target driver uses some non-inline function provided by the kernel proper or by another driver and that function accesses the ioremapped memory area of interest. KernelStrider needs to track all such functions in order not to miss some memory accesses to that ioremapped area. Perhaps, that's manageable. There are not too many such functions, aren't they? > I don't really know. I guess everything could be possible in > proprietary drivers, but you can look at the instruction decoding > code in mmiotrace, which digs up the type and size of access and > the value. That has been enough so far. Yes, I will take a closer look on that part of MmioTrace, thanks for the point. Regards, Eugene -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131019/abfc4305/attachment.html>
[Bug 70650] Blackscreen on Unity3D Games
https://bugs.freedesktop.org/show_bug.cgi?id=70650 Laurent carlier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Laurent carlier --- *** This bug has been marked as a duplicate of bug 60929 *** -- 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/20131019/d3332d06/attachment.html>
[Bug 60929] [r600-llvm] mono games with opengl are blocking on start
https://bugs.freedesktop.org/show_bug.cgi?id=60929 Laurent carlier changed: What|Removed |Added CC||openproggerfreak at gmail.com --- Comment #20 from Laurent carlier --- *** Bug 70650 has been marked as a duplicate of this 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/20131019/b3c931be/attachment.html>
[Bug 70542] [r600g] HD5450 + uvd + hdmi flickers
https://bugs.freedesktop.org/show_bug.cgi?id=70542 --- Comment #9 from dagg --- (In reply to comment #8) > (In reply to comment #7) > > not sure if it is relevant but I use a 10 meters cable to connect the tv to > > the computer > > That's a bit much. Could you try with a shorter one to make sure it's not > the cable? nope... tv is too far. anyway, didn't had any issues when I was using the intel gpu. -- 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/20131019/cec57e93/attachment.html>
[Bug 70650] New: Blackscreen on Unity3D Games
https://bugs.freedesktop.org/show_bug.cgi?id=70650 Priority: medium Bug ID: 70650 Assignee: dri-devel at lists.freedesktop.org Summary: Blackscreen on Unity3D Games Severity: normal Classification: Unclassified OS: Linux (All) Reporter: openproggerfreak at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 87855 --> https://bugs.freedesktop.org/attachment.cgi?id=87855=edit RADEON_DUMP_SHADERS(Guns of Icarus) Its not possible to start any Game which is using the Unity3D-Engine (like Guns of Icarus,Splice,Spectraball etc.) When you start the Game a Blackscreen Window appears and nothing more is happening(the Process have no CPU % or changing RAM-Usage). It works with LLVMpipe(LIBGL_ALWAYS_SOFTWARE=1) so its definitly a radeonsi-problem Kernel 3.12rc3 (drm-next git branch) Mesa 10.0.0-devel libdrm git glamor git Xorg 1.14.3 AMD Radeon HD 7970 PS:Sorry for my bad English -.- -- 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/20131019/7b63c84a/attachment.html>
[PATCH 2/2] drm: rename agp_destroy() bus-cb to destroy()
While the only user of agp_destroy() is the PCI-bus for agp-destruction,
this callback is not strictly bound to agp. Rename to destroy() to make
clear that any bus can use it to destroy resources once the device is
removed.
Signed-off-by: David Herrmann
---
Hi
We currently cannot remove the agp_destroy() callback as we have no bus-specific
destroy helpers (compared to bus-specific init helpers). I think we can change
that once we get the revoke/unplug series I'm working on. Until then, we have to
keep the current callbacks.
Feel free to drop it, I just thought the "agp_*" prefix was weird..
Thanks
David
drivers/gpu/drm/drm_pci.c | 2 +-
drivers/gpu/drm/drm_stub.c | 4 ++--
include/drm/drmP.h | 3 +--
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 7d3435c..3e1c3a0 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -299,7 +299,7 @@ static struct drm_bus drm_pci_bus = {
.set_busid = drm_pci_set_busid,
.set_unique = drm_pci_set_unique,
.irq_by_busid = drm_pci_irq_by_busid,
- .agp_destroy = drm_pci_agp_destroy,
+ .destroy = drm_pci_agp_destroy,
};
/**
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index ac211c3..c181b71 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -571,8 +571,8 @@ void drm_dev_unregister(struct drm_device *dev)
if (dev->driver->unload)
dev->driver->unload(dev);
- if (dev->driver->bus->agp_destroy)
- dev->driver->bus->agp_destroy(dev);
+ if (dev->driver->bus->destroy)
+ dev->driver->bus->destroy(dev);
drm_vblank_cleanup(dev);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index dfc44ae..220013d 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -749,8 +749,7 @@ struct drm_bus {
int (*set_unique)(struct drm_device *dev, struct drm_master *master,
struct drm_unique *unique);
int (*irq_by_busid)(struct drm_device *dev, struct drm_irq_busid *p);
- /* hooks that are for PCI */
- void (*agp_destroy)(struct drm_device *dev);
+ void (*destroy)(struct drm_device *dev);
};
--
1.8.4.1
[PATCH 1/2] drm: remove agp_init() bus callback
The PCI bus helper is the only user of it. Call it directly before
device-registration to get rid of the callback.
Note that all drm_agp_*() calls are locked with the drm-global-mutex so we
need to explicitly lock it during initialization. It's not really clear
why it's needed, but lets be safe.
Signed-off-by: David Herrmann
---
Hi
If someone wants to review drm_agpsupport.c and tell me why _all_ calls to
drm_agp_*() functions currently hold the global mutex, I'd be happy to hear it.
Otherwise, I will just not care for that old stuff and keep the semantics with
the kind of ugly locks around drm_pci_agp_*().
Thanks
David
drivers/gpu/drm/drm_pci.c | 13 +++--
drivers/gpu/drm/drm_stub.c | 11 +--
include/drm/drmP.h | 1 -
3 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index f00d7a9..7d3435c 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -299,7 +299,6 @@ static struct drm_bus drm_pci_bus = {
.set_busid = drm_pci_set_busid,
.set_unique = drm_pci_set_unique,
.irq_by_busid = drm_pci_irq_by_busid,
- .agp_init = drm_pci_agp_init,
.agp_destroy = drm_pci_agp_destroy,
};
@@ -338,16 +337,26 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct
pci_device_id *ent,
if (drm_core_check_feature(dev, DRIVER_MODESET))
pci_set_drvdata(pdev, dev);
- ret = drm_dev_register(dev, ent->driver_data);
+ mutex_lock(_global_mutex);
+ ret = drm_pci_agp_init(dev);
+ mutex_unlock(_global_mutex);
if (ret)
goto err_pci;
+ ret = drm_dev_register(dev, ent->driver_data);
+ if (ret)
+ goto err_agp;
+
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
driver->name, driver->major, driver->minor, driver->patchlevel,
driver->date, pci_name(pdev), dev->primary->index);
return 0;
+err_agp:
+ mutex_lock(_global_mutex);
+ drm_pci_agp_destroy(dev);
+ mutex_unlock(_global_mutex);
err_pci:
pci_disable_device(pdev);
err_free:
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 26055ab..ac211c3 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -502,16 +502,10 @@ int drm_dev_register(struct drm_device *dev, unsigned
long flags)
mutex_lock(_global_mutex);
- if (dev->driver->bus->agp_init) {
- ret = dev->driver->bus->agp_init(dev);
- if (ret)
- goto out_unlock;
- }
-
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
ret = drm_get_minor(dev, >control, DRM_MINOR_CONTROL);
if (ret)
- goto err_agp;
+ goto out_unlock;
}
if (drm_core_check_feature(dev, DRIVER_RENDER) && drm_rnodes) {
@@ -554,9 +548,6 @@ err_render_node:
err_control_node:
if (dev->control)
drm_put_minor(>control);
-err_agp:
- if (dev->driver->bus->agp_destroy)
- dev->driver->bus->agp_destroy(dev);
out_unlock:
mutex_unlock(_global_mutex);
return ret;
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2b954ad..dfc44ae 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -750,7 +750,6 @@ struct drm_bus {
struct drm_unique *unique);
int (*irq_by_busid)(struct drm_device *dev, struct drm_irq_busid *p);
/* hooks that are for PCI */
- int (*agp_init)(struct drm_device *dev);
void (*agp_destroy)(struct drm_device *dev);
};
--
1.8.4.1
[Bug 63101] Hard lockup whel launching games like TF2 on kernels 3.11.5 and 3.12 rc4 and above if radeon.dpm=1 is used
https://bugzilla.kernel.org/show_bug.cgi?id=63101 --- Comment #12 from Kertesz Laszlo --- (In reply to Alex Deucher from comment #11) > (In reply to Kertesz Laszlo from comment #10) > > This issue has to do with the radeon driver, because if i dont append > > radeon.dpm=1 to the kernel boot options, TF2 launches even with latest 3.12 > > rc5+ kernel (but it has dismal performance). > > If it was dpm specific you should have mentioned that. Make sure your > kernel has this patch: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/ > ?id=4076a65544e2de310cbf4eaadb13ee15bbfaaf4f Sorry about that. I have the dpm option there since it appeared, i totally forgot about it - now i started the computer in single user mode which doesnt have that option then i proceeded to runlevel 2. This way i saw this. I have that patch, i have the linus kernel cloned from git (now at version v3.12-rc5-123-g04919af). I even re cloned it recently. Also please take a look at bug #62861 - it is related to the dpm code too. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 63101] Hard lockup whel launching games like TF2 on kernels 3.11.5 and 3.12 rc4 and above if radeon.dpm=1 is used
https://bugzilla.kernel.org/show_bug.cgi?id=63101 Kertesz Laszlo changed: What|Removed |Added Summary|Hard lockup whel launching |Hard lockup whel launching |games like TF2 on kernels |games like TF2 on kernels |3.11.5 and 3.12 rc4 and |3.11.5 and 3.12 rc4 and |above |above if radeon.dpm=1 is ||used -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 63101] Hard lockup whel launching games like TF2 on kernels 3.11.5 and 3.12 rc4 and above
https://bugzilla.kernel.org/show_bug.cgi?id=63101 --- Comment #11 from Alex Deucher --- (In reply to Kertesz Laszlo from comment #10) > This issue has to do with the radeon driver, because if i dont append > radeon.dpm=1 to the kernel boot options, TF2 launches even with latest 3.12 > rc5+ kernel (but it has dismal performance). If it was dpm specific you should have mentioned that. Make sure your kernel has this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4076a65544e2de310cbf4eaadb13ee15bbfaaf4f -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 63101] Hard lockup whel launching games like TF2 on kernels 3.11.5 and 3.12 rc4 and above
https://bugzilla.kernel.org/show_bug.cgi?id=63101 --- Comment #10 from Kertesz Laszlo --- This issue has to do with the radeon driver, because if i dont append radeon.dpm=1 to the kernel boot options, TF2 launches even with latest 3.12 rc5+ kernel (but it has dismal performance). Also, the CPU voltage is correct without the dpm option - between 0.9-1.34v, instead of 0.65-1.22 as it is with dpm. -- You are receiving this mail because: You are watching the assignee of the bug.
[Linaro-mm-sig] [PATCH] gpu: drm: Add helpers to allow export gem cma objects
I realize that this patch (done for 3.10) is deprecated because there
is something similar that has been push on 3.12.
Anyway the question about how/where set O_RDWR dma_buf_export is valid.
Your advice are welcome.
Benjamin
2013/10/19 Daniel Vetter :
> On Fri, Oct 18, 2013 at 11:00:57AM +0200, benjamin.gaignard at linaro.org
> wrote:
>> From: Benjamin Gaignard
>>
>> DRM already offer helpers to use CMA for dumb buffers.
>> This patch add helpers to export/import gem_cam objects and allow them to be
>> mmap from userland.
>> The goal is to make working this kind of sequence: create_dumb, get fd from
>> buffer handle and then use fd (maybe in another process which may ignore it
>> is comming from DRM) to mmap the buffer.
>>
>> drm_gem_cma_prime_export() add O_RDWR to flags to be sure that memory
>> could be mmapped later with PROT_WRITE flag.
>>
>> Signed-off-by: Benjamin Gaignard
>
> [snip]
>
>> +struct dma_buf *drm_gem_cma_prime_export(struct drm_device *drm_dev,
>> + struct drm_gem_object *obj, int flags)
>> +{
>> + struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
>> +
>> + flags |= O_RDWR;
>
> This here looks funny ... I think either we need to add more flags to the
> prime dma-buf exporting to also pass this flag through. Or we should just
> generally set this in dma_buf_export. Doing this as an exporter-specific
> hack feels wrong.
> -Daniel
>
>> + return dma_buf_export(cma_obj, _gem_cma_dmabuf_ops,
>> + cma_obj->base.size, flags);
>> +}
>> +EXPORT_SYMBOL_GPL(drm_gem_cma_prime_export);
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Benjamin Gaignard
Graphic Working Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
[Linaro-mm-sig] [PATCH] gpu: drm: Add helpers to allow export gem cma objects
On Fri, Oct 18, 2013 at 11:00:57AM +0200, benjamin.gaignard at linaro.org wrote:
> From: Benjamin Gaignard
>
> DRM already offer helpers to use CMA for dumb buffers.
> This patch add helpers to export/import gem_cam objects and allow them to be
> mmap from userland.
> The goal is to make working this kind of sequence: create_dumb, get fd from
> buffer handle and then use fd (maybe in another process which may ignore it
> is comming from DRM) to mmap the buffer.
>
> drm_gem_cma_prime_export() add O_RDWR to flags to be sure that memory
> could be mmapped later with PROT_WRITE flag.
>
> Signed-off-by: Benjamin Gaignard
[snip]
> +struct dma_buf *drm_gem_cma_prime_export(struct drm_device *drm_dev,
> + struct drm_gem_object *obj, int flags)
> +{
> + struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
> +
> + flags |= O_RDWR;
This here looks funny ... I think either we need to add more flags to the
prime dma-buf exporting to also pass this flag through. Or we should just
generally set this in dma_buf_export. Doing this as an exporter-specific
hack feels wrong.
-Daniel
> + return dma_buf_export(cma_obj, _gem_cma_dmabuf_ops,
> + cma_obj->base.size, flags);
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_cma_prime_export);
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm: allocate crtc mutex separately from crtc
On Thu, Oct 17, 2013 at 09:27:41PM -0400, Ilija Hadzic wrote: > (dropping stable at ... until we get the fix we can agree on) > > While looking through that function (drm_crtc_helper_set_config) to > figure out what we really need to save and restore, I came across a > piece of code that you added in 25f397a4. The 'if (connector->dpms != > DRM_MODE_DPMS_ON)' (line 719 in the version that is on the top of > Dave's drm-next branch), comes right after the unconditional break, is > unreachable code (and removing it produces the same object code). Can > you explain what your intent was here? Also, the comment above the > break that reads "don't break so fail path works correct[sic]" doesn't > make much sense to me either. The idea was to also remove the break there. I just haven't had the time yet to fix this fumble and test it a bit. For the funny commment I think this is just to avoid the code in the outer for loop wrestling with the connector->encoder pointer. Removing the comment and inline the ret = -EINVAL; goto fail; would be clearer code imo. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 70647] New: [radeonsi] Crash unigine-heaven 3.0 with msaa enabled
https://bugs.freedesktop.org/show_bug.cgi?id=70647 Priority: medium Bug ID: 70647 Assignee: dri-devel at lists.freedesktop.org Summary: [radeonsi] Crash unigine-heaven 3.0 with msaa enabled Severity: normal Classification: Unclassified OS: All Reporter: grantipak at gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 87852 --> https://bugs.freedesktop.org/attachment.cgi?id=87852=edit unigine-heaven v3.0 msaa crash log ArchLinux x32; kernel 3.12rc5; llvm - svn; mesa - git; Radeon HD 7950 When i run unigine-heaven 3.0 with msaa enabled(no matter 2x, 4x or 8x) it was crashed with error: Can't run "./heaven_x86 -project Heaven -video_app opengl -data_path ../ -engine_config ../data/heaven_3.0.cfg -system_script demos/heaven/unigine.cpp -sound_app openal -video_multisample 1 -video_fullscreen 0 -video_mode 2 -extern_define "RELEASE" -extern_plugin " " -console_command "d3d11_render_use_tessellation 0 && gl_render_use_arb_tessellation_shader 0 && render_shaders 2 && render_anisotropy 2 && render_restart"" process -- 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/20131019/77d584d6/attachment.html>
[PATCH] drm/radeon/audio: use actual pll clock for setting up dto
Am 19.10.2013 01:30, schrieb Alex Deucher:
> Use the actual pll clock (rather than the mode clock) to set
> up the audio dto. This fixes audio playback speed issues
> when the pll clock does not exactly match the mode clock.
>
> Signed-off-by: Alex Deucher
Damn, had the same idea while sleeping over it. Patch is:
Reviewed-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/atombios_crtc.c | 2 ++
> drivers/gpu/drm/radeon/evergreen_hdmi.c | 9 +
> drivers/gpu/drm/radeon/r600_hdmi.c | 16 +---
> drivers/gpu/drm/radeon/radeon_mode.h| 1 +
> 4 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index bf87f6d..3a6059f 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -1027,6 +1027,8 @@ static void atombios_crtc_set_pll(struct drm_crtc
> *crtc, struct drm_display_mode
> radeon_compute_pll_legacy(pll, radeon_crtc->adjusted_clock,
> _clock,
> _div, _fb_div, _div,
> _div);
>
> + radeon_crtc->pll_clock = pll_clock * 10; /* convert to khz units */
> +
> atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id,
>radeon_crtc->crtc_id, _crtc->ss);
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> index 6787365..0d55870 100644
> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> @@ -225,7 +225,7 @@ static void evergreen_hdmi_update_avi_infoframe(struct
> drm_encoder *encoder,
> frame[0xC] | (frame[0xD] << 8) | (header[1] << 24));
> }
>
> -static void evergreen_audio_set_dto(struct drm_encoder *encoder, u32 clock)
> +static void evergreen_audio_set_dto(struct drm_encoder *encoder)
> {
> struct drm_device *dev = encoder->dev;
> struct radeon_device *rdev = dev->dev_private;
> @@ -233,9 +233,10 @@ static void evergreen_audio_set_dto(struct drm_encoder
> *encoder, u32 clock)
> struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
> struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
> u32 base_rate = 24000;
> - u32 max_ratio = clock / base_rate;
> + u32 max_ratio = radeon_crtc->pll_clock / base_rate;
> u32 dto_phase;
> - u32 dto_modulo = clock;
> + /* need to use the exact pll clock here to keep audio rate correct */
> + u32 dto_modulo = radeon_crtc->pll_clock;
> u32 wallclock_ratio;
> u32 dto_cntl;
>
> @@ -296,7 +297,7 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder,
> struct drm_display_mode
> return;
> offset = dig->afmt->offset;
>
> - evergreen_audio_set_dto(encoder, mode->clock);
> + evergreen_audio_set_dto(encoder);
>
> WREG32(HDMI_VBI_PACKET_CONTROL + offset,
> HDMI_NULL_SEND); /* send null packets when required */
> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
> b/drivers/gpu/drm/radeon/r600_hdmi.c
> index 21f2b74..b8c444e 100644
> --- a/drivers/gpu/drm/radeon/r600_hdmi.c
> +++ b/drivers/gpu/drm/radeon/r600_hdmi.c
> @@ -219,16 +219,18 @@ static void r600_hdmi_audio_workaround(struct
> drm_encoder *encoder)
>value, ~HDMI0_AUDIO_TEST_EN);
> }
>
> -void r600_audio_set_dto(struct drm_encoder *encoder, u32 clock)
> +static void r600_audio_set_dto(struct drm_encoder *encoder)
> {
> struct drm_device *dev = encoder->dev;
> struct radeon_device *rdev = dev->dev_private;
> struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
> + struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
> u32 base_rate = 24000;
> - u32 max_ratio = clock / base_rate;
> + u32 max_ratio = radeon_crtc->pll_clock / base_rate;
> u32 dto_phase;
> - u32 dto_modulo = clock;
> + /* need to use the exact pll clock here to keep audio rate correct */
> + u32 dto_modulo = radeon_crtc->pll_clock;
> u32 wallclock_ratio;
> u32 dto_cntl;
>
> @@ -279,17 +281,17 @@ void r600_audio_set_dto(struct drm_encoder *encoder,
> u32 clock)
>*/
> if (dig->dig_encoder == 0) {
> WREG32(DCCG_AUDIO_DTO0_PHASE, base_rate * 100);
> - WREG32(DCCG_AUDIO_DTO0_MODULE, clock * 100);
> + WREG32(DCCG_AUDIO_DTO0_MODULE, dto_modulo * 100);
> WREG32(DCCG_AUDIO_DTO_SELECT, 0); /* select DTO0 */
> } else {
> WREG32(DCCG_AUDIO_DTO1_PHASE, base_rate * 100);
> - WREG32(DCCG_AUDIO_DTO1_MODULE, clock * 100);
> + WREG32(DCCG_AUDIO_DTO1_MODULE, dto_modulo * 100);
> WREG32(DCCG_AUDIO_DTO_SELECT, 1); /* select DTO1 */
>
[PATCH 1/2] drm/radeon/audio: write audio/video latency info for DCE4/5
Am 18.10.2013 22:41, schrieb Alex Deucher:
> Needed by the hda driver to properly set up synchronization
> on the audio side.
>
> Signed-off-by: Alex Deucher
For both: Reviewed-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/evergreen_hdmi.c | 37
>
> drivers/gpu/drm/radeon/evergreend.h | 38
> +
> 2 files changed, 75 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> index 5fbe486..abdc893 100644
> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> @@ -58,6 +58,42 @@ static void evergreen_hdmi_update_ACR(struct drm_encoder
> *encoder, uint32_t cloc
> WREG32(HDMI_ACR_48_1 + offset, acr.n_48khz);
> }
>
> +static void dce4_afmt_write_latency_fields(struct drm_encoder *encoder,
> +struct drm_display_mode *mode)
> +{
> + struct radeon_device *rdev = encoder->dev->dev_private;
> + struct drm_connector *connector;
> + struct radeon_connector *radeon_connector = NULL;
> + u32 tmp = 0;
> +
> + list_for_each_entry(connector,
> >dev->mode_config.connector_list, head) {
> + if (connector->encoder == encoder) {
> + radeon_connector = to_radeon_connector(connector);
> + break;
> + }
> + }
> +
> + if (!radeon_connector) {
> + DRM_ERROR("Couldn't find encoder's connector\n");
> + return;
> + }
> +
> + if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
> + if (connector->latency_present[1])
> + tmp = VIDEO_LIPSYNC(connector->video_latency[1]) |
> + AUDIO_LIPSYNC(connector->audio_latency[1]);
> + else
> + tmp = VIDEO_LIPSYNC(255) | AUDIO_LIPSYNC(255);
> + } else {
> + if (connector->latency_present[0])
> + tmp = VIDEO_LIPSYNC(connector->video_latency[0]) |
> + AUDIO_LIPSYNC(connector->audio_latency[0]);
> + else
> + tmp = VIDEO_LIPSYNC(255) | AUDIO_LIPSYNC(255);
> + }
> + WREG32(AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_LIPSYNC, tmp);
> +}
> +
> static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
> {
> struct radeon_device *rdev = encoder->dev->dev_private;
> @@ -327,6 +363,7 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder,
> struct drm_display_mode
> dce6_afmt_write_sad_regs(encoder);
> } else {
> evergreen_hdmi_write_sad_regs(encoder);
> + dce4_afmt_write_latency_fields(encoder, mode);
> }
>
> err = drm_hdmi_avi_infoframe_from_display_mode(, mode);
> diff --git a/drivers/gpu/drm/radeon/evergreend.h
> b/drivers/gpu/drm/radeon/evergreend.h
> index fa81893..11e002a 100644
> --- a/drivers/gpu/drm/radeon/evergreend.h
> +++ b/drivers/gpu/drm/radeon/evergreend.h
> @@ -750,6 +750,44 @@
>* bit6 = 192 kHz
>*/
>
> +#define AZ_CHANNEL_COUNT_CONTROL 0x5fe4
> +# define HBR_CHANNEL_COUNT(x) (((x) & 0x7) << 0)
> +# define COMPRESSED_CHANNEL_COUNT(x)(((x) & 0x7) << 4)
> +/* HBR_CHANNEL_COUNT, COMPRESSED_CHANNEL_COUNT
> + * 0 = use stream header
> + * 1-7 = channel count - 1
> + */
> +#define AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_LIPSYNC 0x5fe8
> +# define VIDEO_LIPSYNC(x) (((x) & 0xff) << 0)
> +# define AUDIO_LIPSYNC(x) (((x) & 0xff) << 8)
> +/* VIDEO_LIPSYNC, AUDIO_LIPSYNC
> + * 0 = invalid
> + * x = legal delay value
> + * 255 = sync not supported
> + */
> +#define AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_HBR 0x5fec
> +# define HBR_CAPABLE(1 << 0) /*
> enabled by default */
> +
> +#define AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_AV_ASSOCIATION0 0x5ff4
> +# define DISPLAY0_TYPE(x) (((x) & 0x3) << 0)
> +# define DISPLAY_TYPE_NONE 0
> +# define DISPLAY_TYPE_HDMI 1
> +# define DISPLAY_TYPE_DP 2
> +# define DISPLAY0_ID(x) (((x) & 0x3f) << 2)
> +# define DISPLAY1_TYPE(x) (((x) & 0x3) << 8)
> +# define DISPLAY1_ID(x) (((x) & 0x3f) <<
> 10)
> +# define DISPLAY2_TYPE(x) (((x) & 0x3) << 16)
> +# define DISPLAY2_ID(x) (((x) & 0x3f) <<
> 18)
> +# define DISPLAY3_TYPE(x) (((x) & 0x3) << 24)
> +# define DISPLAY3_ID(x) (((x) & 0x3f) <<
> 26)
> +#define AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_AV_ASSOCIATION1 0x5ff8
> +# define DISPLAY4_TYPE(x) (((x)
MmioTrace: Using the Instruction Decoder, etc.
On Fri, 18 Oct 2013 00:11:15 +0400 Eugene Shatokhin wrote: > Hi, > > Good to know that! > > Yes, it should be faster than page faulting, although I haven't done the > benchmarking yet. And yes, it is not needed to disable all but one CPU. In > my current implementation, I use an ordered workqueue to send the data to > the mmapped output buffer (where they will be read from from the user > space) and that ensures the order of events is kept. May be less than ideal > but it currently works quite well with network drivers, the performance > overhead is acceptable there. Ah, you are not using the ftrace framework nor relayfs? Mmiotrace used to be relayfs at one point and then converted to ftrace. > A subtle drawback may be that the system sees the memory reads and writes > made by the code of the driver directly but if the driver uses some other > kernel functions, it needs to intercept these calls and determine how they > access the memory of interest. Theoretically, it could be less accurate > than page fault handling. A page fault happens no matter if the driver > accesses the memory directly or via strcpy(), for example. I doubt this > would be a big problem for tracking the accesses to ioremapped memory > though. > > Nevertheless, it is manageable, the system already handles string > functions, for example, and reports appropriate events. The handlers for > other functions could be added as well. So this just requires a bit more > maintenance work. Are you saying that you intercept function calls, and *never* rely on page faulting? Does that mean that if a driver does the ugly thing and dereferences an iomem pointer directly, you won't catch that? Unfortunately, I think proprietary drivers do such uglies, since they are x86 and x86_64 only where it works. Or they might have the iomem accessor functions inlined. What I had in mind was to still use page faulting to catch the memory accessing machine instructions, but then use emulation to execute that instruction with the memory address diverted to the real ioremapped region instead of the dummy region given to the driver. Currently for each access, on the page fault, mmiotrace uses single stepping and page table manipulation to let the instruction run for real, and immediately afterwards set things back to page faulting. Sorry, I see my terminology was wrong. I don't think we can avoid the page faulting, but I'd like to avoid the single-stepping and page table mangling on the fly. Heh, things are slowly coming back to me. What do you thing, would it still be interesting? > > Unfortunately, my job exhausts my coding energy, and I haven't even > touched mmiotrace in years. > > I understand. I have many other responsibilities too. Code to write, bugs > to fix, etc. ;-) > > Well, then, when time permits, I'll try to prepare a prototype so that its > performance and reliability could be evaluated. Hard to tell what the > numbers will be before that. > > Suggestions, comments and other feedback are welcome of course. > > And, by the way, video drivers do not use SSE and similar instructions when > accessing ioremapped memory, do they? > Such things are rare in the kernel and usually frowned upon so I opted not > to handle them so far in KernelStrider. I don't really know. I guess everything could be possible in proprietary drivers, but you can look at the instruction decoding code in mmiotrace, which digs up the type and size of access and the value. That has been enough so far. Thanks, pq > 2013/10/17 Pekka Paalanen > > > On Mon, 14 Oct 2013 22:45:09 +0400 > > Eugene Shatokhin wrote: > > > > > Hi, > > > > > > There is an interesting TODO item on MmioTraceDeveloper page: > > > "kprobes has a generic instruction decoding facility, use that instead of > > > homebrewn (or KVM), and use emulation instead of page faulting" > > > > > > Actually, I have done something similar in one of my systems, > > KernelStrider > > > (http://code.google.com/p/kernel-strider/). The system instruments a > > kernel > > > module when that module is being loaded. The instrumented code executes > > > instead of the original one and provides information about the memory > > > accesses it makes and the functions it calls. These data are sent to user > > > space for further analysis. > > > > > > Currently, I use this system to detect data races in the Linux kernel > > (and > > > have found some). I suppose, it could probably be useful to MmioTrace as > > > well. > > > > > > KernelStrider uses an enhanced version of the x86 instruction decoder > > that > > > Kprobes use and relies on binary instrumentation rather than on page > > > faults. So, it can track: > > > - memory accesses (address and size of the accessed memory as well as the > > > access type are recorded) > > > - function calls (exported functions and callbacks, one can setup pre- > > and > > > post- handlers for these) > > > > > > Is there any interest in trying this approach to the task of MmioTrace? >
[Bug 70542] [r600g] HD5450 + uvd + hdmi flickers
https://bugs.freedesktop.org/show_bug.cgi?id=70542 --- Comment #8 from Christian K?nig --- (In reply to comment #7) > not sure if it is relevant but I use a 10 meters cable to connect the tv to > the computer That's a bit much. Could you try with a shorter one to make sure it's not the cable? -- 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/20131019/b4a127ae/attachment.html>
[pull] radeon drm-fixes-3.12
Hi Dave, Most just regression fixes for audio, dpm, and uvd, plus a resource leak fix for cik. The following changes since commit bc5bd37ce48c66e9192ad2e7231e9678880f6f8e: drm: Pad drm_mode_get_connector to 64-bit boundary (2013-10-18 07:42:23 +0100) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.12 for you to fetch changes up to 555b1b651acf44bf27ebbb04235d38a8fd2d58dc: drm/radeon/audio: don't set speaker allocation on DCE4+ (2013-10-18 20:00:09 -0400) Alex Deucher (6): drm/radeon/atom: workaround vbios bug in transmitter table on rs780 drm/radeon: make missing smc ucode non-fatal (r7xx-SI) drm/radeon: make missing smc ucode non-fatal (CI) drm/radeon/audio: don't set speaker allocation on DCE3.2 drm/radeon: rework audio option drm/radeon/audio: don't set speaker allocation on DCE4+ Christian K?nig (2): drm/radeon: stop the leaks in cik_ib_test drm/radeon/uvd: revert lower msg buffer requirements on UVD3 drivers/gpu/drm/radeon/atombios_encoders.c | 54 -- drivers/gpu/drm/radeon/cik.c | 4 +++ drivers/gpu/drm/radeon/dce6_afmt.c | 3 ++ drivers/gpu/drm/radeon/evergreen_hdmi.c| 3 ++ drivers/gpu/drm/radeon/ni.c| 1 + drivers/gpu/drm/radeon/r600.c | 1 + drivers/gpu/drm/radeon/r600_hdmi.c | 3 ++ drivers/gpu/drm/radeon/radeon_connectors.c | 33 +++--- drivers/gpu/drm/radeon/radeon_cs.c | 3 +- drivers/gpu/drm/radeon/radeon_drv.c| 4 +-- drivers/gpu/drm/radeon/radeon_uvd.c| 3 +- drivers/gpu/drm/radeon/si.c| 1 + drivers/gpu/drm/radeon/uvd_v1_0.c | 4 +-- 13 files changed, 80 insertions(+), 37 deletions(-)
[Bug 70542] [r600g] HD5450 + uvd + hdmi flickers
https://bugs.freedesktop.org/show_bug.cgi?id=70542 --- Comment #7 from dagg --- with the patch applied it still flickers, moreover it might have increased the rate of flickering. not sure if it is relevant but I use a 10 meters cable to connect the tv to the computer -- 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/20131019/6d2a4fc5/attachment.html>
[Bug 70542] [r600g] HD5450 + uvd + hdmi flickers
https://bugs.freedesktop.org/show_bug.cgi?id=70542 --- Comment #6 from dagg --- tried with radeon.disp_priority=2, screen still flickers, this time much earlier. trying with the patch and without radeon.disp_priority=2 -- 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/20131019/160465c2/attachment-0001.html>
[Bug 70542] [r600g] HD5450 + uvd + hdmi flickers
https://bugs.freedesktop.org/show_bug.cgi?id=70542 --- Comment #5 from dagg --- Created attachment 87844 --> https://bugs.freedesktop.org/attachment.cgi?id=87844=edit setup's dmesg while flickering occuers -- 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/20131019/a7f97004/attachment.html>
[Bug 70542] [r600g] HD5450 + uvd + hdmi flickers
https://bugs.freedesktop.org/show_bug.cgi?id=70542 --- Comment #4 from dagg --- Created attachment 87843 --> https://bugs.freedesktop.org/attachment.cgi?id=87843=edit seat's xorg log -- 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/20131019/7c012620/attachment.html>
[Bug 70542] [r600g] HD5450 + uvd + hdmi flickers
https://bugs.freedesktop.org/show_bug.cgi?id=70542 --- Comment #3 from dagg --- greetings, sorry it took long to answer, it seems that the time between one flickering to another has got bigger, from one every sec I have now one every few minutes. this might be related to the fact that I'm running mesa, libdrm and xf86-video-ati from git an update them every week. anyway, here are dmesg and xorg log (I was sure I attached it but it seems that i didn't). I'll try now with radeon.disp_priority=2 and report back. -- 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/20131019/6e320b1b/attachment.html>
[Bug 63101] Hard lockup whel launching games like TF2 on kernels 3.11.5 and 3.12 rc4 and above
https://bugzilla.kernel.org/show_bug.cgi?id=63101 --- Comment #9 from Kertesz Laszlo --- Reverted 6d15ee492809d38bd62237b6d0f6a81d4dd12d15, bit didnt help, i still get the lockup. Build v3.12-rc3-265-gafe05d4 (until commit afe05d41e2c25ca3e047f9c7e5341bda553a932f) is working. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 1/2] drm/radeon/audio: write audio/video latency info for DCE4/5
18.10.2013 23:41, Alex Deucher kirjoitti:
> Needed by the hda driver to properly set up synchronization
> on the audio side.
For the record, the ALSA hda driver does not actually do anything with
these values yet (and my work-in-progress doesn't change that), except
show them in ELD information.
This might change in the future of course :)
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/evergreen_hdmi.c | 37
> drivers/gpu/drm/radeon/evergreend.h | 38
> +
> 2 files changed, 75 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> index 5fbe486..abdc893 100644
> --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
> +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
> @@ -58,6 +58,42 @@ static void evergreen_hdmi_update_ACR(struct drm_encoder
> *encoder, uint32_t cloc
> WREG32(HDMI_ACR_48_1 + offset, acr.n_48khz);
> }
>
> +static void dce4_afmt_write_latency_fields(struct drm_encoder *encoder,
> +struct drm_display_mode *mode)
> +{
> + struct radeon_device *rdev = encoder->dev->dev_private;
> + struct drm_connector *connector;
> + struct radeon_connector *radeon_connector = NULL;
> + u32 tmp = 0;
> +
> + list_for_each_entry(connector,
> >dev->mode_config.connector_list, head) {
> + if (connector->encoder == encoder) {
> + radeon_connector = to_radeon_connector(connector);
> + break;
> + }
> + }
> +
> + if (!radeon_connector) {
> + DRM_ERROR("Couldn't find encoder's connector\n");
> + return;
> + }
> +
> + if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
> + if (connector->latency_present[1])
> + tmp = VIDEO_LIPSYNC(connector->video_latency[1]) |
> + AUDIO_LIPSYNC(connector->audio_latency[1]);
> + else
> + tmp = VIDEO_LIPSYNC(255) | AUDIO_LIPSYNC(255);
> + } else {
> + if (connector->latency_present[0])
> + tmp = VIDEO_LIPSYNC(connector->video_latency[0]) |
> + AUDIO_LIPSYNC(connector->audio_latency[0]);
> + else
> + tmp = VIDEO_LIPSYNC(255) | AUDIO_LIPSYNC(255);
> + }
> + WREG32(AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_LIPSYNC, tmp);
> +}
> +
> static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder)
> {
> struct radeon_device *rdev = encoder->dev->dev_private;
> @@ -327,6 +363,7 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder,
> struct drm_display_mode
> dce6_afmt_write_sad_regs(encoder);
> } else {
> evergreen_hdmi_write_sad_regs(encoder);
> + dce4_afmt_write_latency_fields(encoder, mode);
> }
>
> err = drm_hdmi_avi_infoframe_from_display_mode(, mode);
> diff --git a/drivers/gpu/drm/radeon/evergreend.h
> b/drivers/gpu/drm/radeon/evergreend.h
> index fa81893..11e002a 100644
> --- a/drivers/gpu/drm/radeon/evergreend.h
> +++ b/drivers/gpu/drm/radeon/evergreend.h
> @@ -750,6 +750,44 @@
> * bit6 = 192 kHz
> */
>
> +#define AZ_CHANNEL_COUNT_CONTROL 0x5fe4
> +# define HBR_CHANNEL_COUNT(x) (((x) & 0x7) << 0)
> +# define COMPRESSED_CHANNEL_COUNT(x)(((x) & 0x7) << 4)
> +/* HBR_CHANNEL_COUNT, COMPRESSED_CHANNEL_COUNT
> + * 0 = use stream header
> + * 1-7 = channel count - 1
> + */
> +#define AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_LIPSYNC 0x5fe8
> +# define VIDEO_LIPSYNC(x) (((x) & 0xff) << 0)
> +# define AUDIO_LIPSYNC(x) (((x) & 0xff) << 8)
> +/* VIDEO_LIPSYNC, AUDIO_LIPSYNC
> + * 0 = invalid
> + * x = legal delay value
> + * 255 = sync not supported
> + */
> +#define AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_HBR 0x5fec
> +# define HBR_CAPABLE(1 << 0) /*
> enabled by default */
> +
> +#define AZ_F0_CODEC_PIN0_CONTROL_RESPONSE_AV_ASSOCIATION0 0x5ff4
> +# define DISPLAY0_TYPE(x) (((x) & 0x3) << 0)
> +# define DISPLAY_TYPE_NONE 0
> +# define DISPLAY_TYPE_HDMI 1
> +# define DISPLAY_TYPE_DP 2
> +# define DISPLAY0_ID(x) (((x) & 0x3f) << 2)
> +# define DISPLAY1_TYPE(x) (((x) & 0x3) << 8)
> +# define DISPLAY1_ID(x) (((x) & 0x3f) <<
> 10)
> +# define DISPLAY2_TYPE(x) (((x) & 0x3) << 16)
> +# define DISPLAY2_ID(x) (((x) & 0x3f) <<
> 18)
> +# define DISPLAY3_TYPE(x) (((x) & 0x3) << 24)
> +# define DISPLAY3_ID(x)
[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 wazzubrad at gmail.com changed: What|Removed |Added Priority|medium |highest Component|Drivers/Gallium/r600|Drivers/DRI/Radeon --- Comment #28 from wazzubrad at gmail.com --- My XBMC system is useless until there is a fix. Thank you to whoever figures this out. $ lspci 00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Richland [Radeon HD 8370D] dmesg - http://paste.ubuntu.com/6260473/ xbmc.log - http://paste.ubuntu.com/6260482/ Xorg.0.log - http://paste.ubuntu.com/6260486/ vdpauinfo - http://paste.ubuntu.com/6260488/ dpkg -l |grep mesa - http://paste.ubuntu.com/6260490/ -- 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/20131019/47447574/attachment.html>
