[Bug 46331] OOPS in radeon_ttm_bo_destroy when runing r600 piglit tests

[bugzilla-dae...@bugzilla.kernel.org]

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

[bugzilla-dae...@bugzilla.kernel.org]

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

[bugzilla-dae...@bugzilla.kernel.org]

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

[bugzilla-dae...@bugzilla.kernel.org]

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

[bugzilla-dae...@bugzilla.kernel.org]

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

[bugzilla-dae...@bugzilla.kernel.org]

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

[bugzilla-dae...@bugzilla.kernel.org]

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

[bugzilla-dae...@bugzilla.kernel.org]

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

[bugzilla-dae...@bugzilla.kernel.org]

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

[Shirish S]

From: Shirish Shankarappa 

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 
---
 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

[Shirish S]

From: Shirish Shankarappa 

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(-)

[PATCH] drm/exynos: Update the MAX_EDID value for E-DDC

[Shirish S]

From: Shirish Shankarappa 

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 
---
 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

[Shirish S]

From: Shirish Shankarappa 

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(-)

[RFC patch 4/4] Re: dma-buf-mgr: multiple dma-buf synchronization (v3)

[Daniel Vetter]

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

[Marek Olšák]

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

[Marek Olšák]

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

[Tejun Heo]

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

[Lan Tianyu]

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)

[Thomas Hellstrom]

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

[Dave Airlie]

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)

[Maarten Lankhorst]

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

[InKi Dae]

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)

[Thomas Hellstrom]

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

[Hans Verkuil]

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

[Alan Cox]

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

[InKi Dae]

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

[Tomasz Stanislawski]

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

[Dave Airlie]

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)

[Maarten Lankhorst]

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

[Hans Verkuil]

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

[Hans Verkuil]

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

[Hans Verkuil]

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

[Hans Verkuil]

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

[Hans Verkuil]

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

[InKi Dae]

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

[Laurent Pinchart]

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

[Alan Cox]

From: Alan Cox 

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 
---

 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

[Hans Verkuil]

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

[Hans Verkuil]

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

[Hans Verkuil]

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

[Ville Syrjälä]

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?

[Takashi Iwai]

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

[bugzilla-dae...@freedesktop.org]

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

[Dave Airlie]

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

[bugzilla-dae...@freedesktop.org]

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

[Daniel Vetter]

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

[Daniel Vetter]

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

[Daniel Vetter]

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

[InKi Dae]

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

[Josh Boyer]

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]

-- 
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?

[Ricardo Neri]

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

[Ville Syrjälä]

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?

[Takashi Iwai]

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

[Hans Verkuil]

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

[Alan Cox]

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

[Laurent Pinchart]

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

[Hans Verkuil]

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

[Hans Verkuil]

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

[Hans Verkuil]

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

[Hans Verkuil]

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)

[Maarten Lankhorst]

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

[Tomasz Stanislawski]

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

[Alan Cox]

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)

[Maarten Lankhorst]

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)

[Thomas Hellstrom]

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

[Marek Olšák]

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

[Marek Olšák]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[Tejun Heo]

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

[bugzilla-daemon]

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

[bugzilla-daemon]

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

[Shirish S]

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

[Lan Tianyu]

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

[Shirish S]

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

[Shirish S]

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

[Shirish S]

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

[Shirish S]

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