Btrfs corruption Oops ( was: Re: PCI resources above 4GB)

-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

[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

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

missing license in drm_usb prevents module loading

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

[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

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.

[PATCH] mm: extend prefault helpers to fault in more than PAGE_SIZE

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

[PATCH 1/2] drm/nouveau: Add lock on drm_helper_resume_force_mode

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

[PATCH 4/8 v7] drm/i915/intel_i2c: use WAIT cycle, not STOP

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

[PATCH 2/2] drm/i915/intel_i2c: reduce verbosity of some messages

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

[PATCH 1/2] drm/i915/intel_i2c: handle zero-length reads

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

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

-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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

-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

btrfs oops [was Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)]

-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

[PATCH v4 14/14] v4l: fimc: support for dmabuf importing

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

[PATCH v4 13/14] v4l: s5p-tv: mixer: support for dmabuf importing

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

[PATCH v4 12/14] v4l: vb2-dma-contig: change map/unmap behaviour for importers

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

[PATCH v4 11/14] v4l: vb2-dma-contig: add support for dma_buf importing

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

[PATCH v4 10/14] v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator

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

[PATCH v4 09/14] v4l: vb2: add prepare/finish callbacks to allocators

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

[PATCH v4 08/14] v4l: vb2-dma-contig: add support for scatterlist in userptr mode

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

[PATCH v4 07/14] v4l: vb2-dma-contig: Reorder functions

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

[PATCH v4 06/14] v4l: vb2-dma-contig: Remove unneeded allocation context structure

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

[PATCH v4 05/14] v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc

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

[PATCH v4 04/14] v4l: vb: remove warnings about MEMORY_DMABUF

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

[PATCH v4 03/14] v4l: vb2: add support for shared buffer (dma_buf)

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

[PATCH v4 01/14] v4l: Add DMABUF as a memory type

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

[PATCH v4 00/14] Integration of videobuf2 with dmabuf

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

[PATCH] xf86drm.c: add counter for ioctl restarting

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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

[PATCH] xf86drm.c: add counter for ioctl restarting

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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>

[PATCH 00/12] Add more DMT and common modes

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

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

-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

[PATCH 1/4] drm: add the VIC number to the CEA EDID modes

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

[PATCH 12/12] drm/edid: Generate modes from extra_modes for range descriptors

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

[PATCH 11/12] drm/edid: Add extra_modes

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

[PATCH 10/12] drm/edid: Give the est3 mode struct a real name

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

[PATCH 09/12] drm/edid: Update range descriptor struct for EDID 1.4

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

[PATCH 08/12] drm/edid: Do drm_dmt_modes_for_range() for all range descriptor types

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.

[PATCH 07/12] drm/edid: Fix some comment typos in the DMT mode list

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

[PATCH 06/12] drm/edid: Add the reduced blanking DMT modes to the DMT list

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

[PATCH 05/12] drm/edid: s/drm_gtf_modes_for_range/drm_dmt_modes_for_range/

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

[PATCH 04/12] drm/edid: Remove a misleading comment

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

[PATCH 03/12] drm/edid: Allow drm_mode_find_dmt to hunt for reduced-blanking modes

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

[PATCH 02/12] drm/edid: Rewrite drm_mode_find_dmt search loop

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

[PATCH 01/12] drm/edid: Document drm_mode_find_dmt

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

[PATCH 00/12] Add more DMT and common modes

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

[PATCH 4/4] drm/i915: make DBLCLK modes work

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

[PATCH 3/4] drm/i915: rename AVI InfoFrame field 'PR' to 'YQ_CN_PR'

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

[PATCH 2/4] drm: add DRM_MODE_FLAG_DBLCLK to CEA modes requiring it

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

[PATCH 1/4] drm: add the VIC number to the CEA EDID modes

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

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

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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

[PATCH] drm/radeon/si: add missing radeon_bo_unreserve in si_rlc_init()

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

[PATCH] xf86drm.c: add counter for ioctl restarting

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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

[Intel-gfx] [PATCH 5/7] drm/edid: Armor drm_dmt_modes_for_range for reduced blanking modes

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

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

-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

[PATCH] drm/radeon: disable MSI on RV515

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

[PATCH 3/4] drm: Add drm_format_{horz, vert}_chroma_subsampling() utility functions

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

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

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

[PATCH 2/2] drm/i915/intel_i2c: reduce verbosity of some messages

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

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

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

[PATCH] xf86drm.c: add counter for ioctl restarting

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

PCI resources above 4GB

-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

PCI resources above 4GB

-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

[PATCH 1/2] drm/i915/intel_i2c: handle zero-length reads

Also, Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48269 -Chris -- Chris Wilson, Intel Open Source Technology Centre

[PATCH 1/2] drm/i915/intel_i2c: handle zero-length reads

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

[RFC 4/4] drm: Add NVIDIA Tegra support

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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

No subject

than escalating the bug into a random failure. -Chris -- Chris Wilson, Intel Open Source Technology Centre

PCI resources above 4GB

-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

PCI resources above 4GB

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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

[RFC 4/4] drm: Add NVIDIA Tegra support

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>

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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

[PATCH] drm/radeon: disable MSI on RV515

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

[PATCH] drm/radeon/si: add missing radeon_bo_unreserve in si_rlc_init() v2

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

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,

PCI resources above 4GB

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

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

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

[PATCH 3/4] drm: Add drm_format_{horz, vert}_chroma_subsampling() utility functions

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

PCI resources above 4GB

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

[RFC 4/4] drm: Add NVIDIA Tegra support

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,

[PATCH] nouveau: Set special lane map for the right chipset

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.

Re: PCI resources above 4GB

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

Re: [RFC 4/4] drm: Add NVIDIA Tegra support

* 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

Re: PCI resources above 4GB

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

Re: PCI resources above 4GB

-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

Re: [PATCH 3/4] drm: Add drm_format_{horz, vert}_chroma_subsampling() utility functions

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

Re: [PATCH 1/2] drm/i915/intel_i2c: handle zero-length reads

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

Re: [PATCH 1/2] drm/i915/intel_i2c: handle zero-length reads

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

[PATCH] xf86drm.c: add counter for ioctl restarting

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)

Re: [PATCH] xf86drm.c: add counter for ioctl restarting

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