On Tue, Nov 26, 2013 at 11:25:49AM +, Simon Farnsworth wrote:
> Extend the parsing of the xrandr EDID property block to read extension
> blocks, not just the basic block.
>
> Signed-off-by: Simon Farnsworth
Hi,
That patch seems to work as intended, so pushed it with my r-b tag.
Sorry it too
sts.freedesktop.org/archives/dri-devel/attachments/20131217/033b2432/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131217/4720bdac/attachment.html>
|--- |NOTOURBUG
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131217/1c07d792/attachment.html>
On Tue, Dec 17, 2013 at 8:04 PM, Dave Airlie wrote:
> On Wed, Dec 11, 2013 at 11:24 PM, Daniel Vetter
> wrote:
>> This was hidden in a generic void * dev->mm_private. But only ever
>> used for gem. But thanks to this fake generic pretension no one
>> noticed that Rob's drm drivers are now all br
On Tue, 17 Dec 2013, Thierry Reding wrote:
> Implements an I2C-over-AUX I2C adapter on top of the generic drm_dp_aux
> infrastructure. It extracts the retry logic from existing drivers, which
> should help in porting those drivers to this new helper.
>
> Signed-off-by: Thierry Reding
> ---
> dri
From: Yongjian Xu
arg->time_out_us comes from user-space, then overflow may occur in this line:
uint64_t wait_timeout = ((uint64_t)arg->timeout_us * HZ);
This is not a serious problem, but still a bug.
Signed-off-by: Yongjian Xu
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 ++
1 fi
On Tue, Dec 17, 2013 at 10:17:24AM -0800, Keith Packard wrote:
> Chris Wilson writes:
>
> > The bspec still says we must assert SR01 bit5 prior to disabling the VGA
> > plane.
> >
> > Perhaps the test should be whether (vga_reg & VGA_DISP_DISABLE) == 0 and
> > do nothing if the plane is already o
On Tue, 17 Dec 2013, Thierry Reding wrote:
> This is a superset of the current i2c_dp_aux bus functionality and can
> be used to transfer native AUX in addition to I2C-over-AUX messages.
>
> Helpers are provided to read and write the DPCD, either blockwise or
> byte-wise. Many of the existing help
DRM driver for (virtual) vga cards using the bochs dispi
interface, such as the qemu standard vga (qemu -vga std).
Don't bother supporting anything but 32bpp for now, even
though the virtual hardware is able to do that.
Known issue: mmap(/dev/fb0) doesn't work.
Signed-off-by: Gerd Hoffmann
---
On Tue, Dec 17, 2013 at 09:12:10AM -0800, Keith Packard wrote:
> We want to disable the (unused) VGA plane on the intel hardware, which
> should be a simple matter of writing the vga control register. However,
> in 2009 (commit 24f119c769bacac5729297b682fec7811a983cc6), that simple
> code was chang
Implements an I2C-over-AUX I2C adapter on top of the generic drm_dp_aux
infrastructure. It extracts the retry logic from existing drivers, which
should help in porting those drivers to this new helper.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 178 ++
Add a helper to probe a DP link (reading out the maximum rate, link
count and capabilities) as well as configuring it accordingly.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 77 +
include/drm/drm_dp_helper.h | 30 ++
The function reads the link status (6 bytes starting at offset 0x202)
from the DPCD so that it can be conveniently passed to other DPCD
helpers.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 16
include/drm/drm_dp_helper.h | 3 +++
2 files changed, 19
This is a superset of the current i2c_dp_aux bus functionality and can
be used to transfer native AUX in addition to I2C-over-AUX messages.
Helpers are provided to read and write the DPCD, either blockwise or
byte-wise. Many of the existing helpers for DisplayPort take a copy of a
portion of the D
Hi,
This small series introduces some infrastructure to support AUX channels
in a generic way. Drivers make use of it by embedding and filling in a
struct drm_dp_aux. Various helpers can then be used to for example read
from or write to the DPCD.
Patch 1 adds the basic infrastructure as well as a
On Tue, Dec 17, 2013 at 4:33 PM, Dave Airlie wrote:
>
> are available in the git repository at:
>
> git://people.freedesktop.org/~airlied/linux
Nope.
I assume you meant the 'drm-fixes' branch, but you didn't actually
*say* that, and when I pull it I don't get the same diffstat you
claim, so I'
like the hdmi packets the driver is sending.
Does booting with radeon.audio=0 help?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/a
it will suck a bit more power?
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/at
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131217/7ad40222/attachment.html>
Hi Dave,
Just a few more fixes for radeon:
- Stability fix for cayman dpm
- audio fixes for dce6+
The following changes since commit f1cd6594496aa4dc3b816794b4e781058f99867c:
Merge branch 'ttm-fixes-3.13' of git://people.freedesktop.org/~thomash/linux
into drm-next (2013-12-17 09:22:26 +1000)
Enable use of DT for DMM/Tiler.
Originally worked on by Andy Gross
Cc: Andy Gross
Cc: DRI Development
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/d
If you feed the tool a suitable bogus register map you can break it
in arbitary (code executing) ways. While this isn't a particularly
exciting or probable attack vector we still ought to fix it.
One of a set of sscanf issues reported by Jackie Chang
Signed-off-by: Alan Cox
---
drivers/gpu/drm/
We attempt to reschedule an active work which can itself corrupt the
workqueue lists, and we may then free the work item whilst the task is
still pending. Both of these may lead to a system deadlock and an
unresponsive machine without any outputs for a panic to even be shown.
[7.372961] WARNIN
option? If not, it's probably a
buggy monitor or a hdmi receiver that doesn't patch the checksum correctly.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131217/469f4883/attachment.html>
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131217/2e175fc6/attachment-0001.html>
On Tue, Dec 17, 2013 at 09:33:08AM +0200, Jani Nikula wrote:
> On Mon, 16 Dec 2013, Chris Wilson wrote:
> > If we fail to remove a conflicting fb driver, we need to abort the
> > loading of the second driver to avoid likely kernel panics.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Jean-Christoph
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131217/85a650d1/attachment.html>
On Mon, 07 Oct 2013 11:05:57 +0300
Jani Nikula wrote:
> On Fri, 04 Oct 2013, Todd Previte wrote:
> > - DP_TEST_LINK_PATTERN is ambiguous, rename to DP_TEST_LINK_VIDEO_PATTERN
> > to clarify
> > - Added DP_TEST_LINK_FAUX_PATTERN to support automated testing of Fast AUX
> >
> > Signed-off-by:
efuse to load the driver if the card is secondary...
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131217/b384c947/attachment.pgp>
On Mon, 16 Dec 2013, Chris Wilson wrote:
> If we fail to remove a conflicting fb driver, we need to abort the
> loading of the second driver to avoid likely kernel panics.
>
> Signed-off-by: Chris Wilson
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: linux-fbdev at vger.kerne
On Mon, Dec 16, 2013 at 5:40 PM, Daniel Vetter wrote:
> Have a bit of logic in the exynos ->detect function to re-try a 2nd
> round of edid probing after each hdp interrupt if the first one
> returns an -ENXIO. Only tricky part is to be careful with edge
> detection so that userspace gets all the
We want to disable the (unused) VGA plane on the intel hardware, which
should be a simple matter of writing the vga control register. However,
in 2009 (commit 24f119c769bacac5729297b682fec7811a983cc6), that simple
code was changed to also smash the SR01 VGA register to fix "random
crash and lockups
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131217/2a88aa54/attachment.html>
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131217/8fde705a/attachment.html>
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131217/634a0c2f/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131217/4b7b273f/attachment.html>
On Mon, Dec 16, 2013 at 11:55 PM, Daniel Drake wrote:
> On Mon, Dec 16, 2013 at 4:19 PM, Daniel Vetter wrote:
>> This usually happens if the hpd isn't properly recessed and we start
>> the i2c transaction while the physical connection hasn't been
>> established properly yet. If you're _really_ sl
39 matches
Mail list logo
