-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/12 19:12, Steven Newbury wrote:
> On 13/04/12 18:38, Steven Newbury wrote:
>> On 13/04/12 17:17, Yinghai Lu wrote:
> Looks like either a btrfs regression or bad interaction
> with for-pci-res-alloc. Oops attached.
Just hit the sa
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #5 from Alex Deucher 2012-04-13 15:28:25 PDT
---
(In reply to comment #4)
> forcing DPMS off and on will restore display. (I have this shell script bound
> to F12 and taping that key will restore the display.)
>
> xset dpms for
I couldn't load the udl-drm driver with most things built as a module,
getting symbol resolution errors. Adding
MODULE_LICENSE("GPL");
to drm_usb.c fixed this
-Shawn Landden
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #4 from Wolfgang Rupprecht
2012-04-13 14:48:22 PDT ---
I'm seeing the same thing. Na display after either replug/hotplug, front-panel
soft-off power cycling, or back-panel power supply power cycling.
xorg-x11-server-Xorg-1.11.4-1.f
On Thu, Mar 1, 2012 at 20:22, Daniel Vetter wrote:
> +/* Multipage variants of the above prefault helpers, useful if more than
> + * PAGE_SIZE of date needs to be prefaulted. These are separate from the
> above
> + * functions (which only handle up to PAGE_SIZE) to avoid clobbering the
> + * file
Hi,
Peter Huewe wrote:
> mode_config should be locked when calling drm_helper_resume_force_mode.
> This patch adds the lock, similar to #927a2f119.
Does this fix a problem that has been observed in the wild, or only a
theoretical one?
Curious,
Jonathan
On Thu, Apr 12, 2012 at 4:26 AM, Chris Wilson
wrote:
> On Thu, 12 Apr 2012 02:17:46 +0800, Daniel Kurtz
> wrote:
>> On Wed, Apr 11, 2012 at 5:34 AM, Chris Wilson
>> wrote:
>> > The last major item on the wishlist is solving how to drive the SDVO i2c
>> > over gmbus. I think it is just a matte
Some of these messages can be hit when userspace tries to probe the i2c
with nothing connected or if the driver code tries to do the same. See:
https://bugs.freedesktop.org/show_bug.cgi?id=48248
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/i915/intel_i2c.c |7 ---
1 files changed, 4 i
A common method of probing an i2c bus is trying to do a zero-length read.
Handle this case by checking the length first waiting for data to be read.
This is actually important, since attempting a zero-length read is one
of the ways that i2cdetect and i2c_new_probed_device detect whether
there is d
https://bugs.freedesktop.org/show_bug.cgi?id=45901
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=46005
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=31533
--- Comment #3 from Jos van Wolput 2012-04-13
19:33:15 PDT ---
(In reply to comment #2)
> Is this still an issue with the latest code in xf86-video-ati git master?
Yes it is, at least when scrolling Iceweasel pages, showing some black or
blurre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/12 18:38, Steven Newbury wrote:
> On 13/04/12 17:17, Yinghai Lu wrote:
Looks like either a btrfs regression or bad interaction with
for-pci-res-alloc. Oops attached.
>>> Just hit the same oops on the rc1+for-pci-res-alloc kernel I
https://bugs.freedesktop.org/show_bug.cgi?id=43405
--- Comment #9 from Jos van Wolput 2012-04-13
18:53:46 PDT ---
(In reply to comment #8)
I still get the same issue when using r600g driver from git mesa, no such issue
using mesa-8.0.2.
All 3D demos are affected as well as google earth and GLC_
At Fri, 13 Apr 2012 12:31:25 -0400,
Adam Jackson wrote:
>
> On 4/13/12 11:41 AM, Takashi Iwai wrote:
> > At Fri, 13 Apr 2012 11:30:01 -0400, Alex Deucher wrote:
> >> One thing to be careful of is that some monitors (especially LCD
> >> panels) don't like modes that are not in their EDIDs. As such
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/12 17:17, Yinghai Lu wrote:
>>> Looks like either a btrfs regression or bad interaction with
>>> for-pci-res-alloc. Oops attached.
>> Just hit the same oops on the rc1+for-pci-res-alloc kernel I
>> tried earlier so it's not definitely someth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/12 17:17, Yinghai Lu wrote:
>>> Looks like either a btrfs regression or bad interaction with
>>> for-pci-res-alloc. Oops attached.
>> Just hit the same oops on the rc1+for-pci-res-alloc kernel I
>> tried earlier so it's not definitely someth
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 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
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
From: Sumit Semwal
This patch makes changes for adding dma-contig as a dma_buf user. It provides
function implementations for the {attach, detach, map, unmap}_dmabuf()
mem_ops of DMABUF memory type.
Signed-off-by: Sumit Semwal
Signed-off-by: Sumit Semwal
[author of the original patch]
From: Marek Szyprowski
Add prepare/finish callbacks to vb2-dma-contig allocator.
Signed-off-by: Marek Szyprowski
---
drivers/media/video/videobuf2-dma-contig.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-con
From: Marek Szyprowski
This patch adds support for prepare/finish callbacks in VB2 allocators. These
callback are used for buffer flushing.
Signed-off-by: Marek Szyprowski
---
drivers/media/video/videobuf2-core.c | 11 +++
include/media/videobuf2-core.h |7 +++
2 files
From: Andrzej Pietrasiewicz
This patch introduces usage of dma_map_sg to map memory behind
a userspace pointer to a device as dma-contiguous mapping.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Marek Szyprowski
[bugfixing]
Signed-off-by: Kamil Debski
[bugfixing]
Signed
From: Laurent Pinchart
Group functions by buffer type.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/videobuf2-dma-contig.c | 92 ---
1 files changed, 54 insertions(+), 38 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media
vb2-dma-contig returns a vb2_dc_conf structure instance as the vb2
allocation context. That structure only stores a pointer to the physical
device. Remove it and use the device pointer directly as the allocation
context.
Signed-off-by: Tomasz Stanislawski
---
drivers/media/video/videobuf2-dma-co
From: Laurent Pinchart
Signed-off-by: Laurent Pinchart
---
drivers/media/video/videobuf2-dma-contig.c | 36 ++--
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
in
From: Sumit Semwal
Adding DMABUF memory type causes videobuf to complain about not using it
in some switch cases. This patch removes these warnings.
Signed-off-by: Sumit Semwal
---
drivers/media/video/videobuf-core.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/d
From: Sumit Semwal
This patch adds support for DMABUF memory type in videobuf2. It calls relevant
APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
For this version, the support is for videobuf2 as a user of the shared buffer;
so the allocation of the buffer is done outside of V4L2. [A s
This patch adds description and usage examples for importing
DMABUF file descriptor in V4L2.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/media/v4l/compat.xml |4 +
Documentation/DocBook/media/v4l/io.xml | 179 +++
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
---
include/linux/vide
Hello everyone,
This patchset adds support for DMABUF [2] importing to V4L2 stack.
The support for DMABUF exporting was moved to separate patchset
due to dependency on patches for DMA mapping redesign by
Marek Szyprowski [4].
v4:
- rebased on mainline 3.4-rc2
- included missing importing support
On Fri, Apr 13, 2012 at 03:42:16PM +0200, Daniel Vetter wrote:
> On Fri, Apr 13, 2012 at 05:26:42PM +0400, Anton V. Boyarshinov wrote:
> > In some cases ioclt->alarm->ioctl loop can be infinite:
> > ioctl(7, 0x40086482, 0xbfb62738)= ? ERESTARTSYS (To be restarted)
> > --- SIGALRM (Alarm clo
At Fri, 13 Apr 2012 11:30:01 -0400,
Alex Deucher wrote:
>
> On Fri, Apr 13, 2012 at 11:13 AM, Takashi Iwai wrote:
> > At Fri, 13 Apr 2012 15:35:04 +0100,
> > Dave Airlie wrote:
> >>
> >> > I don't think we need to support all wild modes, too. ?But the _very_
> >> > common modes like 1366x768 and
In some cases ioclt->alarm->ioctl loop can be infinite:
ioctl(7, 0x40086482, 0xbfb62738)= ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn() = ? (mask now [])
ioctl(7, 0x40086482, 0xbfb62738)= ? ERESTARTSYS (To be restarted)
At Fri, 13 Apr 2012 10:55:16 -0400,
Adam Jackson wrote:
>
> On 4/13/12 10:29 AM, Takashi Iwai wrote:
> > At Fri, 13 Apr 2012 10:14:46 -0400,
> > Adam Jackson wrote:
> >> Yeah, that's a bug. That's why I said it should be renamed
> >> drm_dmt_modes_for_range and run unconditionally if we find a ra
ID data from two
monitors.
thanks,
Takashi
-- next part --
A non-text attachment was scrubbed...
Name: xrandr1
Type: application/octet-stream
Size: 10715 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120413/40a3605
On 4/13/12 4:33 PM, Adam Jackson wrote:
> Incorporates some feedback from Rodrigo and Takashi. Major themes of the
> series:
>
> - Fix the DMT list to include reduced-blanking modes
> - Add modes from DMT for any range descriptor type
> - Add an extra modes list for things not in DMT
> - For range
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/12 16:23, Steven Newbury wrote:
> On 13/04/12 15:19, Steven Newbury wrote:
>> On 13/04/12 15:13, Daniel Vetter wrote:
>>> On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury
>>> wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
On 4/13/12 3:31 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The specification defines a VIC (Video Identification Code) for each
> mode. When we're browsing drm_edid_modes.h, it really helps to have the
> number available (otherwise we have to count...). These numbers are also
> used in the ED
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 73
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7131f38..9e3794d 100644
--- a/drivers/gpu/drm/drm_edid.c
++
Some common sizes that don't show up in DMT.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index eab60ea..26a1d33 100644
---
We want the same type for extra modes inferred from ranges.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index ab3a051..eab60ea 10
Signed-off-by: Adam Jackson
---
include/drm/drm_edid.h | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index bcb9a66..8cefbbe 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -90,
EDID 1.4 retcons the meaning of the "GTF feature" bit to mean "is
continuous frequency", and moves the set of supported timing formulas
into the range descriptor itself. In any event, the range descriptor
can act as a filter on the DMT list without regard to a specific timing
formula.
Signed-off-
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index 4be9c1a..ab3a051 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers
Copied from the list in xserver.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 94 +-
1 files changed, 93 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..4be9
Slightly more honest naming.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 70dcf7a..355e6a0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers
mode_in_range() handles what this was warning about.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4f52103..70dcf7a 100644
--- a/drivers/gpu/drm/
It won't find any, yet. Fix up callers to match: standard mode codes
will look prefer r-b modes for a given size if present, EST3 mode codes
will look for exactly the r-b-ness mentioned in the mode code. This
might mean fewer modes matched for EST3 mode codes between now and when
the DMT mode lis
No functional change, but will make an upcoming change clearer.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 79a3637..0a23ee5 10
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a18b0d..79a3637 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@
Incorporates some feedback from Rodrigo and Takashi. Major themes of the
series:
- Fix the DMT list to include reduced-blanking modes
- Add modes from DMT for any range descriptor type
- Add an extra modes list for things not in DMT
- For ranges that specify a formula, generate timings from the e
From: Paulo Zanoni
They require an AVI InfoFrame with a proper Pixel Repetition field.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729
Signed-off-by: Paulo Zanoni
---
I'm still waiting for confirmation on bugzilla, but I have access to a
TV that reproduces the problem and the prob
From: Paulo Zanoni
To keep the consistency with the other fields.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_drv.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 79cabf5..175cc
From: Paulo Zanoni
CEA modes 6, 7, 8, 9, 21, 22, 23, 24, 44, 45, 50, 51, 54, 55, 58 and 59
require sending pixel data 2 times. This doesn't mean the modes will
work yet, but now the drivers know they're different.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/drm_edid_modes.h | 38
From: Paulo Zanoni
The specification defines a VIC (Video Identification Code) for each
mode. When we're browsing drm_edid_modes.h, it really helps to have the
number available (otherwise we have to count...). These numbers are also
used in the EDID data (by the CEA-EXT extension block).
Signed-
At Fri, 13 Apr 2012 10:14:46 -0400,
Adam Jackson wrote:
>
> On 4/12/12 7:09 PM, Rodrigo Vivi wrote:
>
> >> CVT monitors _must_ accept GTF as well, EDID says so. So functionally
> >> there's nothing wrong with the existing code.
> >
> > Actually the current code just check for gtf flag... so if a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/12 15:19, Steven Newbury wrote:
> On 13/04/12 15:13, Daniel Vetter wrote:
>> On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>>
>>> On 13/04/12 14:52, Steven Newbury wrote:
>>
On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 13/04/12 14:52, Steven Newbury wrote:
> > On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury
> > wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> >>
> >> On 13/
So, the modes that I added in that list was half got from windows on
my monitor and half requested by HP.
So let forget about other modes and focus on the one required by HP.
HP has requested the same list for everybody 3 years ago and it was
added by Windows and AMD at that time but our open driv
On Don, 2012-04-12 at 16:13 -0400, alexdeucher at gmail.com wrote:
> From: Alex Deucher
>
> Forget to unreserve after pinning. This can lead to problems in
> soft reset and resume.
>
> Signed-off-by: Alex Deucher
[...]
> @@ -3024,12 +3025,12 @@ int si_rlc_init(struct radeon_device *rdev)
>
On Fri, Apr 13, 2012 at 05:26:42PM +0400, Anton V. Boyarshinov wrote:
> In some cases ioclt->alarm->ioctl loop can be infinite:
> ioctl(7, 0x40086482, 0xbfb62738)= ? ERESTARTSYS (To be restarted)
> --- SIGALRM (Alarm clock) @ 0 (0) ---
> sigreturn() = ? (mask now
> I don't think we need to support all wild modes, too. ?But the _very_
> common modes like 1366x768 and 1600x900 should be really supported as
> default.
You guys still haven't answered the basic question, what HW is this broken?
Can you provide some EDIDs?
Dave.
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #5 from Alex Deucher 2012-04-13 15:28:25 PDT ---
(In reply to comment #4)
> forcing DPMS off and on will restore display. (I have this shell script bound
> to F12 and taping that key will restore the display.)
>
> xset dpms forc
On 4/12/12 5:35 PM, Adam Jackson wrote:
> @@ -1030,6 +1026,10 @@ drm_dmt_modes_for_range(struct drm_connector
> *connector, struct edid *edid,
>
> for (i = 0; i< drm_num_dmt_modes; i++) {
> if (mode_in_range(drm_dmt_modes + i, edid, timing)) {
> + if (mode
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/12 15:13, Daniel Vetter wrote:
> On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 13/04/12 14:52, Steven Newbury wrote:
>>> On Fri, 13 Apr 2012, 14:26:19 BST, Steven New
From: Dave Airlie
My rv515 card is very flaky with msi enabled. Every so often it loses a rearm
and never comes back, manually banging the rearm brings it back.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_irq_kms.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-
On Fri, Apr 13, 2012 at 04:42:04AM +0200, Roland Scheidegger wrote:
> Am 12.04.2012 14:23, schrieb Ville Syrj?l?:
> > On Wed, Apr 11, 2012 at 08:53:08PM +0200, Roland Scheidegger wrote:
> >> Am 05.04.2012 20:35, schrieb ville.syrjala at linux.intel.com:
> >>> From: Ville Syrj?l?
> >>>
> >>> These
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/12 14:52, Steven Newbury wrote:
> On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 13/04/12 13:49, Steven Newbury wrote:
>>> On 13/04/12 12:58, Steven Newbury wrote:
>>>
On Fri, Apr 13, 2012 at 07:47:54PM +0800, Daniel Kurtz wrote:
> Some of these messages can be hit when userspace tries to probe the i2c
> with nothing connected or if the driver code tries to do the same. See:
> https://bugs.freedesktop.org/show_bug.cgi?id=48248
>
> Signed-off-by: Daniel Kurtz
Bo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/12 19:12, Steven Newbury wrote:
> On 13/04/12 18:38, Steven Newbury wrote:
>> On 13/04/12 17:17, Yinghai Lu wrote:
> Looks like either a btrfs regression or bad interaction
> with for-pci-res-alloc. Oops attached.
Just hit the sa
On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 13/04/12 13:49, Steven Newbury wrote:
> > On 13/04/12 12:58, Steven Newbury wrote:
> >
> > > > It's not stable, crashes soon after GMA comes up. (Could be
> > > > unrelated breaka
https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #4 from Wolfgang Rupprecht
2012-04-13 14:48:22 PDT ---
I'm seeing the same thing. Na display after either replug/hotplug, front-panel
soft-off power cycling, or back-panel power supply power cycling.
xorg-x11-server-Xorg-1.11.4-1.f
On Fri, 13 Apr 2012 17:26:42 +0400, "Anton V. Boyarshinov" wrote:
> In some cases ioclt->alarm->ioctl loop can be infinite:
> ioctl(7, 0x40086482, 0xbfb62738)= ? ERESTARTSYS (To be restarted)
> --- SIGALRM (Alarm clock) @ 0 (0) ---
> sigreturn() = ? (mask now []
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/12 13:49, Steven Newbury wrote:
> On 13/04/12 12:58, Steven Newbury wrote:
>
>>> It's not stable, crashes soon after GMA comes up. (Could be
>>> unrelated breakage in linus/master? Probably not but I will
>>> verify.) I noticed the high al
On 4/13/12 4:33 PM, Adam Jackson wrote:
Incorporates some feedback from Rodrigo and Takashi. Major themes of the
series:
- Fix the DMT list to include reduced-blanking modes
- Add modes from DMT for any range descriptor type
- Add an extra modes list for things not in DMT
- For ranges that spec
On 4/13/12 3:31 PM, Paulo Zanoni wrote:
From: Paulo Zanoni
The specification defines a VIC (Video Identification Code) for each
mode. When we're browsing drm_edid_modes.h, it really helps to have the
number available (otherwise we have to count...). These numbers are also
used in the EDID data (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/12 12:58, Steven Newbury wrote:
>> It's not stable, crashes soon after GMA comes up. (Could be
>> unrelated breakage in linus/master? Probably not but I will
>> verify.) I noticed the high allocations are occuring from the
>> top of 64-bit
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 73
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7131f38..9e3794d 100644
--- a/drivers/gpu/drm/drm_edid.c
++
We want the same type for extra modes inferred from ranges.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index ab3a051..eab60ea 10
Some common sizes that don't show up in DMT.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index eab60ea..26a1d33 100644
---
Signed-off-by: Adam Jackson
---
include/drm/drm_edid.h | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index bcb9a66..8cefbbe 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -90,
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index 4be9c1a..ab3a051 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers
EDID 1.4 retcons the meaning of the "GTF feature" bit to mean "is
continuous frequency", and moves the set of supported timing formulas
into the range descriptor itself. In any event, the range descriptor
can act as a filter on the DMT list without regard to a specific timing
formula.
Signed-off-
Copied from the list in xserver.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 94 +-
1 files changed, 93 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..4be9
Slightly more honest naming.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 70dcf7a..355e6a0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers
mode_in_range() handles what this was warning about.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4f52103..70dcf7a 100644
--- a/drivers/gpu/drm/
It won't find any, yet. Fix up callers to match: standard mode codes
will look prefer r-b modes for a given size if present, EST3 mode codes
will look for exactly the r-b-ness mentioned in the mode code. This
might mean fewer modes matched for EST3 mode codes between now and when
the DMT mode lis
No functional change, but will make an upcoming change clearer.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 79a3637..0a23ee5 10
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a18b0d..79a3637 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@
Incorporates some feedback from Rodrigo and Takashi. Major themes of the
series:
- Fix the DMT list to include reduced-blanking modes
- Add modes from DMT for any range descriptor type
- Add an extra modes list for things not in DMT
- For ranges that specify a formula, generate timings from the e
Also,
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48269
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, 13 Apr 2012 19:47:53 +0800, Daniel Kurtz
wrote:
> A common method of probing an i2c bus is trying to do a zero-length read.
> Handle this case by checking the length first waiting for data to be read.
>
> This is actually important, since attempting a zero-length read is one
> of the way
On 04/13/2012 03:14 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 04/12/2012 11:44 AM, Thierry Reding wrote:
> [...]
>> And given that, I don't think we should name the node after some
>> OS-specific software concept. Device tree is intended to model hardware.
> [...]
>>> Maybe one solu
On 4/13/12 11:25 AM, David Airlie wrote:
> I'm still intrigued about what hardware exists with a panel with a native
> mode it doesn't describe.
>
> How are we to know what the panel preferred mode is in this case?
>
> Or is this for larger panels wanting to use smaller modes?
AFAICT, yes, this
than escalating the bug into a random failure.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/04/12 12:45, Steven Newbury wrote:
> On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu
> wrote:
>
>> On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury
>> wrote:
>
> It would be useful to preserve as much low PCI memory
> address space a
GMA still isn't mapped high so there's no room for the
256M radeon pref mem.
Attached /proc/iomem output for docked and undocked.
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: iomem.undocked
URL:
<http://lists.freedesktop.o
From: Paulo Zanoni
They require an AVI InfoFrame with a proper Pixel Repetition field.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729
Signed-off-by: Paulo Zanoni
---
I'm still waiting for confirmation on bugzilla, but I have access to a
TV that reproduces the problem and the prob
1 - 100 of 181 matches
Mail list logo
