[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 Jure Repinc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||UNREPRODUCIBLE --- Comment #8 from Jure Repinc 2012-08-22 20:57:15 --- Updated the kernel to the latest revision which contains the patch and have run piglit test three time and no oops this time. So I'm closing as unreproducible with latest code. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #7 from Alex Deucher 2012-08-22 19:32:24 --- I believe this is fixed by this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=676bc2e1e4f9072f7a640d5b7c99ffdf9709a6e7 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 --- Comment #6 from Jure Repinc 2012-08-22 19:23:08 --- Created an attachment (id=78221) --> (https://bugzilla.kernel.org/attachment.cgi?id=78221) config -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 --- Comment #5 from Jure Repinc 2012-08-22 19:22:33 --- Created an attachment (id=78211) --> (https://bugzilla.kernel.org/attachment.cgi?id=78211) Xorg.0.log -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 --- Comment #4 from Jure Repinc 2012-08-22 19:22:03 --- Created an attachment (id=78201) --> (https://bugzilla.kernel.org/attachment.cgi?id=78201) modules -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 --- Comment #3 from Jure Repinc 2012-08-22 19:21:32 --- Created an attachment (id=78191) --> (https://bugzilla.kernel.org/attachment.cgi?id=78191) cpuinfo -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 --- Comment #2 from Jure Repinc 2012-08-22 19:21:04 --- Created an attachment (id=78181) --> (https://bugzilla.kernel.org/attachment.cgi?id=78181) lspci -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 --- Comment #1 from Jure Repinc 2012-08-22 19:20:30 --- Created an attachment (id=78171) --> (https://bugzilla.kernel.org/attachment.cgi?id=78171) dmesg -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 46331] New: OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 Summary: OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests Product: Drivers Version: 2.5 Kernel Version: 3.6.0-rc2+ Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: jlp.bugs at gmail.com Regression: No I have run r600 piglit tests and the OOPS error screen showed up with this: BUG: unable to handle kernel NULL pointer dereference at 0008 IP: [] radeon_ttm_bo_destroy+0x34/0xd0 [radeon] PGD 108522067 PUD 123182067 PMD 0 Oops: 0002 [#1] PREEMPT SMP Modules linked in: asus_atk0110 usb_storage snd_hda_codec_hdmi radeon snd_hda_codec_realtek i2c_algo_bit snd_hda_intel snd_hda_codec snd_pcm coretemp aesni_intel aes_x86_64 r8169 hwmon drm_kms_helper ttm drm aes_generic xhci_hcd i2c_i801 mii ablk_helper cryptd video snd_page_alloc snd_timer snd ehci_hcd wmi CPU 0 Pid: 14945, comm: max-texture-siz Not tainted 3.6.0-rc2-00124-g6dab7ed #1 System manufacturer System Product Name/P8H67 RIP: 0010:[] [] radeon_ttm_bo_destroy+0x34/0xd0 [radeon] RSP: 0018:8800d9fbfb18 EFLAGS: 00010282 RAX: 8802059c6800 RBX: 8802059c6848 RCX: RDX: RSI: RDI: 8802147f6ed8 RBP: 8802059c6800 R08: R09: 88021ec13f40 R10: ea00035a0540 R11: a00bab18 R12: 8802147f6580 R13: 8802059c6848 R14: 8802059c6848 R15: 8802059c6888 FS: 7f7fcdf95740() GS:88021ec0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0008 CR3: d6db1000 CR4: 000407f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process max-texture-siz (pid: 14945, threadinfo 8800d9fbe000, task 880215376600) Stack: 8802059c688c 00400480 8802147f6580 a007481d 0001 0001 8802147f65a0 8802147f69a8 8802133f11f8 a00758a4 0296 0003 Call Trace: [] ? ttm_bo_release_list+0xad/0x100 [ttm] [] ? ttm_bo_release+0x194/0x230 [ttm] [] ? ttm_bo_unref+0x3d/0x60 [ttm] [] ? ttm_bo_init+0x2ac/0x3f0 [ttm] [] ? radeon_bo_create+0x1f4/0x300 [radeon] [] ? radeon_bo_clear_va+0x50/0x50 [radeon] [] ? radeon_gem_object_create+0x64/0x110 [radeon] [] ? radeon_gem_create_ioctl+0x6c/0x120 [radeon] [] ? drm_ioctl+0x40c/0x4c0 [drm] [] ? radeon_gem_pwrite_ioctl+0x30/0x30 [radeon] [] ? do_page_fault+0x182/0x440 [] ? do_vfs_ioctl+0x8f/0x530 [] ? vm_mmap_pgoff+0x73/0xa0 [] ? sys_ioctl+0x49/0x80 [] ? system_call_fastpath+0x16/0x1b Code: 89 fb 48 89 6c 24 08 48 8d 6f b8 4c 89 64 24 10 48 8b bf c8 01 00 00 48 81 c7 d8 0e 00 00 e8 b4 aa 2f e1 48 8b 53 b8 48 8b 43 c0 <48> 89 42 08 48 89 10 48 8b bb c8 01 00 00 48 89 6b b8 48 89 6b RIP [] radeon_ttm_bo_destroy+0x34/0xd0 [radeon] RSP CR2: 0008 ---[ end trace 61e9627de8e05172 ]--- The card is Radeon HD 5750, I'm using Mesa from git (8d1a9a9), libdrm is also from git. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH V2] drm: edid: add support for E-DDC
From: Shirish ShankarappaThe current logic for probing ddc is limited to 2 blocks (256 bytes), this patch adds support for the 4 block (512) data. To do this, a single 8-bit segment index is passed to the display via the I2C address 30h. Data from the selected segment is then immediately read via the regular DDC2 address using a repeated I2C 'START' signal. Signed-off-by: Shirish Shankarappa --- drivers/gpu/drm/drm_edid.c | 19 +-- 1 files changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index a8743c3..33a3888 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -253,7 +253,9 @@ static int drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf, int block, int len) { - unsigned char start = block * EDID_LENGTH; + unsigned short start = block * EDID_LENGTH; + unsigned char segment = block >> 1; + unsigned short segFlags = segment ? 0 : I2C_M_IGNORE_NAK; int ret, retries = 5; /* The core i2c driver will automatically retry the transfer if the @@ -264,27 +266,32 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf, */ do { struct i2c_msg msgs[] = { - { + { /*set segment pointer */ + .addr = DDC_SEGMENT_ADDR, + .flags = segFlags, + .len= 1, + .buf= , + }, { /*set offset */ .addr = DDC_ADDR, .flags = 0, .len= 1, .buf= , - }, { + }, { /*set data */ .addr = DDC_ADDR, .flags = I2C_M_RD, .len= len, .buf= buf, } }; - ret = i2c_transfer(adapter, msgs, 2); + ret = i2c_transfer(adapter, msgs, 3); if (ret == -ENXIO) { DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n", adapter->name); break; } - } while (ret != 2 && --retries); + } while (ret != 3 && --retries); - return ret == 2 ? 0 : -1; + return ret == 3 ? 0 : -1; } static bool drm_edid_is_zero(u8 *in_edid, int length) -- 1.7.0.4
[PATCH V2] drm: edid: add support for E-DDC
From: Shirish ShankarappaThis patch adds support in probing 4 block edid data, for E-DDC. This is the first test case in CTS, for HDMI compliance. Changes from V1: 1. Data type of offset adress updated to unsigned short 2. Updated the buf feild of msg[0] Based on drm-next branch Shirish Shankarappa (1): drm: edid: add support for E-DDC drivers/gpu/drm/drm_edid.c | 19 +-- 1 files changed, 13 insertions(+), 6 deletions(-)
[PATCH] drm/exynos: Update the MAX_EDID value for E-DDC
From: Shirish ShankarappaThe value of MAX_EDID is now valid only for 2 block EDID data which is 256, but to support 4 block EDID (E-DDC) this needs to be 512. Signed-off-by: Shirish Shankarappa --- drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c b/drivers/gpu/drm/exynos/exynos_drm_connector.c index d956819..69d02b5 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c @@ -32,7 +32,7 @@ #include "exynos_drm_drv.h" #include "exynos_drm_encoder.h" -#define MAX_EDID 256 +#define MAX_EDID 512 #define to_exynos_connector(x) container_of(x, struct exynos_drm_connector,\ drm_connector) -- 1.7.0.4
[PATCH] Update MAX_EDID value in exynos
From: Shirish ShankarappaThe value of MAX_EDID is now valid only for 2 block EDID data which is 256, but to support 4 block EDID (E-DDC) this needs to be 512. Based on drm-next branch Shirish Shankarappa (1): drm/exynos: Update the MAX_EDID value for E-DDC drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
[RFC patch 4/4] Re: dma-buf-mgr: multiple dma-buf synchronization (v3)
On Wed, Aug 22, 2012 at 02:52:10PM +0200, Thomas Hellstrom wrote: > Hi, Maarten, > please see some comments inline. > > On 08/22/2012 01:50 PM, Maarten Lankhorst wrote: > >Hey Dan, > > > >Op 16-08-12 01:12, Daniel Vetter schreef: > >>Hi Maarten, > >> > >>Ok, here comes the promised review (finally!), but it's rather a > >>high-level thingy. I've mostly thought about how we could create a neat > >>api with the following points. For a bit of clarity, I've grouped the > >>different considerations a bit. > >> > >Thanks, I have significantly reworked the api based on your comments. > > > >Documentation is currently lacking, and will get updated again for the final > >version. > > > >Full patch series also includes some ttm changes to make use of > >dma-reservation, > >with the intention of moving out fencing from ttm too, but that requires > >more work. > > > >For the full series see: > >http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip > > > >My plan is to add a pointer for dma_reservation to a dma-buf, > >so all users of dma-reservation can perform reservations across > >multiple devices as well. Since the default for ttm likely will > >mean only a few buffers are shared I didn't want to complicate > >the abi for ttm much further so only added a pointer that can be > >null to use ttm's reservation_object structure. > > > >The major difference with ttm is that each reservation object > >gets its own lock for fencing and reservations, but they can > >be merged: > > TTM previously had a lock on each buffer object which protected > sync_obj and sync_obj_arg, however > when fencing multiple buffers, say 100 buffers or so in a single > command submission, it meant 100 > locks / unlocks that weren't really necessary, since just updating > the sync_obj and sync_obj_arg members > is a pretty quick operation, whereas locking may be a pretty slow > operation, so those locks were removed > for efficiency. > The reason a single lock (the lru lock) is used to protect > reservation is that a TTM object that is being reserved > *atomically* needs to be taken off LRU lists, since processes > performing LRU eviction don't take a ticket > when evicting, and may thus cause deadlocks; It might be possible to > fix this within TTM by requiring a ticket > for all reservation, but then that ticket needs to be passed down > the call chain for all functions that may perform > a reservation. It would perhaps be simpler (but perhaps not so fair) > to use the current thread info pointer as a ticket > sequence number. While discussing this stuff with Maarten I've read through the generic mutex code, and I think we could adapt the ideas from in there (which would boil down to a single atomice op for the fastpath for both reserve and unreserve, which even have per-arch optimized asm). So I think we can make the per-obj lock as fast as it's possible, since the current ttm fences already use that atomic op. For passing the reservation_ticket down the callstacks I guess with a common reservation systems used for shared buffers (which is the idea here) we can make a good case to add a pointer to the current thread info. Especially for cross-device reservations through dma_buf I think that would simplify the interfaces quite a bit. Wrt the dma_ prefix I agree it's not a stellar name, but since the intention is to use this together with dma_buf and dma_fence to faciliate cross-device madness it does fit somewhat ... Fyi I hopefully get around to play with Maarten's patches a bit, too. One of the things I'd like to add to the current reservation framework is lockdep annotations. Since if we use this across devices it's way too easy to nest reservations improperly, or to create deadlocks because one thread grabs another lock while holding reservations, while another tries to reserve buffers while holding that lock. > >spin_lock(obj->resv) __dma_object_reserve() grab a ref to all > >obj->fences spin_unlock(obj->resv) > > > >spin_lock(obj->resv) assign new fence to obj->fences > >__dma_object_unreserve() spin_unlock(obj->resv) > > > >There's only one thing about fences I haven't been able to map yet > >properly. vmwgfx has sync_obj_flush, but as far as I can tell it has > >not much to do with sync objects, but is rather a generic 'flush before > >release'. Maybe one of the vmwgfx devs could confirm whether that call > >is really needed there? And if so, if there could be some other way do > >that, because it seems to be the ttm_bo_wait call before that would be > >enough, if not it might help more to move the flush to some other call. > > The fence flush should be interpreted as an operation for fencing > mechanisms that aren't otherwise required to signal in finite time, and > where the time from flush to signal might be substantial. TTM is then > supposed to issue a fence flush when it knows ahead of time that it will > soon perform a periodical poll for a buffer to be idle, but not block > waiting for the buffer to be idle.
[PATCH 2/2] drm/radeon: initialize tracked CS state
This should help catch uninitialized registers and reject commands because of that. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/r600_cs.c |9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c index 7799e28..8866937 100644 --- a/drivers/gpu/drm/radeon/r600_cs.c +++ b/drivers/gpu/drm/radeon/r600_cs.c @@ -315,7 +315,14 @@ static void r600_cs_track_init(struct r600_cs_track *track) track->cb_color_bo[i] = NULL; track->cb_color_bo_offset[i] = 0x; track->cb_color_bo_mc[i] = 0x; - } + track->cb_color_frag_bo[i] = NULL; + track->cb_color_frag_offset[i] = 0x; + track->cb_color_tile_bo[i] = NULL; + track->cb_color_tile_offset[i] = 0x; + track->cb_color_mask[i] = 0x; + } + track->nsamples = 16; + track->log_nsamples = 4; track->cb_target_mask = 0x; track->cb_shader_mask = 0x; track->cb_dirty = true; -- 1.7.9.5
[PATCH 1/2] drm/radeon: fix reading CB_COLORn_MASK from the CS
Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/r600_cs.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c index ab74e6b..7799e28 100644 --- a/drivers/gpu/drm/radeon/r600_cs.c +++ b/drivers/gpu/drm/radeon/r600_cs.c @@ -1416,7 +1416,7 @@ static int r600_cs_check_reg(struct radeon_cs_parser *p, u32 reg, u32 idx) case R_028118_CB_COLOR6_MASK: case R_02811C_CB_COLOR7_MASK: tmp = (reg - R_028100_CB_COLOR0_MASK) / 4; - track->cb_color_mask[tmp] = ib[idx]; + track->cb_color_mask[tmp] = radeon_get_ib_value(p, idx); if (G_0280A0_TILE_MODE(track->cb_color_info[tmp])) { track->cb_dirty = true; } -- 1.7.9.5
[PATCH] i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1
This is an equivalent conversion and will ease scheduled removal of WQ_NON_REENTRANT. Signed-off-by: Tejun Heo --- drivers/gpu/drm/i915/i915_dma.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 9cf7dfe..a55ca7a 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1536,11 +1536,9 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) * * All tasks on the workqueue are expected to acquire the dev mutex * so there is no point in running more than one instance of the -* workqueue at any time: max_active = 1 and NON_REENTRANT. +* workqueue at any time. Use an ordered one. */ - dev_priv->wq = alloc_workqueue("i915", - WQ_UNBOUND | WQ_NON_REENTRANT, - 1); + dev_priv->wq = alloc_ordered_workqueue("i915", 0); if (dev_priv->wq == NULL) { DRM_ERROR("Failed to create our workqueue.\n"); ret = -ENOMEM;
[PATCH 2/4] ACPI: export symbol acpi_get_table_with_size
2012/8/21 Alex Deucher : > Any objections from the ACPI folks to this patch going into 3.6 and stable? > hi Alex: I saw the patch from Feng Tang. http://marc.info/?l=linux-acpi=134380363332502=2 which is trying to replace acpi_get_table_with_size() with acpi_get_table(). Since the size can be get via struct acpi_table_header->length, acpi_get_table_with_size() is redundant and it will be removed. > Alex > > On Mon, Aug 20, 2012 at 11:19 AM, wrote: >> From: Alex Deucher >> >> We need it in the radeon drm module to fetch >> and verify the vbios image on UEFI systems. >> >> Signed-off-by: Alex Deucher >> Cc: stable at vger.kernel.org >> --- >> drivers/acpi/acpica/tbxface.c |1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c >> index ea4c6d5..29e51bc 100644 >> --- a/drivers/acpi/acpica/tbxface.c >> +++ b/drivers/acpi/acpica/tbxface.c >> @@ -387,6 +387,7 @@ acpi_get_table_with_size(char *signature, >> >> return (AE_NOT_FOUND); >> } >> +ACPI_EXPORT_SYMBOL(acpi_get_table_with_size) >> >> acpi_status >> acpi_get_table(char *signature, >> -- >> 1.7.7.5 >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best regards Tianyu Lan
[RFC patch 4/4] Re: dma-buf-mgr: multiple dma-buf synchronization (v3)
On 08/22/2012 03:32 PM, Maarten Lankhorst wrote: > Hey, > > Op 22-08-12 14:52, Thomas Hellstrom schreef: >> Hi, Maarten, >> please see some comments inline. >> >> On 08/22/2012 01:50 PM, Maarten Lankhorst wrote: >>> Hey Dan, >>> >>> Op 16-08-12 01:12, Daniel Vetter schreef: Hi Maarten, Ok, here comes the promised review (finally!), but it's rather a high-level thingy. I've mostly thought about how we could create a neat api with the following points. For a bit of clarity, I've grouped the different considerations a bit. >>> Thanks, I have significantly reworked the api based on your comments. >>> >>> Documentation is currently lacking, and will get updated again for the >>> final version. >>> >>> Full patch series also includes some ttm changes to make use of >>> dma-reservation, >>> with the intention of moving out fencing from ttm too, but that requires >>> more work. >>> >>> For the full series see: >>> http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip >>> >>> My plan is to add a pointer for dma_reservation to a dma-buf, >>> so all users of dma-reservation can perform reservations across >>> multiple devices as well. Since the default for ttm likely will >>> mean only a few buffers are shared I didn't want to complicate >>> the abi for ttm much further so only added a pointer that can be >>> null to use ttm's reservation_object structure. >>> >>> The major difference with ttm is that each reservation object >>> gets its own lock for fencing and reservations, but they can >>> be merged: >> TTM previously had a lock on each buffer object which protected sync_obj and >> sync_obj_arg, however >> when fencing multiple buffers, say 100 buffers or so in a single command >> submission, it meant 100 >> locks / unlocks that weren't really necessary, since just updating the >> sync_obj and sync_obj_arg members >> is a pretty quick operation, whereas locking may be a pretty slow operation, >> so those locks were removed >> for efficiency. > Speaking of which, mind if I kill sync_obj_arg? Only user is again vmwgfx and > it always seems to pass the same > for flags, namely DRM_VMW_FENCE_FLAG_EXEC. I guess so, although I've always thought it to be a great idea :), but nobody really understands or care what it's for. Which is a single fence might have multiple definitions of signaled, depending on the user: Consider an awkward GPU with a single command stream that feeds multiple engines. The command parser signals when it has parsed the commands, the 2D engine signals when it is done with the 2D commands it has been fed, and the 3D engine signals when the 3D engine is done, and finally the flush engine signals when all rendered data is flushed. Depending on which engines touch a buffer, each buffer may have a different view on when the attached fence is signaled. But anyway. No in-tree driver is using it, (the old unichrome driver did), and I guess the same functionality can be implemented with multiple fences attached to a single buffer, so feel free to get rid of it. >> The reason a single lock (the lru lock) is used to protect reservation is >> that a TTM object that is being reserved >> *atomically* needs to be taken off LRU lists, since processes performing LRU >> eviction don't take a ticket >> when evicting, and may thus cause deadlocks; It might be possible to fix >> this within TTM by requiring a ticket >> for all reservation, but then that ticket needs to be passed down the call >> chain for all functions that may perform >> a reservation. It would perhaps be simpler (but perhaps not so fair) to use >> the current thread info pointer as a ticket >> sequence number. > Yeah, that's why the ttm patch for ttm_bo_reserve_locked always calls > dma_object_reserve with no_wait set to true. :) > It does its own EBUSY handling for the no_wait case, so there should be no > functional changes. I need to look a bit deeper into the TTM patches, but as long as nothing breaks I've nothing against it using dma reservation objects. OTOH, it might be worthwhile thinking about the 'dma' prefix, since the reservation objects may find use elsewhere as well, for example for vmwgfx resources, that really have little to do with dma-buffers or buffers at all. > > I've been toying with the idea of always requiring a sequence number, I just > didn't in the current patch yet > since it would mean converting every driver, so for a preliminary patch based > on a unmerged api it was > not worth the time. > >>> spin_lock(obj->resv) >>> __dma_object_reserve() >>> grab a ref to all obj->fences >>> spin_unlock(obj->resv) >>> >>> spin_lock(obj->resv) >>> assign new fence to obj->fences >>> __dma_object_unreserve() >>> spin_unlock(obj->resv) >>> >>> There's only one thing about fences I haven't been able to map >>> yet properly. vmwgfx has sync_obj_flush, but as far as I can >>> tell it has not much to do with sync objects, but is rather a >>> generic 'flush before
[git pull] drm fixes + one fbcon one
On Wed, Aug 22, 2012 at 2:06 PM, Dave Airlie wrote: > > Hi Linus, > > Intel: edid fixes, power consumption fix, s/r fix, haswell fix > radeon: BIOS loading fixes for UEFI and Thunderbolt machines, better MSAA > validation, lockup timeout fixes, modesetting fixes > one udl dpms fix, > one vmwgfx fix, > couple of trivial core changes > > There is an export added to ACPI as part of the radeon bios fixes, > > I've also included the fbcon flashing cursor vs deinit race fix, that > seems the simplest place to start, so that distros can pick it up easier. Me notices now you've already pulled the fbcon fix, let me know if you want me to drop my one, or just pull in the commit above it in my tree, 27fc4f1c0be917b1e5cef934783f9b09e28e92ea also now a branch in the same tree called drm-fixes-no-fbcon. Dave.
[RFC patch 4/4] Re: dma-buf-mgr: multiple dma-buf synchronization (v3)
Hey, Op 22-08-12 14:52, Thomas Hellstrom schreef: > Hi, Maarten, > please see some comments inline. > > On 08/22/2012 01:50 PM, Maarten Lankhorst wrote: >> Hey Dan, >> >> Op 16-08-12 01:12, Daniel Vetter schreef: >>> Hi Maarten, >>> >>> Ok, here comes the promised review (finally!), but it's rather a >>> high-level thingy. I've mostly thought about how we could create a neat >>> api with the following points. For a bit of clarity, I've grouped the >>> different considerations a bit. >>> >> Thanks, I have significantly reworked the api based on your comments. >> >> Documentation is currently lacking, and will get updated again for the final >> version. >> >> Full patch series also includes some ttm changes to make use of >> dma-reservation, >> with the intention of moving out fencing from ttm too, but that requires >> more work. >> >> For the full series see: >> http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip >> >> My plan is to add a pointer for dma_reservation to a dma-buf, >> so all users of dma-reservation can perform reservations across >> multiple devices as well. Since the default for ttm likely will >> mean only a few buffers are shared I didn't want to complicate >> the abi for ttm much further so only added a pointer that can be >> null to use ttm's reservation_object structure. >> >> The major difference with ttm is that each reservation object >> gets its own lock for fencing and reservations, but they can >> be merged: > > TTM previously had a lock on each buffer object which protected sync_obj and > sync_obj_arg, however > when fencing multiple buffers, say 100 buffers or so in a single command > submission, it meant 100 > locks / unlocks that weren't really necessary, since just updating the > sync_obj and sync_obj_arg members > is a pretty quick operation, whereas locking may be a pretty slow operation, > so those locks were removed > for efficiency. Speaking of which, mind if I kill sync_obj_arg? Only user is again vmwgfx and it always seems to pass the same for flags, namely DRM_VMW_FENCE_FLAG_EXEC. > The reason a single lock (the lru lock) is used to protect reservation is > that a TTM object that is being reserved > *atomically* needs to be taken off LRU lists, since processes performing LRU > eviction don't take a ticket > when evicting, and may thus cause deadlocks; It might be possible to fix this > within TTM by requiring a ticket > for all reservation, but then that ticket needs to be passed down the call > chain for all functions that may perform > a reservation. It would perhaps be simpler (but perhaps not so fair) to use > the current thread info pointer as a ticket > sequence number. Yeah, that's why the ttm patch for ttm_bo_reserve_locked always calls dma_object_reserve with no_wait set to true. :) It does its own EBUSY handling for the no_wait case, so there should be no functional changes. I've been toying with the idea of always requiring a sequence number, I just didn't in the current patch yet since it would mean converting every driver, so for a preliminary patch based on a unmerged api it was not worth the time. >> spin_lock(obj->resv) >> __dma_object_reserve() >> grab a ref to all obj->fences >> spin_unlock(obj->resv) >> >> spin_lock(obj->resv) >> assign new fence to obj->fences >> __dma_object_unreserve() >> spin_unlock(obj->resv) >> >> There's only one thing about fences I haven't been able to map >> yet properly. vmwgfx has sync_obj_flush, but as far as I can >> tell it has not much to do with sync objects, but is rather a >> generic 'flush before release'. Maybe one of the vmwgfx devs >> could confirm whether that call is really needed there? And if >> so, if there could be some other way do that, because it seems >> to be the ttm_bo_wait call before that would be enough, if not >> it might help more to move the flush to some other call. > > The fence flush should be interpreted as an operation for fencing mechanisms > that aren't otherwise required to > signal in finite time, and where the time from flush to signal might be > substantial. TTM is then supposed to > issue a fence flush when it knows ahead of time that it will soon perform a > periodical poll for a buffer to be > idle, but not block waiting for the buffer to be idle. The delayed buffer > delete mechanism is, I think, the only user > currently. > For hardware that always signal fences immediately, the flush mechanism is > not needed. So if I understand it correctly it is the same as I'm doing in fences with dma_fence::enable_sw_signals? Great, I don't need to add another op then. Although it looks like I should export a function to manually enable it for those cases. :) >> >> + >> +int >> +__dma_object_reserve(struct dma_reservation_object *obj, bool intr, >> + bool no_wait, dma_reservation_ticket_t *ticket) >> +{ >> +int ret; >> +u64 sequence = ticket ? ticket->seqno : 0; >> + >> +while (unlikely(atomic_cmpxchg(>reserved, 0, 1) != 0))
[PATCH] drm/exynos: Add dependency for G2D in Kconfig
Applied, Thanks. 2012/8/14 Sachin Kamat : > Select Exynos DRM based G2D only if non-DRM based Exynos G2D driver > is not selected. > > Signed-off-by: Sachin Kamat > --- > drivers/gpu/drm/exynos/Kconfig |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig > index 7f50967..59a26e5 100644 > --- a/drivers/gpu/drm/exynos/Kconfig > +++ b/drivers/gpu/drm/exynos/Kconfig > @@ -36,6 +36,6 @@ config DRM_EXYNOS_VIDI > > config DRM_EXYNOS_G2D > bool "Exynos DRM G2D" > - depends on DRM_EXYNOS > + depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_G2D > help > Choose this option if you want to use Exynos G2D for DRM. > -- > 1.7.4.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC patch 4/4] Re: dma-buf-mgr: multiple dma-buf synchronization (v3)
Hi, Maarten, please see some comments inline. On 08/22/2012 01:50 PM, Maarten Lankhorst wrote: > Hey Dan, > > Op 16-08-12 01:12, Daniel Vetter schreef: >> Hi Maarten, >> >> Ok, here comes the promised review (finally!), but it's rather a >> high-level thingy. I've mostly thought about how we could create a neat >> api with the following points. For a bit of clarity, I've grouped the >> different considerations a bit. >> > Thanks, I have significantly reworked the api based on your comments. > > Documentation is currently lacking, and will get updated again for the final > version. > > Full patch series also includes some ttm changes to make use of > dma-reservation, > with the intention of moving out fencing from ttm too, but that requires more > work. > > For the full series see: > http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip > > My plan is to add a pointer for dma_reservation to a dma-buf, > so all users of dma-reservation can perform reservations across > multiple devices as well. Since the default for ttm likely will > mean only a few buffers are shared I didn't want to complicate > the abi for ttm much further so only added a pointer that can be > null to use ttm's reservation_object structure. > > The major difference with ttm is that each reservation object > gets its own lock for fencing and reservations, but they can > be merged: TTM previously had a lock on each buffer object which protected sync_obj and sync_obj_arg, however when fencing multiple buffers, say 100 buffers or so in a single command submission, it meant 100 locks / unlocks that weren't really necessary, since just updating the sync_obj and sync_obj_arg members is a pretty quick operation, whereas locking may be a pretty slow operation, so those locks were removed for efficiency. The reason a single lock (the lru lock) is used to protect reservation is that a TTM object that is being reserved *atomically* needs to be taken off LRU lists, since processes performing LRU eviction don't take a ticket when evicting, and may thus cause deadlocks; It might be possible to fix this within TTM by requiring a ticket for all reservation, but then that ticket needs to be passed down the call chain for all functions that may perform a reservation. It would perhaps be simpler (but perhaps not so fair) to use the current thread info pointer as a ticket sequence number. > spin_lock(obj->resv) > __dma_object_reserve() > grab a ref to all obj->fences > spin_unlock(obj->resv) > > spin_lock(obj->resv) > assign new fence to obj->fences > __dma_object_unreserve() > spin_unlock(obj->resv) > > There's only one thing about fences I haven't been able to map > yet properly. vmwgfx has sync_obj_flush, but as far as I can > tell it has not much to do with sync objects, but is rather a > generic 'flush before release'. Maybe one of the vmwgfx devs > could confirm whether that call is really needed there? And if > so, if there could be some other way do that, because it seems > to be the ttm_bo_wait call before that would be enough, if not > it might help more to move the flush to some other call. The fence flush should be interpreted as an operation for fencing mechanisms that aren't otherwise required to signal in finite time, and where the time from flush to signal might be substantial. TTM is then supposed to issue a fence flush when it knows ahead of time that it will soon perform a periodical poll for a buffer to be idle, but not block waiting for the buffer to be idle. The delayed buffer delete mechanism is, I think, the only user currently. For hardware that always signal fences immediately, the flush mechanism is not needed. > > PS: For ttm devs some of the code may look familiar, I don't know > if the kernel accepts I-told-you-so tag or not, but if it does > you might want to add them now. :-) > > PPS: I'm aware that I still need to add a signaled op to fences > > diff --git a/Documentation/DocBook/device-drivers.tmpl > b/Documentation/DocBook/device-drivers.tmpl > index 030f705..7da9637 100644 > --- a/Documentation/DocBook/device-drivers.tmpl > +++ b/Documentation/DocBook/device-drivers.tmpl > @@ -129,6 +129,8 @@ X!Edrivers/base/interface.c > !Edrivers/base/dma-fence.c > !Iinclude/linux/dma-fence.h > !Iinclude/linux/dma-seqno-fence.h > +!Edrivers/base/dma-reservation.c > +!Iinclude/linux/dma-reservation.h > !Edrivers/base/dma-coherent.c > !Edrivers/base/dma-mapping.c > > diff --git a/drivers/base/Makefile b/drivers/base/Makefile > index 6e9f217..b26e639 100644 > --- a/drivers/base/Makefile > +++ b/drivers/base/Makefile > @@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o > obj-y += power/ > obj-$(CONFIG_HAS_DMA) += dma-mapping.o > obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o > -obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o > +obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o dma-reservation.o > obj-$(CONFIG_ISA) += isa.o >
[PATCHv8 01/26] v4l: Add DMABUF as a memory type
On Wed August 22 2012 14:09:18 Tomasz Stanislawski wrote: > Hi Hans, > Thank your for the review. > Please refer to the comments below. > > On 08/22/2012 12:27 PM, Hans Verkuil wrote: > > On Tue August 14 2012 17:34:31 Tomasz Stanislawski wrote: > >> From: Sumit Semwal > >> > >> Adds DMABUF memory type to v4l framework. Also adds the related file > >> descriptor in v4l2_plane and v4l2_buffer. > >> > >> Signed-off-by: Tomasz Stanislawski > >>[original work in the PoC for buffer sharing] > >> Signed-off-by: Sumit Semwal > >> Signed-off-by: Sumit Semwal > >> Acked-by: Laurent Pinchart > >> --- > >> drivers/media/video/v4l2-compat-ioctl32.c | 18 ++ > >> drivers/media/video/v4l2-ioctl.c |1 + > >> include/linux/videodev2.h |7 +++ > >> 3 files changed, 26 insertions(+) > >> > >> diff --git a/drivers/media/video/v4l2-compat-ioctl32.c > >> b/drivers/media/video/v4l2-compat-ioctl32.c > >> index 9ebd5c5..a2e0549 100644 > >> --- a/drivers/media/video/v4l2-compat-ioctl32.c > >> +++ b/drivers/media/video/v4l2-compat-ioctl32.c > >> @@ -304,6 +304,7 @@ struct v4l2_plane32 { > >>union { > >>__u32 mem_offset; > >>compat_long_t userptr; > >> + __u32 fd; > > > > Shouldn't this be int? > > > > Notice that this field should be consistent with fd field used in > 'struct v4l2_exportbuffer'. Therefore I prefer to use fixed-size types. > One could use __s32 here but notice that file descriptors are defined > as small, nonnegative integers according to POSIX spec. The type __u32 > suits well for this purpose. The negative values returned by open > syscall are used only to indicate failures. > > On the other hand, using __s32 may help to avoid compiler warning while > building userspace apps due to 'signed-vs-unsigned comparisons'. > > However, I do not have any strong opinion about 'int vs __u32' issue :). > Do you think that using __s32 for both QUERYBUF and EXPBUF is a good > compromise? The type of a fd is highly variable in the kernel. Just try this for fun: grep [^a-z]fd[^a-z] -rsI include/linux/ 'int' or 'unsigned int' are by far the most common types. But in structs I did see a few __s32 types, so I think __s32 is a decent type to use. Just make sure it is __s32 everywhere. Right now __u32 and int are both used. Regards, Hans > > >>} m; > >>__u32 data_offset; > >>__u32 reserved[11]; > >> @@ -325,6 +326,7 @@ struct v4l2_buffer32 { > >>__u32 offset; > >>compat_long_t userptr; > >>compat_caddr_t planes; > >> + __u32 fd; > > > > Ditto. > > > >>} m; > >>__u32 length; > >>__u32 reserved2; > > > Regards, > > > > Hans > > > > Regards, > > Tomasz > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH 0/2] console_lock debug improvements
On Wed, 22 Aug 2012 00:34:30 +0200 Daniel Vetter wrote: > Hi all, > > After Dave Airlie blew through a few days to track down a deadlock at boot-up > when handing over from the firmware fb to the kms/drm framebuffer driver (1), > I've > figured that lockdep /should/ have caught this. > > And indeed, by adding proper annotations to the console_lock it complains > about > the potential deadlock when exercising the entire driver life-cycle of just > one > fb driver (i.e. not even a handover required). While at it, I've replaced the > existing in_interrupt check with the more paranoid might_sleep. > > Comments, flames and review highly welcome. This will be an absolute godsend for DRI debugging. Definitely wants to go in. Alan
[PATCH 4/4] drm: remove the raw_edid field from struct drm_display_info
Acked-by: Inki Dae 2012/8/15 Jani Nikula : > Neither the drm core nor any of the drivers really need the raw_edid field > of struct drm_display_info for anything. Instead of being useful, it > creates confusion about who is responsible for freeing the memory it points > to and setting the field to NULL afterwards, leading to memory leaks and > dangling pointers. > > Remove the raw_edid field, and fix drivers as necessary. > > Reported-by: Russell King > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/drm_edid.c|3 --- > drivers/gpu/drm/drm_edid_load.c | 23 +-- > drivers/gpu/drm/exynos/exynos_drm_connector.c |4 +--- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 13 - > drivers/gpu/drm/gma500/cdv_intel_hdmi.c |2 -- > drivers/gpu/drm/gma500/oaktrail_hdmi.c|1 - > drivers/gpu/drm/gma500/psb_intel_sdvo.c |3 --- > drivers/gpu/drm/i915/intel_dp.c |4 > drivers/gpu/drm/i915/intel_hdmi.c |3 --- > drivers/gpu/drm/i915/intel_modes.c|1 - > drivers/gpu/drm/i915/intel_sdvo.c |3 --- > drivers/gpu/drm/mgag200/mgag200_mode.c|1 - > drivers/gpu/drm/udl/udl_connector.c |3 --- > drivers/staging/omapdrm/omap_connector.c |5 + > include/drm/drm_crtc.h|2 -- > 15 files changed, 15 insertions(+), 56 deletions(-) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index a8743c3..bcc4725 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -399,10 +399,7 @@ struct edid *drm_get_edid(struct drm_connector > *connector, > if (drm_probe_ddc(adapter)) > edid = (struct edid *)drm_do_get_edid(connector, adapter); > > - connector->display_info.raw_edid = (char *)edid; > - > return edid; > - > } > EXPORT_SYMBOL(drm_get_edid); > > diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c > index 0303935..186832e 100644 > --- a/drivers/gpu/drm/drm_edid_load.c > +++ b/drivers/gpu/drm/drm_edid_load.c > @@ -114,8 +114,8 @@ static u8 generic_edid[GENERIC_EDIDS][128] = { > }, > }; > > -static int edid_load(struct drm_connector *connector, char *name, > -char *connector_name) > +static u8 *edid_load(struct drm_connector *connector, char *name, > + char *connector_name) > { > const struct firmware *fw; > struct platform_device *pdev; > @@ -205,7 +205,6 @@ static int edid_load(struct drm_connector *connector, > char *name, > edid = new_edid; > } > > - connector->display_info.raw_edid = edid; > DRM_INFO("Got %s EDID base block and %d extension%s from " > "\"%s\" for connector \"%s\"\n", builtin ? "built-in" : > "external", valid_extensions, valid_extensions == 1 ? "" : "s", > @@ -215,7 +214,10 @@ relfw_out: > release_firmware(fw); > > out: > - return err; > + if (err) > + return ERR_PTR(err); > + > + return edid; > } > > int drm_load_edid_firmware(struct drm_connector *connector) > @@ -223,6 +225,7 @@ int drm_load_edid_firmware(struct drm_connector > *connector) > char *connector_name = drm_get_connector_name(connector); > char *edidname = edid_firmware, *last, *colon; > int ret; > + struct edid *edid; > > if (*edidname == '\0') > return 0; > @@ -240,13 +243,13 @@ int drm_load_edid_firmware(struct drm_connector > *connector) > if (*last == '\n') > *last = '\0'; > > - ret = edid_load(connector, edidname, connector_name); > - if (ret) > + edid = (struct edid *) edid_load(connector, edidname, connector_name); > + if (IS_ERR_OR_NULL(edid)) > return 0; > > - drm_mode_connector_update_edid_property(connector, > - (struct edid *) connector->display_info.raw_edid); > + drm_mode_connector_update_edid_property(connector, edid); > + ret = drm_add_edid_modes(connector, edid); > + kfree(edid); > > - return drm_add_edid_modes(connector, (struct edid *) > - connector->display_info.raw_edid); > + return ret; > } > diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c > b/drivers/gpu/drm/exynos/exynos_drm_connector.c > index d956819..9dce3b9 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c > @@ -147,9 +147,7 @@ static int exynos_drm_connector_get_modes(struct > drm_connector *connector) > > drm_mode_connector_update_edid_property(connector, edid); > count = drm_add_edid_modes(connector, edid); > - > - kfree(connector->display_info.raw_edid); > - connector->display_info.raw_edid = edid; > + kfree(edid); >
[PATCHv8 01/26] v4l: Add DMABUF as a memory type
Hi Hans, Thank your for the review. Please refer to the comments below. On 08/22/2012 12:27 PM, Hans Verkuil wrote: > On Tue August 14 2012 17:34:31 Tomasz Stanislawski wrote: >> From: Sumit Semwal >> >> Adds DMABUF memory type to v4l framework. Also adds the related file >> descriptor in v4l2_plane and v4l2_buffer. >> >> Signed-off-by: Tomasz Stanislawski >>[original work in the PoC for buffer sharing] >> Signed-off-by: Sumit Semwal >> Signed-off-by: Sumit Semwal >> Acked-by: Laurent Pinchart >> --- >> drivers/media/video/v4l2-compat-ioctl32.c | 18 ++ >> drivers/media/video/v4l2-ioctl.c |1 + >> include/linux/videodev2.h |7 +++ >> 3 files changed, 26 insertions(+) >> >> diff --git a/drivers/media/video/v4l2-compat-ioctl32.c >> b/drivers/media/video/v4l2-compat-ioctl32.c >> index 9ebd5c5..a2e0549 100644 >> --- a/drivers/media/video/v4l2-compat-ioctl32.c >> +++ b/drivers/media/video/v4l2-compat-ioctl32.c >> @@ -304,6 +304,7 @@ struct v4l2_plane32 { >> union { >> __u32 mem_offset; >> compat_long_t userptr; >> +__u32 fd; > > Shouldn't this be int? > Notice that this field should be consistent with fd field used in 'struct v4l2_exportbuffer'. Therefore I prefer to use fixed-size types. One could use __s32 here but notice that file descriptors are defined as small, nonnegative integers according to POSIX spec. The type __u32 suits well for this purpose. The negative values returned by open syscall are used only to indicate failures. On the other hand, using __s32 may help to avoid compiler warning while building userspace apps due to 'signed-vs-unsigned comparisons'. However, I do not have any strong opinion about 'int vs __u32' issue :). Do you think that using __s32 for both QUERYBUF and EXPBUF is a good compromise? >> } m; >> __u32 data_offset; >> __u32 reserved[11]; >> @@ -325,6 +326,7 @@ struct v4l2_buffer32 { >> __u32 offset; >> compat_long_t userptr; >> compat_caddr_t planes; >> +__u32 fd; > > Ditto. > >> } m; >> __u32 length; >> __u32 reserved2; > Regards, > > Hans > Regards, Tomasz
[PATCH] fbcon: fix race condition between console lock and cursor timer
On Tue, Aug 21, 2012 at 7:15 PM, Alan Cox wrote: >> So after much tracing with direct netconsole writes (printks >> under console_lock not so useful), I think I found the race. > > Direct netconsole write would be a useful patch to have mainline I think > 8) Well I used a one line wrapper around the netconsole write_msg, which just passed NULL as the first arg, then sprinkled netconsole_write_msg around the place, not having printf stuff could be an annoyance for some people, for this it didn't matter. Peter I wish I had a serial port to work with :-) > > Not really the proper fix but its clear and is probably the best thing to > go in initially with a cc: stable. Can you at least stick a large > > + /* FIXME: we should sort out the unbind locking instead */ Done, and cc stable, I'll send this to Linus via my tree as its fairly urgent from my pov. Dave. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC patch 4/4] Re: dma-buf-mgr: multiple dma-buf synchronization (v3)
Hey Dan, Op 16-08-12 01:12, Daniel Vetter schreef: > Hi Maarten, > > Ok, here comes the promised review (finally!), but it's rather a > high-level thingy. I've mostly thought about how we could create a neat > api with the following points. For a bit of clarity, I've grouped the > different considerations a bit. > Thanks, I have significantly reworked the api based on your comments. Documentation is currently lacking, and will get updated again for the final version. Full patch series also includes some ttm changes to make use of dma-reservation, with the intention of moving out fencing from ttm too, but that requires more work. For the full series see: http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip My plan is to add a pointer for dma_reservation to a dma-buf, so all users of dma-reservation can perform reservations across multiple devices as well. Since the default for ttm likely will mean only a few buffers are shared I didn't want to complicate the abi for ttm much further so only added a pointer that can be null to use ttm's reservation_object structure. The major difference with ttm is that each reservation object gets its own lock for fencing and reservations, but they can be merged: spin_lock(obj->resv) __dma_object_reserve() grab a ref to all obj->fences spin_unlock(obj->resv) spin_lock(obj->resv) assign new fence to obj->fences __dma_object_unreserve() spin_unlock(obj->resv) There's only one thing about fences I haven't been able to map yet properly. vmwgfx has sync_obj_flush, but as far as I can tell it has not much to do with sync objects, but is rather a generic 'flush before release'. Maybe one of the vmwgfx devs could confirm whether that call is really needed there? And if so, if there could be some other way do that, because it seems to be the ttm_bo_wait call before that would be enough, if not it might help more to move the flush to some other call. PS: For ttm devs some of the code may look familiar, I don't know if the kernel accepts I-told-you-so tag or not, but if it does you might want to add them now. :-) PPS: I'm aware that I still need to add a signaled op to fences diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 030f705..7da9637 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -129,6 +129,8 @@ X!Edrivers/base/interface.c !Edrivers/base/dma-fence.c !Iinclude/linux/dma-fence.h !Iinclude/linux/dma-seqno-fence.h +!Edrivers/base/dma-reservation.c +!Iinclude/linux/dma-reservation.h !Edrivers/base/dma-coherent.c !Edrivers/base/dma-mapping.c diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 6e9f217..b26e639 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o obj-y += power/ obj-$(CONFIG_HAS_DMA) += dma-mapping.o obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o -obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o +obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o dma-reservation.o obj-$(CONFIG_ISA) += isa.o obj-$(CONFIG_FW_LOADER)+= firmware_class.o obj-$(CONFIG_NUMA) += node.o diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 24e88fe..3c84ead 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -25,8 +25,10 @@ #include #include #include +#include #include #include +#include static inline int is_dma_buf_file(struct file *); @@ -40,6 +42,9 @@ static int dma_buf_release(struct inode *inode, struct file *file) dmabuf = file->private_data; dmabuf->ops->release(dmabuf); + + if (dmabuf->resv == (struct dma_reservation_object*)[1]) + dma_reservation_object_fini(dmabuf->resv); kfree(dmabuf); return 0; } @@ -94,6 +99,8 @@ struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops, { struct dma_buf *dmabuf; struct file *file; + size_t alloc_size = sizeof(struct dma_buf); + alloc_size += sizeof(struct dma_reservation_object); if (WARN_ON(!priv || !ops || !ops->map_dma_buf @@ -105,13 +112,15 @@ struct dma_buf *dma_buf_export(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); dmabuf->priv = priv; dmabuf->ops = ops; dmabuf->size = size; + dmabuf->resv = (struct dma_reservation_object*)[1]; + dma_reservation_object_init(dmabuf->resv); file = anon_inode_getfile("dmabuf", _buf_fops, dmabuf, flags); diff --git a/drivers/base/dma-reservation.c b/drivers/base/dma-reservation.c new file mode 100644 index 000..e7cf4fa --- /dev/null +++
[PATCHv8 13/26] v4l: vivi: support for dmabuf importing
On Wed August 22 2012 12:56:30 Hans Verkuil wrote: > On Tue August 14 2012 17:34:43 Tomasz Stanislawski wrote: > > This patch enhances VIVI driver with a support for importing a buffer > > from DMABUF file descriptors. > > Thanks for adding DMABUF support to vivi. > > What would be great is if DMABUF support is also added to mem2mem_testdev. > It would make an excellent test case to take the vivi output, pass it > through mem2mem_testdev, and finally output the image using the gpu, all > using dmabuf. > > It's also very useful for application developers to test dmabuf support > without requiring special hardware (other than a dmabuf-enabled gpu > driver). Adding VIDIOC_EXPBUF support to vivi and mem2mem_testdev would be welcome as well for the same reasons. Regards, Hans > > Regards, > > Hans > > > > > Signed-off-by: Tomasz Stanislawski > > Signed-off-by: Kyungmin Park > > --- > > drivers/media/video/Kconfig |1 + > > drivers/media/video/vivi.c |2 +- > > 2 files changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig > > index 966954d..8fa81be 100644 > > --- a/drivers/media/video/Kconfig > > +++ b/drivers/media/video/Kconfig > > @@ -653,6 +653,7 @@ config VIDEO_VIVI > > depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE > > select FONT_8x16 > > select VIDEOBUF2_VMALLOC > > + select DMA_SHARED_BUFFER > > default n > > ---help--- > > Enables a virtual video driver. This device shows a color bar > > diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c > > index a6351c4..37d8fd4 100644 > > --- a/drivers/media/video/vivi.c > > +++ b/drivers/media/video/vivi.c > > @@ -1308,7 +1308,7 @@ static int __init vivi_create_instance(int inst) > > q = >vb_vidq; > > memset(q, 0, sizeof(dev->vb_vidq)); > > q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE; > > - q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_READ; > > + q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ; > > q->drv_priv = dev; > > q->buf_struct_size = sizeof(struct vivi_buffer); > > q->ops = _video_qops; > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCHv8 23/26] v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING
On Tue August 14 2012 17:34:53 Tomasz Stanislawski wrote: > From: Marek Szyprowski Please add some more information in the commit message. I've no idea what's going on here or why :-) Regards, Hans > Signed-off-by: Marek Szyprowski > --- > drivers/media/video/atmel-isi.c |2 +- > drivers/media/video/blackfin/bfin_capture.c |2 +- > drivers/media/video/marvell-ccic/mcam-core.c |3 ++- > drivers/media/video/mx2_camera.c |2 +- > drivers/media/video/mx2_emmaprp.c|2 +- > drivers/media/video/mx3_camera.c |2 +- > drivers/media/video/s5p-fimc/fimc-core.c |2 +- > drivers/media/video/s5p-fimc/fimc-lite.c |2 +- > drivers/media/video/s5p-g2d/g2d.c|2 +- > drivers/media/video/s5p-jpeg/jpeg-core.c |2 +- > drivers/media/video/s5p-mfc/s5p_mfc.c|5 ++-- > drivers/media/video/s5p-tv/mixer_video.c |2 +- > drivers/media/video/sh_mobile_ceu_camera.c |2 +- > drivers/media/video/videobuf2-dma-contig.c | 33 > +++--- > drivers/staging/media/dt3155v4l/dt3155v4l.c |2 +- > include/media/videobuf2-dma-contig.h |4 +++- > 16 files changed, 44 insertions(+), 25 deletions(-) > > diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c > index 6274a91..9fb5283 100644 > --- a/drivers/media/video/atmel-isi.c > +++ b/drivers/media/video/atmel-isi.c > @@ -1000,7 +1000,7 @@ static int __devinit atmel_isi_probe(struct > platform_device *pdev) > list_add(>dma_desc[i].list, >dma_desc_head); > } > > - isi->alloc_ctx = vb2_dma_contig_init_ctx(>dev); > + isi->alloc_ctx = vb2_dma_contig_init_ctx(>dev, 0); > if (IS_ERR(isi->alloc_ctx)) { > ret = PTR_ERR(isi->alloc_ctx); > goto err_alloc_ctx; > diff --git a/drivers/media/video/blackfin/bfin_capture.c > b/drivers/media/video/blackfin/bfin_capture.c > index 1677623..7e90b65 100644 > --- a/drivers/media/video/blackfin/bfin_capture.c > +++ b/drivers/media/video/blackfin/bfin_capture.c > @@ -893,7 +893,7 @@ static int __devinit bcap_probe(struct platform_device > *pdev) > } > bcap_dev->ppi->priv = bcap_dev; > > - bcap_dev->alloc_ctx = vb2_dma_contig_init_ctx(>dev); > + bcap_dev->alloc_ctx = vb2_dma_contig_init_ctx(>dev, 0); > if (IS_ERR(bcap_dev->alloc_ctx)) { > ret = PTR_ERR(bcap_dev->alloc_ctx); > goto err_free_ppi; > diff --git a/drivers/media/video/marvell-ccic/mcam-core.c > b/drivers/media/video/marvell-ccic/mcam-core.c > index ce2b7b4..10d4db5 100644 > --- a/drivers/media/video/marvell-ccic/mcam-core.c > +++ b/drivers/media/video/marvell-ccic/mcam-core.c > @@ -,7 +,8 @@ static int mcam_setup_vb2(struct mcam_camera *cam) > #ifdef MCAM_MODE_DMA_CONTIG > vq->ops = _vb2_ops; > vq->mem_ops = _dma_contig_memops; > - cam->vb_alloc_ctx = vb2_dma_contig_init_ctx(cam->dev); > + cam->vb_alloc_ctx = vb2_dma_contig_init_ctx(cam->dev, > + VB2_CREATE_VADDR); > vq->io_modes = VB2_MMAP | VB2_USERPTR; > cam->dma_setup = mcam_ctlr_dma_contig; > cam->frame_complete = mcam_dma_contig_done; > diff --git a/drivers/media/video/mx2_camera.c > b/drivers/media/video/mx2_camera.c > index 637bde8..5c30302 100644 > --- a/drivers/media/video/mx2_camera.c > +++ b/drivers/media/video/mx2_camera.c > @@ -1766,7 +1766,7 @@ static int __devinit mx2_camera_probe(struct > platform_device *pdev) > if (cpu_is_mx25()) > pcdev->soc_host.capabilities = SOCAM_HOST_CAP_STRIDE; > > - pcdev->alloc_ctx = vb2_dma_contig_init_ctx(>dev); > + pcdev->alloc_ctx = vb2_dma_contig_init_ctx(>dev, 0); > if (IS_ERR(pcdev->alloc_ctx)) { > err = PTR_ERR(pcdev->alloc_ctx); > goto eallocctx; > diff --git a/drivers/media/video/mx2_emmaprp.c > b/drivers/media/video/mx2_emmaprp.c > index 2810015..23c6c42 100644 > --- a/drivers/media/video/mx2_emmaprp.c > +++ b/drivers/media/video/mx2_emmaprp.c > @@ -962,7 +962,7 @@ static int emmaprp_probe(struct platform_device *pdev) >0, MEM2MEM_NAME, pcdev) < 0) > goto rel_vdev; > > - pcdev->alloc_ctx = vb2_dma_contig_init_ctx(>dev); > + pcdev->alloc_ctx = vb2_dma_contig_init_ctx(>dev, 0); > if (IS_ERR(pcdev->alloc_ctx)) { > v4l2_err(>v4l2_dev, "Failed to alloc vb2 context\n"); > ret = PTR_ERR(pcdev->alloc_ctx); > diff --git a/drivers/media/video/mx3_camera.c > b/drivers/media/video/mx3_camera.c > index f13643d..882026f 100644 > --- a/drivers/media/video/mx3_camera.c > +++ b/drivers/media/video/mx3_camera.c > @@ -1227,7 +1227,7 @@ static int __devinit mx3_camera_probe(struct > platform_device *pdev) > soc_host->v4l2_dev.dev = >dev; > soc_host->nr= pdev->id; > > -
[PATCHv8 19/26] v4l: vb2: add buffer exporting via dmabuf
On Tue August 14 2012 17:34:49 Tomasz Stanislawski wrote: > This patch adds extension to videobuf2-core. It allow to export a mmap buffer > as a file descriptor. > > Signed-off-by: Tomasz Stanislawski > Signed-off-by: Kyungmin Park > Acked-by: Laurent Pinchart > --- > drivers/media/video/videobuf2-core.c | 67 > ++ > include/media/videobuf2-core.h |2 + > 2 files changed, 69 insertions(+) > > diff --git a/drivers/media/video/videobuf2-core.c > b/drivers/media/video/videobuf2-core.c > index aed21e4..61354ec 100644 > --- a/drivers/media/video/videobuf2-core.c > +++ b/drivers/media/video/videobuf2-core.c > @@ -1743,6 +1743,73 @@ static int __find_plane_by_offset(struct vb2_queue *q, > unsigned long off, > } > > /** > + * vb2_expbuf() - Export a buffer as a file descriptor > + * @q: videobuf2 queue > + * @eb: export buffer structure passed from userspace to > vidioc_expbuf > + * handler in driver > + * > + * The return values from this function are intended to be directly returned > + * from vidioc_expbuf handler in driver. > + */ > +int vb2_expbuf(struct vb2_queue *q, struct v4l2_exportbuffer *eb) > +{ > + struct vb2_buffer *vb = NULL; > + struct vb2_plane *vb_plane; > + unsigned int buffer, plane; > + int ret; > + struct dma_buf *dbuf; > + > + if (q->memory != V4L2_MEMORY_MMAP) { > + dprintk(1, "Queue is not currently set up for mmap\n"); > + return -EINVAL; > + } > + > + if (!q->mem_ops->get_dmabuf) { > + dprintk(1, "Queue does not support DMA buffer exporting\n"); > + return -EINVAL; > + } > + > + if (eb->flags & ~O_CLOEXEC) { > + dprintk(1, "Queue does support only O_CLOEXEC flag\n"); > + return -EINVAL; > + } > + > + /* > + * Find the plane corresponding to the offset passed by userspace. > + */ > + ret = __find_plane_by_offset(q, eb->mem_offset, , ); > + if (ret) { > + dprintk(1, "invalid offset %u\n", eb->mem_offset); > + return ret; > + } > + > + vb = q->bufs[buffer]; > + vb_plane = >planes[plane]; > + > + dbuf = call_memop(q, get_dmabuf, vb_plane->mem_priv); > + if (IS_ERR_OR_NULL(dbuf)) { > + dprintk(1, "Failed to export buffer %d, plane %d\n", > + buffer, plane); > + return -EINVAL; > + } > + > + ret = dma_buf_fd(dbuf, eb->flags); > + if (ret < 0) { > + dprintk(3, "buffer %d, plane %d failed to export (%d)\n", > + buffer, plane, ret); > + dma_buf_put(dbuf); > + return ret; > + } > + > + dprintk(3, "buffer %d, plane %d exported as %d descriptor\n", > + buffer, plane, ret); > + eb->fd = ret; > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(vb2_expbuf); > + > +/** > * vb2_mmap() - map video buffers into application address space > * @q: videobuf2 queue > * @vma: vma passed to the mmap file operation handler in the driver > diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h > index c306fec..b034424 100644 > --- a/include/media/videobuf2-core.h > +++ b/include/media/videobuf2-core.h > @@ -81,6 +81,7 @@ struct vb2_fileio_data; > struct vb2_mem_ops { > void*(*alloc)(void *alloc_ctx, unsigned long size); > void(*put)(void *buf_priv); > + struct dma_buf *(*get_dmabuf)(void *buf_priv); > > void*(*get_userptr)(void *alloc_ctx, unsigned long vaddr, > unsigned long size, int write); > @@ -363,6 +364,7 @@ int vb2_queue_init(struct vb2_queue *q); > void vb2_queue_release(struct vb2_queue *q); > > int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b); > +int vb2_expbuf(struct vb2_queue *q, struct v4l2_exportbuffer *eb); > int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b, bool nonblocking); > > int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type type); > Please add a vb2_ioctl_expbuf helper function as well! Regards, Hans
[PATCHv8 18/26] v4l: add buffer exporting via dmabuf
On Tue August 14 2012 17:34:48 Tomasz Stanislawski wrote: > This patch adds extension to V4L2 api. It allow to export a mmap buffer as > file > descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by > mmap and return a file descriptor on success. > > Signed-off-by: Tomasz Stanislawski > Signed-off-by: Kyungmin Park > --- > drivers/media/video/v4l2-compat-ioctl32.c |1 + > drivers/media/video/v4l2-dev.c|1 + > drivers/media/video/v4l2-ioctl.c | 15 +++ > include/linux/videodev2.h | 26 ++ > include/media/v4l2-ioctl.h|2 ++ > 5 files changed, 45 insertions(+) > > diff --git a/drivers/media/video/v4l2-compat-ioctl32.c > b/drivers/media/video/v4l2-compat-ioctl32.c > index a2e0549..7689c4a 100644 > --- a/drivers/media/video/v4l2-compat-ioctl32.c > +++ b/drivers/media/video/v4l2-compat-ioctl32.c > @@ -971,6 +971,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int > cmd, unsigned long arg) > case VIDIOC_S_FBUF32: > case VIDIOC_OVERLAY32: > case VIDIOC_QBUF32: > + case VIDIOC_EXPBUF: > case VIDIOC_DQBUF32: > case VIDIOC_STREAMON32: > case VIDIOC_STREAMOFF32: > diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c > index 71237f5..f6e7ea5 100644 > --- a/drivers/media/video/v4l2-dev.c > +++ b/drivers/media/video/v4l2-dev.c > @@ -607,6 +607,7 @@ static void determine_valid_ioctls(struct video_device > *vdev) > SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs); > SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf); > SET_VALID_IOCTL(ops, VIDIOC_QBUF, vidioc_qbuf); > + SET_VALID_IOCTL(ops, VIDIOC_EXPBUF, vidioc_expbuf); > SET_VALID_IOCTL(ops, VIDIOC_DQBUF, vidioc_dqbuf); > SET_VALID_IOCTL(ops, VIDIOC_OVERLAY, vidioc_overlay); > SET_VALID_IOCTL(ops, VIDIOC_G_FBUF, vidioc_g_fbuf); > diff --git a/drivers/media/video/v4l2-ioctl.c > b/drivers/media/video/v4l2-ioctl.c > index dffd3c9..c4e8c7e 100644 > --- a/drivers/media/video/v4l2-ioctl.c > +++ b/drivers/media/video/v4l2-ioctl.c > @@ -458,6 +458,14 @@ static void v4l_print_buffer(const void *arg, bool > write_only) > tc->type, tc->flags, tc->frames, *(__u32 > *)tc->userbits); > } > > +static void v4l_print_exportbuffer(const void *arg, bool write_only) > +{ > + const struct v4l2_exportbuffer *p = arg; > + > + pr_cont("fd=%d, mem_offset=%lx, flags=%lx\n", > + p->fd, (unsigned long)p->mem_offset, (unsigned long)p->flags); Why the unsigned long casts? > +} > + > static void v4l_print_create_buffers(const void *arg, bool write_only) > { > const struct v4l2_create_buffers *p = arg; > @@ -1254,6 +1262,12 @@ static int v4l_streamoff(const struct v4l2_ioctl_ops > *ops, > return ops->vidioc_streamoff(file, fh, *(unsigned int *)arg); > } > > +static int v4l_expbuf(const struct v4l2_ioctl_ops *ops, > + struct file *file, void *fh, void *arg) > +{ > + return ops->vidioc_expbuf(file, fh, arg); > +} Not needed... > + > static int v4l_g_tuner(const struct v4l2_ioctl_ops *ops, > struct file *file, void *fh, void *arg) > { > @@ -1947,6 +1961,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = { > IOCTL_INFO_STD(VIDIOC_S_FBUF, vidioc_s_fbuf, v4l_print_framebuffer, > INFO_FL_PRIO), > IOCTL_INFO_STD(VIDIOC_OVERLAY, vidioc_overlay, v4l_print_u32, > INFO_FL_PRIO), > IOCTL_INFO_FNC(VIDIOC_QBUF, v4l_qbuf, v4l_print_buffer, INFO_FL_QUEUE), > + IOCTL_INFO_FNC(VIDIOC_EXPBUF, v4l_expbuf, v4l_print_exportbuffer, > INFO_FL_CLEAR(v4l2_exportbuffer, flags)), ...use IOCTL_INFO_STD instead. > IOCTL_INFO_FNC(VIDIOC_DQBUF, v4l_dqbuf, v4l_print_buffer, > INFO_FL_QUEUE), > IOCTL_INFO_FNC(VIDIOC_STREAMON, v4l_streamon, v4l_print_buftype, > INFO_FL_PRIO | INFO_FL_QUEUE), > IOCTL_INFO_FNC(VIDIOC_STREAMOFF, v4l_streamoff, v4l_print_buftype, > INFO_FL_PRIO | INFO_FL_QUEUE), > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h > index 7f918dc..b5d058b 100644 > --- a/include/linux/videodev2.h > +++ b/include/linux/videodev2.h > @@ -688,6 +688,31 @@ struct v4l2_buffer { > #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800 > #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000 > > +/** > + * struct v4l2_exportbuffer - export of video buffer as DMABUF file > descriptor > + * > + * @fd: file descriptor associated with DMABUF (set by driver) > + * @mem_offset: buffer memory offset as returned by VIDIOC_QUERYBUF in > struct > + * v4l2_buffer::m.offset (for single-plane formats) or > + * v4l2_plane::m.offset (for multi-planar formats) > + * @flags: flags for newly created file, currently only O_CLOEXEC is > + * supported, refer to manual of open syscall for more details > + * > + * Contains data used for exporting a video
[PATCHv8 17/26] Documentation: media: description of DMABUF exporting in V4L2
On Tue August 14 2012 17:34:47 Tomasz Stanislawski wrote: > This patch adds description and usage examples for exporting > DMABUF file descriptor in V4L2. > > Signed-off-by: Tomasz Stanislawski > Signed-off-by: Kyungmin Park > CC: linux-doc at vger.kernel.org > --- > Documentation/DocBook/media/v4l/compat.xml|3 + > Documentation/DocBook/media/v4l/io.xml|3 + > Documentation/DocBook/media/v4l/v4l2.xml |1 + > Documentation/DocBook/media/v4l/vidioc-expbuf.xml | 223 > + > 4 files changed, 230 insertions(+) > create mode 100644 Documentation/DocBook/media/v4l/vidioc-expbuf.xml > > diff --git a/Documentation/DocBook/media/v4l/compat.xml > b/Documentation/DocBook/media/v4l/compat.xml > index ff45330..802c1ab 100644 > --- a/Documentation/DocBook/media/v4l/compat.xml > +++ b/Documentation/DocBook/media/v4l/compat.xml > @@ -2609,6 +2609,9 @@ ioctls. > Importing DMABUF file descriptors as a new IO method described > in . > > + > + Exporting DMABUF files using ioctl. > + > > > > diff --git a/Documentation/DocBook/media/v4l/io.xml > b/Documentation/DocBook/media/v4l/io.xml > index 98253ee..c27e59b 100644 > --- a/Documentation/DocBook/media/v4l/io.xml > +++ b/Documentation/DocBook/media/v4l/io.xml > @@ -488,6 +488,9 @@ buffer from userspace using a file descriptor previously > exported for a > different or the same device (known as the importer role), or both. This > section describes the DMABUF importer role API in V4L2. > > +Refer to DMABUF exporting for > +details about exporting a V4L2 buffers as DMABUF file descriptors. > + > Input and output devices support the streaming I/O method when the > V4L2_CAP_STREAMING flag in the > capabilities field of returned > by > diff --git a/Documentation/DocBook/media/v4l/v4l2.xml > b/Documentation/DocBook/media/v4l/v4l2.xml > index 0292ed1..874c085 100644 > --- a/Documentation/DocBook/media/v4l/v4l2.xml > +++ b/Documentation/DocBook/media/v4l/v4l2.xml > @@ -568,6 +568,7 @@ and discussions on the V4L mailing list. > > > > + This list is sorted alphabetically, so sub-expbuf should go after sub-enumstd. > > > > diff --git a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml > b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml > new file mode 100644 > index 000..30ebf67 > --- /dev/null > +++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml > @@ -0,0 +1,223 @@ > + > + > + > +ioctl VIDIOC_EXPBUF > + > + > + > + > +VIDIOC_EXPBUF > +Export a buffer as a DMABUF file descriptor. > + > + > + > + > + > + int ioctl > + int fd > + int request > + struct v4l2_exportbuffer > *argp > + > + > + > + > + > +Arguments > + > + > + > + fd > + > + > + > + > + > + request > + > + VIDIOC_EXPBUF > + > + > + > + argp > + > + > + > + > + > + > + > + > +Description > + > + > + Experimental > + This is an experimental > + interface and may change in the future. > + > + > +This ioctl is an extension to the memory > +mapping I/O method therefore it is available only for > +V4L2_MEMORY_MMAP buffers. It can be used to export a > +buffer as DMABUF file at any time after buffers have been allocated with the > + ioctl. > + > +Prior to exporting an application calls +linkend="vidioc-querybuf">VIDIOC_QUERYBUF to obtain memory offsets. > When > +using the multi-planar API every plane has > +own offset. > + > +To export a buffer, the application fills . The > + mem_offset field is set to the offset obtained > +from VIDIOC_QUERYBUF . Additional flags may be posted > in > +the flags field. Refer to manual for open > syscall Better IMHO: 'Refer to the manual for open()' > +for details. Currently only O_CLOEXEC is guaranteed to be supported. All > other > +fields must be set to zero. In a case of multi-planar API, every plane is > +exported separately using multiple VIDIOC_EXPBUF > +calls. > + > + After calling VIDIOC_EXPBUF the fd > + field will be set by a driver. This is a DMABUF file > +descriptor. The application may pass it to other API. Refer to +linkend="dmabuf">DMABUF importing for details about importing DMABUF > +files into V4L2 nodes. A developer is encouraged to close a DMABUF file when > it > +is no longer used. Some explanation of why this is recommended would be useful. > + > + > + > + > + Examples > + > + > + Exporting a buffer. > + > +int buffer_export(int v4lfd, bt, int index, int *dmafd) > +{ > + buf; > + expbuf; > + > + memset(buf, 0, sizeof buf); > + buf.type = bt; > + buf.memory = V4L2_MEMORY_MMAP; > + buf.index = index; > + > + if (ioctl (v4lfd, , buf) == -1) { > + perror ("VIDIOC_QUERYBUF"); > +
[PATCH 3/4] drm/exynos: fix EDID memory leak in HDMI
2012/8/15 Jani Nikula : > The EDID returned by drm_get_edid() was never freed. > > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/exynos/exynos_hdmi.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c > b/drivers/gpu/drm/exynos/exynos_hdmi.c > index 409e2ec..b55335b 100644 > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c > @@ -1282,6 +1282,7 @@ static int hdmi_get_edid(void *ctx, struct > drm_connector *connector, > DRM_DEBUG_KMS("%s : width[%d] x height[%d]\n", > (hdata->dvi_mode ? "dvi monitor" : "hdmi monitor"), > raw_edid->width_cm, raw_edid->height_cm); > + kfree(raw_edid); Applied, Thanks. > } else { > return -ENODEV; > } > -- > 1.7.4.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv8 13/26] v4l: vivi: support for dmabuf importing
Hi Hans, On Wednesday 22 August 2012 12:56:30 Hans Verkuil wrote: > On Tue August 14 2012 17:34:43 Tomasz Stanislawski wrote: > > This patch enhances VIVI driver with a support for importing a buffer > > from DMABUF file descriptors. > > Thanks for adding DMABUF support to vivi. > > What would be great is if DMABUF support is also added to mem2mem_testdev. > It would make an excellent test case to take the vivi output, pass it > through mem2mem_testdev, and finally output the image using the gpu, all > using dmabuf. > > It's also very useful for application developers to test dmabuf support > without requiring special hardware (other than a dmabuf-enabled gpu > driver). One important missing feature is support for exporting GPU buffers as dmabuf file descriptors in the userspace APIs. I'm not sure where that would plug in the graphics stack, but we probably need at least a Linux-specific OpenGL extension for that. I've heard from Rob Clark that work was ongoing in that direction. I believe that https://wiki.linaro.org/OfficeofCTO/MemoryManagement?action=AttachFile=get=linux- video.pdf is also related. -- Regards, Laurent Pinchart
[PATCH] cdv: Fix call to cdv_intel_dp_set_m_n
From: Alan CoxWe should be making this call not praying that the values are right. In addition as noted by Josiah Standing we should be calling this for eDP as well. Signed-off-by: Alan Cox --- drivers/gpu/drm/gma500/cdv_intel_display.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c b/drivers/gpu/drm/gma500/cdv_intel_display.c index 4df1e72..3cfd093 100644 --- a/drivers/gpu/drm/gma500/cdv_intel_display.c +++ b/drivers/gpu/drm/gma500/cdv_intel_display.c @@ -1125,8 +1125,8 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc, } /* dpll |= PLL_REF_INPUT_DREFCLK; */ - if (is_dp) { -/*FIXMEcdv_intel_dp_set_m_n(crtc, mode, adjusted_mode); */ + if (is_dp || is_edp) { + cdv_intel_dp_set_m_n(crtc, mode, adjusted_mode); } else { REG_WRITE(PIPE_GMCH_DATA_M(pipe), 0); REG_WRITE(PIPE_GMCH_DATA_N(pipe), 0);
[PATCHv8 13/26] v4l: vivi: support for dmabuf importing
On Tue August 14 2012 17:34:43 Tomasz Stanislawski wrote: > This patch enhances VIVI driver with a support for importing a buffer > from DMABUF file descriptors. Thanks for adding DMABUF support to vivi. What would be great is if DMABUF support is also added to mem2mem_testdev. It would make an excellent test case to take the vivi output, pass it through mem2mem_testdev, and finally output the image using the gpu, all using dmabuf. It's also very useful for application developers to test dmabuf support without requiring special hardware (other than a dmabuf-enabled gpu driver). Regards, Hans > > Signed-off-by: Tomasz Stanislawski > Signed-off-by: Kyungmin Park > --- > drivers/media/video/Kconfig |1 + > drivers/media/video/vivi.c |2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig > index 966954d..8fa81be 100644 > --- a/drivers/media/video/Kconfig > +++ b/drivers/media/video/Kconfig > @@ -653,6 +653,7 @@ config VIDEO_VIVI > depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE > select FONT_8x16 > select VIDEOBUF2_VMALLOC > + select DMA_SHARED_BUFFER > default n > ---help--- > Enables a virtual video driver. This device shows a color bar > diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c > index a6351c4..37d8fd4 100644 > --- a/drivers/media/video/vivi.c > +++ b/drivers/media/video/vivi.c > @@ -1308,7 +1308,7 @@ static int __init vivi_create_instance(int inst) > q = >vb_vidq; > memset(q, 0, sizeof(dev->vb_vidq)); > q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE; > - q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_READ; > + q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ; > q->drv_priv = dev; > q->buf_struct_size = sizeof(struct vivi_buffer); > q->ops = _video_qops; >
[PATCHv8 02/26] Documentation: media: description of DMABUF importing in V4L2
On Tue August 14 2012 17:34:32 Tomasz Stanislawski wrote: > This patch adds description and usage examples for importing > DMABUF file descriptor in V4L2. > > Signed-off-by: Tomasz Stanislawski > Signed-off-by: Kyungmin Park > CC: linux-doc at vger.kernel.org > --- > Documentation/DocBook/media/v4l/compat.xml |4 + > Documentation/DocBook/media/v4l/io.xml | 180 > > .../DocBook/media/v4l/vidioc-create-bufs.xml |3 +- > Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 15 ++ > Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 47 ++--- > 5 files changed, 226 insertions(+), 23 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/compat.xml > b/Documentation/DocBook/media/v4l/compat.xml > index 98e8d08..ff45330 100644 > --- a/Documentation/DocBook/media/v4l/compat.xml > +++ b/Documentation/DocBook/media/v4l/compat.xml > @@ -2605,6 +2605,10 @@ ioctls. > > Support for frequency band enumeration: > ioctl. > > + > + Importing DMABUF file descriptors as a new IO method described > + in . > + > > > > diff --git a/Documentation/DocBook/media/v4l/io.xml > b/Documentation/DocBook/media/v4l/io.xml > index 1885cc0..98253ee 100644 > --- a/Documentation/DocBook/media/v4l/io.xml > +++ b/Documentation/DocBook/media/v4l/io.xml > @@ -472,6 +472,163 @@ rest should be evident. > > > > + > +Streaming I/O (DMA buffer importing) > + > + > + Experimental > + This is an experimental > + interface and may change in the future. > + > + > +The DMABUF framework provides a generic mean for sharing buffers > between s/mean/method/ > + multiple devices. Device drivers that support DMABUF can export a DMA buffer > +to userspace as a file descriptor (known as the exporter role), import a DMA > +buffer from userspace using a file descriptor previously exported for a > +different or the same device (known as the importer role), or both. This > +section describes the DMABUF importer role API in V4L2. > + > +Input and output devices support the streaming I/O method when the > +V4L2_CAP_STREAMING flag in the > +capabilities field of returned > by > +the ioctl is set. Whether importing DMA buffers through > +DMABUF file descriptors is supported is determined by calling the > + ioctl with the memory type set to > +V4L2_MEMORY_DMABUF. > + > +This I/O method is dedicated for sharing DMA buffers between V4L > and > +other APIs. Buffers (planes) are allocated by a driver on behalf of the > +application, and exported to the application as file descriptors using an API > +specific to the allocator driver. Only those file descriptor are exchanged, > +these files and meta-information are passed in (or in This sentence doesn't work well. It's unclear what is meant by 'these files'. Do you mean 'these file descriptors'? > + in the multi-planar API case). The driver must be switched into > +DMABUF I/O mode by calling the with the desired buffer type. > +No buffers (planes) are allocated beforehand, consequently they are not > indexed > +and cannot be queried like mapped buffers with the > +VIDIOC_QUERYBUF ioctl. I disagree with that. Userptr buffers can use QUERYBUF just fine. Even for the userptr you still have to fill in the buffer index when calling QBUF. So I see no reason why you couldn't use QUERYBUF in the DMABUF case. The only difference is that the fd field is undefined (set to -1 perhaps?) if the bufffer isn't queued. QUERYBUF can be very useful for debugging, for example to see what the status is of each buffer and how many are queued. > + > + > + Initiating streaming I/O with DMABUF file descriptors > + > + > + reqbuf; > + > +memset (reqbuf, 0, sizeof (reqbuf)); > +reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; > +reqbuf.memory = V4L2_MEMORY_DMABUF; > +reqbuf.count = 1; > + > +if (ioctl (fd, , reqbuf) == -1) { > + if (errno == EINVAL) > + printf ("Video capturing or DMABUF streaming is not > supported\n"); > + else > + perror ("VIDIOC_REQBUFS"); > + > + exit (EXIT_FAILURE); Let's stick to the kernel coding style, so no ' ' before '(' in function calls. Same for the other program examples below. > +} > + > + > + > +Buffer (plane) file descriptor is passed on the fly with the s/Buffer/The buffer/ > + ioctl. In case of multiplanar buffers, every plane can be 'Can be', 'should be' or 'must be'? Does it ever make sense to have the same fd for different planes? Do we have restrictions on this in the userptr case? > +associated with a different DMABUF descriptor. Although buffers are commonly > +cycled, applications can pass a different DMABUF descriptor at each > +VIDIOC_QBUF call. > + > + > + Queueing DMABUF using single plane API > + > + > +int buffer_queue(int v4lfd, int index, int dmafd) > +{ > + buf; > + > + memset(buf, 0, sizeof buf);
[PATCHv8 01/26] v4l: Add DMABUF as a memory type
On Tue August 14 2012 17:34:31 Tomasz Stanislawski wrote: > From: Sumit Semwal > > Adds DMABUF memory type to v4l framework. Also adds the related file > descriptor in v4l2_plane and v4l2_buffer. > > Signed-off-by: Tomasz Stanislawski >[original work in the PoC for buffer sharing] > Signed-off-by: Sumit Semwal > Signed-off-by: Sumit Semwal > Acked-by: Laurent Pinchart > --- > drivers/media/video/v4l2-compat-ioctl32.c | 18 ++ > drivers/media/video/v4l2-ioctl.c |1 + > include/linux/videodev2.h |7 +++ > 3 files changed, 26 insertions(+) > > diff --git a/drivers/media/video/v4l2-compat-ioctl32.c > b/drivers/media/video/v4l2-compat-ioctl32.c > index 9ebd5c5..a2e0549 100644 > --- a/drivers/media/video/v4l2-compat-ioctl32.c > +++ b/drivers/media/video/v4l2-compat-ioctl32.c > @@ -304,6 +304,7 @@ struct v4l2_plane32 { > union { > __u32 mem_offset; > compat_long_t userptr; > + __u32 fd; Shouldn't this be int? > } m; > __u32 data_offset; > __u32 reserved[11]; > @@ -325,6 +326,7 @@ struct v4l2_buffer32 { > __u32 offset; > compat_long_t userptr; > compat_caddr_t planes; > + __u32 fd; Ditto. > } m; > __u32 length; > __u32 reserved2; > @@ -348,6 +350,9 @@ static int get_v4l2_plane32(struct v4l2_plane *up, struct > v4l2_plane32 *up32, > up_pln = compat_ptr(p); > if (put_user((unsigned long)up_pln, >m.userptr)) > return -EFAULT; > + } else if (memory == V4L2_MEMORY_DMABUF) { > + if (copy_in_user(>m.fd, >m.fd, sizeof(int))) > + return -EFAULT; > } else { > if (copy_in_user(>m.mem_offset, >m.mem_offset, > sizeof(__u32))) > @@ -371,6 +376,11 @@ static int put_v4l2_plane32(struct v4l2_plane *up, > struct v4l2_plane32 *up32, > if (copy_in_user(>m.mem_offset, >m.mem_offset, > sizeof(__u32))) > return -EFAULT; > + /* For DMABUF, driver might've set up the fd, so copy it back. */ > + if (memory == V4L2_MEMORY_DMABUF) > + if (copy_in_user(>m.fd, >m.fd, > + sizeof(int))) > + return -EFAULT; > > return 0; > } > @@ -453,6 +463,10 @@ static int get_v4l2_buffer32(struct v4l2_buffer *kp, > struct v4l2_buffer32 __user > if (get_user(kp->m.offset, >m.offset)) > return -EFAULT; > break; > + case V4L2_MEMORY_DMABUF: > + if (get_user(kp->m.fd, >m.fd)) > + return -EFAULT; > + break; > } > } > > @@ -517,6 +531,10 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, > struct v4l2_buffer32 __user > if (put_user(kp->m.offset, >m.offset)) > return -EFAULT; > break; > + case V4L2_MEMORY_DMABUF: > + if (put_user(kp->m.fd, >m.fd)) > + return -EFAULT; > + break; > } > } > > diff --git a/drivers/media/video/v4l2-ioctl.c > b/drivers/media/video/v4l2-ioctl.c > index 6bc47fc..dffd3c9 100644 > --- a/drivers/media/video/v4l2-ioctl.c > +++ b/drivers/media/video/v4l2-ioctl.c > @@ -155,6 +155,7 @@ static const char *v4l2_memory_names[] = { > [V4L2_MEMORY_MMAP]= "mmap", > [V4L2_MEMORY_USERPTR] = "userptr", > [V4L2_MEMORY_OVERLAY] = "overlay", > + [V4L2_MEMORY_DMABUF] = "dmabuf", > }; > > #define prt_names(a, arr) a) >= 0) && ((a) < ARRAY_SIZE(arr))) ? \ > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h > index 7a147c8..7f918dc 100644 > --- a/include/linux/videodev2.h > +++ b/include/linux/videodev2.h > @@ -186,6 +186,7 @@ enum v4l2_memory { > V4L2_MEMORY_MMAP = 1, > V4L2_MEMORY_USERPTR = 2, > V4L2_MEMORY_OVERLAY = 3, > + V4L2_MEMORY_DMABUF = 4, > }; > > /* see also http://vektor.theorem.ca/graphics/ycbcr/ */ > @@ -596,6 +597,8 @@ struct v4l2_requestbuffers { > * should be passed to mmap() called on the video node) > * @userptr: when memory is V4L2_MEMORY_USERPTR, a userspace pointer > * pointing to this plane > + * @fd: when memory is V4L2_MEMORY_DMABUF, a userspace > file > + * descriptor associated with this plane > * @data_offset: offset in the plane to the start of data; usually 0, > * unless there is a header in front of the data > * > @@ -610,6
[PATCH] drm: edid: add support for E-DDC
On Tue, Aug 21, 2012 at 04:28:20PM -0700, Shirish S wrote: > On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrj?l? < > ville.syrjala at linux.intel.com> wrote: > > > On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote: > Here are my earlier comments on Jean's patch: > > http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html > > > > > If i am not wrong am doing exactly what you have said in you comments. > > This seems a bit wrong to me. The spec says that the ack for the > segment address is "don't care", but for the segment pointer the ack is > required (when segment != 0). > The variable segFlags is "dont care for block 0 and 1 wheras". > > With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from a > non E-DDC display, if we try to read segment != 0 from it. Of course > we shouldn't do that unless the display lied to us about what extension > blocks it provides. > > So I'm not sure if it would be better to trust that the display never > lies about the extension blocks, or if we should just assume all E-DDC > displays ack both segment addr and pointer. The no-ack feature seems > to there for backwards compatibility, for cases where the host always > sends the segment addr/pointer even when reading segment 0 (which your > code doesn't do). > > To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split > into two flags (one for addr, other for data). > > Hence i have split the i2c_msg into 3, segment pointer,offset(addr) > and data pointer. I was referring to the addr and data phases of the segment pointer. According to the spec the ack for the addr is always optional. But I suppose no sane device would nak the addr, while acking the data. -- Ville Syrj?l? Intel OTC
[alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
At Tue, 21 Aug 2012 19:58:02 -0500, Ricardo Neri wrote: > > > > On 08/21/2012 07:39 AM, Clark, Rob wrote: > > On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen > > wrote: > >> On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: > >>> Hello! > >>> > >>> I have been working on prototypes for the ASoC OMAP HDMI audio driver to > >>> propagate events from the HDMI output (e.g., display getting > >>> enabled/disabled/suspended). This for the users of the driver to react > >>> to such events. For instance, if the display is disabled or disconected, > >>> audio could be stopped, rerouted or whatever other decision the user > >>> makes. This is needed because, if, for instance, the HDMI IP goes off, > >>> audio will stall and the audio users will only see a "playback write > >>> error (DMA or IRQ trouble?)" > >>> > >>> In my prototypes I have used snd_soc_jack for this purpose and I have > >>> some questions: > >>> > >>> *I see snd_soc_jack is used mostly for headsets and microphones with > >>> actual external mechanical connections. Strictly, in my case I propagate > >>> events originated by the OMAP display driver (changes in the power > >>> state), and not from external events. Some of these events are generated > >>> from an actual HDMI cable connection/disconnection, though. > >>> > >>> *Maybe the event should be propagated by omapdss/omapdrm/drm and the > >>> entity in charge of the audio policy should listen those events instead. > >>> > >>> *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it is > >>> feasible for an audio driver to report events from an AV output. > >>> > >>> I was wondering about how much sense does it make to you guys use a > >>> snd_soc_jack in this case? > >> > >> How does DRM handle audio? I made a quick grep, but I see the drm > >> drivers only enabling the audio in the HW, nothing else. > > > > I confess to not knowing too much about audio/alsa, but what does > > audio driver need from hdmi? Just hotplug events? > > At least for the case of the ASoC HDMI audio driver (but hopefully for > other audio drivers as well), it needs to detect whether an HDMI output > is available, if the display's current configuration supports audio > (e.g., a 1080p display configured as VGA should be reported as not > supporting audio). It also needs interfaces to > configure/prepare/start/stop audio. Also, of course, needs to know if > the display is off/on/suspended and when transitions occur. For OMAP, > omapdss provide an interface for this functionality for ALSA or any > other interested user. > > > > From a quick look, it seems most of what the existing drm drivers are > > doing is detecting if the display supports audio, and then turning > > on/off the hw.. (and some infoframe stuff in some cases). > > Yes, it seems to me that every driver makes its own audio > implementation, mainly focused on configuration. I could not find any > audio common interface so that users like ALSA can take advantage of. > > Also, I could not see any ALSA driver using functionality provided by a > drm driver. > > Maybe the lack of audio support in drm is because the audio users should > not talk to drm directly but to a lower level component (omapdrm, > omapdss?). However, today there exists video technology supports audio > as well, such as DisplayPort or HDMI. Could it make more sense now to > provide audio support? The reason is that the audio and video handling are already separated in the hardware level, at least, for desktop graphics. The audio infoframe is passed via ELD to the audio controller part upon plug/unplugging via HD-audio unsolicited event, and the audio driver sets up the stuff according to the given ELD. Thus no extra interface between drm and ALSA was required in the kernel API level, so far. Takashi
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #18 from Alexandre Demers 2012-08-22 05:32:58 UTC --- (In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #10) > > > Well, it seems running it through qapitrace doesn't lock. > > > > The apitrace looks incomplete: it doesn't contain any actual rendering > > operations. > > I'll rerun it at home tonight. You were right, I had missed a ";" between the arguments. Bam, locked. I was unable to retrieve a trace. Well, I may try to run it in debug mode to see where it stops later this week. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[git pull] drm fixes + one fbcon one
Hi Linus, Intel: edid fixes, power consumption fix, s/r fix, haswell fix radeon: BIOS loading fixes for UEFI and Thunderbolt machines, better MSAA validation, lockup timeout fixes, modesetting fixes one udl dpms fix, one vmwgfx fix, couple of trivial core changes There is an export added to ACPI as part of the radeon bios fixes, I've also included the fbcon flashing cursor vs deinit race fix, that seems the simplest place to start, so that distros can pick it up easier. Dave. The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92: Linux 3.6-rc2 (2012-08-16 14:51:24 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-fixes for you to fetch changes up to d8636a2717bb3da2a7ce2154bf08de90bb8c87b0: fbcon: fix race condition between console lock and cursor timer (v1.1) (2012-08-22 14:00:35 +1000) Alan Cox (1): drm: stop vmgfx driver explosion Alex Deucher (5): ACPI: export symbol acpi_get_table_with_size drm/radeon: convert radeon vfct code to use acpi_get_table_with_size drm/radeon: split ATRM support out from the ATPX handler (v3) Revert "drm/radeon: fix bo creation retry path" drm/radeon/ss: use num_crtc rather than hardcoded 6 Ben Widawsky (1): drm/i915/contexts: fix list corruption Christian K?nig (1): drm/radeon: init lockup timeout on ring init Damien Lespiau (1): drm: Remove two unused fields from struct drm_display_mode Daniel Vetter (2): drm/i915: fix hsw uncached pte drm/i915: use hsw rps tuning values everywhere on gen6+ Dave Airlie (4): Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes drm/udl: dpms off the crtc when disabled. fbcon: fix race condition between console lock and cursor timer (v1.1) David Lamparter (1): drm/radeon: implement ACPI VFCT vbios fetch (v3) Jani Nikula (3): drm/i915: fix EDID memory leak in SDVO drm/i915: extract connector update from intel_ddc_get_modes() for reuse drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads Jerome Glisse (1): drm/radeon: avoid turning off spread spectrum for used pll Marek Ol??k (2): drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700 drm/radeon: fix checking of MSAA renderbuffers on r600-r700 Sachin Kamat (1): drm: Add missing static storage class specifiers in drm_proc.c file Tvrtko Ursulin (1): drm/radeon/kms: extend the Fujitsu D3003-S2 board connector quirk to cover later silicon stepping drivers/acpi/acpica/tbxface.c|1 + drivers/char/agp/intel-agp.h |1 + drivers/char/agp/intel-gtt.c | 105 +--- drivers/gpu/drm/drm_modes.c |3 - drivers/gpu/drm/drm_proc.c |4 +- drivers/gpu/drm/i915/i915_gem.c |8 +- drivers/gpu/drm/i915/i915_gem_gtt.c |5 +- drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_crt.c | 36 ++- drivers/gpu/drm/i915/intel_drv.h |2 + drivers/gpu/drm/i915/intel_modes.c | 31 -- drivers/gpu/drm/i915/intel_pm.c | 15 +-- drivers/gpu/drm/i915/intel_sdvo.c|1 + drivers/gpu/drm/radeon/atombios_crtc.c | 25 - drivers/gpu/drm/radeon/r600_cs.c | 105 drivers/gpu/drm/radeon/r600d.h | 17 drivers/gpu/drm/radeon/radeon.h | 15 --- drivers/gpu/drm/radeon/radeon_atombios.c |2 +- drivers/gpu/drm/radeon/radeon_atpx_handler.c | 56 +-- drivers/gpu/drm/radeon/radeon_bios.c | 138 +- drivers/gpu/drm/radeon/radeon_drv.c |3 +- drivers/gpu/drm/radeon/radeon_object.c |3 +- drivers/gpu/drm/radeon/radeon_ring.c |1 + drivers/gpu/drm/radeon/reg_srcs/r600 |8 -- drivers/gpu/drm/udl/udl_modeset.c|3 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |6 +- drivers/video/console/fbcon.c|9 +- include/drm/drm_crtc.h |2 - 28 files changed, 424 insertions(+), 182 deletions(-)
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #17 from Alexandre Demers 2012-08-22 03:02:45 UTC --- (In reply to comment #13) > (In reply to comment #12) > > I tried to trace RenderFeatTest (one of the other applications locking my > > system). It did as with the piglit test: it didn't crash. However, the > > rendering is corrupted where it locks when launched from a terminal. Trace > > is > > 75MB when compressed if you want me to upload it somewhere. > > I forgot to say: it doesn't lock anymore at all. I should have written "... > where it locked when launched from a terminal". It was locking at test 7. I'm > attaching a screenshot from that test. > > I'll bisect to see if I can find which commit "fixed" the lock. I was not able to figure out the combination that fixed the thing. Well, let's focus on the piglit test that locks the beast. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 2/2] console: implement lockdep support for console_lock
Dave Airlie recently discovered a locking bug in the fbcon layer, where a timer_del_sync (for the blinking cursor) deadlocks with the timer itself, since both (want to) hold the console_lock: https://lkml.org/lkml/2012/8/21/36 Unfortunately the console_lock isn't a plain mutex and hence has no lockdep support. Which resulted in a few days wasted of tracking down this bug (complicated by the fact that printk doesn't show anything when the console is locked) instead of noticing the bug much earlier with the lockdep splat. Hence I've figured I need to fix that for the next deadlock involving console_lock - and with kms/drm growing ever more complex locking that'll eventually happen. Now the console_lock has rather funky semantics, so after a quick irc discussion with Thomas Gleixner and Dave Airlie I've quickly ditched the original idead of switching to a real mutex (since it won't work) and instead opted to annotate the console_lock with lockdep information manually. There are a few special cases: - The console_lock state is protected by the console_sem, and usually grabbed/dropped at _lock/_unlock time. But the suspend/resume code drops the semaphore without dropping the console_lock (see suspend_console/resume_console). But since the same thread that did the suspend will do the resume, we don't need to fix up anything. - In the printk code there's a special trylock, only used to kick off the logbuffer printk'ing in console_unlock. But all that happens while lockdep is disable (since printk does a few other evil tricks). So no issue there, either. - The console_lock can also be acquired form irq context (but only with a trylock). lockdep already handles that. This all leaves us with annotating the normal console_lock, _unlock and _trylock functions. And yes, it works - simply unloading a drm kms driver resulted in lockdep complaining about the deadlock in fbcon_deinit: == [ INFO: possible circular locking dependency detected ] 3.6.0-rc2+ #552 Not tainted --- kms-reload/3577 is trying to acquire lock: ((>queue)){+.+...}, at: [] wait_on_work+0x0/0xa7 but task is already holding lock: (console_lock){+.+.+.}, at: [] bind_con_driver+0x38/0x263 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (console_lock){+.+.+.}: [] lock_acquire+0x95/0x105 [] console_lock+0x59/0x5b [] fb_flashcursor+0x2e/0x12c [] process_one_work+0x1d9/0x3b4 [] worker_thread+0x1a7/0x24b [] kthread+0x7f/0x87 [] kernel_thread_helper+0x4/0x10 -> #0 ((>queue)){+.+...}: [] __lock_acquire+0x999/0xcf6 [] lock_acquire+0x95/0x105 [] wait_on_work+0x3b/0xa7 [] __cancel_work_timer+0xbf/0x102 [] cancel_work_sync+0xb/0xd [] fbcon_deinit+0x11c/0x1dc [] bind_con_driver+0x145/0x263 [] unbind_con_driver+0x14f/0x195 [] store_bind+0x1ad/0x1c1 [] dev_attr_store+0x13/0x1f [] sysfs_write_file+0xe9/0x121 [] vfs_write+0x9b/0xfd [] sys_write+0x3e/0x6b [] system_call_fastpath+0x16/0x1b other info that might help us debug this: Possible unsafe locking scenario: CPU0CPU1 lock(console_lock); lock((>queue)); lock(console_lock); lock((>queue)); *** DEADLOCK *** Cc: Dave Airlie Cc: Thomas Gleixner Signed-off-by: Daniel Vetter --- kernel/printk.c |9 + 1 file changed, 9 insertions(+) diff --git a/kernel/printk.c b/kernel/printk.c index ed9af6a..ab2ab24 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -87,6 +87,12 @@ static DEFINE_SEMAPHORE(console_sem); struct console *console_drivers; EXPORT_SYMBOL_GPL(console_drivers); +#ifdef CONFIG_LOCKDEP +struct lockdep_map console_lock_dep_map = { + .name = "console_lock" +}; +#endif + /* * This is used for debugging the mess that is the VT code by * keeping track if we have the console semaphore held. It's @@ -1916,6 +1922,7 @@ void console_lock(void) return; console_locked = 1; console_may_schedule = 1; + mutex_acquire(_lock_dep_map, 0, 0, _RET_IP_); } EXPORT_SYMBOL(console_lock); @@ -1937,6 +1944,7 @@ int console_trylock(void) } console_locked = 1; console_may_schedule = 0; + mutex_acquire(_lock_dep_map, 0, 1, _RET_IP_); return 1; } EXPORT_SYMBOL(console_trylock); @@ -2097,6 +2105,7 @@ skip: local_irq_restore(flags); } console_locked = 0; + mutex_release(_lock_dep_map, 1, _RET_IP_); /* Release the exclusive_console once it is used */ if (unlikely(exclusive_console)) -- 1.7.10.4
[PATCH 1/2] console: use might_sleep in console_lock
Instead of BUG_ON(in_interrupt()), since that doesn't check for all the newfangled stuff like preempt. Note that this is valid since the console_sem is essentially used like a real mutex with only two twists: - we allow trylock from hardirq context - across suspend/resume we lock the logical console_lock, but drop the semaphore protecting the locking state. Now that doesn't guarantee that no one is playing tricks in single-thread atomic contexts at suspend/resume/boot time, but - I couldn't find anything suspicious with some grepping, - might_sleep shouldn't die, - and I think the upside of catching more potential issues is worth the risk of getting a might_sleep backtrace that would have been save (and then dealing with that fallout). Cc: Dave Airlie Cc: Thomas Gleixner Signed-off-by: Daniel Vetter --- kernel/printk.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/printk.c b/kernel/printk.c index 66a2ea3..ed9af6a 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -1909,7 +1909,8 @@ static int __cpuinit console_cpu_notify(struct notifier_block *self, */ void console_lock(void) { - BUG_ON(in_interrupt()); + might_sleep(); + down(_sem); if (console_suspended) return; -- 1.7.10.4
[PATCH 0/2] console_lock debug improvements
Hi all, After Dave Airlie blew through a few days to track down a deadlock at boot-up when handing over from the firmware fb to the kms/drm framebuffer driver (1), I've figured that lockdep /should/ have caught this. And indeed, by adding proper annotations to the console_lock it complains about the potential deadlock when exercising the entire driver life-cycle of just one fb driver (i.e. not even a handover required). While at it, I've replaced the existing in_interrupt check with the more paranoid might_sleep. Comments, flames and review highly welcome. Yours, Daniel [1]: https://lkml.org/lkml/2012/8/21/36 Daniel Vetter (2): console: use might_sleep in console_lock console: implement lockdep support for console_lock kernel/printk.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) -- 1.7.10.4
Re: [PATCH] drm/exynos: Add dependency for G2D in Kconfig
Applied, Thanks. 2012/8/14 Sachin Kamat sachin.ka...@linaro.org: Select Exynos DRM based G2D only if non-DRM based Exynos G2D driver is not selected. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/gpu/drm/exynos/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index 7f50967..59a26e5 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -36,6 +36,6 @@ config DRM_EXYNOS_VIDI config DRM_EXYNOS_G2D bool Exynos DRM G2D - depends on DRM_EXYNOS + depends on DRM_EXYNOS !VIDEO_SAMSUNG_S5P_G2D help Choose this option if you want to use Exynos G2D for DRM. -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: fix race condition between console lock and cursor timer
On Tue, Aug 21, 2012 at 2:40 AM, Dave Airlie airl...@redhat.com wrote: So we've had a fair few reports of fbcon handover breakage between efi/vesafb and i915 surface recently, so I dedicated a couple of days to finding the problem. Essentially the last thing we saw was the conflicting framebuffer message and that was all. So after much tracing with direct netconsole writes (printks under console_lock not so useful), I think I found the race. Thread A (driver load)Thread B (timer thread) unbind_con_driver - | bind_con_driver -| vc-vc_sw-con_deinit - | fbcon_deinit - | console_lock()| | | | fbcon_flashcursor timer fires | console_lock() - blocked for A | | fbcon_del_cursor_timer - del_timer_sync (BOOM) Of course because all of this is under the console lock, we never see anything, also since we also just unbound the active console guess what we never see anything. Hopefully this fixes the problem for anyone seeing vesafb-kms driver handoff. Signed-off-by: David Airlie airl...@redhat.com --- drivers/video/console/fbcon.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c index 2e471c2..f8a79fc 100644 --- a/drivers/video/console/fbcon.c +++ b/drivers/video/console/fbcon.c @@ -372,8 +372,12 @@ static void fb_flashcursor(struct work_struct *work) struct vc_data *vc = NULL; int c; int mode; + int ret; + + ret = console_trylock(); + if (ret == 0) + return; - console_lock(); if (ops ops-currcon != -1) vc = vc_cons[ops-currcon].d; I have a Dell XPS 8300 machine with a Radeon card in it that started showing this problem yesterday with 3.6-rc2 kernels. I tested this patch on top of v3.6-rc2-206-g10c63c9 this morning and the problem seems to have been cleared up for me. That includes making sure the grub2 file has the gfxterm set, etc. I know we've been seeing this quite a bit more on Fedora 17, so we'll want to have some people test a 3.5 build with it but things are looking better. josh -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] ACPI: export symbol acpi_get_table_with_size
-- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On 08/21/2012 07:39 AM, Clark, Rob wrote: On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: Hello! I have been working on prototypes for the ASoC OMAP HDMI audio driver to propagate events from the HDMI output (e.g., display getting enabled/disabled/suspended). This for the users of the driver to react to such events. For instance, if the display is disabled or disconected, audio could be stopped, rerouted or whatever other decision the user makes. This is needed because, if, for instance, the HDMI IP goes off, audio will stall and the audio users will only see a playback write error (DMA or IRQ trouble?) In my prototypes I have used snd_soc_jack for this purpose and I have some questions: *I see snd_soc_jack is used mostly for headsets and microphones with actual external mechanical connections. Strictly, in my case I propagate events originated by the OMAP display driver (changes in the power state), and not from external events. Some of these events are generated from an actual HDMI cable connection/disconnection, though. *Maybe the event should be propagated by omapdss/omapdrm/drm and the entity in charge of the audio policy should listen those events instead. *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it is feasible for an audio driver to report events from an AV output. I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case? How does DRM handle audio? I made a quick grep, but I see the drm drivers only enabling the audio in the HW, nothing else. I confess to not knowing too much about audio/alsa, but what does audio driver need from hdmi? Just hotplug events? At least for the case of the ASoC HDMI audio driver (but hopefully for other audio drivers as well), it needs to detect whether an HDMI output is available, if the display's current configuration supports audio (e.g., a 1080p display configured as VGA should be reported as not supporting audio). It also needs interfaces to configure/prepare/start/stop audio. Also, of course, needs to know if the display is off/on/suspended and when transitions occur. For OMAP, omapdss provide an interface for this functionality for ALSA or any other interested user. From a quick look, it seems most of what the existing drm drivers are doing is detecting if the display supports audio, and then turning on/off the hw.. (and some infoframe stuff in some cases). Yes, it seems to me that every driver makes its own audio implementation, mainly focused on configuration. I could not find any audio common interface so that users like ALSA can take advantage of. Also, I could not see any ALSA driver using functionality provided by a drm driver. Maybe the lack of audio support in drm is because the audio users should not talk to drm directly but to a lower level component (omapdrm, omapdss?). However, today there exists video technology supports audio as well, such as DisplayPort or HDMI. Could it make more sense now to provide audio support? Does ASoC support 'hotplug' of audio devices? If so, maybe it makes some sense to have some support in drm core. At least all the edid parsing stuff to determine if the display supports audio should be generic and not driver specific. drm already supports generic edid parsing to check for audio support. This is a good example of how an audio driver could just use that functionality to probe audio support. Ricardo BR, -R If there's a common generic way to handle this, we should obviously use that. But if we need to choose between doing something custom or doing it in omapdrm driver, I think we should go for drm the only solution and forget about audio with omapfb. Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: edid: add support for E-DDC
On Tue, Aug 21, 2012 at 04:28:20PM -0700, Shirish S wrote: On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote: Here are my earlier comments on Jean's patch: http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html If i am not wrong am doing exactly what you have said in you comments. This seems a bit wrong to me. The spec says that the ack for the segment address is don't care, but for the segment pointer the ack is required (when segment != 0). The variable segFlags is dont care for block 0 and 1 wheras. With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from a non E-DDC display, if we try to read segment != 0 from it. Of course we shouldn't do that unless the display lied to us about what extension blocks it provides. So I'm not sure if it would be better to trust that the display never lies about the extension blocks, or if we should just assume all E-DDC displays ack both segment addr and pointer. The no-ack feature seems to there for backwards compatibility, for cases where the host always sends the segment addr/pointer even when reading segment 0 (which your code doesn't do). To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split into two flags (one for addr, other for data). Hence i have split the i2c_msg into 3, segment pointer,offset(addr) and data pointer. I was referring to the addr and data phases of the segment pointer. According to the spec the ack for the addr is always optional. But I suppose no sane device would nak the addr, while acking the data. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
At Tue, 21 Aug 2012 19:58:02 -0500, Ricardo Neri wrote: On 08/21/2012 07:39 AM, Clark, Rob wrote: On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: Hello! I have been working on prototypes for the ASoC OMAP HDMI audio driver to propagate events from the HDMI output (e.g., display getting enabled/disabled/suspended). This for the users of the driver to react to such events. For instance, if the display is disabled or disconected, audio could be stopped, rerouted or whatever other decision the user makes. This is needed because, if, for instance, the HDMI IP goes off, audio will stall and the audio users will only see a playback write error (DMA or IRQ trouble?) In my prototypes I have used snd_soc_jack for this purpose and I have some questions: *I see snd_soc_jack is used mostly for headsets and microphones with actual external mechanical connections. Strictly, in my case I propagate events originated by the OMAP display driver (changes in the power state), and not from external events. Some of these events are generated from an actual HDMI cable connection/disconnection, though. *Maybe the event should be propagated by omapdss/omapdrm/drm and the entity in charge of the audio policy should listen those events instead. *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it is feasible for an audio driver to report events from an AV output. I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case? How does DRM handle audio? I made a quick grep, but I see the drm drivers only enabling the audio in the HW, nothing else. I confess to not knowing too much about audio/alsa, but what does audio driver need from hdmi? Just hotplug events? At least for the case of the ASoC HDMI audio driver (but hopefully for other audio drivers as well), it needs to detect whether an HDMI output is available, if the display's current configuration supports audio (e.g., a 1080p display configured as VGA should be reported as not supporting audio). It also needs interfaces to configure/prepare/start/stop audio. Also, of course, needs to know if the display is off/on/suspended and when transitions occur. For OMAP, omapdss provide an interface for this functionality for ALSA or any other interested user. From a quick look, it seems most of what the existing drm drivers are doing is detecting if the display supports audio, and then turning on/off the hw.. (and some infoframe stuff in some cases). Yes, it seems to me that every driver makes its own audio implementation, mainly focused on configuration. I could not find any audio common interface so that users like ALSA can take advantage of. Also, I could not see any ALSA driver using functionality provided by a drm driver. Maybe the lack of audio support in drm is because the audio users should not talk to drm directly but to a lower level component (omapdrm, omapdss?). However, today there exists video technology supports audio as well, such as DisplayPort or HDMI. Could it make more sense now to provide audio support? The reason is that the audio and video handling are already separated in the hardware level, at least, for desktop graphics. The audio infoframe is passed via ELD to the audio controller part upon plug/unplugging via HD-audio unsolicited event, and the audio driver sets up the stuff according to the given ELD. Thus no extra interface between drm and ALSA was required in the kernel API level, so far. Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 13/26] v4l: vivi: support for dmabuf importing
On Tue August 14 2012 17:34:43 Tomasz Stanislawski wrote: This patch enhances VIVI driver with a support for importing a buffer from DMABUF file descriptors. Thanks for adding DMABUF support to vivi. What would be great is if DMABUF support is also added to mem2mem_testdev. It would make an excellent test case to take the vivi output, pass it through mem2mem_testdev, and finally output the image using the gpu, all using dmabuf. It's also very useful for application developers to test dmabuf support without requiring special hardware (other than a dmabuf-enabled gpu driver). Regards, Hans Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/Kconfig |1 + drivers/media/video/vivi.c |2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 966954d..8fa81be 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -653,6 +653,7 @@ config VIDEO_VIVI depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE select FONT_8x16 select VIDEOBUF2_VMALLOC + select DMA_SHARED_BUFFER default n ---help--- Enables a virtual video driver. This device shows a color bar diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c index a6351c4..37d8fd4 100644 --- a/drivers/media/video/vivi.c +++ b/drivers/media/video/vivi.c @@ -1308,7 +1308,7 @@ static int __init vivi_create_instance(int inst) q = dev-vb_vidq; memset(q, 0, sizeof(dev-vb_vidq)); q-type = V4L2_BUF_TYPE_VIDEO_CAPTURE; - q-io_modes = VB2_MMAP | VB2_USERPTR | VB2_READ; + q-io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ; q-drv_priv = dev; q-buf_struct_size = sizeof(struct vivi_buffer); q-ops = vivi_video_qops; ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] cdv: Fix call to cdv_intel_dp_set_m_n
From: Alan Cox a...@linux.intel.com We should be making this call not praying that the values are right. In addition as noted by Josiah Standing we should be calling this for eDP as well. Signed-off-by: Alan Cox a...@linux.intel.com --- drivers/gpu/drm/gma500/cdv_intel_display.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c b/drivers/gpu/drm/gma500/cdv_intel_display.c index 4df1e72..3cfd093 100644 --- a/drivers/gpu/drm/gma500/cdv_intel_display.c +++ b/drivers/gpu/drm/gma500/cdv_intel_display.c @@ -1125,8 +1125,8 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc, } /* dpll |= PLL_REF_INPUT_DREFCLK; */ - if (is_dp) { -/*FIXMEcdv_intel_dp_set_m_n(crtc, mode, adjusted_mode); */ + if (is_dp || is_edp) { + cdv_intel_dp_set_m_n(crtc, mode, adjusted_mode); } else { REG_WRITE(PIPE_GMCH_DATA_M(pipe), 0); REG_WRITE(PIPE_GMCH_DATA_N(pipe), 0); ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 13/26] v4l: vivi: support for dmabuf importing
Hi Hans, On Wednesday 22 August 2012 12:56:30 Hans Verkuil wrote: On Tue August 14 2012 17:34:43 Tomasz Stanislawski wrote: This patch enhances VIVI driver with a support for importing a buffer from DMABUF file descriptors. Thanks for adding DMABUF support to vivi. What would be great is if DMABUF support is also added to mem2mem_testdev. It would make an excellent test case to take the vivi output, pass it through mem2mem_testdev, and finally output the image using the gpu, all using dmabuf. It's also very useful for application developers to test dmabuf support without requiring special hardware (other than a dmabuf-enabled gpu driver). One important missing feature is support for exporting GPU buffers as dmabuf file descriptors in the userspace APIs. I'm not sure where that would plug in the graphics stack, but we probably need at least a Linux-specific OpenGL extension for that. I've heard from Rob Clark that work was ongoing in that direction. I believe that https://wiki.linaro.org/OfficeofCTO/MemoryManagement?action=AttachFiledo=gettarget=linux- video.pdf is also related. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 17/26] Documentation: media: description of DMABUF exporting in V4L2
On Tue August 14 2012 17:34:47 Tomasz Stanislawski wrote: This patch adds description and usage examples for exporting DMABUF file descriptor in V4L2. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com CC: linux-...@vger.kernel.org --- Documentation/DocBook/media/v4l/compat.xml|3 + Documentation/DocBook/media/v4l/io.xml|3 + Documentation/DocBook/media/v4l/v4l2.xml |1 + Documentation/DocBook/media/v4l/vidioc-expbuf.xml | 223 + 4 files changed, 230 insertions(+) create mode 100644 Documentation/DocBook/media/v4l/vidioc-expbuf.xml diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index ff45330..802c1ab 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2609,6 +2609,9 @@ ioctls./para paraImporting DMABUF file descriptors as a new IO method described in xref linkend=dmabuf /./para /listitem +listitem + paraExporting DMABUF files using VIDIOC-EXPBUF; ioctl./para +/listitem /itemizedlist /section diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 98253ee..c27e59b 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -488,6 +488,9 @@ buffer from userspace using a file descriptor previously exported for a different or the same device (known as the importer role), or both. This section describes the DMABUF importer role API in V4L2./para +paraRefer to link linked=vidioc-expbuf DMABUF exporting /link for +details about exporting a V4L2 buffers as DMABUF file descriptors./para + paraInput and output devices support the streaming I/O method when the constantV4L2_CAP_STREAMING/constant flag in the structfieldcapabilities/structfield field of v4l2-capability; returned by diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 0292ed1..874c085 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -568,6 +568,7 @@ and discussions on the V4L mailing list./revremark sub-overlay; sub-prepare-buf; sub-qbuf; +sub-expbuf; This list is sorted alphabetically, so sub-expbuf should go after sub-enumstd. sub-querybuf; sub-querycap; sub-queryctrl; diff --git a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml new file mode 100644 index 000..30ebf67 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml @@ -0,0 +1,223 @@ +refentry id=vidioc-expbuf + + refmeta +refentrytitleioctl VIDIOC_EXPBUF/refentrytitle +manvol; + /refmeta + + refnamediv +refnameVIDIOC_EXPBUF/refname +refpurposeExport a buffer as a DMABUF file descriptor./refpurpose + /refnamediv + + refsynopsisdiv +funcsynopsis + funcprototype + funcdefint functionioctl/function/funcdef + paramdefint parameterfd/parameter/paramdef + paramdefint parameterrequest/parameter/paramdef + paramdefstruct v4l2_exportbuffer *parameterargp/parameter/paramdef + /funcprototype +/funcsynopsis + /refsynopsisdiv + + refsect1 +titleArguments/title + +variablelist + varlistentry + termparameterfd/parameter/term + listitem + parafd;/para + /listitem + /varlistentry + varlistentry + termparameterrequest/parameter/term + listitem + paraVIDIOC_EXPBUF/para + /listitem + /varlistentry + varlistentry + termparameterargp/parameter/term + listitem + para/para + /listitem + /varlistentry +/variablelist + /refsect1 + + refsect1 +titleDescription/title + +note + titleExperimental/title + paraThis is an link linkend=experimental experimental /link + interface and may change in the future./para +/note + +paraThis ioctl is an extension to the link linkend=mmapmemory +mapping/link I/O method therefore it is available only for +constantV4L2_MEMORY_MMAP/constant buffers. It can be used to export a +buffer as DMABUF file at any time after buffers have been allocated with the +VIDIOC-REQBUFS; ioctl./para + +paraPrior to exporting an application calls link +linkend=vidioc-querybufVIDIOC_QUERYBUF/link to obtain memory offsets. When +using the link linkend=planar-apismulti-planar API/link every plane has +own offset./para + +paraTo export a buffer, the application fills v4l2-exportbuffer;. The +structfield mem_offset /structfield field is set to the offset obtained +from constant VIDIOC_QUERYBUF /constant. Additional flags may be posted in +the structfield flags /structfield field. Refer
Re: [PATCHv8 18/26] v4l: add buffer exporting via dmabuf
On Tue August 14 2012 17:34:48 Tomasz Stanislawski wrote: This patch adds extension to V4L2 api. It allow to export a mmap buffer as file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by mmap and return a file descriptor on success. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/v4l2-compat-ioctl32.c |1 + drivers/media/video/v4l2-dev.c|1 + drivers/media/video/v4l2-ioctl.c | 15 +++ include/linux/videodev2.h | 26 ++ include/media/v4l2-ioctl.h|2 ++ 5 files changed, 45 insertions(+) diff --git a/drivers/media/video/v4l2-compat-ioctl32.c b/drivers/media/video/v4l2-compat-ioctl32.c index a2e0549..7689c4a 100644 --- a/drivers/media/video/v4l2-compat-ioctl32.c +++ b/drivers/media/video/v4l2-compat-ioctl32.c @@ -971,6 +971,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int cmd, unsigned long arg) case VIDIOC_S_FBUF32: case VIDIOC_OVERLAY32: case VIDIOC_QBUF32: + case VIDIOC_EXPBUF: case VIDIOC_DQBUF32: case VIDIOC_STREAMON32: case VIDIOC_STREAMOFF32: diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c index 71237f5..f6e7ea5 100644 --- a/drivers/media/video/v4l2-dev.c +++ b/drivers/media/video/v4l2-dev.c @@ -607,6 +607,7 @@ static void determine_valid_ioctls(struct video_device *vdev) SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs); SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf); SET_VALID_IOCTL(ops, VIDIOC_QBUF, vidioc_qbuf); + SET_VALID_IOCTL(ops, VIDIOC_EXPBUF, vidioc_expbuf); SET_VALID_IOCTL(ops, VIDIOC_DQBUF, vidioc_dqbuf); SET_VALID_IOCTL(ops, VIDIOC_OVERLAY, vidioc_overlay); SET_VALID_IOCTL(ops, VIDIOC_G_FBUF, vidioc_g_fbuf); diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c index dffd3c9..c4e8c7e 100644 --- a/drivers/media/video/v4l2-ioctl.c +++ b/drivers/media/video/v4l2-ioctl.c @@ -458,6 +458,14 @@ static void v4l_print_buffer(const void *arg, bool write_only) tc-type, tc-flags, tc-frames, *(__u32 *)tc-userbits); } +static void v4l_print_exportbuffer(const void *arg, bool write_only) +{ + const struct v4l2_exportbuffer *p = arg; + + pr_cont(fd=%d, mem_offset=%lx, flags=%lx\n, + p-fd, (unsigned long)p-mem_offset, (unsigned long)p-flags); Why the unsigned long casts? +} + static void v4l_print_create_buffers(const void *arg, bool write_only) { const struct v4l2_create_buffers *p = arg; @@ -1254,6 +1262,12 @@ static int v4l_streamoff(const struct v4l2_ioctl_ops *ops, return ops-vidioc_streamoff(file, fh, *(unsigned int *)arg); } +static int v4l_expbuf(const struct v4l2_ioctl_ops *ops, + struct file *file, void *fh, void *arg) +{ + return ops-vidioc_expbuf(file, fh, arg); +} Not needed... + static int v4l_g_tuner(const struct v4l2_ioctl_ops *ops, struct file *file, void *fh, void *arg) { @@ -1947,6 +1961,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = { IOCTL_INFO_STD(VIDIOC_S_FBUF, vidioc_s_fbuf, v4l_print_framebuffer, INFO_FL_PRIO), IOCTL_INFO_STD(VIDIOC_OVERLAY, vidioc_overlay, v4l_print_u32, INFO_FL_PRIO), IOCTL_INFO_FNC(VIDIOC_QBUF, v4l_qbuf, v4l_print_buffer, INFO_FL_QUEUE), + IOCTL_INFO_FNC(VIDIOC_EXPBUF, v4l_expbuf, v4l_print_exportbuffer, INFO_FL_CLEAR(v4l2_exportbuffer, flags)), ...use IOCTL_INFO_STD instead. IOCTL_INFO_FNC(VIDIOC_DQBUF, v4l_dqbuf, v4l_print_buffer, INFO_FL_QUEUE), IOCTL_INFO_FNC(VIDIOC_STREAMON, v4l_streamon, v4l_print_buftype, INFO_FL_PRIO | INFO_FL_QUEUE), IOCTL_INFO_FNC(VIDIOC_STREAMOFF, v4l_streamoff, v4l_print_buftype, INFO_FL_PRIO | INFO_FL_QUEUE), diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h index 7f918dc..b5d058b 100644 --- a/include/linux/videodev2.h +++ b/include/linux/videodev2.h @@ -688,6 +688,31 @@ struct v4l2_buffer { #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800 #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000 +/** + * struct v4l2_exportbuffer - export of video buffer as DMABUF file descriptor + * + * @fd: file descriptor associated with DMABUF (set by driver) + * @mem_offset: buffer memory offset as returned by VIDIOC_QUERYBUF in struct + * v4l2_buffer::m.offset (for single-plane formats) or + * v4l2_plane::m.offset (for multi-planar formats) + * @flags: flags for newly created file, currently only O_CLOEXEC is + * supported, refer to manual of open syscall for more details + * + * Contains data used for exporting a video buffer as DMABUF file descriptor. + * The buffer is identified by a
Re: [PATCHv8 19/26] v4l: vb2: add buffer exporting via dmabuf
On Tue August 14 2012 17:34:49 Tomasz Stanislawski wrote: This patch adds extension to videobuf2-core. It allow to export a mmap buffer as a file descriptor. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/videobuf2-core.c | 67 ++ include/media/videobuf2-core.h |2 + 2 files changed, 69 insertions(+) diff --git a/drivers/media/video/videobuf2-core.c b/drivers/media/video/videobuf2-core.c index aed21e4..61354ec 100644 --- a/drivers/media/video/videobuf2-core.c +++ b/drivers/media/video/videobuf2-core.c @@ -1743,6 +1743,73 @@ static int __find_plane_by_offset(struct vb2_queue *q, unsigned long off, } /** + * vb2_expbuf() - Export a buffer as a file descriptor + * @q: videobuf2 queue + * @eb: export buffer structure passed from userspace to vidioc_expbuf + * handler in driver + * + * The return values from this function are intended to be directly returned + * from vidioc_expbuf handler in driver. + */ +int vb2_expbuf(struct vb2_queue *q, struct v4l2_exportbuffer *eb) +{ + struct vb2_buffer *vb = NULL; + struct vb2_plane *vb_plane; + unsigned int buffer, plane; + int ret; + struct dma_buf *dbuf; + + if (q-memory != V4L2_MEMORY_MMAP) { + dprintk(1, Queue is not currently set up for mmap\n); + return -EINVAL; + } + + if (!q-mem_ops-get_dmabuf) { + dprintk(1, Queue does not support DMA buffer exporting\n); + return -EINVAL; + } + + if (eb-flags ~O_CLOEXEC) { + dprintk(1, Queue does support only O_CLOEXEC flag\n); + return -EINVAL; + } + + /* + * Find the plane corresponding to the offset passed by userspace. + */ + ret = __find_plane_by_offset(q, eb-mem_offset, buffer, plane); + if (ret) { + dprintk(1, invalid offset %u\n, eb-mem_offset); + return ret; + } + + vb = q-bufs[buffer]; + vb_plane = vb-planes[plane]; + + dbuf = call_memop(q, get_dmabuf, vb_plane-mem_priv); + if (IS_ERR_OR_NULL(dbuf)) { + dprintk(1, Failed to export buffer %d, plane %d\n, + buffer, plane); + return -EINVAL; + } + + ret = dma_buf_fd(dbuf, eb-flags); + if (ret 0) { + dprintk(3, buffer %d, plane %d failed to export (%d)\n, + buffer, plane, ret); + dma_buf_put(dbuf); + return ret; + } + + dprintk(3, buffer %d, plane %d exported as %d descriptor\n, + buffer, plane, ret); + eb-fd = ret; + + return 0; +} +EXPORT_SYMBOL_GPL(vb2_expbuf); + +/** * vb2_mmap() - map video buffers into application address space * @q: videobuf2 queue * @vma: vma passed to the mmap file operation handler in the driver diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index c306fec..b034424 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -81,6 +81,7 @@ struct vb2_fileio_data; struct vb2_mem_ops { void*(*alloc)(void *alloc_ctx, unsigned long size); void(*put)(void *buf_priv); + struct dma_buf *(*get_dmabuf)(void *buf_priv); void*(*get_userptr)(void *alloc_ctx, unsigned long vaddr, unsigned long size, int write); @@ -363,6 +364,7 @@ int vb2_queue_init(struct vb2_queue *q); void vb2_queue_release(struct vb2_queue *q); int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b); +int vb2_expbuf(struct vb2_queue *q, struct v4l2_exportbuffer *eb); int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b, bool nonblocking); int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type type); Please add a vb2_ioctl_expbuf helper function as well! Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 23/26] v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING
On Tue August 14 2012 17:34:53 Tomasz Stanislawski wrote: From: Marek Szyprowski m.szyprow...@samsung.com Please add some more information in the commit message. I've no idea what's going on here or why :-) Regards, Hans Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- drivers/media/video/atmel-isi.c |2 +- drivers/media/video/blackfin/bfin_capture.c |2 +- drivers/media/video/marvell-ccic/mcam-core.c |3 ++- drivers/media/video/mx2_camera.c |2 +- drivers/media/video/mx2_emmaprp.c|2 +- drivers/media/video/mx3_camera.c |2 +- drivers/media/video/s5p-fimc/fimc-core.c |2 +- drivers/media/video/s5p-fimc/fimc-lite.c |2 +- drivers/media/video/s5p-g2d/g2d.c|2 +- drivers/media/video/s5p-jpeg/jpeg-core.c |2 +- drivers/media/video/s5p-mfc/s5p_mfc.c|5 ++-- drivers/media/video/s5p-tv/mixer_video.c |2 +- drivers/media/video/sh_mobile_ceu_camera.c |2 +- drivers/media/video/videobuf2-dma-contig.c | 33 +++--- drivers/staging/media/dt3155v4l/dt3155v4l.c |2 +- include/media/videobuf2-dma-contig.h |4 +++- 16 files changed, 44 insertions(+), 25 deletions(-) diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c index 6274a91..9fb5283 100644 --- a/drivers/media/video/atmel-isi.c +++ b/drivers/media/video/atmel-isi.c @@ -1000,7 +1000,7 @@ static int __devinit atmel_isi_probe(struct platform_device *pdev) list_add(isi-dma_desc[i].list, isi-dma_desc_head); } - isi-alloc_ctx = vb2_dma_contig_init_ctx(pdev-dev); + isi-alloc_ctx = vb2_dma_contig_init_ctx(pdev-dev, 0); if (IS_ERR(isi-alloc_ctx)) { ret = PTR_ERR(isi-alloc_ctx); goto err_alloc_ctx; diff --git a/drivers/media/video/blackfin/bfin_capture.c b/drivers/media/video/blackfin/bfin_capture.c index 1677623..7e90b65 100644 --- a/drivers/media/video/blackfin/bfin_capture.c +++ b/drivers/media/video/blackfin/bfin_capture.c @@ -893,7 +893,7 @@ static int __devinit bcap_probe(struct platform_device *pdev) } bcap_dev-ppi-priv = bcap_dev; - bcap_dev-alloc_ctx = vb2_dma_contig_init_ctx(pdev-dev); + bcap_dev-alloc_ctx = vb2_dma_contig_init_ctx(pdev-dev, 0); if (IS_ERR(bcap_dev-alloc_ctx)) { ret = PTR_ERR(bcap_dev-alloc_ctx); goto err_free_ppi; diff --git a/drivers/media/video/marvell-ccic/mcam-core.c b/drivers/media/video/marvell-ccic/mcam-core.c index ce2b7b4..10d4db5 100644 --- a/drivers/media/video/marvell-ccic/mcam-core.c +++ b/drivers/media/video/marvell-ccic/mcam-core.c @@ -,7 +,8 @@ static int mcam_setup_vb2(struct mcam_camera *cam) #ifdef MCAM_MODE_DMA_CONTIG vq-ops = mcam_vb2_ops; vq-mem_ops = vb2_dma_contig_memops; - cam-vb_alloc_ctx = vb2_dma_contig_init_ctx(cam-dev); + cam-vb_alloc_ctx = vb2_dma_contig_init_ctx(cam-dev, + VB2_CREATE_VADDR); vq-io_modes = VB2_MMAP | VB2_USERPTR; cam-dma_setup = mcam_ctlr_dma_contig; cam-frame_complete = mcam_dma_contig_done; diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c index 637bde8..5c30302 100644 --- a/drivers/media/video/mx2_camera.c +++ b/drivers/media/video/mx2_camera.c @@ -1766,7 +1766,7 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev) if (cpu_is_mx25()) pcdev-soc_host.capabilities = SOCAM_HOST_CAP_STRIDE; - pcdev-alloc_ctx = vb2_dma_contig_init_ctx(pdev-dev); + pcdev-alloc_ctx = vb2_dma_contig_init_ctx(pdev-dev, 0); if (IS_ERR(pcdev-alloc_ctx)) { err = PTR_ERR(pcdev-alloc_ctx); goto eallocctx; diff --git a/drivers/media/video/mx2_emmaprp.c b/drivers/media/video/mx2_emmaprp.c index 2810015..23c6c42 100644 --- a/drivers/media/video/mx2_emmaprp.c +++ b/drivers/media/video/mx2_emmaprp.c @@ -962,7 +962,7 @@ static int emmaprp_probe(struct platform_device *pdev) 0, MEM2MEM_NAME, pcdev) 0) goto rel_vdev; - pcdev-alloc_ctx = vb2_dma_contig_init_ctx(pdev-dev); + pcdev-alloc_ctx = vb2_dma_contig_init_ctx(pdev-dev, 0); if (IS_ERR(pcdev-alloc_ctx)) { v4l2_err(pcdev-v4l2_dev, Failed to alloc vb2 context\n); ret = PTR_ERR(pcdev-alloc_ctx); diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c index f13643d..882026f 100644 --- a/drivers/media/video/mx3_camera.c +++ b/drivers/media/video/mx3_camera.c @@ -1227,7 +1227,7 @@ static int __devinit mx3_camera_probe(struct platform_device *pdev) soc_host-v4l2_dev.dev = pdev-dev; soc_host-nr= pdev-id; - mx3_cam-alloc_ctx = vb2_dma_contig_init_ctx(pdev-dev);
[RFC patch 4/4] Re: dma-buf-mgr: multiple dma-buf synchronization (v3)
Hey Dan, Op 16-08-12 01:12, Daniel Vetter schreef: Hi Maarten, Ok, here comes the promised review (finally!), but it's rather a high-level thingy. I've mostly thought about how we could create a neat api with the following points. For a bit of clarity, I've grouped the different considerations a bit. snip Thanks, I have significantly reworked the api based on your comments. Documentation is currently lacking, and will get updated again for the final version. Full patch series also includes some ttm changes to make use of dma-reservation, with the intention of moving out fencing from ttm too, but that requires more work. For the full series see: http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip My plan is to add a pointer for dma_reservation to a dma-buf, so all users of dma-reservation can perform reservations across multiple devices as well. Since the default for ttm likely will mean only a few buffers are shared I didn't want to complicate the abi for ttm much further so only added a pointer that can be null to use ttm's reservation_object structure. The major difference with ttm is that each reservation object gets its own lock for fencing and reservations, but they can be merged: spin_lock(obj-resv) __dma_object_reserve() grab a ref to all obj-fences spin_unlock(obj-resv) spin_lock(obj-resv) assign new fence to obj-fences __dma_object_unreserve() spin_unlock(obj-resv) There's only one thing about fences I haven't been able to map yet properly. vmwgfx has sync_obj_flush, but as far as I can tell it has not much to do with sync objects, but is rather a generic 'flush before release'. Maybe one of the vmwgfx devs could confirm whether that call is really needed there? And if so, if there could be some other way do that, because it seems to be the ttm_bo_wait call before that would be enough, if not it might help more to move the flush to some other call. PS: For ttm devs some of the code may look familiar, I don't know if the kernel accepts I-told-you-so tag or not, but if it does you might want to add them now. :-) PPS: I'm aware that I still need to add a signaled op to fences diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 030f705..7da9637 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -129,6 +129,8 @@ X!Edrivers/base/interface.c !Edrivers/base/dma-fence.c !Iinclude/linux/dma-fence.h !Iinclude/linux/dma-seqno-fence.h +!Edrivers/base/dma-reservation.c +!Iinclude/linux/dma-reservation.h !Edrivers/base/dma-coherent.c !Edrivers/base/dma-mapping.c /sect1 diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 6e9f217..b26e639 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o obj-y += power/ obj-$(CONFIG_HAS_DMA) += dma-mapping.o obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o -obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o +obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o dma-reservation.o obj-$(CONFIG_ISA) += isa.o obj-$(CONFIG_FW_LOADER)+= firmware_class.o obj-$(CONFIG_NUMA) += node.o diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 24e88fe..3c84ead 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -25,8 +25,10 @@ #include linux/fs.h #include linux/slab.h #include linux/dma-buf.h +#include linux/dma-fence.h #include linux/anon_inodes.h #include linux/export.h +#include linux/dma-reservation.h static inline int is_dma_buf_file(struct file *); @@ -40,6 +42,9 @@ static int dma_buf_release(struct inode *inode, struct file *file) dmabuf = file-private_data; dmabuf-ops-release(dmabuf); + + if (dmabuf-resv == (struct dma_reservation_object*)dmabuf[1]) + dma_reservation_object_fini(dmabuf-resv); kfree(dmabuf); return 0; } @@ -94,6 +99,8 @@ struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops, { struct dma_buf *dmabuf; struct file *file; + size_t alloc_size = sizeof(struct dma_buf); + alloc_size += sizeof(struct dma_reservation_object); if (WARN_ON(!priv || !ops || !ops-map_dma_buf @@ -105,13 +112,15 @@ struct dma_buf *dma_buf_export(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); dmabuf-priv = priv; dmabuf-ops = ops; dmabuf-size = size; + dmabuf-resv = (struct dma_reservation_object*)dmabuf[1]; + dma_reservation_object_init(dmabuf-resv); file = anon_inode_getfile(dmabuf, dma_buf_fops, dmabuf, flags); diff --git a/drivers/base/dma-reservation.c
Re: [PATCHv8 01/26] v4l: Add DMABUF as a memory type
Hi Hans, Thank your for the review. Please refer to the comments below. On 08/22/2012 12:27 PM, Hans Verkuil wrote: On Tue August 14 2012 17:34:31 Tomasz Stanislawski wrote: From: Sumit Semwal sumit.sem...@ti.com Adds DMABUF memory type to v4l framework. Also adds the related file descriptor in v4l2_plane and v4l2_buffer. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com [original work in the PoC for buffer sharing] Signed-off-by: Sumit Semwal sumit.sem...@ti.com Signed-off-by: Sumit Semwal sumit.sem...@linaro.org Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/v4l2-compat-ioctl32.c | 18 ++ drivers/media/video/v4l2-ioctl.c |1 + include/linux/videodev2.h |7 +++ 3 files changed, 26 insertions(+) diff --git a/drivers/media/video/v4l2-compat-ioctl32.c b/drivers/media/video/v4l2-compat-ioctl32.c index 9ebd5c5..a2e0549 100644 --- a/drivers/media/video/v4l2-compat-ioctl32.c +++ b/drivers/media/video/v4l2-compat-ioctl32.c @@ -304,6 +304,7 @@ struct v4l2_plane32 { union { __u32 mem_offset; compat_long_t userptr; +__u32 fd; Shouldn't this be int? Notice that this field should be consistent with fd field used in 'struct v4l2_exportbuffer'. Therefore I prefer to use fixed-size types. One could use __s32 here but notice that file descriptors are defined as small, nonnegative integers according to POSIX spec. The type __u32 suits well for this purpose. The negative values returned by open syscall are used only to indicate failures. On the other hand, using __s32 may help to avoid compiler warning while building userspace apps due to 'signed-vs-unsigned comparisons'. However, I do not have any strong opinion about 'int vs __u32' issue :). Do you think that using __s32 for both QUERYBUF and EXPBUF is a good compromise? } m; __u32 data_offset; __u32 reserved[11]; @@ -325,6 +326,7 @@ struct v4l2_buffer32 { __u32 offset; compat_long_t userptr; compat_caddr_t planes; +__u32 fd; Ditto. } m; __u32 length; __u32 reserved2; Regards, Hans Regards, Tomasz ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] console_lock debug improvements
On Wed, 22 Aug 2012 00:34:30 +0200 Daniel Vetter daniel.vet...@ffwll.ch wrote: Hi all, After Dave Airlie blew through a few days to track down a deadlock at boot-up when handing over from the firmware fb to the kms/drm framebuffer driver (1), I've figured that lockdep /should/ have caught this. And indeed, by adding proper annotations to the console_lock it complains about the potential deadlock when exercising the entire driver life-cycle of just one fb driver (i.e. not even a handover required). While at it, I've replaced the existing in_interrupt check with the more paranoid might_sleep. Comments, flames and review highly welcome. This will be an absolute godsend for DRI debugging. Definitely wants to go in. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC patch 4/4] Re: dma-buf-mgr: multiple dma-buf synchronization (v3)
Hey, Op 22-08-12 14:52, Thomas Hellstrom schreef: Hi, Maarten, please see some comments inline. On 08/22/2012 01:50 PM, Maarten Lankhorst wrote: Hey Dan, Op 16-08-12 01:12, Daniel Vetter schreef: Hi Maarten, Ok, here comes the promised review (finally!), but it's rather a high-level thingy. I've mostly thought about how we could create a neat api with the following points. For a bit of clarity, I've grouped the different considerations a bit. snip Thanks, I have significantly reworked the api based on your comments. Documentation is currently lacking, and will get updated again for the final version. Full patch series also includes some ttm changes to make use of dma-reservation, with the intention of moving out fencing from ttm too, but that requires more work. For the full series see: http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip My plan is to add a pointer for dma_reservation to a dma-buf, so all users of dma-reservation can perform reservations across multiple devices as well. Since the default for ttm likely will mean only a few buffers are shared I didn't want to complicate the abi for ttm much further so only added a pointer that can be null to use ttm's reservation_object structure. The major difference with ttm is that each reservation object gets its own lock for fencing and reservations, but they can be merged: TTM previously had a lock on each buffer object which protected sync_obj and sync_obj_arg, however when fencing multiple buffers, say 100 buffers or so in a single command submission, it meant 100 locks / unlocks that weren't really necessary, since just updating the sync_obj and sync_obj_arg members is a pretty quick operation, whereas locking may be a pretty slow operation, so those locks were removed for efficiency. Speaking of which, mind if I kill sync_obj_arg? Only user is again vmwgfx and it always seems to pass the same for flags, namely DRM_VMW_FENCE_FLAG_EXEC. The reason a single lock (the lru lock) is used to protect reservation is that a TTM object that is being reserved *atomically* needs to be taken off LRU lists, since processes performing LRU eviction don't take a ticket when evicting, and may thus cause deadlocks; It might be possible to fix this within TTM by requiring a ticket for all reservation, but then that ticket needs to be passed down the call chain for all functions that may perform a reservation. It would perhaps be simpler (but perhaps not so fair) to use the current thread info pointer as a ticket sequence number. Yeah, that's why the ttm patch for ttm_bo_reserve_locked always calls dma_object_reserve with no_wait set to true. :) It does its own EBUSY handling for the no_wait case, so there should be no functional changes. I've been toying with the idea of always requiring a sequence number, I just didn't in the current patch yet since it would mean converting every driver, so for a preliminary patch based on a unmerged api it was not worth the time. spin_lock(obj-resv) __dma_object_reserve() grab a ref to all obj-fences spin_unlock(obj-resv) spin_lock(obj-resv) assign new fence to obj-fences __dma_object_unreserve() spin_unlock(obj-resv) There's only one thing about fences I haven't been able to map yet properly. vmwgfx has sync_obj_flush, but as far as I can tell it has not much to do with sync objects, but is rather a generic 'flush before release'. Maybe one of the vmwgfx devs could confirm whether that call is really needed there? And if so, if there could be some other way do that, because it seems to be the ttm_bo_wait call before that would be enough, if not it might help more to move the flush to some other call. The fence flush should be interpreted as an operation for fencing mechanisms that aren't otherwise required to signal in finite time, and where the time from flush to signal might be substantial. TTM is then supposed to issue a fence flush when it knows ahead of time that it will soon perform a periodical poll for a buffer to be idle, but not block waiting for the buffer to be idle. The delayed buffer delete mechanism is, I think, the only user currently. For hardware that always signal fences immediately, the flush mechanism is not needed. So if I understand it correctly it is the same as I'm doing in fences with dma_fence::enable_sw_signals? Great, I don't need to add another op then. Although it looks like I should export a function to manually enable it for those cases. :) snip + +int +__dma_object_reserve(struct dma_reservation_object *obj, bool intr, + bool no_wait, dma_reservation_ticket_t *ticket) +{ +int ret; +u64 sequence = ticket ? ticket-seqno : 0; + +while (unlikely(atomic_cmpxchg(obj-reserved, 0, 1) != 0)) { +/** + * Deadlock avoidance for multi-dmabuf reserving. + */ +if (sequence obj-sequence) { +/** +
Re: [RFC patch 4/4] Re: dma-buf-mgr: multiple dma-buf synchronization (v3)
On 08/22/2012 03:32 PM, Maarten Lankhorst wrote: Hey, Op 22-08-12 14:52, Thomas Hellstrom schreef: Hi, Maarten, please see some comments inline. On 08/22/2012 01:50 PM, Maarten Lankhorst wrote: Hey Dan, Op 16-08-12 01:12, Daniel Vetter schreef: Hi Maarten, Ok, here comes the promised review (finally!), but it's rather a high-level thingy. I've mostly thought about how we could create a neat api with the following points. For a bit of clarity, I've grouped the different considerations a bit. snip Thanks, I have significantly reworked the api based on your comments. Documentation is currently lacking, and will get updated again for the final version. Full patch series also includes some ttm changes to make use of dma-reservation, with the intention of moving out fencing from ttm too, but that requires more work. For the full series see: http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip My plan is to add a pointer for dma_reservation to a dma-buf, so all users of dma-reservation can perform reservations across multiple devices as well. Since the default for ttm likely will mean only a few buffers are shared I didn't want to complicate the abi for ttm much further so only added a pointer that can be null to use ttm's reservation_object structure. The major difference with ttm is that each reservation object gets its own lock for fencing and reservations, but they can be merged: TTM previously had a lock on each buffer object which protected sync_obj and sync_obj_arg, however when fencing multiple buffers, say 100 buffers or so in a single command submission, it meant 100 locks / unlocks that weren't really necessary, since just updating the sync_obj and sync_obj_arg members is a pretty quick operation, whereas locking may be a pretty slow operation, so those locks were removed for efficiency. Speaking of which, mind if I kill sync_obj_arg? Only user is again vmwgfx and it always seems to pass the same for flags, namely DRM_VMW_FENCE_FLAG_EXEC. I guess so, although I've always thought it to be a great idea :), but nobody really understands or care what it's for. Which is a single fence might have multiple definitions of signaled, depending on the user: Consider an awkward GPU with a single command stream that feeds multiple engines. The command parser signals when it has parsed the commands, the 2D engine signals when it is done with the 2D commands it has been fed, and the 3D engine signals when the 3D engine is done, and finally the flush engine signals when all rendered data is flushed. Depending on which engines touch a buffer, each buffer may have a different view on when the attached fence is signaled. But anyway. No in-tree driver is using it, (the old unichrome driver did), and I guess the same functionality can be implemented with multiple fences attached to a single buffer, so feel free to get rid of it. The reason a single lock (the lru lock) is used to protect reservation is that a TTM object that is being reserved *atomically* needs to be taken off LRU lists, since processes performing LRU eviction don't take a ticket when evicting, and may thus cause deadlocks; It might be possible to fix this within TTM by requiring a ticket for all reservation, but then that ticket needs to be passed down the call chain for all functions that may perform a reservation. It would perhaps be simpler (but perhaps not so fair) to use the current thread info pointer as a ticket sequence number. Yeah, that's why the ttm patch for ttm_bo_reserve_locked always calls dma_object_reserve with no_wait set to true. :) It does its own EBUSY handling for the no_wait case, so there should be no functional changes. I need to look a bit deeper into the TTM patches, but as long as nothing breaks I've nothing against it using dma reservation objects. OTOH, it might be worthwhile thinking about the 'dma' prefix, since the reservation objects may find use elsewhere as well, for example for vmwgfx resources, that really have little to do with dma-buffers or buffers at all. I've been toying with the idea of always requiring a sequence number, I just didn't in the current patch yet since it would mean converting every driver, so for a preliminary patch based on a unmerged api it was not worth the time. spin_lock(obj-resv) __dma_object_reserve() grab a ref to all obj-fences spin_unlock(obj-resv) spin_lock(obj-resv) assign new fence to obj-fences __dma_object_unreserve() spin_unlock(obj-resv) There's only one thing about fences I haven't been able to map yet properly. vmwgfx has sync_obj_flush, but as far as I can tell it has not much to do with sync objects, but is rather a generic 'flush before release'. Maybe one of the vmwgfx devs could confirm whether that call is really needed there? And if so, if there could be some other way do that, because it seems to be the ttm_bo_wait call before that would be enough, if not it might help more to move the flush to some
[PATCH 1/2] drm/radeon: fix reading CB_COLORn_MASK from the CS
Signed-off-by: Marek Olšák mar...@gmail.com --- drivers/gpu/drm/radeon/r600_cs.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c index ab74e6b..7799e28 100644 --- a/drivers/gpu/drm/radeon/r600_cs.c +++ b/drivers/gpu/drm/radeon/r600_cs.c @@ -1416,7 +1416,7 @@ static int r600_cs_check_reg(struct radeon_cs_parser *p, u32 reg, u32 idx) case R_028118_CB_COLOR6_MASK: case R_02811C_CB_COLOR7_MASK: tmp = (reg - R_028100_CB_COLOR0_MASK) / 4; - track-cb_color_mask[tmp] = ib[idx]; + track-cb_color_mask[tmp] = radeon_get_ib_value(p, idx); if (G_0280A0_TILE_MODE(track-cb_color_info[tmp])) { track-cb_dirty = true; } -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon: initialize tracked CS state
This should help catch uninitialized registers and reject commands because of that. Signed-off-by: Marek Olšák mar...@gmail.com --- drivers/gpu/drm/radeon/r600_cs.c |9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c index 7799e28..8866937 100644 --- a/drivers/gpu/drm/radeon/r600_cs.c +++ b/drivers/gpu/drm/radeon/r600_cs.c @@ -315,7 +315,14 @@ static void r600_cs_track_init(struct r600_cs_track *track) track-cb_color_bo[i] = NULL; track-cb_color_bo_offset[i] = 0x; track-cb_color_bo_mc[i] = 0x; - } + track-cb_color_frag_bo[i] = NULL; + track-cb_color_frag_offset[i] = 0x; + track-cb_color_tile_bo[i] = NULL; + track-cb_color_tile_offset[i] = 0x; + track-cb_color_mask[i] = 0x; + } + track-nsamples = 16; + track-log_nsamples = 4; track-cb_target_mask = 0x; track-cb_shader_mask = 0x; track-cb_dirty = true; -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46331] New: OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 Summary: OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests Product: Drivers Version: 2.5 Kernel Version: 3.6.0-rc2+ Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: jlp.b...@gmail.com Regression: No I have run r600 piglit tests and the OOPS error screen showed up with this: BUG: unable to handle kernel NULL pointer dereference at 0008 IP: [a01762f4] radeon_ttm_bo_destroy+0x34/0xd0 [radeon] PGD 108522067 PUD 123182067 PMD 0 Oops: 0002 [#1] PREEMPT SMP Modules linked in: asus_atk0110 usb_storage snd_hda_codec_hdmi radeon snd_hda_codec_realtek i2c_algo_bit snd_hda_intel snd_hda_codec snd_pcm coretemp aesni_intel aes_x86_64 r8169 hwmon drm_kms_helper ttm drm aes_generic xhci_hcd i2c_i801 mii ablk_helper cryptd video snd_page_alloc snd_timer snd ehci_hcd wmi CPU 0 Pid: 14945, comm: max-texture-siz Not tainted 3.6.0-rc2-00124-g6dab7ed #1 System manufacturer System Product Name/P8H67 RIP: 0010:[a01762f4] [a01762f4] radeon_ttm_bo_destroy+0x34/0xd0 [radeon] RSP: 0018:8800d9fbfb18 EFLAGS: 00010282 RAX: 8802059c6800 RBX: 8802059c6848 RCX: RDX: RSI: RDI: 8802147f6ed8 RBP: 8802059c6800 R08: R09: 88021ec13f40 R10: ea00035a0540 R11: a00bab18 R12: 8802147f6580 R13: 8802059c6848 R14: 8802059c6848 R15: 8802059c6888 FS: 7f7fcdf95740() GS:88021ec0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0008 CR3: d6db1000 CR4: 000407f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process max-texture-siz (pid: 14945, threadinfo 8800d9fbe000, task 880215376600) Stack: 8802059c688c 00400480 8802147f6580 a007481d 0001 0001 8802147f65a0 8802147f69a8 8802133f11f8 a00758a4 0296 0003 Call Trace: [a007481d] ? ttm_bo_release_list+0xad/0x100 [ttm] [a00758a4] ? ttm_bo_release+0x194/0x230 [ttm] [a007597d] ? ttm_bo_unref+0x3d/0x60 [ttm] [a007751c] ? ttm_bo_init+0x2ac/0x3f0 [ttm] [a0176614] ? radeon_bo_create+0x1f4/0x300 [radeon] [a01762c0] ? radeon_bo_clear_va+0x50/0x50 [radeon] [a0187df4] ? radeon_gem_object_create+0x64/0x110 [radeon] [a018816c] ? radeon_gem_create_ioctl+0x6c/0x120 [radeon] [a00b011c] ? drm_ioctl+0x40c/0x4c0 [drm] [a0188100] ? radeon_gem_pwrite_ioctl+0x30/0x30 [radeon] [81028362] ? do_page_fault+0x182/0x440 [8110460f] ? do_vfs_ioctl+0x8f/0x530 [810be483] ? vm_mmap_pgoff+0x73/0xa0 [81104af9] ? sys_ioctl+0x49/0x80 [81473be2] ? system_call_fastpath+0x16/0x1b Code: 89 fb 48 89 6c 24 08 48 8d 6f b8 4c 89 64 24 10 48 8b bf c8 01 00 00 48 81 c7 d8 0e 00 00 e8 b4 aa 2f e1 48 8b 53 b8 48 8b 43 c0 48 89 42 08 48 89 10 48 8b bb c8 01 00 00 48 89 6b b8 48 89 6b RIP [a01762f4] radeon_ttm_bo_destroy+0x34/0xd0 [radeon] RSP 8800d9fbfb18 CR2: 0008 ---[ end trace 61e9627de8e05172 ]--- The card is Radeon HD 5750, I'm using Mesa from git (8d1a9a9), libdrm is also from git. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 --- Comment #2 from Jure Repinc jlp.b...@gmail.com 2012-08-22 19:21:04 --- Created an attachment (id=78181) -- (https://bugzilla.kernel.org/attachment.cgi?id=78181) lspci -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 --- Comment #3 from Jure Repinc jlp.b...@gmail.com 2012-08-22 19:21:32 --- Created an attachment (id=78191) -- (https://bugzilla.kernel.org/attachment.cgi?id=78191) cpuinfo -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 --- Comment #6 from Jure Repinc jlp.b...@gmail.com 2012-08-22 19:23:08 --- Created an attachment (id=78221) -- (https://bugzilla.kernel.org/attachment.cgi?id=78221) config -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 Alex Deucher alexdeuc...@gmail.com changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #7 from Alex Deucher alexdeuc...@gmail.com 2012-08-22 19:32:24 --- I believe this is fixed by this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=676bc2e1e4f9072f7a640d5b7c99ffdf9709a6e7 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests
https://bugzilla.kernel.org/show_bug.cgi?id=46331 Jure Repinc jlp.b...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||UNREPRODUCIBLE --- Comment #8 from Jure Repinc jlp.b...@gmail.com 2012-08-22 20:57:15 --- Updated the kernel to the latest revision which contains the patch and have run piglit test three time and no oops this time. So I'm closing as unreproducible with latest code. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] i915: use alloc_ordered_workqueue() instead of explicit UNBOUND w/ max_active = 1
This is an equivalent conversion and will ease scheduled removal of WQ_NON_REENTRANT. Signed-off-by: Tejun Heo t...@kernel.org --- drivers/gpu/drm/i915/i915_dma.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 9cf7dfe..a55ca7a 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1536,11 +1536,9 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) * * All tasks on the workqueue are expected to acquire the dev mutex * so there is no point in running more than one instance of the -* workqueue at any time: max_active = 1 and NON_REENTRANT. +* workqueue at any time. Use an ordered one. */ - dev_priv-wq = alloc_workqueue(i915, - WQ_UNBOUND | WQ_NON_REENTRANT, - 1); + dev_priv-wq = alloc_ordered_workqueue(i915, 0); if (dev_priv-wq == NULL) { DRM_ERROR(Failed to create our workqueue.\n); ret = -ENOMEM; ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #19 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-08-23 04:12:52 UTC --- So about this locking piglit test (depthstencil-render-miplevels 146 s=z24_s8_d=z32f_s8), I've been able to track it down to: line 218: piglit_report_result(PIGLIT_SKIP); I don't know if we are supposed to be hitting this path, but either way, it seems piglit_report_result(PIGLIT_SKIP) locks. I suppose this function must be releasing resources before exiting, but something wrong is happening in there. By the way, I'm now running kernel 3.6.0-rc3 with latest drm and mesa. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot
https://bugs.freedesktop.org/show_bug.cgi?id=42373 --- Comment #33 from Kunal kunal.gangakhed...@gmail.com 2012-08-23 04:58:33 UTC --- (In reply to comment #28) (In reply to comment #27) (In reply to comment #26) (In reply to comment #25) You might try the 5 patches starting with this one: http://lists.freedesktop.org/archives/dri-devel/2012-August/026498.html On top of previous patche(s) (by Jerome)? or as separate set? They apply on top of his patches. No luck :( It's still the same after applying those patches and rebuilding the kernel. Attaching the xorg log and dmesg log after this. Anything more that I can try? Or something wrong that I did? Do these patches need any additional bits from 3.6 kernels? Asking since the Ubuntu Quantal series is based on 3.5 while these patches are all fairly new. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: Update the MAX_EDID value for E-DDC
From: Shirish Shankarappa s.shir...@samsung.com The value of MAX_EDID is now valid only for 2 block EDID data which is 256, but to support 4 block EDID (E-DDC) this needs to be 512. Signed-off-by: Shirish Shankarappa s.shir...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c b/drivers/gpu/drm/exynos/exynos_drm_connector.c index d956819..69d02b5 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c @@ -32,7 +32,7 @@ #include exynos_drm_drv.h #include exynos_drm_encoder.h -#define MAX_EDID 256 +#define MAX_EDID 512 #define to_exynos_connector(x) container_of(x, struct exynos_drm_connector,\ drm_connector) -- 1.7.0.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] ACPI: export symbol acpi_get_table_with_size
2012/8/21 Alex Deucher alexdeuc...@gmail.com: Any objections from the ACPI folks to this patch going into 3.6 and stable? hi Alex: I saw the patch from Feng Tang. http://marc.info/?l=linux-acpim=134380363332502w=2 which is trying to replace acpi_get_table_with_size() with acpi_get_table(). Since the size can be get via struct acpi_table_header-length, acpi_get_table_with_size() is redundant and it will be removed. Alex On Mon, Aug 20, 2012 at 11:19 AM, alexdeuc...@gmail.com wrote: From: Alex Deucher alexander.deuc...@amd.com We need it in the radeon drm module to fetch and verify the vbios image on UEFI systems. Signed-off-by: Alex Deucher alexander.deuc...@amd.com Cc: sta...@vger.kernel.org --- drivers/acpi/acpica/tbxface.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c index ea4c6d5..29e51bc 100644 --- a/drivers/acpi/acpica/tbxface.c +++ b/drivers/acpi/acpica/tbxface.c @@ -387,6 +387,7 @@ acpi_get_table_with_size(char *signature, return (AE_NOT_FOUND); } +ACPI_EXPORT_SYMBOL(acpi_get_table_with_size) acpi_status acpi_get_table(char *signature, -- 1.7.7.5 -- To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best regards Tianyu Lan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Update MAX_EDID value in exynos
From: Shirish Shankarappa s.shir...@samsung.com The value of MAX_EDID is now valid only for 2 block EDID data which is 256, but to support 4 block EDID (E-DDC) this needs to be 512. Based on drm-next branch Shirish Shankarappa (1): drm/exynos: Update the MAX_EDID value for E-DDC drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm: edid: add support for E-DDC
From: Shirish Shankarappa s.shir...@samsung.com This patch adds support in probing 4 block edid data, for E-DDC. This is the first test case in CTS, for HDMI compliance. Changes from V1: 1. Data type of offset adress updated to unsigned short 2. Updated the buf feild of msg[0] Based on drm-next branch Shirish Shankarappa (1): drm: edid: add support for E-DDC drivers/gpu/drm/drm_edid.c | 19 +-- 1 files changed, 13 insertions(+), 6 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm: edid: add support for E-DDC
From: Shirish Shankarappa s.shir...@samsung.com The current logic for probing ddc is limited to 2 blocks (256 bytes), this patch adds support for the 4 block (512) data. To do this, a single 8-bit segment index is passed to the display via the I2C address 30h. Data from the selected segment is then immediately read via the regular DDC2 address using a repeated I2C 'START' signal. Signed-off-by: Shirish Shankarappa s.shir...@samsung.com --- drivers/gpu/drm/drm_edid.c | 19 +-- 1 files changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index a8743c3..33a3888 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -253,7 +253,9 @@ static int drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf, int block, int len) { - unsigned char start = block * EDID_LENGTH; + unsigned short start = block * EDID_LENGTH; + unsigned char segment = block 1; + unsigned short segFlags = segment ? 0 : I2C_M_IGNORE_NAK; int ret, retries = 5; /* The core i2c driver will automatically retry the transfer if the @@ -264,27 +266,32 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf, */ do { struct i2c_msg msgs[] = { - { + { /*set segment pointer */ + .addr = DDC_SEGMENT_ADDR, + .flags = segFlags, + .len= 1, + .buf= segment, + }, { /*set offset */ .addr = DDC_ADDR, .flags = 0, .len= 1, .buf= start, - }, { + }, { /*set data */ .addr = DDC_ADDR, .flags = I2C_M_RD, .len= len, .buf= buf, } }; - ret = i2c_transfer(adapter, msgs, 2); + ret = i2c_transfer(adapter, msgs, 3); if (ret == -ENXIO) { DRM_DEBUG_KMS(drm: skipping non-existent adapter %s\n, adapter-name); break; } - } while (ret != 2 --retries); + } while (ret != 3 --retries); - return ret == 2 ? 0 : -1; + return ret == 3 ? 0 : -1; } static bool drm_edid_is_zero(u8 *in_edid, int length) -- 1.7.0.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm: edid: add support for E-DDC
The current logic for probing ddc is limited to 2 blocks (256 bytes), this patch adds support for the 4 block (512) data. To do this, a single 8-bit segment index is passed to the display via the I2C address 30h. Data from the selected segment is then immediately read via the regular DDC2 address using a repeated I2C 'START' signal. Signed-off-by: Shirish S s.shir...@samsung.com --- drivers/gpu/drm/drm_edid.c | 19 +-- 1 files changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index a8743c3..33a3888 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -253,7 +253,9 @@ static int drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf, int block, int len) { - unsigned char start = block * EDID_LENGTH; + unsigned short start = block * EDID_LENGTH; + unsigned char segment = block 1; + unsigned short segFlags = segment ? 0 : I2C_M_IGNORE_NAK; int ret, retries = 5; /* The core i2c driver will automatically retry the transfer if the @@ -264,27 +266,32 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf, */ do { struct i2c_msg msgs[] = { - { + { /*set segment pointer */ + .addr = DDC_SEGMENT_ADDR, + .flags = segFlags, + .len= 1, + .buf= segment, + }, { /*set offset */ .addr = DDC_ADDR, .flags = 0, .len= 1, .buf= start, - }, { + }, { /*set data */ .addr = DDC_ADDR, .flags = I2C_M_RD, .len= len, .buf= buf, } }; - ret = i2c_transfer(adapter, msgs, 2); + ret = i2c_transfer(adapter, msgs, 3); if (ret == -ENXIO) { DRM_DEBUG_KMS(drm: skipping non-existent adapter %s\n, adapter-name); break; } - } while (ret != 2 --retries); + } while (ret != 3 --retries); - return ret == 2 ? 0 : -1; + return ret == 3 ? 0 : -1; } static bool drm_edid_is_zero(u8 *in_edid, int length) -- 1.7.0.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel