[Intel-gfx] [PATCH 1/2] drm: share drm_add_fake_info_node
On Tue, Jan 14, 2014 at 06:14:06AM -0800, Ben Widawsky wrote:
> Both i915 and Armada had the exact same implementation. For an upcoming
> patch, I'd like to call this function from two different source files in
> i915, and having it available externally helps there too.
>
> While moving, add 'debugfs_' to the name in order to match the other drm
> debugfs helper functions.
>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: intel-gfx at lists.freedesktop.org
> Signed-off-by: Ben Widawsky
drm_debugfs_create_files in drm_debugfs.c has the almost same code again.
Now the problem here is that the interface is a bit botched up, since all
the users in i915 and armada actaully faile to clean up teh debugfs dentry
if drm_add_fake_info_node.
So I think the right approach is to extrace a new drm_debugfs_create_node
helper which is used by i915, armada and drm_debugfs_create_files. Also I
think it's better to split this up into a drm core patch and then
i915/armada driver patches, for easier merging.
-Daniel
> ---
> drivers/gpu/drm/armada/armada_debugfs.c | 24 +---
> drivers/gpu/drm/drm_debugfs.c | 24
> drivers/gpu/drm/i915/i915_debugfs.c | 32 +++-
> include/drm/drmP.h | 9 +
> 4 files changed, 37 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/armada/armada_debugfs.c
> b/drivers/gpu/drm/armada/armada_debugfs.c
> index 471e456..02f2978 100644
> --- a/drivers/gpu/drm/armada/armada_debugfs.c
> +++ b/drivers/gpu/drm/armada/armada_debugfs.c
> @@ -107,28 +107,6 @@ static struct drm_info_list armada_debugfs_list[] = {
> };
> #define ARMADA_DEBUGFS_ENTRIES ARRAY_SIZE(armada_debugfs_list)
>
> -static int drm_add_fake_info_node(struct drm_minor *minor, struct dentry
> *ent,
> - const void *key)
> -{
> - struct drm_info_node *node;
> -
> - node = kmalloc(sizeof(struct drm_info_node), GFP_KERNEL);
> - if (node == NULL) {
> - debugfs_remove(ent);
> - return -ENOMEM;
> - }
> -
> - node->minor = minor;
> - node->dent = ent;
> - node->info_ent = (void *) key;
> -
> - mutex_lock(&minor->debugfs_lock);
> - list_add(&node->list, &minor->debugfs_list);
> - mutex_unlock(&minor->debugfs_lock);
> -
> - return 0;
> -}
> -
> static int armada_debugfs_create(struct dentry *root, struct drm_minor
> *minor,
> const char *name, umode_t mode, const struct file_operations *fops)
> {
> @@ -136,7 +114,7 @@ static int armada_debugfs_create(struct dentry *root,
> struct drm_minor *minor,
>
> de = debugfs_create_file(name, mode, root, minor->dev, fops);
>
> - return drm_add_fake_info_node(minor, de, fops);
> + return drm_debugfs_add_fake_info_node(minor, de, fops);
> }
>
> int armada_drm_debugfs_init(struct drm_minor *minor)
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index b4b51d4..1edaac0 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -237,5 +237,29 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
> return 0;
> }
>
> +int drm_debugfs_add_fake_info_node(struct drm_minor *minor,
> +struct dentry *ent,
> +const void *key)
> +{
> + struct drm_info_node *node;
> +
> + node = kmalloc(sizeof(*node), GFP_KERNEL);
> + if (node == NULL) {
> + debugfs_remove(ent);
> + return -ENOMEM;
> + }
> +
> + node->minor = minor;
> + node->dent = ent;
> + node->info_ent = (void *) key;
> +
> + mutex_lock(&minor->debugfs_lock);
> + list_add(&node->list, &minor->debugfs_list);
> + mutex_unlock(&minor->debugfs_lock);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_debugfs_add_fake_info_node);
> +
> #endif /* CONFIG_DEBUG_FS */
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 430eb3e..f2ef30c 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -51,32 +51,6 @@ static const char *yesno(int v)
> return v ? "yes" : "no";
> }
>
> -/* As the drm_debugfs_init() routines are called before dev->dev_private is
> - * allocated we need to hook into the minor for release. */
> -static int
> -drm_add_fake_info_node(struct drm_minor *minor,
> -struct dentry *ent,
> -const void *key)
> -{
> - struct drm_info_node *node;
> -
> - node = kmalloc(sizeof(*node), GFP_KERNEL);
> - if (node == NULL) {
> - debugfs_remove(ent);
> - return -ENOMEM;
> - }
> -
> - node->minor = minor;
> - node->dent = ent;
> - node->info_ent = (void *) key;
> -
> - mutex_lock(&minor->debugfs_lock);
> - list_add(&node->list, &minor->debugfs_list);
> - mutex_unlock(&minor->debugfs_lock);
> -
> - return 0;
> -}
> -
> static int i915_capabiliti
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 Paul Menzel changed: What|Removed |Added CC||paulepanter at users.sourcefor ||ge.net --- Comment #8 from Paul Menzel --- Just a note, that the Debian Linux kernel has fbcon compiled in. CONFIG_FRAMEBUFFER_CONSOLE=y -- 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/20140115/a0036f3e/attachment-0001.html>
[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering
https://bugs.freedesktop.org/show_bug.cgi?id=73528 --- Comment #3 from Michel D?nzer --- (In reply to comment #2) > [...] compiling takes many minutes as it is. git bisect minimizes the number of times you need to compile Mesa to isolate the change introducing the problem. > I can't estimate where it might have broken either, Your initial report says it's working with Mesa 9.2.3 but broken with current Git, that's good enough for bisecting. > nor risk experiencing the problem too many times (given it almost > brings the system down). I don't think it's that dramatic. It sounds like the usual symptoms of the GPU repeatedly hanging and being reset by the driver. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140115/cc9ec0cd/attachment.html>
[Bug 73625] rv730 agp unstable while uvd video playback
https://bugs.freedesktop.org/show_bug.cgi?id=73625 --- Comment #1 from Roman Elshin --- I am sorry, disabling ColorTiling2D does not fix it, but it definitely makes situation better. I suppose there are different bugs mixed here, and disabling ColorTiling2D hide some of them. -- 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/20140115/4e44b070/attachment.html>
[git pull] drm last fixes
Hi Linus, One nouveau regression fix on older cards, i915 black screen fixes, and a revert for a strange G33 intel problem. Dave. The following changes since commit 7e22e91102c6b9df7c4ae2168910e19d2bb14cd6: Linux 3.13-rc8 (2014-01-12 17:04:18 +0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 703a8c2dfa5aa69b9b0a6684dc78ea28a2c7fe3e: Merge branch 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2014-01-15 15:01:11 +1000) Ben Skeggs (1): drm/nouveau: fix null ptr dereferences on some boards Dave Airlie (3): Merge tag 'drm-intel-fixes-2014-01-13' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Revert "drm: copy mode type in drm_mode_connector_list_update()" Merge branch 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Jesse Barnes (1): drm/i915/bdw: make sure south port interrupts are enabled properly v2 Paulo Zanoni (1): drm/i915: fix DDI PLLs HW state readout code Ville Syrj?l? (1): drm/i915: Don't grab crtc mutexes in intel_modeset_gem_init() drivers/gpu/drm/drm_modes.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 2 ++ drivers/gpu/drm/i915/intel_ddi.c | 8 +++- drivers/gpu/drm/i915/intel_display.c | 4 ++-- drivers/gpu/drm/nouveau/core/include/subdev/i2c.h | 2 +- drivers/gpu/drm/nouveau/core/include/subdev/instmem.h | 7 +++ drivers/gpu/drm/nouveau/core/subdev/i2c/base.c| 4 ++-- drivers/gpu/drm/nouveau/core/subdev/therm/ic.c| 10 +- drivers/gpu/drm/nouveau/dispnv04/dfp.c| 2 +- drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 2 +- 10 files changed, 29 insertions(+), 14 deletions(-)
[Bug 73649] New: SIGSEGV: r600_sb::bc_parser::decode_shader()
https://bugs.freedesktop.org/show_bug.cgi?id=73649 Priority: medium Bug ID: 73649 Assignee: dri-devel at lists.freedesktop.org Summary: SIGSEGV: r600_sb::bc_parser::decode_shader() Severity: normal Classification: Unclassified OS: All Reporter: octoploid at yandex.com Hardware: Other Status: NEW Version: 10.0 Component: Drivers/Gallium/r600 Product: Mesa Trying to run the http://code.google.com/p/glyphy/ demo with r600 LLVM backend enabled I get: Enter: demo_glstate_create Enter: demo_shader_create_program Enter: compile_shader Leave: compile_shader Enter: compile_shader Leave: compile_shader Enter: link_program Leave: link_program Leave: demo_shader_create_program Enter: demo_atlas_create Leave: demo_atlas_create Leave: demo_glstate_create Enter: demo_view_create Leave: demo_view_create Welcome to GLyphy demo 45 glyphs; avg num endpoints 23.78; avg error 60.4%; avg tex fetch 2.96; avg 2.23kb per glyph Setting vsync on. Setting sRGB framebuffer on. No sRGB framebuffer extension found; failed to set sRGB framebuffer Setting debug to 0 Setting contrast to 1 Setting gamma_adjust to 1 Setting outline to 0 Setting outline_thickness to 1 Setting boldness to 0 Program received signal SIGSEGV, Segmentation fault. 0x76a865e6 in r600_sb::bc_parser::decode_shader() () from /usr/lib64/dri/r600_dri.so (gdb) bt #0 0x76a865e6 in r600_sb::bc_parser::decode_shader() () from /usr/lib64/dri/r600_dri.so #1 0x76a8b23e in r600_sb_bytecode_process () from /usr/lib64/dri/r600_dri.so #2 0x76a20966 in r600_shader_select () from /usr/lib64/dri/r600_dri.so #3 0x76a22100 in r600_create_shader_state () from /usr/lib64/dri/r600_dri.so #4 0x76b69bae in st_translate_fragment_program () from /usr/lib64/dri/r600_dri.so #5 0x76b6bf66 in st_get_fp_variant () from /usr/lib64/dri/r600_dri.so #6 0x76a60a15 in update_fp () from /usr/lib64/dri/r600_dri.so #7 0x76a7a63f in st_validate_state () from /usr/lib64/dri/r600_dri.so #8 0x768e807a in st_Clear.lto_priv.2949 () from /usr/lib64/dri/r600_dri.so #9 0x00406df2 in demo_view_display (vu=0x9f0ae0, buffer=0x83e260) at demo-view.cc:640 #10 0x77bc2934 in fghcbDisplayWindow () from /usr/lib/libglut.so.3 #11 0x77bc63f9 in fgEnumWindows () from /usr/lib/libglut.so.3 #12 0x77bc2f55 in glutMainLoopEvent () from /usr/lib/libglut.so.3 #13 0x77bc373d in glutMainLoop () from /usr/lib/libglut.so.3 #14 0x00403250 in main (argc=1, argv=) at glyphy-demo.cc:136 -- 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/20140115/16b46326/attachment-0001.html>
[Bug 73511] clinfo mises Max clock frequency on r600
https://bugs.freedesktop.org/show_bug.cgi?id=73511 --- Comment #4 from Igor Gnatenko --- Created attachment 92115 --> https://bugs.freedesktop.org/attachment.cgi?id=92115&action=edit [PATCH rebased] drm/radeon: add query to fetch the max engine clock. (In reply to comment #2) > Here's the kernel patch: > http://people.freedesktop.org/~agd5f/0001-drm-radeon-add-query-to-fetch-the- > max-engine-clock.patch This patch doesn't apply to latest git tree. I've rebased 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/20140115/2f675f3e/attachment.html>
Kernel 3.12.x breaks video playback using XBMC on Intel
Hi all, I sent this initially to the linux-kernel list but suggestion was to send it to dri-devel. I use Ubuntu 13.10 x64. I run XBMC Alpha Git 10 using HDMI output. I use Ubuntu kernels from mainline (http://kernel.ubuntu.com/~kernel-ppa/mainline) Kernel 3.8.x / 3.11.10 (and some others kernels) work fine and every frame is rendered properly. Problem: Using kernel 3.12.1 / 3.12.7 (I tested only these two) video playback skips several frames per second. Mainboard: Intel DH61AG BIOS: AGH6110H.86A.0106.2013.0509.1441 CPU: Intel i3-3240 Memory: 4 Gb One SSD is being used I am attaching logs from dmesg - there are visible differences between 3.11 and 3.12, e.g. ACPI: \_SB_.PCI0.TPMX: can't evaluate _ADR (0x5) ACPI: \_SB_.PCI0.PDRC: can't evaluate _ADR (0x5) ACPI: \_SB_.PCI0.DOCK: can't evaluate _ADR (0x5) Regards, Bjoern -- next part -- A non-text attachment was scrubbed... Name: kernel_3.11.10.log Type: text/x-log Size: 56029 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140115/159c1e3f/attachment-0003.bin> -- next part -- A non-text attachment was scrubbed... Name: kernel_3.12.1.log Type: text/x-log Size: 55428 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140115/159c1e3f/attachment-0004.bin> -- next part -- A non-text attachment was scrubbed... Name: kernel_3.12.7.log Type: text/x-log Size: 56219 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140115/159c1e3f/attachment-0005.bin>
[PATCH] intel: Track whether a buffer is idle to avoid trips to the kernel.
I've seen a number of apps spending unreasonable amounts of time in
drm_intel_bo_busy during the buffer mapping process.
We can't track idleness in general, in the case of buffers shared
across processes. But this should significantly reduce our overhead
for checking for busy on things like VBOs.
Improves (unoptimized) glamor x11perf -f8text by 0.243334% +/-
0.161498% (n=1549), which has formerly been spending about .5% of its
time hitting the kernel for drm_intel_gem_bo_busy().
---
I've still got a patch outstanding on the list for valgrind-cleaning
the modesetting paths. Since we're probably rolling a release soon,
that might be nice to get in.
intel/intel_bufmgr_gem.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 75e95e6..27ad576 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -212,6 +212,15 @@ struct _drm_intel_bo_gem {
bool reusable;
/**
+* Boolean of whether the GPU is definitely not accessing the buffer.
+*
+* This is only valid when reusable, since non-reusable
+* buffers are those that have been shared wth other
+* processes, so we don't know their state.
+*/
+ bool idle;
+
+ /**
* Size in bytes of this buffer and its relocation descendents.
*
* Used to avoid costly tree walking in
@@ -567,11 +576,19 @@ drm_intel_gem_bo_busy(drm_intel_bo *bo)
struct drm_i915_gem_busy busy;
int ret;
+ if (bo_gem->reusable && bo_gem->idle)
+ return false;
+
VG_CLEAR(busy);
busy.handle = bo_gem->gem_handle;
ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_BUSY, &busy);
-
+ if (ret == 0) {
+ bo_gem->idle = !busy.busy;
+ return busy.busy;
+ } else {
+ return false;
+ }
return (ret == 0 && busy.busy);
}
@@ -2242,6 +2259,8 @@ drm_intel_gem_bo_exec(drm_intel_bo *bo, int used,
drm_intel_bo *bo = bufmgr_gem->exec_bos[i];
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+ bo_gem->idle = false;
+
/* Disconnect the buffer from the validate list */
bo_gem->validate_index = -1;
bufmgr_gem->exec_bos[i] = NULL;
@@ -2337,6 +2356,8 @@ skip_execution:
drm_intel_bo *bo = bufmgr_gem->exec_bos[i];
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *)bo;
+ bo_gem->idle = false;
+
/* Disconnect the buffer from the validate list */
bo_gem->validate_index = -1;
bufmgr_gem->exec_bos[i] = NULL;
--
1.8.5.2
[Intel-gfx] [PATCH 1/2] drm: share drm_add_fake_info_node
On Wed, Jan 15, 2014 at 12:40 AM, Russell King - ARM Linux wrote: > On Wed, Jan 15, 2014 at 12:25:10AM +0100, Daniel Vetter wrote: >> On Tue, Jan 14, 2014 at 06:14:06AM -0800, Ben Widawsky wrote: >> > Both i915 and Armada had the exact same implementation. For an upcoming >> > patch, I'd like to call this function from two different source files in >> > i915, and having it available externally helps there too. >> > >> > While moving, add 'debugfs_' to the name in order to match the other drm >> > debugfs helper functions. >> > >> > Cc: linux-arm-kernel at lists.infradead.org >> > Cc: intel-gfx at lists.freedesktop.org >> > Signed-off-by: Ben Widawsky >> >> drm_debugfs_create_files in drm_debugfs.c has the almost same code again. >> Now the problem here is that the interface is a bit botched up, since all >> the users in i915 and armada actaully faile to clean up teh debugfs dentry >> if drm_add_fake_info_node. > > That's not correct - armada does clean up these, I think you need to > take a closer look at the code. > > We do this by setting node->info_ent to the file operations structure, > which is a unique key to the file being registered. > > Upon failure to create the fake node, we appropriately call > drm_debugfs_remove_files() with the first argument being a pointer to > the file operations. This causes drm_debugfs_remove_files() to match > the fake entry, call debugfs_remove() on the dentry, and remove the > node from the list, and free the node structure we allocated. > > Upon driver teardown, we also call drm_debugfs_remove_files() but with > each fops which should be registered, thus cleaning up each fake node > which was created. > > So, Armada does clean up these entries properly. Indeed I've missed that and it's just i915 that botches this. I still think the helper would be saner if it cleans up all its leftovers in the failure case. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/dp: Fix typo in comment
Replace an occurrence of "adapater" with "adapter". Signed-off-by: Thierry Reding --- drivers/gpu/drm/drm_dp_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index dba4205de274..dc1e8a247f27 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -206,7 +206,7 @@ i2c_dp_aux_prepare_bus(struct i2c_adapter *adapter) * i2c_dp_aux_add_bus() - register an i2c adapter using the aux ch helper * @adapter: i2c adapter to register * - * This registers an i2c adapater that uses dp aux channel as it's underlaying + * This registers an i2c adapter that uses dp aux channel as it's underlaying * transport. The driver needs to fill out the &i2c_algo_dp_aux_data structure * and store it in the algo_data member of the @adapter argument. This will be * used by the i2c over dp aux algorithm to drive the hardware. -- 1.8.4.2
[Intel-gfx] [PATCH 1/2] drm: share drm_add_fake_info_node
On Wed, Jan 15, 2014 at 9:39 AM, Daniel Vetter wrote: > On Wed, Jan 15, 2014 at 12:40 AM, Russell King - ARM Linux > wrote: >> On Wed, Jan 15, 2014 at 12:25:10AM +0100, Daniel Vetter wrote: >>> On Tue, Jan 14, 2014 at 06:14:06AM -0800, Ben Widawsky wrote: >>> > Both i915 and Armada had the exact same implementation. For an upcoming >>> > patch, I'd like to call this function from two different source files in >>> > i915, and having it available externally helps there too. >>> > >>> > While moving, add 'debugfs_' to the name in order to match the other drm >>> > debugfs helper functions. >>> > >>> > Cc: linux-arm-kernel at lists.infradead.org >>> > Cc: intel-gfx at lists.freedesktop.org >>> > Signed-off-by: Ben Widawsky >>> >>> drm_debugfs_create_files in drm_debugfs.c has the almost same code again. >>> Now the problem here is that the interface is a bit botched up, since all >>> the users in i915 and armada actaully faile to clean up teh debugfs dentry >>> if drm_add_fake_info_node. >> >> That's not correct - armada does clean up these, I think you need to >> take a closer look at the code. >> >> We do this by setting node->info_ent to the file operations structure, >> which is a unique key to the file being registered. >> >> Upon failure to create the fake node, we appropriately call >> drm_debugfs_remove_files() with the first argument being a pointer to >> the file operations. This causes drm_debugfs_remove_files() to match >> the fake entry, call debugfs_remove() on the dentry, and remove the >> node from the list, and free the node structure we allocated. >> >> Upon driver teardown, we also call drm_debugfs_remove_files() but with >> each fops which should be registered, thus cleaning up each fake node >> which was created. >> >> So, Armada does clean up these entries properly. > > Indeed I've missed that and it's just i915 that botches this. I still > think the helper would be saner if it cleans up all its leftovers in > the failure case. Ok, now I've actually page all the stuff back in - if drm_add_fake_info_node fails we don't set up a drm_info_node structure and link it anywhere. Which means drm_debugfs_remove_files won't ever find it and hence can't possibly call debugfs_remove. Which means the debugfs dentry is leaked. So I think the semantics of that new debugfs helper should get fixed to also allocate and clean up the debugfs node. I agree that i915 is even worse since it doesn't bother to clean up any debugfs files at all in the failure case. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v3 3/4] drm/dp: Add DisplayPort link helpers
On Tue, Jan 14, 2014 at 10:52:55AM -0500, Alex Deucher wrote: > On Tue, Jan 14, 2014 at 9:55 AM, Thierry Reding > wrote: [...] > > +/** > > + * drm_dp_link_configure() - configure a DisplayPort link > > + * @aux: DisplayPort AUX cahnnel > > + * @link: pointer to a structure containing the link configuration > > + * > > + * Returns 0 on seccuss or a negative error code on failure. > > spelling. success. Good catch. Thanks! There's also "cahnnel" above and when running a spell checker it pointed out a few others. I've rolled fixes for all of them into a v4, which I guess I'll resend anyway because I forgot to attach the Tegra eDP implementation that I promised. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140115/7b191791/attachment.pgp>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
0.00 1.00 0.00 0.00 0.00 1.00 filter: load detection: 1 range: (0, 1) HDMI-0 disconnected (normal left inverted right x axis y axis) Identifier: 0x55 Timestamp: 139873 Subpixel: horizontal rgb Clones: CRTCs: 0 1 2 3 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: dither: off supported: off, on audio: auto supported: off, on, auto underscan vborder: 0 range: (0, 128) underscan hborder: 0 range: (0, 128) underscan: off supported: off, on, auto coherent: 1 range: (0, 1) -- 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/20140115/1c966511/attachment-0001.html>
[PATCH v2 2/2] drm/tegra: Obtain head number from DT
On Tue, Jan 14, 2014 at 10:53:19AM -0700, Stephen Warren wrote:
> On 01/14/2014 07:45 AM, Thierry Reding wrote:
> > The head number of a given display controller is fixed in hardware and
> > required to program outputs appropriately. Relying on the driver probe
> > order to determine this number will not work, since that could yield a
> > situation where the second head was probed first and would be assigned
> > head number 0 instead of 1.
> >
> > By explicitly specifying the head number in the device tree, it is no
> > longer necessary to rely on these assumptions. As a fallback, if the
> > property isn't available, derive the head number from the display
> > controller node's position in the device tree. That's somewhat more
> > reliable than the previous default but not a proper solution.
>
> The series,
> Tested-by: Stephen Warren
>
> This patch should really have been sent to the DT maintainers and list
> since it changes a DT binding...
Indeed. I'll resend this to the appropriate people and lists. Sorry
about that.
> > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>
> > +static int tegra_dc_parse_dt(struct tegra_dc *dc)
> > +{
> > + struct device_node *np;
> > + u32 value = 0;
> > + int err;
> > +
> > + err = of_property_read_u32(dc->dev->of_node, "nvidia,head", &value);
>
> If of_property_read_u32() returns an error, does it guarantee that value
> is left unchanged? I suspect it'd be safer to add ...
That's the way it's always been at least. of_property_read_u32() ends up
calling of_property_read_u32_array(), which looking at the code only
modifies the out_values parameter when it knows that it will succeed.
Furthermore the function's kernel-doc explicitly says that "out_values
is modified only if a valid u32 value can be decoded" (i.e. on success).
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140115/c0e8e70a/attachment.pgp>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #10 from Paul Menzel --- Created attachment 92126 --> https://bugs.freedesktop.org/attachment.cgi?id=92126&action=edit Linux kernel 3.13-rc8+-disable-ss ring buffer (`dmesg`) Some seconds seem to be missing as the ring buffer overflowed. Please tell me if something important is missing. -- 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/20140115/ebec7bb4/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #11 from Paul Menzel --- Created attachment 92128 --> https://bugs.freedesktop.org/attachment.cgi?id=92128&action=edit X server log file with Linux 3.13-rc8-disable-ss I attached an USB mouse later on. -- 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/20140115/4bb73fa3/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #12 from Paul Menzel --- Alex, please tell me if you still need the Linux output with your second patch applied or anything else. Thanks again! -- 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/20140115/acb0d9f0/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #13 from Paul Menzel --- One other question, how does MS Windows figure out the correct modelines when the EDID of the monitor is incorrect? (I did not try the shipped Windows 8 at all but assume it works.) -- 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/20140115/5d72929f/attachment.html>
[alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
15.01.2014 13:27, Jyri Sarha kirjoitti: > On 12/31/2013 03:25 PM, Mark Brown wrote: >> On Fri, Dec 20, 2013 at 12:39:38PM +0200, Jyri Sarha wrote: >>> support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE. >>> The 8 least significant bits are ignored. >> >> Where does this constraint come from? >> > > From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N > register statically to a value that works only with 4 byte samples. > According to my tests it is possible to support 3 and 2 byte samples too > by changing the CTS_N register value, but I am not sure if the > configuration can be changed on the fly. My data sheet of the nxp chip > is very vague about the register definitions, but I suppose the register > configures some clock divider on the chip. HDMI supports only upto 24bit > audio and the data sheet states that any extraneous least significant > bits are ignored. That sounds strange, CTS/N values only depend on audio sample rate and TMDS/video clock, not on the audio format or the size of samples (HDMI spec sec 7.2 - Audio Sample Clock Capture and Regeneration). Sure there isn't anything more going on (like the used HDMI sink being more tolerant to wrong CTS/N with 4-byte samples, or more likely something else I can't immediately think of)? BTW, radeon driver has some code that calculates static CTS/N values since the hw autogeneration is not reliable there: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/r600_hdmi.c Not that it directly helps now, but just for the record... -- Anssi Hannula
[PATCH] drm/dp: Fix typo in comment
On Wed, Jan 15, 2014 at 3:40 AM, Thierry Reding wrote: > Replace an occurrence of "adapater" with "adapter". > > Signed-off-by: Thierry Reding Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/drm_dp_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c > index dba4205de274..dc1e8a247f27 100644 > --- a/drivers/gpu/drm/drm_dp_helper.c > +++ b/drivers/gpu/drm/drm_dp_helper.c > @@ -206,7 +206,7 @@ i2c_dp_aux_prepare_bus(struct i2c_adapter *adapter) > * i2c_dp_aux_add_bus() - register an i2c adapter using the aux ch helper > * @adapter: i2c adapter to register > * > - * This registers an i2c adapater that uses dp aux channel as it's > underlaying > + * This registers an i2c adapter that uses dp aux channel as it's underlaying > * transport. The driver needs to fill out the &i2c_algo_dp_aux_data > structure > * and store it in the algo_data member of the @adapter argument. This will > be > * used by the i2c over dp aux algorithm to drive the hardware. > -- > 1.8.4.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #14 from Alex Deucher --- (In reply to comment #9) > Applying your patch to disable ss to Linux 3.13-rc8 worked. The monitor > displays now something even with KMS. Thanks! > > It could still be that something else fixed it in Linux 3.13-rc8 which was > not yet in 3.12.6. I?ll post the logs so you can decide. Can you test 3.13-rc8 without the ss-patch to confirm what fixed 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/20140115/b02c43b4/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #15 from Alex Deucher --- (In reply to comment #13) > One other question, how does MS Windows figure out the correct modelines > when the EDID of the monitor is incorrect? (I did not try the shipped > Windows 8 at all but assume it works.) It's not incorrect, you can have multiple modes with different clocks for saving power. E.g., when the system is idle for a while, switch to the lower clocked mode. -- 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/20140115/0034055b/attachment.html>
[Bug 34708] running piglit on r600 causes gkrellm to lose text color
https://bugs.freedesktop.org/show_bug.cgi?id=34708 --- Comment #1 from Tom Stellard --- Is this still an issue with the latest mesa from git? -- 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/20140115/dc841714/attachment.html>
[PATCH] drm/tegra: Obtain head number from DT
The head number of a given display controller is fixed in hardware and
required to program outputs appropriately. Relying on the driver probe
order to determine this number will not work, since that could yield a
situation where the second head was probed first and would be assigned
head number 0 instead of 1.
By explicitly specifying the head number in the device tree, it is no
longer necessary to rely on these assumptions. As a fallback, if the
property isn't available, derive the head number from the display
controller node's position in the device tree. That's somewhat more
reliable than the previous default but not a proper solution.
Tested-by: Stephen Warren
Signed-off-by: Thierry Reding
---
Changes in v2:
- if the nvidia,head property isn't present, find the position of the
display controller within the DT and derive the head number from it
.../bindings/gpu/nvidia,tegra20-host1x.txt | 3 ++
drivers/gpu/drm/tegra/dc.c | 41 --
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
index 9e9008f8fa32..efaeec8961b6 100644
--- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
@@ -118,6 +118,9 @@ of the following host1x client modules:
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- dc
+ - nvidia,head: The number of the display controller head. This is used to
+setup the various types of output to receive video data from the given
+head.
Each display controller node has a child node, named "rgb", that represents
the RGB output associated with the controller. It can take the following
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 386f3b4b0094..9336006b475d 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1100,8 +1100,6 @@ static int tegra_dc_init(struct host1x_client *client)
struct tegra_dc *dc = host1x_client_to_dc(client);
int err;
- dc->pipe = tegra->drm->mode_config.num_crtc;
-
drm_crtc_init(tegra->drm, &dc->base, &tegra_crtc_funcs);
drm_mode_crtc_set_gamma_size(&dc->base, 256);
drm_crtc_helper_add(&dc->base, &tegra_crtc_helper_funcs);
@@ -1187,6 +1185,41 @@ static const struct of_device_id tegra_dc_of_match[] = {
}
};
+static int tegra_dc_parse_dt(struct tegra_dc *dc)
+{
+ struct device_node *np;
+ u32 value = 0;
+ int err;
+
+ err = of_property_read_u32(dc->dev->of_node, "nvidia,head", &value);
+ if (err < 0) {
+ dev_err(dc->dev, "missing \"nvidia,head\" property\n");
+
+ /*
+* If the nvidia,head property isn't present, try to find the
+* correct head number by looking up the position of this
+* display controller's node within the device tree. Assuming
+* that the nodes are ordered properly in the DTS file and
+* that the translation into a flattened device tree blob
+* preserves that ordering this will actually yield the right
+* head number.
+*
+* If those assumptions don't hold, this will still work for
+* cases where only a single display controller is used.
+*/
+ for_each_matching_node(np, tegra_dc_of_match) {
+ if (np == dc->dev->of_node)
+ break;
+
+ value++;
+ }
+ }
+
+ dc->pipe = value;
+
+ return 0;
+}
+
static int tegra_dc_probe(struct platform_device *pdev)
{
const struct of_device_id *id;
@@ -1207,6 +1240,10 @@ static int tegra_dc_probe(struct platform_device *pdev)
dc->dev = &pdev->dev;
dc->soc = id->data;
+ err = tegra_dc_parse_dt(dc);
+ if (err < 0)
+ return err;
+
dc->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(dc->clk)) {
dev_err(&pdev->dev, "failed to get clock\n");
--
1.8.4.2
Kernel 3.12.x breaks video playback using XBMC on Intel
Am Wed, 15 Jan 2014 08:21:48 +0100 schrieb bjoern : > Hi all, > > I sent this initially to the linux-kernel list but suggestion was to > send it to dri-devel. > > I use Ubuntu 13.10 x64. I run XBMC Alpha Git 10 using HDMI output. > > I use Ubuntu kernels from mainline > (http://kernel.ubuntu.com/~kernel-ppa/mainline) > > Kernel 3.8.x / 3.11.10 (and some others kernels) work fine and every > frame is rendered properly. > > Problem: > Using kernel 3.12.1 / 3.12.7 (I tested only these two) video playback > skips several frames per second. > > Mainboard: Intel DH61AG > BIOS: AGH6110H.86A.0106.2013.0509.1441 > CPU: Intel i3-3240 > Memory: 4 Gb > One SSD is being used > > I am attaching logs from dmesg - there are visible differences between > 3.11 and 3.12, e.g. > > ACPI: \_SB_.PCI0.TPMX: can't evaluate _ADR (0x5) > ACPI: \_SB_.PCI0.PDRC: can't evaluate _ADR (0x5) > ACPI: \_SB_.PCI0.DOCK: can't evaluate _ADR (0x5) > > Regards, > Bjoern I've created a bugzilla entry for this as it seems more appropriate than the mailing list I guess: https://bugs.freedesktop.org/show_bug.cgi?id=73667
[alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
On Wed, 15 Jan 2014 13:27:21 +0200 Jyri Sarha wrote: > From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N > register statically to a value that works only with 4 byte samples. > According to my tests it is possible to support 3 and 2 byte samples too > by changing the CTS_N register value, but I am not sure if the > configuration can be changed on the fly. My data sheet of the nxp chip > is very vague about the register definitions, but I suppose the register > configures some clock divider on the chip. HDMI supports only upto 24bit > audio and the data sheet states that any extraneous least significant > bits are ignored. In the tda998x driver, the CTS_N is automatic (AIP_CNTRL_0_ACR_MAN is not set). Then, in my Cubox (Marvell A510 + tda19988), the 16, 24 and 32 bits formats are working well with I2S input at any rate. -- Ken ar c'henta? | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #16 from Paul Menzel --- (In reply to comment #15) > (In reply to comment #13) > > One other question, how does MS Windows figure out the correct modelines > > when the EDID of the monitor is incorrect? (I did not try the shipped > > Windows 8 at all but assume it works.) > > It's not incorrect, you can have multiple modes with different clocks for > saving power. E.g., when the system is idle for a while, switch to the > lower clocked mode. If the display is not able to display something with a certain modeline, I?d call it incorrect. What did I miss? -- 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/20140115/576fb204/attachment-0001.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #17 from Alex Deucher --- (In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #13) > > > One other question, how does MS Windows figure out the correct modelines > > > when the EDID of the monitor is incorrect? (I did not try the shipped > > > Windows 8 at all but assume it works.) > > > > It's not incorrect, you can have multiple modes with different clocks for > > saving power. E.g., when the system is idle for a while, switch to the > > lower clocked mode. > > If the display is not able to display something with a certain modeline, I?d > call it incorrect. What did I miss? I was just guessing at a possible cause for the display problem. It turns out it's not the issue anyway. -- 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/20140115/0074d7eb/attachment.html>
[PATCH v2 2/2] drm/tegra: Obtain head number from DT
On 01/15/2014 02:06 AM, Thierry Reding wrote:
> On Tue, Jan 14, 2014 at 10:53:19AM -0700, Stephen Warren wrote:
>> On 01/14/2014 07:45 AM, Thierry Reding wrote:
>>> The head number of a given display controller is fixed in hardware and
>>> required to program outputs appropriately. Relying on the driver probe
>>> order to determine this number will not work, since that could yield a
>>> situation where the second head was probed first and would be assigned
>>> head number 0 instead of 1.
>>>
>>> By explicitly specifying the head number in the device tree, it is no
>>> longer necessary to rely on these assumptions. As a fallback, if the
>>> property isn't available, derive the head number from the display
>>> controller node's position in the device tree. That's somewhat more
>>> reliable than the previous default but not a proper solution.
>>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>>
>>> +static int tegra_dc_parse_dt(struct tegra_dc *dc)
>>> +{
>>> + struct device_node *np;
>>> + u32 value = 0;
>>> + int err;
>>> +
>>> + err = of_property_read_u32(dc->dev->of_node, "nvidia,head", &value);
>>
>> If of_property_read_u32() returns an error, does it guarantee that value
>> is left unchanged? I suspect it'd be safer to add ...
>
> That's the way it's always been at least. of_property_read_u32() ends up
> calling of_property_read_u32_array(), which looking at the code only
> modifies the out_values parameter when it knows that it will succeed.
>
> Furthermore the function's kernel-doc explicitly says that "out_values
> is modified only if a valid u32 value can be decoded" (i.e. on success).
OK, that last bit is the important part. So, this is fine.
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #18 from Alex Deucher --- Created attachment 92171 --> https://bugs.freedesktop.org/attachment.cgi?id=92171&action=edit patch 1/2 Can you try the two attached patches and see if they help? Patch 2/2 is the actual fix. If you have any problems with both patches, drop patch 1/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/20140115/67b327cd/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #19 from Alex Deucher --- Created attachment 92172 --> https://bugs.freedesktop.org/attachment.cgi?id=92172&action=edit patch 2/2 Patch 2/2. The actual fix for 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/20140115/8a612760/attachment.html>
[Bug 73625] rv730 agp unstable while uvd video playback
https://bugs.freedesktop.org/show_bug.cgi?id=73625 --- Comment #2 from Roman Elshin --- mesa-9.2.5 (kernel-3.13-rc7) seems to work (at least with mpv), so it looks like regression in mesa. -- 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/20140115/3743e518/attachment.html>
[Intel-gfx] [PATCH 1/2] drm: share drm_add_fake_info_node
On Wed, Jan 15, 2014 at 09:45:28AM +0100, Daniel Vetter wrote:
> On Wed, Jan 15, 2014 at 9:39 AM, Daniel Vetter wrote:
> > On Wed, Jan 15, 2014 at 12:40 AM, Russell King - ARM Linux
> > wrote:
> >> On Wed, Jan 15, 2014 at 12:25:10AM +0100, Daniel Vetter wrote:
> >>> On Tue, Jan 14, 2014 at 06:14:06AM -0800, Ben Widawsky wrote:
> >>> > Both i915 and Armada had the exact same implementation. For an upcoming
> >>> > patch, I'd like to call this function from two different source files in
> >>> > i915, and having it available externally helps there too.
> >>> >
> >>> > While moving, add 'debugfs_' to the name in order to match the other drm
> >>> > debugfs helper functions.
> >>> >
> >>> > Cc: linux-arm-kernel at lists.infradead.org
> >>> > Cc: intel-gfx at lists.freedesktop.org
> >>> > Signed-off-by: Ben Widawsky
> >>>
> >>> drm_debugfs_create_files in drm_debugfs.c has the almost same code again.
> >>> Now the problem here is that the interface is a bit botched up, since all
> >>> the users in i915 and armada actaully faile to clean up teh debugfs dentry
> >>> if drm_add_fake_info_node.
> >>
> >> That's not correct - armada does clean up these, I think you need to
> >> take a closer look at the code.
> >>
> >> We do this by setting node->info_ent to the file operations structure,
> >> which is a unique key to the file being registered.
> >>
> >> Upon failure to create the fake node, we appropriately call
> >> drm_debugfs_remove_files() with the first argument being a pointer to
> >> the file operations. This causes drm_debugfs_remove_files() to match
> >> the fake entry, call debugfs_remove() on the dentry, and remove the
> >> node from the list, and free the node structure we allocated.
> >>
> >> Upon driver teardown, we also call drm_debugfs_remove_files() but with
> >> each fops which should be registered, thus cleaning up each fake node
> >> which was created.
> >>
> >> So, Armada does clean up these entries properly.
> >
> > Indeed I've missed that and it's just i915 that botches this. I still
> > think the helper would be saner if it cleans up all its leftovers in
> > the failure case.
>
> Ok, now I've actually page all the stuff back in - if
> drm_add_fake_info_node fails we don't set up a drm_info_node structure
> and link it anywhere. Which means drm_debugfs_remove_files won't ever
> find it and hence can't possibly call debugfs_remove. Which means the
> debugfs dentry is leaked. So I think the semantics of that new debugfs
> helper should get fixed to also allocate and clean up the debugfs
> node.
>
> I agree that i915 is even worse since it doesn't bother to clean up
> any debugfs files at all in the failure case.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Perhaps I don't understand what you want here. The only failure path in
the fake entry creation does already call debugfs_remove.
if (node == NULL) {
debugfs_remove(ent);
return -ENOMEM;
}
So long as the function succeeds, the node will be findable and removable.
--
Ben Widawsky, Intel Open Source Technology Center
[Bug 73625] rv730 agp unstable while uvd video playback
https://bugs.freedesktop.org/show_bug.cgi?id=73625 --- Comment #3 from Alex Deucher --- Can you bisect? -- 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/20140115/eda46f06/attachment.html>
[Bug 73625] rv730 agp unstable while uvd video playback
https://bugs.freedesktop.org/show_bug.cgi?id=73625 --- Comment #4 from Roman Elshin --- Will try, but this machine is so slow -- 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/20140115/2c04c60d/attachment.html>
[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1
https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #10 from kilobug at kilobug.org --- I tried the patch, with various kind of programs (3d games, 2d games, desktop apps, mplayer, ...). It worked somewhat better, but I still got some lockup with some programs (I'll send the dmesg), and even some complete freeze (like while playing a video with mplayer). If needed, I can try to make more tests with various programs (games, phoronix test suite, ...) and give the result (works well, lockup but recovery, freeze) depending on the program. But they'll take some time (since I'll need to reboot quite a lot), so I'll only be able to do it during the week-end, and only if it's useful. Also, should I limit myself to free software, or should I include some non-free games in the mix ? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1
https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #11 from kilobug at kilobug.org --- Created attachment 122201 --> https://bugzilla.kernel.org/attachment.cgi?id=122201&action=edit DMESG : with the drm-next branch and the patch from https://bugzilla.kernel.org/show_bug.cgi?id=68571#c5 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
: 60512 Subpixel: horizontal rgb Clones: CRTCs: 0 1 2 3 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: dither: off supported: off, on audio: auto supported: off, on, auto underscan vborder: 0 range: (0, 128) underscan hborder: 0 range: (0, 128) underscan: off supported: off, on, auto coherent: 1 range: (0, 1) -- 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/20140115/8c59655a/attachment-0001.html>
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #89 from marc at ttux.net --- I am on 3.12.7 and the R600_DEBUG=nohyperz seems to work fine for me. Without it, it crashes after just couple of minutes (machine rebooting automatically). I have a HD6950. So thank you for the tip. -- 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/20140115/889ba859/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #21 from Alex Deucher --- (In reply to comment #20) > I guess I spoke too soon. :( Now starting the system a second time, the > display is black again with the backlight enabled. I was able to login > blindly into GNOME using GDM, so X is running. I?ll post the log files. > Hopefully something can be spotted. Make sure you booted the correct kernel. -- 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/20140115/75aabe19/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #22 from Alex Deucher --- Does forcing a dpms cycle help? e.g., sleep 5; xset dpms force off and then after the monitor blanks, move the mouse to trigger a wake up. -- 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/20140115/ed8e4511/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #23 from Paul Menzel --- Turning the display off and on again, the display works fine. $ xrandr --output eDP --off $ xrandr --output eDP --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/20140115/cd8f7571/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #24 from Alex Deucher --- (In reply to comment #23) > Turning the display off and on again, the display works fine. > > $ xrandr --output eDP --off > $ xrandr --output eDP --auto Does that work without patches or only with one of the patches from this bug? If it requires a patch or patches, which one(s)? -- 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/20140115/31788bc0/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #25 from Paul Menzel --- Alex, thank you for the quick replies! When doing the tests, should I save certain logs? Do you want me to pass special debug parameters? -- 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/20140115/c85c556f/attachment.html>
[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1
https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #12 from Alex Deucher --- Does disabling hyperZ help? E.g., set env var R600_DEBUG=nohyperz in /etc/environment or however your distro handles global env vars. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 73053] dpm hangs with BTC parts
https://bugs.freedesktop.org/show_bug.cgi?id=73053 --- Comment #24 from Alex Deucher --- Does disabling hyperZ help? E.g., set env var R600_DEBUG=nohyperz in /etc/environment or however your distro handles global env vars. -- 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/20140115/0ef30920/attachment-0001.html>
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #90 from Alexandre Demers --- (In reply to comment #89) > I am on 3.12.7 and the R600_DEBUG=nohyperz seems to work fine for me. > Without it, it crashes after just couple of minutes (machine rebooting > automatically). I have a HD6950. So thank you for the tip. Are you seeing this problem with HyperZ since the introduction of dpm or is it something new (a regression)? Have you tried a 3.13-rcX kernel to see if this is still happening? -- 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/20140115/7a3d715c/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #26 from Alex Deucher --- (In reply to comment #25) > Alex, thank you for the quick replies! > > When doing the tests, should I save certain logs? Do you want me to pass > special debug parameters? I don't need any logs at the moment. I just need to know which patches (if any) are necessary to get the display working. -- 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/20140115/33aed2d8/attachment.html>
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #91 from Alex Deucher --- (In reply to comment #88) > Forget that... locked as always. > > I'll test 3.14 soon, either from Alex's drm-next or when we'll get > 3.14-rc1... Have you tried disabling hyperz globally rather than just for a specific app? E.g., set env var R600_DEBUG=nohyperz in /etc/environment or however your distro handles global env vars. -- 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/20140115/49166b88/attachment.html>
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #92 from Alexandre Demers --- (In reply to comment #91) > (In reply to comment #88) > > Forget that... locked as always. > > > > I'll test 3.14 soon, either from Alex's drm-next or when we'll get > > 3.14-rc1... > > Have you tried disabling hyperz globally rather than just for a specific > app? E.g., set env var R600_DEBUG=nohyperz in /etc/environment or however > your distro handles global env vars. That's what I did. I'll test it again, just in case. -- 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/20140115/9857317c/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #27 from Paul Menzel --- So turning the display off and on with xrandr or xset does not always work even with the patched Linux kernel. -- 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/20140115/50f11c3e/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #28 from Paul Menzel --- I was able to get the display to work with Debian?s Linux kernel 3.12.6 (with none of your patches applied) using `xrandr --output eDP --off` and `xrandr --output eDP --auto`. So it looks like no patch is needed after all. -- 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/20140115/882683f5/attachment.html>
[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so
https://bugs.freedesktop.org/show_bug.cgi?id=64810 --- Comment #38 from Rafael Castillo --- (In reply to comment #37) > (In reply to comment #36) > > Yes seems fully fuixed > > Is runtime memory usage as low as with my patch? seems so, but im not really sure if ksysguard is that exact -- 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/20140115/3b5bab22/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #29 from Paul Menzel --- Do you want me to test something else or can we assume that no Linux kernel patch is needed and the display has to be dealt with? As commented, turning it off and on does not always get it to 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/20140115/8bfeff3f/attachment-0001.html>
[Nouveau] [Fwd: [PATCH] Fix null dereference oopses for nv40 cards] kernel 3.13.0-rc8
Seems to work OK thanks.
Bob
On Tue, 2014-01-14 at 15:15 +1000, Ben Skeggs wrote:
> On Tue, Jan 14, 2014 at 3:07 PM, Ben Skeggs wrote:
> > On Tue, Jan 14, 2014 at 1:22 PM, Bob Gleitsmann
> > wrote:
> >> I should have mentioned that this applies to Linus' 3.13.0-rc7 and rc8
> >> git. Maybe it's obvious.
> > Hey Bob,
> >
> > Thanks for reporting this. Can you try the attached patch instead and
> > report if it helps you?
> Thinko in first attempt, new one attached.
>
> >
> > Ben.
> >
> >>
> >> Sorry about that.
> >>
> >> Bob
> >> Forwarded Message
> >> From: Bob Gleitsmann
> >> To: bskeggs at redhat.com
> >> Cc: nouveau at lists.freedesktop.org, dri-devel at lists.freedesktop.org
> >> Subject: [PATCH] Fix null dereference oopses for nv40 cards
> >> Date: Mon, 13 Jan 2014 01:45:36 -0500
> >>
> >> The problem affects nv40 cards during booting. It comes from there being
> >> two places where subdev arrays are maintained. A commit was recently
> >> added to make the two equal. However, the struct nouveau_device version
> >> ends up being referenced before it is initialized. The problem arises
> >> during the creation of the INSTMEM and THERM subdevs. '
> >>
> >> Signed off by: Bob Gleitsmann rjgleits at bellsouth.net
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
> >> b/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
> >> index b10a143..0f494ca 100644
> >> --- a/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
> >> +++ b/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
> >> @@ -23,6 +23,7 @@
> >> */
> >>
> >> #include
> >> +#include
> >>
> >> #include "nv04.h"
> >>
> >> @@ -38,6 +39,7 @@ nv40_instmem_ctor(struct nouveau_object *parent, struct
> >> nouveau_object *engine,
> >>
> >> ret = nouveau_instmem_create(parent, engine, oclass, &priv);
> >> *pobject = nv_object(priv);
> >> + device->subdev[NVDEV_SUBDEV_INSTMEM] = *pobject;
> >> if (ret)
> >> return ret;
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
> >> b/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
> >> index 002e51b..59b25be 100644
> >> --- a/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
> >> +++ b/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
> >> @@ -187,9 +187,11 @@ nv40_therm_ctor(struct nouveau_object *parent,
> >> {
> >> struct nv40_therm_priv *priv;
> >> int ret;
> >> + struct nouveau_device *device = nv_device(parent);
> >>
> >> ret = nouveau_therm_create(parent, engine, oclass, &priv);
> >> *pobject = nv_object(priv);
> >> + device->subdev[NVDEV_SUBDEV_THERM] = *pobject;
> >> if (ret)
> >> return ret;
> >>
> >>
> >>
> >>
> >> ___
> >> Nouveau mailing list
> >> Nouveau at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/nouveau
[PATCH] drm/exynos: Fix multiplatform breakage for ipp
There is no need to include "plat/map-base.h" in ipp driver. Remove this and enable this driver for multi-platform. Signed-off-by: Tushar Behera --- drivers/gpu/drm/exynos/Kconfig |2 +- drivers/gpu/drm/exynos/exynos_drm_ipp.c |1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index f227f54..3af44c2 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -51,7 +51,7 @@ config DRM_EXYNOS_G2D config DRM_EXYNOS_IPP bool "Exynos DRM IPP" - depends on DRM_EXYNOS && !ARCH_MULTIPLATFORM + depends on DRM_EXYNOS help Choose this option if you want to use IPP feature for DRM. diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c b/drivers/gpu/drm/exynos/exynos_drm_ipp.c index d519a4e..eefb429 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c @@ -16,7 +16,6 @@ #include #include #include -#include #include #include -- 1.7.9.5
[PATCH RFC v2 REPOST 2/8] ASoC: davinci-evm: Add named clock reference to DT bindings
On 12/31/2013 03:16 PM, Mark Brown wrote:
> On Fri, Dec 20, 2013 at 12:38:27PM +0200, Jyri Sarha wrote:
>
>> +static int evm_startup(struct snd_pcm_substream *substream)
>> +{
>> +struct snd_soc_pcm_runtime *rtd = substream->private_data;
>> +struct snd_soc_card *soc_card = rtd->codec->card;
>> +struct clk *mclk = ((struct snd_soc_card_drvdata_davinci *)
>> +snd_soc_card_get_drvdata(soc_card))->mclk;
>
> Why do you need to cast away void? Ths indicates something is going
> wrong here though I can't see what.
I'll fix that.
>> +mclk = of_clk_get_by_name(np, "ti,codec-clock");
>> +if (PTR_ERR(mclk) == -EPROBE_DEFER) {
>> +return -EPROBE_DEFER;
>> +} else if (IS_ERR(mclk)) {
>> +dev_dbg(&pdev->dev, "Codec clock not found.\n");
>> +mclk = NULL;
>> +}
>
> The driver will unconditionally enable and disable the clock which I'd
> not expect to work well if we got an error, I'd expect either NULL checks
> on use or a fixed clock to be registered from code in the case where
> we're using the old binding.
>
In the drivers/clk/clk.c the clk == NULL is always checked before using
the pointer. However, adding NULL checks would save couple of
lock-unlock cycles. I'll add them.
> I'd also expect to see devm_clk_get() used here, with the standard
> clock-names based lookup from DT.
>
I'll fix that.
Best regards,
Jyri
[PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
On 12/31/2013 03:25 PM, Mark Brown wrote:
> On Fri, Dec 20, 2013 at 12:39:38PM +0200, Jyri Sarha wrote:
>
>> Add machine driver support for BeagleBone-Black and other boards with
>> tilcdc support and NXP TDA998X HDMI transmitter connected to McASP
>> port in I2S mode. The 44100 Hz sample-rate and it's multiples can not
>> be supported on Beaglebone-Black because of limited clock-rate
>
> Can the drivers infer this from the clocks?
It does. The commit message is referring to a BBB HW specific feature.
Guess I should remove that note from the commit message, since it does
not concern the code itself.
>
>> support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
>> The 8 least significant bits are ignored.
>
> Where does this constraint come from?
>
From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
register statically to a value that works only with 4 byte samples.
According to my tests it is possible to support 3 and 2 byte samples too
by changing the CTS_N register value, but I am not sure if the
configuration can be changed on the fly. My data sheet of the nxp chip
is very vague about the register definitions, but I suppose the register
configures some clock divider on the chip. HDMI supports only upto 24bit
audio and the data sheet states that any extraneous least significant
bits are ignored.
>> +struct snd_soc_card_drvdata_davinci *drvdata =
>> +(struct snd_soc_card_drvdata_davinci *)
>> +snd_soc_card_get_drvdata(soc_card);
>
> Again with the casting.
>
I'll fix that.
>> +runtime->hw.rate_min = drvdata->rate_constraint->list[0];
>> +runtime->hw.rate_max = drvdata->rate_constraint->list[
>> +drvdata->rate_constraint->count - 1];
>> +runtime->hw.rates = SNDRV_PCM_RATE_KNOT;
>> +
>> +snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
>> + drvdata->rate_constraint);
>> +snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
>> + 2, 2);
>
> Why not just set all this statically when registering the DAI?
Because there is no relevant DAI to where to put these limitations. I
did not want to add yet another dummy codec driver, but decided to use
the already existing ASoC HDMI codec. By default the driver support all
audio params supported by HDMI. The limitations are coming from NXP
chip, the NXP driver, and because the chip is used in i2s mode. In other
words the limitation is coming from machine setup, not from the DAIs.
>
>> +static unsigned int evm_get_bclk(struct snd_pcm_hw_params *params)
>> +{
>> +int sample_size = snd_pcm_format_width(params_format(params));
>> +int rate = params_rate(params);
>> +int channels = params_channels(params);
>> +
>> +return sample_size * channels * rate;
>> +}
>
> snd_soc_params_to_frame_size().
>
Rather snd_soc_params_to_bclk(), but thanks. I'll use that.
>> +static int evm_tda998x_hw_params(struct snd_pcm_substream *substream,
>> + struct snd_pcm_hw_params *params)
>> +{
>> +struct snd_soc_pcm_runtime *rtd = substream->private_data;
>> +struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
>> +struct snd_soc_codec *codec = rtd->codec;
>> +struct snd_soc_card *soc_card = codec->card;
>> +struct platform_device *pdev = to_platform_device(soc_card->dev);
>> +unsigned int bclk_freq = evm_get_bclk(params);
>> +unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
>> + snd_soc_card_get_drvdata(soc_card))->sysclk;
>> +int ret;
>> +
>> +ret = snd_soc_dai_set_clkdiv(cpu_dai, 1, sysclk / bclk_freq);
>> +if (ret < 0) {
>> +dev_err(&pdev->dev, "can't set CPU DAI clock divider %d\n",
>> +ret);
>> +return ret;
>> +}
>
> This looks like something the DAI driver ought to be able to work out
> for itself based on the clock rate and sample format.
>
I guess that could be done.
Peter, what do you say if I set BCLK divider automatically if mcasp
set_sysclk() has been called with SND_SOC_CLOCK_IN?
>> +static unsigned int tda998x_hdmi_rates[] = {
>> +32000,
>> +44100,
>> +48000,
>> +88200,
>> +96000,
>> +};
>
> The changelog said that 44.1kHz and its multiples couldn't be supported
> - is that just the multiples?
>
As I mentioned earlier, that is a BBB HW limitation only, the code
bellow is able to decide what rates are available based on the sysclk rate.
>> +static struct snd_pcm_hw_constraint_list *evm_tda998x_rate_constraint(
>> +struct snd_soc_card *soc_card)
>> +{
>> +struct platform_device *pdev = to_platform_device(soc_card->dev);
>> +unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
>> + snd_soc_card_get_drvdata(soc_card))->sysclk;
>> +struct snd_pcm_hw_constraint_list *ret;
>> +unsigned int *rates;
>> +int i = 0, j = 0;
>> +
>> +ret = devm_kzalloc(soc_card-
[alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
On 01/15/2014 03:48 PM, Anssi Hannula wrote: > 15.01.2014 13:27, Jyri Sarha kirjoitti: >> On 12/31/2013 03:25 PM, Mark Brown wrote: >>> On Fri, Dec 20, 2013 at 12:39:38PM +0200, Jyri Sarha wrote: support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE. The 8 least significant bits are ignored. >>> >>> Where does this constraint come from? >>> >> >> From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N >> register statically to a value that works only with 4 byte samples. >> According to my tests it is possible to support 3 and 2 byte samples too >> by changing the CTS_N register value, but I am not sure if the >> configuration can be changed on the fly. My data sheet of the nxp chip >> is very vague about the register definitions, but I suppose the register >> configures some clock divider on the chip. HDMI supports only upto 24bit >> audio and the data sheet states that any extraneous least significant >> bits are ignored. > > That sounds strange, CTS/N values only depend on audio sample rate and > TMDS/video clock, not on the audio format or the size of samples (HDMI > spec sec 7.2 - Audio Sample Clock Capture and Regeneration). > > Sure there isn't anything more going on (like the used HDMI sink being > more tolerant to wrong CTS/N with 4-byte samples, or more likely > something else I can't immediately think of)? > On theoretical level I am not really sure about anything, because have not been able to get my hands on proper NXP TDA19988 documentation. However, while playing around with my Beaglebone-Black I have have found out in practice that by changing CTS_N register's (page 0x11 reg 0x0c) K_SEL bits (bit 2 to 0)[1] I can get 2, 3 and 4 byte samples to work consistently by setting: K_SEL = 1 for SNDRV_PCM_FORMAT_S16_LE K_SEL = 2 for SNDRV_PCM_FORMAT_S24_3LE K_SEL = 3 for SNDRV_PCM_FORMAT_S32_LE Because I do not really know what is going on, I did not want to suggest any changes to the driver and just use the format that works with the current driver version. The HDMI sinks I have been using are a Toshiba 22B2LF1G and Thomson 42E90NF32 televisions. About those I just know that they both behave the same way. Best regards, Jyri [1] The closest data sheet that has any description about the chip registers I have found is this: http://media.digikey.com/pdf/Data%20Sheets/NXP%20PDFs/TDA9983B.pdf
[PATCH 4/7] dma-buf: use reservation objects
Em Mon, 13 Jan 2014 13:32:16 +0100
Maarten Lankhorst escreveu:
> This allows reservation objects to be used in dma-buf. it's required
> for implementing polling support on the fences that belong to a dma-buf.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/base/dma-buf.c | 22 --
> drivers/gpu/drm/drm_prime.c|8 +++-
> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
> drivers/gpu/drm/i915/i915_gem_dmabuf.c |2 +-
> drivers/gpu/drm/nouveau/nouveau_drm.c |1 +
> drivers/gpu/drm/nouveau/nouveau_gem.h |1 +
> drivers/gpu/drm/nouveau/nouveau_prime.c|7 +++
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |2 +-
> drivers/gpu/drm/radeon/radeon_drv.c|2 ++
> drivers/gpu/drm/radeon/radeon_prime.c |8
> drivers/gpu/drm/ttm/ttm_object.c |2 +-
> drivers/media/v4l2-core/videobuf2-dma-contig.c |2 +-
With regards to this small change on VB2-dma-contig:
Acked-by: Mauro Carvalho Chehab
> include/drm/drmP.h |2 ++
> include/linux/dma-buf.h|9 ++---
> 14 files changed, 59 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index 1e16cbd61da2..85e792c2c909 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -25,10 +25,12 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
>
> static inline int is_dma_buf_file(struct file *);
>
> @@ -56,6 +58,9 @@ static int dma_buf_release(struct inode *inode, struct file
> *file)
> list_del(&dmabuf->list_node);
> mutex_unlock(&db_list.lock);
>
> + if (dmabuf->resv == (struct reservation_object*)&dmabuf[1])
> + reservation_object_fini(dmabuf->resv);
> +
> kfree(dmabuf);
> return 0;
> }
> @@ -128,6 +133,7 @@ static inline int is_dma_buf_file(struct file *file)
> * @size:[in]Size of the buffer
> * @flags: [in]mode flags for the file.
> * @exp_name:[in]name of the exporting module - useful for
> debugging.
> + * @resv:[in]reservation-object, NULL to allocate default one.
> *
> * Returns, on success, a newly created dma_buf object, which wraps the
> * supplied private data and operations for dma_buf_ops. On either missing
> @@ -135,10 +141,17 @@ static inline int is_dma_buf_file(struct file *file)
> *
> */
> struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops
> *ops,
> - size_t size, int flags, const char *exp_name)
> + size_t size, int flags, const char *exp_name,
> + struct reservation_object *resv)
> {
> struct dma_buf *dmabuf;
> struct file *file;
> + size_t alloc_size = sizeof(struct dma_buf);
> + if (!resv)
> + alloc_size += sizeof(struct reservation_object);
> + else
> + /* prevent &dma_buf[1] == dma_buf->resv */
> + alloc_size += 1;
>
> if (WARN_ON(!priv || !ops
> || !ops->map_dma_buf
> @@ -150,7 +163,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const
> struct dma_buf_ops *ops,
> return ERR_PTR(-EINVAL);
> }
>
> - dmabuf = kzalloc(sizeof(struct dma_buf), GFP_KERNEL);
> + dmabuf = kzalloc(alloc_size, GFP_KERNEL);
> if (dmabuf == NULL)
> return ERR_PTR(-ENOMEM);
>
> @@ -158,6 +171,11 @@ struct dma_buf *dma_buf_export_named(void *priv, const
> struct dma_buf_ops *ops,
> dmabuf->ops = ops;
> dmabuf->size = size;
> dmabuf->exp_name = exp_name;
> + if (!resv) {
> + resv = (struct reservation_object*)&dmabuf[1];
> + reservation_object_init(resv);
> + }
> + dmabuf->resv = resv;
>
> file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
> if (IS_ERR(file)) {
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 56805c39c906..a13e90245adf 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -318,7 +318,13 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops
> = {
> struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
>struct drm_gem_object *obj, int flags)
> {
> - return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size, flags);
> + struct reservation_object *robj = NULL;
> +
> + if (dev->driver->gem_prime_res_obj)
> + robj = dev->driver->gem_prime_res_obj(obj);
> +
> + return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
> + flags, robj);
> }
> EXPORT_SYMBOL(drm_gem_prime_export);
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> b/drivers/gpu/drm/ex
