On Thu August 23 2012 01:39:34 Laurent Pinchart wrote:
> Hi Hans,
>
> On Wednesday 22 August 2012 13:41:05 Hans Verkuil wrote:
> > 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 i
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #20 from Michel Dänzer 2012-08-23 06:45:54 UTC
---
(In reply to comment #19)
> 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
https://bugzilla.kernel.org/show_bug.cgi?id=46331
--- Comment #9 from Michel Dänzer 2012-08-23 06:28:27 ---
(In reply to comment #8)
> 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 unreprod
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
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 S (1):
drm: edid: add support f
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 S
---
drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/
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 S (1):
drm/exynos: Update the MAX_EDID value for E-DDC
drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +-
1 files chang
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 v
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 Shank
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_dr
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&m=134380363332502&w=2
which is trying to replace acpi_get_table_with_size() with
acpi_get_table(). Since t
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 d
https://bugs.freedesktop.org/show_bug.cgi?id=42373
--- Comment #33 from Kunal 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:/
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #19 from Alexandre Demers 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);
https://bugzilla.kernel.org/show_bug.cgi?id=46331
Jure Repinc changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=46331
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
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
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
---
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
--- Yo
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
--- Yo
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
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
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
T
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 v
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 Shank
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 d
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_dr
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
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
i
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/rad
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
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
Hi Hans,
On Wednesday 22 August 2012 13:41:05 Hans Verkuil wrote:
> 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 m
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&m=134380363332502&w=2
which is trying to replace acpi_get_table_with_size() with
acpi_get_table(). Since t
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,
>>
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 fi
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 rathe
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
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
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 memor
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 i
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 t
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_pl
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
https://bugzilla.kernel.org/show_bug.cgi?id=46331
Jure Repinc changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 consid
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 DM
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
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/video
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
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
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
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 b
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 deletio
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 e
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
https://bugzilla.kernel.org/show_bug.cgi?id=46331
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #7 f
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-
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
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
---
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
--- Yo
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
--- Yo
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
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
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
T
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
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 th
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
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
i
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/rad
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 revie
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 rathe
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 i
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 nea
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 inc
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 memor
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_pl
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 ACP
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 consid
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 DM
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
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/video
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
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-...@vger.kernel.org
> ---
> Documentation/DocBook/media/v4
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 b
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 deletio
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 e
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-...@vger.kernel.org
> ---
> Documentation/DocBook/media/v4
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-
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: i
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 th
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/ar
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
lo
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 conso
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
95 matches
Mail list logo
