-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
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
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.
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
> + *
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
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
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
-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
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
-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
-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
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
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
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
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
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
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
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
---
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
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
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
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
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
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
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
hanks,
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/40a3605e/attachment-0004.obj>
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
-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
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
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
@@
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-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
+++
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
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
+++
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
---
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
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
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
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
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
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
---
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
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
-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
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
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
> 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.
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
-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
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
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
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
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
-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
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
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
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
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.org/archives/dri-devel/att
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 when
>> you try and set them you often get a wonky display or
On Fri, Apr 13, 2012 at 11:41 AM, Takashi Iwai wrote:
> 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
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 1600x900 should be really supported as
>> > default.
>>
>> You guys
>
> I agree with your point, too. When I worked on supporting these
> modes
> in X server side, I didn't pick up all such modes but only really de
> facto standard ones. It should suffice for most demands, indeed.
>
> Also, we don't have to add always 1600x900 or 1366x768. Such a mode
> is
edid = <>;
};
hdmi_out {
output = <>;
ddc = <>;
};
};
But then "outputs" should probably become something like "connectors"
instead and the initial configuration refers to the "_out" phandles.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120413/8463fb48/attachment.pgp>
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 range
>> descriptor.
>
> Yeah, I saw your patches. Should the further
On Fri, Apr 13, 2012 at 10:19 AM, Dave Airlie wrote:
> 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
Reviewed-by: Alex Deucher
> ---
>
From: Alex Deucher
Forget to unreserve after pinning. This can lead to problems in
soft reset and resume.
v2: rework patch as per Michel's suggestion.
Signed-off-by: Alex Deucher
Reviewed-by: Michel D?nzer
---
drivers/gpu/drm/radeon/si.c |5 ++---
1 files
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 monitor
> is gtf2 or cvt this dmt modes are not being added.
Yeah,
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 as possible for hotplug devices (like my Radeon), but the
> > > > other problem is small
>> 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 something new in the btrfs code. ?Seems
> like it's a 64/32bit pointer issue??
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 functions return the chroma subsampling factors for the specified
>>> pixel
part --
A non-text attachment was scrubbed...
Name: assign_sorting.patch
Type: application/octet-stream
Size: 1259 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120413/76a55111/attachment.obj>
-- next part --
A non
Am Mittwoch, den 11.04.2012, 15:18 + schrieb Arnd Bergmann:
> On Wednesday 11 April 2012, Thierry Reding wrote:
> > * Daniel Vetter wrote:
> > > On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
> > > > * Daniel Vetter wrote:
> > > > > On Wed, Apr 11, 2012 at 02:10:30PM +0200,
The refactoring of the nv50 logic, introduced in 8663bc7c, modified the
test for the special lane map used on some Apple computers with Nvidia
chipsets. The tested MBA3,1 would still boot, but resume from suspend
stopped working. This patch restores the old test, which fixes the problem.
On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu ying...@kernel.org wrote:
On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury st...@snewbury.org.uk
wrote:
It would be useful to preserve as much low PCI memory address
space as possible for hotplug devices (like my Radeon), but the
* 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 solution would be to have a top-level DRM device with a
On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu ying...@kernel.org wrote:
On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury st...@snewbury.org.uk
wrote:
It would be useful to preserve as much low PCI memory address
space as possible for hotplug devices (like my Radeon), but the
-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 ying...@kernel.org
wrote:
On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury
st...@snewbury.org.uk wrote:
It would be useful to preserve as much low PCI
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.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
On Fri, 13 Apr 2012 19:47:53 +0800, Daniel Kurtz djku...@chromium.org 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
Also,
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48269
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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)
On Fri, 13 Apr 2012 17:26:42 +0400, Anton V. Boyarshinov
boya...@altlinux.org 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() =
1 - 100 of 160 matches
Mail list logo