We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in mode_fixup failures and
ultimately black screens.
Th
On Tue, 10 Apr 2012 09:33:19 +0200, Daniel Vetter
wrote:
> We've only computed whether we need to fall back to 6bpc due to dp
> link bandwidth constrains in mode_valid, but not mode_fixup. Under
> various circumstances X likes to create new modes which then lack
> proper 6bpc flags (if required),
We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in mode_fixup failures and
ultimately black screens.
Ch
We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in mode_fixup failures and
ultimately black screens.
Ch
On 04/07/2012 12:40 AM, Thomas Gleixner wrote:
> On Fri, 6 Apr 2012, Jiri Slaby wrote:
>> It very looks like the generic IRQ handling code is broken. Like it
>> frees/corrupts irq_desc and ...
>
> OMG, your problem analyzing skills are amazing.
Hehe, no I did *no* analysis. I stand here as a bug
On 04/09/2012 07:11 PM, Jesse Barnes wrote:
> On Fri, 30 Mar 2012 11:45:43 +0100 Chris Wilson
> wrote:
>
>> On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby
>> wrote:
>>> I don't know what to dump more, because iir is obviously zero
>>> too. What other sources of interrupts are on the (G33) chip?
On Fri, Apr 6, 2012 at 23:31, Jiri Slaby wrote:
>> That was introduced in 05eff845a28499762075d3a72e238a31f4d2407c to close
>> a race where the pipestat triggered an interrupt after we processed the
>> secondary registers and before reseting the primary.
>>
>> But the basic premise that we should
On 04/06/2012 11:31 PM, Jiri Slaby wrote:
> On 03/30/2012 02:24 PM, Chris Wilson wrote:
>> On Fri, 30 Mar 2012 14:11:47 +0200, Jiri Slaby wrote:
>>> On 03/30/2012 12:45 PM, Chris Wilson wrote:
On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby wrote:
> I don't know what to dump more, because
On Tue, Apr 10, 2012 at 10:47:49AM +0200, Jiri Slaby wrote:
> On 04/09/2012 07:11 PM, Jesse Barnes wrote:
> > On Fri, 30 Mar 2012 11:45:43 +0100 Chris Wilson
> > wrote:
> >
> >> On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby
> >> wrote:
> >>> I don't know what to dump more, because iir is obviou
On 04/10/2012 10:58 AM, Daniel Vetter wrote:
> On Tue, Apr 10, 2012 at 10:47:49AM +0200, Jiri Slaby wrote:
>> On 04/09/2012 07:11 PM, Jesse Barnes wrote:
>>> On Fri, 30 Mar 2012 11:45:43 +0100 Chris Wilson
>>> wrote:
>>>
On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby
wrote:
> I don'
Hi,
in today's -next I see:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] pagevec_move_tail+0x30/0x30
PGD 1bf4fc067 PUD 1bf4f0067 PMD 0
Oops: [#1] SMP
CPU 0
Modules linked in: pl2303 usbserial microcode
Pid: 4260, comm: X Not tainted 3.4.0-rc2-next-20120410
Hello everyone,
The patcheset adds support for DMABUF [1] importing to vmalloc allocator in
videobuf2 stack. This is an incremental patch to 'Integration of videobuf2
with dmabuf' patchset [2]. This patch makes use of vmap extension for dmabuf
proposed by Dave Airlie [3].
The vmap was preferred ov
From: Dave Airlie
Add vmap to dmabuf interface.
Signed-off-by: Dave Airlie
---
drivers/base/dma-buf.c | 29 +
include/linux/dma-buf.h | 16
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dm
This patch adds support for importing DMABUF files for
vmalloc allocator in Videobuf2.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/videobuf2-vmalloc.c | 56 +++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --gi
This patch enhances VIVI driver with a support for importing a buffer
from DMABUF file descriptors.
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 deletions(-)
On Fri, Mar 30, 2012 at 07:46:39PM +0800, Daniel Kurtz wrote:
> The i915 is only able to generate a STOP cycle (i.e. finalize an i2c
> transaction) during a DATA or WAIT phase. In other words, the
> controller rejects a STOP requested as part of the first transaction in a
> sequence.
>
> Thus, fo
On Tue, Apr 10, 2012 at 12:37:46PM +0200, Daniel Vetter wrote:
> On Fri, Mar 30, 2012 at 07:46:39PM +0800, Daniel Kurtz wrote:
> > The i915 is only able to generate a STOP cycle (i.e. finalize an i2c
> > transaction) during a DATA or WAIT phase. In other words, the
> > controller rejects a STOP re
Hi all,
The first patch in this series fixes a long-standing hdmi-on-sdvo regression -
we apparently have not set up the pixel doubling (or quadrupling) correctly.
This regression was introduced in 2.6.36. Now if this patch is indeed correct,
hdmi on sdvo (and _only_ hdmi) for any pixelclock below
We seem to have a decent confusion between the output timings and the
input timings of the sdvo encoder. If I understand the code correctly,
we use the original mode unchanged for the output timings, safe for
the lvds case. And we should use the adjusted mode for input timings.
Clarify the situati
- kill intel_sdvo->input_dtd, it's only used as a temporary variable,
we store the preferred input mode in the adjusted mode at mode_fixup
time.
- rename the function to make it clear what we want it to do (get the
preferred mode) and say in a comment what it unfortunately does as a
side-ef
Unfortunately we can't abort a mode_set, but at least tell the user
that something might have gone wrong when setting the sdvo input or
output timing fails.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff
We round-trip quite often from sdvo dtd timings through drm mode back
to sdvo dtd timings, e.g. due to mode_fixup. Add an informational
message that tells us when we lose things on the way.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c |5 +
1 files changed, 5 insert
On Tue, 10 Apr 2012 13:55:47 +0200, Daniel Vetter
wrote:
> - kill intel_sdvo->input_dtd, it's only used as a temporary variable,
> we store the preferred input mode in the adjusted mode at mode_fixup
> time.
> - rename the function to make it clear what we want it to do (get the
> preferred
Hi Experts:
Wayland drm protocol is a help module for wayland client managing drm device
and buffer, it is used by graphics/mesa and video/vaapi. It can potentially be
used by camera too.
This module used to be in $mesa/src/egl/wayland/wayland-drm, however it's bad
style to export wl_drm_* by li
From: Marek Szyprowski
Let mmap method to use dma_mmap_coherent call. This patch depends on DMA
mapping redesign patches because the usage of dma_mmap_coherent breaks
dma-contig allocator for architectures other than ARM and AVR.
Signed-off-by: Marek Szyprowski
---
drivers/media/video/videobu
Hello everyone,
The patches adds support for DMABUF [1] exporting to V4L2 stack. It was
updated from [7] after Laurent Pinchart's review. The previous patchset was
split into two parts. The support for DMABUF importing was posted in [2]. The
exporter part is dependant on DMA mapping redesign [3]
This patch adds support for vmap and kmap callbacks
for DMABUF exporter.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/videobuf2-dma-contig.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v
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
---
drivers/media/video/videobuf2-core.c | 66 ++
include/media/videobuf2-core.h |2 +
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/v4
This patch enhances s5p-tv with support for DMABUF exporting via
VIDIOC_EXPBUF ioctl.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-tv/mixer_video.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/media/vid
This patch adds the setup of sglist list for MMAP buffers.
It is needed for buffer exporting via DMABUF mechanism.
This patch depends on dma_get_pages extension to DMA api.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/videobuf2-dma-contig.c | 51 +++
The DMABUF documentation says that the map_dma_buf callback should return
scatterlist that is mapped into a caller's address space. In practice, almost
none of existing implementations of DMABUF exporter does it. This patch breaks
the DMABUF specification in order to allow exchange DMABUF buffers
This patch enhances s5p-fimc with support for DMABUF exporting via
VIDIOC_EXPBUF ioctl.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/media/
The DMABUF documentation says that the map_dma_buf callback should return
scatterlist that is mapped into a caller's address space. In practice, almost
none of existing implementations of DMABUF exporter does it. This patch breaks
the DMABUF specification in order to allow exchange DMABUF buffers
This patch enhances s5p-tv with support for DMABUF importing via
V4L2_MEMORY_DMABUF memory type.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-tv/Kconfig |1 +
drivers/media/video/s5p-tv/mixer_video.c |2 +-
2 files changed, 2 insertio
This patch enhances s5p-fimc with support for DMABUF importing via
V4L2_MEMORY_DMABUF memory type.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/Kconfig |1 +
drivers/media/video/s5p-fimc/fimc-capture.c |2 +-
2 files changed, 2
This patch enhances vivi driver with a support for DMABUF exporting via
VIDIOC_EXPBUF ioctl.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/vivi.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/vivi.c
This patch adds support for exporting a dma-contig buffer using
DMABUF interface.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/videobuf2-dma-contig.c | 128
1 files changed, 128 insertions(+), 0 deletions(-)
diff --git a/
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #19 from Alex Deucher 2012-04-10 06:14:26 PDT ---
IIRC, Matthew Garret had a patch to fetch the vbios from EFI during early boot.
Also, there is a way to fetch the vbios on legacy free EFI systems via ACPI,
however, I don't know if ap
On 4/10/12 4:42 AM, Daniel Vetter wrote:
We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in mode_fixup
On Tue, Apr 10, 2012 at 6:41 PM, Daniel Vetter wrote:
> On Tue, Apr 10, 2012 at 12:37:46PM +0200, Daniel Vetter wrote:
>> On Fri, Mar 30, 2012 at 07:46:39PM +0800, Daniel Kurtz wrote:
>> > The i915 is only able to generate a STOP cycle (i.e. finalize an i2c
>> > transaction) during a DATA or WAIT
On Tue, Apr 10, 2012 at 06:56:15PM +0800, Daniel Kurtz wrote:
> On Tue, Apr 10, 2012 at 6:41 PM, Daniel Vetter wrote:
> > On Tue, Apr 10, 2012 at 12:37:46PM +0200, Daniel Vetter wrote:
> >> On Fri, Mar 30, 2012 at 07:46:39PM +0800, Daniel Kurtz wrote:
> >> > The i915 is only able to generate a STO
https://bugs.freedesktop.org/show_bug.cgi?id=48424
Johannes Obermayr changed:
What|Removed |Added
See Also||http://llvm.org/bugs/show_b
Hi Everyone,
This email contains a test application showing DMABUF sharing
between DRM/KMS display and capture node including VIVI.
It shows a simple preview on LCD display. The similar application
was posted in thread:
http://thread.gmane.org/gmane.comp.video.dri.devel/65997
This version makes us
From: Alex Deucher
It seems it can corrupt the monitor EDID in certain cases on certain
boards when running sensors detect. It's rarely used anyway outside
of AIW boards.
http://lists.lm-sensors.org/pipermail/lm-sensors/2012-April/035847.html
http://lists.freedesktop.org/archives/xorg/2011-Janu
On Tue, 10 Apr 2012 13:55:46 +0200
Daniel Vetter wrote:
> We seem to have a decent confusion between the output timings and the
> input timings of the sdvo encoder. If I understand the code correctly,
> we use the original mode unchanged for the output timings, safe for
> the lvds case. And we sh
On Tue, 10 Apr 2012 10:47:49 +0200
Jiri Slaby wrote:
> On 04/09/2012 07:11 PM, Jesse Barnes wrote:
> > On Fri, 30 Mar 2012 11:45:43 +0100 Chris Wilson
> > wrote:
> >
> >> On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby
> >> wrote:
> >>> I don't know what to dump more, because iir is obviously z
On Tue, Apr 10, 2012 at 09:17:37AM -0700, Jesse Barnes wrote:
> On Tue, 10 Apr 2012 13:55:46 +0200
> Daniel Vetter wrote:
>
> > We seem to have a decent confusion between the output timings and the
> > input timings of the sdvo encoder. If I understand the code correctly,
> > we use the original
On Tue, 10 Apr 2012 18:36:49 +0200
Daniel Vetter wrote:
> Well, neither do I have a clue about sdvo, but I think I somewhat
> self-consistent explanation for what's going on.
>
> Sdvo seems to have two timings, one is the output timing which will be
> sent over whatever is connected on the other
We seem to have a decent confusion between the output timings and the
input timings of the sdvo encoder. If I understand the code correctly,
we use the original mode unchanged for the output timings, safe for
the lvds case. And we should use the adjusted mode for input timings.
Clarify the situati
On Tue, Apr 10, 2012 at 09:46:53AM -0400, Adam Jackson wrote:
> On 4/10/12 4:42 AM, Daniel Vetter wrote:
> >We've only computed whether we need to fall back to 6bpc due to dp
> >link bandwidth constrains in mode_valid, but not mode_fixup. Under
> >various circumstances X likes to create new modes w
<#part sign=pgpmime>
On Tue, 10 Apr 2012 09:46:53 -0400, Adam Jackson wrote:
> Certainly an improvement.
>
> Reviewed-by: Adam Jackson
I'd like to know if this actually helps someone before I stick it in
drm-intel-fixes...
--
keith.pack...@intel.com
__
On Thu, Apr 05, 2012 at 01:15:44PM -0500, Rob Clark wrote:
> From: Rob Clark
>
> For now just implementing the exporting APIs, not yet importing. And
> kmap is rejected on tiled buffers (although the usefulness of that seems
> questionable, but could be added later if needed).
-ENOSIGNEDOFFBY :
On 04/10/2012 06:26 PM, Jesse Barnes wrote:
> So port hotplug is always reporting that port C has a hotplug
> interrupt though... If you write 0x3 back to it does the interrupt
> stop?
I'm not sure I got it right. This doesn't help:
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915
From: Rob Clark
For now just implementing the exporting APIs, not yet importing. And
kmap is rejected on tiled buffers (although the usefulness of that seems
questionable, but could be added later if needed).
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/Makefile |1 +
dri
On Tue, 10 Apr 2012 20:11:29 +0200
Jiri Slaby wrote:
> On 04/10/2012 06:26 PM, Jesse Barnes wrote:
> > So port hotplug is always reporting that port C has a hotplug
> > interrupt though... If you write 0x3 back to it does the interrupt
> > stop?
>
> I'm not sure I got it right. This doesn't hel
On 04/10/2012 08:34 PM, Jesse Barnes wrote:
> On Tue, 10 Apr 2012 20:11:29 +0200 Jiri Slaby
> wrote:
>
>> On 04/10/2012 06:26 PM, Jesse Barnes wrote:
>>> So port hotplug is always reporting that port C has a hotplug
>>> interrupt though... If you write 0x3 back to it does the
>>> interrupt stop
On Tue, 10 Apr 2012 12:14:27 -0400, alexdeuc...@gmail.com wrote:
> From: Alex Deucher
>
> It seems it can corrupt the monitor EDID in certain cases on certain
> boards when running sensors detect. It's rarely used anyway outside
> of AIW boards.
>
> http://lists.lm-sensors.org/pipermail/lm-sens
On Tue, Apr 10, 2012 at 09:52:40PM +0200, Jiri Slaby wrote:
> On 04/10/2012 08:34 PM, Jesse Barnes wrote:
> > On Tue, 10 Apr 2012 20:11:29 +0200 Jiri Slaby
> > wrote:
> >
> >> On 04/10/2012 06:26 PM, Jesse Barnes wrote:
> >>> So port hotplug is always reporting that port C has a hotplug
> >>> in
On Tue, 10 Apr 2012 22:32:12 +0200
Daniel Vetter wrote:
> On Tue, Apr 10, 2012 at 09:52:40PM +0200, Jiri Slaby wrote:
> > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> > SERR- >
> > I tried 3.2 and 3.3. Although the spurious interrupts were always
> > there, they occurred wit
On Tue, 10 Apr 2012 17:03:04 +0200, Daniel Vetter wrote:
> On Tue, Apr 10, 2012 at 06:56:15PM +0800, Daniel Kurtz wrote:
> > On Tue, Apr 10, 2012 at 6:41 PM, Daniel Vetter wrote:
> > > On Tue, Apr 10, 2012 at 12:37:46PM +0200, Daniel Vetter wrote:
> > >> On Fri, Mar 30, 2012 at 07:46:39PM +0800,
On Tue, Apr 10, 2012 at 07:13:59PM +0200, Daniel Vetter wrote:
> Reported-and-Tested-by: Bernard Blackham
This tested-by is actually a lie, I've mixed up a few bug reports. Bug
reporter is currently on vacation and will test this stuff in 2 weeks.
-Daniel
> Bugzilla: https://bugs.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=48529
Bug #: 48529
Summary: "glapi: regen for TBO change" kills GNOME3 welcome
screen.
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=48529
--- Comment #1 from Alex Deucher 2012-04-10 16:10:47 PDT ---
Does re-running autogen.sh and 'make clean' fix the issue?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=48529
Erdem U. Altinyurt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Tue, Apr 10, 2012 at 10:52:06AM +0200, Jiri Slaby wrote:
> On 04/06/2012 11:31 PM, Jiri Slaby wrote:
> > On 03/30/2012 02:24 PM, Chris Wilson wrote:
> >> On Fri, 30 Mar 2012 14:11:47 +0200, Jiri Slaby wrote:
> >>> On 03/30/2012 12:45 PM, Chris Wilson wrote:
> On Fri, 30 Mar 2012 11:59:28 +
Hi,
On 04/10/2012 12:11 PM, Tomasz Stanislawski wrote:
From: Dave Airlie
Add vmap to dmabuf interface.
Signed-off-by: Dave Airlie
---
drivers/base/dma-buf.c | 29 +
include/linux/dma-buf.h | 16
2 files changed, 45 insertions(+), 0 deletion
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #20 from Austin Lund 2012-04-10 18:45:03
PDT ---
(In reply to comment #19)
> IIRC, Matthew Garret had a patch to fetch the vbios from EFI during early
> boot.
Is this online anywhere? Do you have a link?
--
Configure bugmail: ht
https://bugs.freedesktop.org/show_bug.cgi?id=48535
Bug #: 48535
Summary: Spurious GL_INVALID_OPERATION error generated by
glColor()
Classification: Unclassified
Product: Mesa
Version: 7.10
Platform: x86-64 (AMD64)
Hi Everyone,
I am referring to this line in drm_drv.c in drm module:
DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl, DRM_ROOT_ONLY)
I can understand that set_master requires root, but if the process is
already master and just want to drop itself from master, I don't see any
point w
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/drm_edid_modes.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..c2534d4 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/dr
On Die, 2012-04-10 at 11:34 -0700, Jesse Barnes wrote:
> On Tue, 10 Apr 2012 20:11:29 +0200
> Jiri Slaby wrote:
>
> > On 04/10/2012 06:26 PM, Jesse Barnes wrote:
> > > So port hotplug is always reporting that port C has a hotplug
> > > interrupt though... If you write 0x3 back to it does the in
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #18 from James Tyrrell 2012-04-09 20:15:22
PDT ---
What would it take to get this patch into mainline? Like I said before I have a
MacBook Pro 8,3 and the patch works for me, allowing me to boot via EFI and use
the Radeon graphics ca
We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in mode_fixup failures and
ultimately black screens.
Th
On Tue, 10 Apr 2012 09:33:19 +0200, Daniel Vetter
wrote:
> We've only computed whether we need to fall back to 6bpc due to dp
> link bandwidth constrains in mode_valid, but not mode_fixup. Under
> various circumstances X likes to create new modes which then lack
> proper 6bpc flags (if required),
We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in mode_fixup failures and
ultimately black screens.
Ch
We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in mode_fixup failures and
ultimately black screens.
Ch
On 04/07/2012 12:40 AM, Thomas Gleixner wrote:
> On Fri, 6 Apr 2012, Jiri Slaby wrote:
>> It very looks like the generic IRQ handling code is broken. Like it
>> frees/corrupts irq_desc and ...
>
> OMG, your problem analyzing skills are amazing.
Hehe, no I did *no* analysis. I stand here as a bug
On 04/09/2012 07:11 PM, Jesse Barnes wrote:
> On Fri, 30 Mar 2012 11:45:43 +0100 Chris Wilson
> wrote:
>
>> On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby
>> wrote:
>>> I don't know what to dump more, because iir is obviously zero
>>> too. What other sources of interrupts are on the (G33) chip?
On Fri, Apr 6, 2012 at 23:31, Jiri Slaby wrote:
>> That was introduced in 05eff845a28499762075d3a72e238a31f4d2407c to close
>> a race where the pipestat triggered an interrupt after we processed the
>> secondary registers and before reseting the primary.
>>
>> But the basic premise that we should
On 04/06/2012 11:31 PM, Jiri Slaby wrote:
> On 03/30/2012 02:24 PM, Chris Wilson wrote:
>> On Fri, 30 Mar 2012 14:11:47 +0200, Jiri Slaby wrote:
>>> On 03/30/2012 12:45 PM, Chris Wilson wrote:
On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby wrote:
> I don't know what to dump more, because
On Tue, Apr 10, 2012 at 10:47:49AM +0200, Jiri Slaby wrote:
> On 04/09/2012 07:11 PM, Jesse Barnes wrote:
> > On Fri, 30 Mar 2012 11:45:43 +0100 Chris Wilson
> > wrote:
> >
> >> On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby
> >> wrote:
> >>> I don't know what to dump more, because iir is obviou
On 04/10/2012 10:58 AM, Daniel Vetter wrote:
> On Tue, Apr 10, 2012 at 10:47:49AM +0200, Jiri Slaby wrote:
>> On 04/09/2012 07:11 PM, Jesse Barnes wrote:
>>> On Fri, 30 Mar 2012 11:45:43 +0100 Chris Wilson
>>> wrote:
>>>
On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby
wrote:
> I don'
Hi,
in today's -next I see:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] pagevec_move_tail+0x30/0x30
PGD 1bf4fc067 PUD 1bf4f0067 PMD 0
Oops: [#1] SMP
CPU 0
Modules linked in: pl2303 usbserial microcode
Pid: 4260, comm: X Not tainted 3.4.0-rc2-next-20120410
Hello everyone,
The patcheset adds support for DMABUF [1] importing to vmalloc allocator in
videobuf2 stack. This is an incremental patch to 'Integration of videobuf2
with dmabuf' patchset [2]. This patch makes use of vmap extension for dmabuf
proposed by Dave Airlie [3].
The vmap was preferred ov
From: Dave Airlie
Add vmap to dmabuf interface.
Signed-off-by: Dave Airlie
---
drivers/base/dma-buf.c | 29 +
include/linux/dma-buf.h | 16
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dm
This patch adds support for importing DMABUF files for
vmalloc allocator in Videobuf2.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/videobuf2-vmalloc.c | 56 +++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --gi
This patch enhances VIVI driver with a support for importing a buffer
from DMABUF file descriptors.
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 deletions(-)
On Fri, Mar 30, 2012 at 07:46:39PM +0800, Daniel Kurtz wrote:
> The i915 is only able to generate a STOP cycle (i.e. finalize an i2c
> transaction) during a DATA or WAIT phase. In other words, the
> controller rejects a STOP requested as part of the first transaction in a
> sequence.
>
> Thus, fo
On Tue, Apr 10, 2012 at 12:37:46PM +0200, Daniel Vetter wrote:
> On Fri, Mar 30, 2012 at 07:46:39PM +0800, Daniel Kurtz wrote:
> > The i915 is only able to generate a STOP cycle (i.e. finalize an i2c
> > transaction) during a DATA or WAIT phase. In other words, the
> > controller rejects a STOP re
Hi all,
The first patch in this series fixes a long-standing hdmi-on-sdvo regression -
we apparently have not set up the pixel doubling (or quadrupling) correctly.
This regression was introduced in 2.6.36. Now if this patch is indeed correct,
hdmi on sdvo (and _only_ hdmi) for any pixelclock below
We seem to have a decent confusion between the output timings and the
input timings of the sdvo encoder. If I understand the code correctly,
we use the original mode unchanged for the output timings, safe for
the lvds case. And we should use the adjusted mode for input timings.
Clarify the situati
- kill intel_sdvo->input_dtd, it's only used as a temporary variable,
we store the preferred input mode in the adjusted mode at mode_fixup
time.
- rename the function to make it clear what we want it to do (get the
preferred mode) and say in a comment what it unfortunately does as a
side-ef
Unfortunately we can't abort a mode_set, but at least tell the user
that something might have gone wrong when setting the sdvo input or
output timing fails.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff
We round-trip quite often from sdvo dtd timings through drm mode back
to sdvo dtd timings, e.g. due to mode_fixup. Add an informational
message that tells us when we lose things on the way.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c |5 +
1 files changed, 5 insert
On Tue, 10 Apr 2012 13:55:47 +0200, Daniel Vetter
wrote:
> - kill intel_sdvo->input_dtd, it's only used as a temporary variable,
> we store the preferred input mode in the adjusted mode at mode_fixup
> time.
> - rename the function to make it clear what we want it to do (get the
> preferred
ri-devel/attachments/20120410/59571c80/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-add-wayland-drm-protocol-module.patch
Type: application/octet-stream
Size: 17748 bytes
Desc: 0001-add-wayland-drm-protocol-module.patch
From: Marek Szyprowski
Let mmap method to use dma_mmap_coherent call. This patch depends on DMA
mapping redesign patches because the usage of dma_mmap_coherent breaks
dma-contig allocator for architectures other than ARM and AVR.
Signed-off-by: Marek Szyprowski
---
drivers/media/video/videobu
Hello everyone,
The patches adds support for DMABUF [1] exporting to V4L2 stack. It was
updated from [7] after Laurent Pinchart's review. The previous patchset was
split into two parts. The support for DMABUF importing was posted in [2]. The
exporter part is dependant on DMA mapping redesign [3]
This patch adds support for vmap and kmap callbacks
for DMABUF exporter.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/videobuf2-dma-contig.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v
1 - 100 of 141 matches
Mail list logo
