From: Dave Airlie
For QXL hw we really want the bits to be replaced as we change
the preferred mode on the fly, and the same goes for virgl when
I get to it, however the original fix for this seems to have caused
a wierd regression on Intel G33 that in a stunning display of failure
at opposition
Hi, Christian,
As Chen Jie says, there are a lot of Loongson machines using RS780,
we are very glad to see the RS780's UVD support.
Regards,
Huacai
> 2014/1/9 Christian K?nig :
>> Hi,
>>
>> The code for the first generation UVD blocks (RV6xx, RS780, RS880 and
>> RV790)
>> is already implemented
sts.freedesktop.org/mailman/listinfo/nouveau
-- next part --
A non-text attachment was scrubbed...
Name: 0001-fix-null-ptr-dereferences-on-some-boards.patch
Type: text/x-patch
Size: 1629 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/5ea59dbe/attachment-0001.bin>
ret = nouveau_therm_create(parent, engine, oclass, &priv);
>> *pobject = nv_object(priv);
>> + device->subdev[NVDEV_SUBDEV_THERM] = *pobject;
>> if (ret)
>> return ret;
>>
>>
>>
>>
>> ___
>> Nouveau mailing list
>> Nouveau at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
-- next part --
A non-text attachment was scrubbed...
Name: 0001-fix-null-ptr-dereferences-on-some-boards.patch
Type: text/x-patch
Size: 4790 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/5b10ce11/attachment.bin>
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/8980d670/attachment.html>
mes when R600_LLVM=1
||with LLVM < 3.4
--
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/att
2014/1/10 Mike Lothian :
> Fingers crossed this happens soon especially now that BluRays can be played
> on Linux
>
> 1080p VC1 does not play well on a Phenom II X4 even when multi threaded
It seems UVD based VC1 playback is broken??
With a Radeon 6570 card, neither X86 nor the loongson platform g
calling parameters are in a mesa dev list post.
--
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/20140114/74afe8b0/attachment-0001.html>
op 13-01-14 19:50, Colin Cross schreef:
> On Mon, Jan 13, 2014 at 4:31 AM, Maarten Lankhorst
> wrote:
>> The kernel fence implementation doesn't use event queues, but needs
>> to perform the same wake up. The symbol is not exported, since the
>> fence implementation is not built as a module.
>>
>>
harvested Tahiti I think.
--
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/20140114/807a748d/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/10d309af/attachment.html>
ons, being against git master.
--
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/20140114/6da32ec8/attachment.html>
sa-git
--
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/20140114/c6029d2a/attachment.html>
2014-01-14 07:06 keltez?ssel, Chen Jie ?rta:
> 2014/1/10 Mike Lothian :
>> Fingers crossed this happens soon especially now that BluRays can be played
>> on Linux
>>
>> 1080p VC1 does not play well on a Phenom II X4 even when multi threaded
> It seems UVD based VC1 playback is broken??
>
> With a R
se control node. What's use of /dev/dri/control node?
I am using Ubuntu 12.04-3
Thanks in advance.
Akash Hajari.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/0cff77a4/attachment.html>
ker. They shouldn't enable GLES2 for the glamor
build.
--
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/20140114/8211a5c1/attachment-0001.html>
radeonsi and mesa-git
I'm closing this then.
--
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/20140114/e618a34e/attachment.html>
Am 14.01.2014 07:06, schrieb Chen Jie:
> 2014/1/10 Mike Lothian :
>> Fingers crossed this happens soon especially now that BluRays can be played
>> on Linux
>>
>> 1080p VC1 does not play well on a Phenom II X4 even when multi threaded
> It seems UVD based VC1 playback is broken??
>
> With a Radeon
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/0117ed63/attachment.html>
the bug.
>
>
--
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/20140114/54b72131/attachment.html>
On Tue, Jan 14, 2014 at 5:15 AM, Akash Hajari wrote:
> Hi,
> I am new to DRM & KMS and I had seen your pdf named "why & how to use kms as
> your user space display api if choice".
> I have to understand initial mode setting flow of x server. So is it
> located in /xorg-server/hw/xfree86/modes/ or
//lists.freedesktop.org/archives/dri-devel/attachments/20140114/f1155e71/attachment.pgp>
Hi David,
I'm not sure if this is a good bisect because the errors are noisy,
however it's good to inform you of this possibility.
First bad commit may be a3483353c ("drm: check for !kdev in drm_unplug_minor()")
===
PARENT COMMIT NOT CLEAN. LOOK OU
next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/d9f51815/attachment.pgp>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140114/6b04379f/attachment.html>
nts/20140114/735b684f/attachment.html>
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/20140114/0dae781e/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/521958d6/attachment.html>
bit hackish
because it assumes that nodes in DTB will be in the same order as in
the DTS. That has been true since the beginning of DT on Linux AFAIK
and therefore should be reasonably safe.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/b20e2b37/attachment.pgp>
Hi
On Tue, Jan 14, 2014 at 2:45 PM, Fengguang Wu wrote:
> Hi David,
>
> I'm not sure if this is a good bisect because the errors are noisy,
> however it's good to inform you of this possibility.
>
> First bad commit may be a3483353c ("drm: check for !kdev in
> drm_unplug_minor()")
To be honest,
The Tegra DRM driver assumes that CRTCs are probed in the order listed
in the DT. While DT makes no such guarantees in the first place, this
used to work fine. With the introduction of the panel support, however,
more often than not one of the CRTCs will defer probing (caused by the
panel not havin
The head number of a given display controller is fixed in hardware and
required to program outputs appropriately. Relying on the driver probe
order to determine this number will not work, since that could yield a
situation where the second head was probed first and would be assigned
head number 0 i
The mask of possible CRTCs that an output (DRM encoder) can be attached
to is relative to the position within the DRM device's list of CRTCs.
Deferred probing can cause this to not match the pipe number associated
with a CRTC. Use the newly introduced drm_crtc_mask() to compute the
mask by looking
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
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
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
Add a helper to probe a DP link (read out the supported DPCD revision,
maximum rate, link count and capabilities) as well as power up the DP
link and configure it accordingly.
Signed-off-by: Thierry Reding
---
Changes in v3:
- split into drm_dp_link_power_up() and drm_dp_link_configure()
- do not
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
---
Changes in v3:
- add back DRM_DEBUG_KMS and DRM_ERROR message
not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/10f73da6/attachment.pgp>
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/c3196f60/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/98bdc535/attachment-0001.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/934c73fc/attachment.html>
is 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/20140114/16eba905/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/12496235/attachment.html>
On Fri, 10 Jan 2014, Cyrille Pontvieux wrote:
> I recently acquired a Toshiba laptop with a Intel Graphics 4600M in it
> (8086:0416, subsystem 1179:fa82).
> This Toshiba system is provided with UEFI (EFI Insyde H2O 1.30).
> I compiled and use Linux kernel 3.13-rc7 (config.gz attached)
> This syst
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/b0ccd428/attachment.html>
Not holding the mutex potentially causes corruption of the kernel
channel when page flipping.
Cc: stable at vger.kernel.org #3.13
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 29c3efdfc7dd..76e3cf025c
There are some cases where it's fine to not hold the cli->mutex, but in those
cases we
are the only caller and we should really be able to acquire cli->mutex without
blocking.
This patch will prevent future occurrences where commands are sent to a channel
without
proper locking.
Signed-off-by:
On Tue, Jan 14, 2014 at 9:55 AM, Thierry Reding
wrote:
> Add a helper to probe a DP link (read out the supported DPCD revision,
> maximum rate, link count and capabilities) as well as power up the DP
> link and configure it accordingly.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v3:
> -
On Tue, Jan 14, 2014 at 9:55 AM, Thierry Reding
wrote:
> 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 wri
On Tue, Jan 14, 2014 at 10:54 AM, Alex Deucher wrote:
> On Tue, Jan 14, 2014 at 9:55 AM, Thierry Reding
> wrote:
>> 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. Va
On 01/14/2014 07:14 AM, Thierry Reding wrote:
> On Mon, Jan 13, 2014 at 10:46:45AM -0700, Stephen Warren wrote:
>> On 01/13/2014 07:21 AM, Thierry Reding wrote:
>>> The head number of a given display controller is fixed in hardware and
>>> required to program outputs appropriately. Relying on the d
u 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/20140114/330ec53b/attachment.html>
On 01/14/2014 07:45 AM, Thierry Reding wrote:
> The head number of a given display controller is fixed in hardware and
> required to program outputs appropriately. Relying on the driver probe
> order to determine this number will not work, since that could yield a
> situation where the second head
This address will be used to verify panel CRC for test and
validation purposes.
Signed-off-by: Rodrigo Vivi
---
include/drm/drm_dp_helper.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1d09050..ba0b90d 100644
---
This debugfs interface will allow intel-gpu-tools test case
to verify if screen has been updated properly on cases like PSR.
v2: Accepted all Daniel's suggestions:
* grab modeset lock
* loop over connector and check DPMS on
* return errors
* use _eDP1 suffix for easy future extensi
op.org/archives/dri-devel/attachments/20140114/aa41cf5f/attachment.html>
ceiving 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/20140114/65a822ec/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/82757a1f/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/976e3a76/attachment.html>
lt to do, if you are
interested.
--
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/20140114/d0c75cec/attachment.html>
nts/20140114/738ab2a5/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/a2bcecec/attachment-0001.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140114/13335df3/attachment.html>
hives/dri-devel/attachments/20140114/f11bd285/attachment.html>
Both i915 and Armada had the exact same implementation. For an upcoming
patch, I'd like to call this function from two different source files in
i915, and having it available externally helps there too.
While moving, add 'debugfs_' to the name in order to match the other drm
debugfs helper functio
On Wed, Jan 15, 2014 at 12:25:10AM +0100, Daniel Vetter wrote:
> On Tue, Jan 14, 2014 at 06:14:06AM -0800, Ben Widawsky wrote:
> > Both i915 and Armada had the exact same implementation. For an upcoming
> > patch, I'd like to call this function from two different source files in
> > i915, and havin
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang
Reviewed-by: Terje Bergstrom
---
Should go via subsystem tree
drivers/gpu/drm/tegra/hdmi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm
On 14/01/14 05:15, Ben Skeggs wrote:
> On Tue, Jan 14, 2014 at 3:07 PM, Ben Skeggs wrote:
>> On Tue, Jan 14, 2014 at 1:22 PM, Bob Gleitsmann
>> wrote:
>>> I should have mentioned that this applies to Linus' 3.13.0-rc7 and rc8
>>> git. Maybe it's obvious.
>> Hey Bob,
>>
>> Thanks for reporting th
69 matches
Mail list logo
