type||
--
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/20140221/f5ca5d15/attachment.html>
On Don, 2014-02-20 at 08:44 +0100, Boszormenyi Zoltan wrote:
> 2014-02-20 06:47 keltez?ssel, Michel D?nzer ?rta:
> > On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote:
> >> 2014-02-20 04:20 keltez?ssel, Michel D?nzer ?rta:
> >>> On Mit, 2014-02-19 at 11:56 +0100, Boszormenyi Zoltan wrote:
On Fri, Feb 21, 2014 at 12:25 PM, Michel D?nzer wrote:
> On Don, 2014-02-20 at 08:44 +0100, Boszormenyi Zoltan wrote:
>> 2014-02-20 06:47 keltez?ssel, Michel D?nzer ?rta:
>> > On Don, 2014-02-20 at 06:09 +0100, Boszormenyi Zoltan wrote:
>> >> 2014-02-20 04:20 keltez?ssel, Michel D?nzer ?rta:
>> >>
Let me know if anything else would be
helpful.
--
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/20140221/4f1d8f76/attachment.html>
On Fri, Feb 21, 2014 at 6:27 AM, Rafael J. Wysocki
wrote:
> On 2/20/2014 10:23 AM, Jiang Liu wrote:
>>
>> Fix regression caused by commit b072e53, which breaks loading nouveau
>> driver on optimus laptops.
>>
>> On some platforms, ACPI _DSM method (nouveau_op_dsm_muid, function 0)
>> has special r
aps the last sentence of the comment can now go
away as well?
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/20140221/ff910e25/attachment.pgp>
h
the device and the minor will have become invalid when drm_dev_ref() is
called.
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/20140221/c0ae5d93/attachment.pgp>
n/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140221/5c0820ef/attachment.pgp>
render0 (GPU#1, render)
?
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/20140221/8e711f5c/attachment.pgp>
l waiting for a reply from
> him.
The series:
Tested-by: Thierry Reding
-- 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/20140221/fa247aa0/attachment-0001.pgp>
Hi
On Fri, Feb 21, 2014 at 8:09 AM, Thierry Reding
wrote:
> On Wed, Jan 29, 2014 at 03:01:53PM +0100, David Herrmann wrote:
> [...]
>> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
>> index c51333e..d3232b6 100644
>> --- a/drivers/gpu/drm/drm_stub.c
>> +++ b/drivers/gpu/drm
v_ref() is
> > called.
>
> No, it's locked via the drm_global_mutex. And later I introduce a
> spinlock here that protects this in case we remove the global lock.
Indeed. Thanks for clarifying.
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/20140221/17b1780a/attachment.pgp>
From: Thierry Reding
This series builds on top of David's reliable DRM minor series:
[PATCH 00/13] DRM Reliable Minor-IDs
Tegra K1 has a Kepler-type GPU without any display engine. Instead it
reuses the Tegra display engine. That means that effectively the GPU
becomes a render-node only
From: Thierry Reding
The term "legacy" is overloaded in the context of DRM. DRM_MINOR_LEGACY
doesn't accurately describe the use of the minor. The associated minor
is the primary minor for a device, as reflected by the .primary field of
struct drm_device. For consistency, rename the enumeration v
From: Thierry Reding
Currently drivers that set the DRIVER_MODESET feature are considered to
be non-legacy drivers. At the same time DRIVER_MODESET implies that the
mode-setting IOCTLs are available. It is therefore not possible to
distinguish between a non-legacy driver with full mode-setting su
From: Thierry Reding
Wherever possible, use drm_core_check_feature() for consistency.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fops.c | 8
drivers/gpu/drm/drm_gem.c | 6 +++---
drivers/gpu/drm/drm_stub.c | 2 +-
drivers/gpu/drm/exyn
From: Thierry Reding
When kernel mode-setting is disabled, mark the driver as legacy to pick
up the special semantics required for userspace mode-setting.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/i915/i915_drv.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
From: Thierry Reding
Support non-legacy drivers without mode-setting functionality by using
the new DRIVER_LEGACY feature to separate out legacy code, rather than
relying on DRIVER_MODESET not being advertised.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_bufs.c | 12
From: Thierry Reding
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_crtc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 35ea15d5..9f9044a0a3ee 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
From: Thierry Reding
Non-legacy devices may not always support mode-setting functionality, so
create the primary minor conditionally.
One setup where this happens is the Tegra K1, where the Tegra DRM driver
exposes the display engine via standard KMS IOCTLs, and nouveau drives
the Kepler-type GP
From: Thierry Reding
The Exynos driver always sets DRIVER_GEM, so testing for the absence of
the feature will always fail.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_
From: Thierry Reding
The gma500 driver sets DRIVER_GEM unconditionally, so testing for the
absence of the feature will always fail.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/gma500/gem.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/dr
From: Thierry Reding
The i810 driver never sets DRIVER_HAVE_IRQ, so testing for the presence
of the feature will always fail.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/i810/i810_dma.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gp
From: Thierry Reding
The i915 driver sets DRIVER_GEM unconditionally, so testing for the
feature will always fail.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/i915/i915_gem_context.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drive
From: Thierry Reding
The QXL driver sets DRIVER_MODESET unconditionally, so testing for the
absence of the feature will always fail.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/qxl/qxl_kms.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gp
On Fri, Feb 21, 2014 at 2:55 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> When kernel mode-setting is disabled, mark the driver as legacy to pick
> up the special semantics required for userspace mode-setting.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/i915/i915_drv.c | 8
fically meant for this type of situation. On a side
note, I think cur_size should be size_t rather than ssize_t.
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/20140221/08d60f63/attachment-0001.pgp>
-
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/20140221/90250735/attachment.pgp>
On Fri, Feb 21, 2014 at 03:34:43AM +, Sharma, Shashank wrote:
> Hi Ville/All,
>
> We gave a presentation on design on this framework, few months ago, in one of
> our common forum with OTC folks.
> We discussed, took review comments, and re-designed the framework, as per
> the feedbacks.
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140221/54f78c03/attachment.html>
[0]: http://lists.x.org/archives/xorg-devel/2014-February/040568.html
-- 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/20140221/009a3a1e/attachment.pgp>
with STEAM_OVERLAY=1.
--
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/20140221/8ea0d4ea/attachment.html>
ms.c:1366
>>> #10 0x00438b4d in AddGPUScreen (pfnInit=0x7fadbcd36c60
>>> ,
>>> argc=argc at entry=1, argv=argv at entry=0x7fff83c684c8) at dispatch.c:3874
>>> #11 0x0047aa9f in InitOutput (pScreenInfo=pScreenInfo at
>>> entry=0x82dd60 ,
>>> argc=argc at entry=1, argv=argv at entry=0x7fff83c684c8) at xf86Init.c:886
>>
>> Hmm, looks like there's confusion about how colormaps are supposed to be
>> handled.
>>
>>
>> Dave, any ideas?
>
> xf86_crtc_supports_gamma probably stops us from ever getting into that
> function, but in the case where we have 0 crtcs I could see fallout.
>
> Either fix the DDX to not call colormap handling if we have 0 crtcs
> and/or fix the server to not install bother with colormaps if we have
> 0 crtcs.
>
Does the attached patch help?
Alex
> Dave.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: 0001-radeon-don-t-install-colormap-handling-if-there-are-.patch
Type: text/x-diff
Size: 1792 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140221/940a29b9/attachment-0001.patch>
031935 SMP Mon Nov 4 00:36:54
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
--
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/2014
attachment was scrubbed...
Name: Xorg.0.log.fixed.gz
Type: application/x-tar
Size: 9901 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140221/e05c9936/attachment.tar>
https://bugzilla.kernel.org/show_bug.cgi?id=70651
--- Comment #2 from Fabio Sangiovanni ---
hi, any advice on this, please?
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Fri, Feb 21, 2014 at 02:20:24PM +, Sharma, Shashank wrote:
> Hi Ville,
>
> Thanks for your time and comments.
> I can understand two basic problems what you see in this implementation:
>
> 1. The most important issue from my POV is that it can't be part of the
> atomic modeset.
>
org/archives/dri-devel/attachments/20140221/11b7f342/attachment.html>
On Fri, Feb 21, 2014 at 9:20 AM, Sharma, Shashank
wrote:
> Hi Ville,
>
> Thanks for your time and comments.
> I can understand two basic problems what you see in this implementation:
>
> 1. The most important issue from my POV is that it can't be part of the
> atomic modeset.
> 2. it make the w
ime_suspend(): radeon_pmops_runtime_suspend+0x0/0xa0
[radeon]
return -22
Xorg crashes and Xorg.0.log now contains the backtrace, attached.
Best regards,
Zolt?n B?sz?rm?nyi
-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log-1.14-segfault.gz
Type: application/x-tar
Size: 7917 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140221/8bd36ad0/attachment.tar>
On Fri, Feb 21, 2014 at 9:32 AM, Boszormenyi Zoltan wrote:
> 2014-02-21 14:37 keltez?ssel, Alex Deucher ?rta:
>
>>
>> Does the attached patch help?
>>
>> Alex
>
>
> Yes, it helped, thank you very much.
> The compressed Xorg.0.log is attached as proof.
>
> To others: the patch is against xf86-video
https://bugzilla.kernel.org/show_bug.cgi?id=70651
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #3 fr
led desktop compositing before doing the tests.
--
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/20140221/01dd5b72/attachment.html>
On Fri, Feb 21, 2014 at 9:46 AM, Ville Syrj?l?
wrote:
> On Fri, Feb 21, 2014 at 02:20:24PM +, Sharma, Shashank wrote:
>> Hi Ville,
>>
>> Thanks for your time and comments.
>> I can understand two basic problems what you see in this implementation:
>>
>> 1. The most important issue from my POV
https://bugzilla.kernel.org/show_bug.cgi?id=70651
--- Comment #4 from Alex Deucher ---
Created attachment 126951
--> https://bugzilla.kernel.org/attachment.cgi?id=126951&action=edit
possible fix for SI
Starting with 3.13, the driver automatically powers down the dGPU on hybrid
laptops when it'
When we power down the dGPU on a PX system, bail if the
user tried to adjust the power state or check the temperature.
The GPU is powered down, so it doesn't make sense to actually
do anything. We could power up the dGPU to complete the
operation, but it would just be undone again as soon as it wa
Am 21.02.2014 16:50, schrieb Alex Deucher:
> When we power down the dGPU on a PX system, bail if the
> user tried to adjust the power state or check the temperature.
> The GPU is powered down, so it doesn't make sense to actually
> do anything. We could power up the dGPU to complete the
> operatio
Now that Christian fixed the performance problems with
the feedback buffer in mesa, we can enable variable UVD
clocks. There are multiple UVD power states associated
with different types and numbers of streams. This uses
the appropriate state based on that information rather
than always using the
On Thu, Feb 20, 2014 at 3:20 PM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Both are complex enough on their own.
>
> Signed-off-by: Christian K?nig
For the series:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/Makefile | 2 +-
> drivers/gpu/drm/radeon/radeon_gart.
Am 21.02.2014 17:34, schrieb Alex Deucher:
> Now that Christian fixed the performance problems with
> the feedback buffer in mesa, we can enable variable UVD
> clocks. There are multiple UVD power states associated
> with different types and numbers of streams. This uses
> the appropriate state b
On Fri, Feb 21, 2014 at 12:01 PM, Christian K?nig
wrote:
> Am 21.02.2014 17:34, schrieb Alex Deucher:
>
>> Now that Christian fixed the performance problems with
>> the feedback buffer in mesa, we can enable variable UVD
>> clocks. There are multiple UVD power states associated
>> with different
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140221/725ea60a/attachment.html>
Hi Ville/All,
We gave a presentation on design on this framework, few months ago, in one of
our common forum with OTC folks.
We discussed, took review comments, and re-designed the framework, as per the
feedbacks.
We also discussed the benefits of providing the controls directly from /sysfs
Thanks, Rafael.
Will cc ACPI maillist next time.
On 2014/2/21 4:27, Rafael J. Wysocki wrote:
> On 2/20/2014 10:23 AM, Jiang Liu wrote:
>> Fix regression caused by commit b072e53, which breaks loading nouveau
>> driver on optimus laptops.
>>
>> On some platforms, ACPI _DSM method (nouveau_op_dsm_mu
Hi Ville,
Thanks for your time and comments.
I can understand two basic problems what you see in this implementation:
1. The most important issue from my POV is that it can't be part of the atomic
modeset.
2. it make the whole API inconsistent.
I am not sure if its good to block all c
David,
Please incorporate the latest TDA998x I2C updates, which can be found at:
git://ftp.arm.linux.org.uk/~rmk/linux-cubox.git tda998x-devel
with SHA1 5e7fe2fef4347d7a09bb15588d8bbe3cb83b6ed4.
Updates from Jean-Fracois for the TDA998x driver, which are on top of
the fixes you have previousl
On Fri, Feb 21, 2014 at 9:49 AM, Rob Clark wrote:
> On Fri, Feb 21, 2014 at 9:20 AM, Sharma, Shashank
> wrote:
>> Hi Ville,
>>
>> Thanks for your time and comments.
>> I can understand two basic problems what you see in this implementation:
>>
>> 1. The most important issue from my POV is that i
ame of the controls and the format of the data (something similar to
the device tree bindings). That way user space can expect "color conversion
matrix" to mean the same thing everywhere, to get the same data as input,
and to work the same way on all platforms.
St?phane
-- next p
From: Ville Syrj?l?
I'm going to require vblank interrupts during modeset in i915 soon, however
the drm vblank code won't currently allow it. It simply refuses to re-enable
the vblank interrupts whenever they were disable and the refcount is
already elevated. That means anyone holding a vblank re
From: Peter Hurley
The irq flags state is already established by the outer
spin_lock_irqsave(); re-disabling irqs is redundant.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/drm_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/driver
From: Ville Syrj?l?
Currently there's one per-device vblank disable timer, and it gets
reset wheneven the vblank refcount for any crtc drops to zero. That
means that one crtc could accidentally be keeping the vblank interrupts
for other crtcs enabled even if there are no users for them. Make the
From: Ville Syrj?l?
If someone holds a vblank reference across the modeset, and after/during
the modeset someone tries to grab a vblank reference, the current code
won't re-enable the vblank interrupts. That's not good, so instead allow
the driver to choose whether drm_vblank_get() should always
From: Ville Syrj?l?
Tell the drm core vblank code to reject drm_vblank_get()s only between
drm_vblank_off() and drm_vblank_on() calls, and sprinkle the appropriate
drm_vblank_on() calls to the .crtc_enable() hooks. At this time I kept
the off calls in their current position, and added the on call
From: Ville Syrj?l?
Allow the driver to specify whether all new vblank requests after
drm_vblank_off() should be rejected. And add a counterpart called
drm_vblank_on() which will again allow vblank requests to come in.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/armada/armada_crtc.c |
2014-02-21 16:12 keltez?ssel, Alex Deucher ?rta:
> On Fri, Feb 21, 2014 at 9:32 AM, Boszormenyi Zoltan wrote:
>> [zozo at localhost ~]$ DRI_PRIME=1 glxgears
>> Running synchronized to the vertical refresh. The framerate should be
>> approximately the same as the monitor refresh rate.
>> 5589 fram
Hi
On Fri, Feb 21, 2014 at 8:30 AM, Thierry Reding
wrote:
> On Wed, Feb 12, 2014 at 02:36:24PM +0100, Daniel Vetter wrote:
>> On Wed, Jan 29, 2014 at 03:01:58PM +0100, David Herrmann wrote:
>> > Whenever we access minor->device, we are in a minor->kdev->...->fops
>> > callback so the minor->kdev
Testing on Exynos4412, when changing screen resolution under GNOME/X11,
first DPMS is set to OFF via drm_mode_obj_set_property_ioctl.
This is done via drm_hdmi_dpms which powers down the mixer then the
HDMI component.
Then the mode change happens. We then see this call chain, powering things
back
Alex,
shouldn't you send a pull request, that this land in 3.14-rc4?
Just in case...
Thanks,
Dieter
Am 20.02.2014 18:47, schrieb Christian K?nig:
> From: Christian K?nig
>
> Otherwise we might get a crash here.
>
> Signed-off-by: Christian K?nig
> Cc: stable at vger.kernel.org
> ---
> dr
On Fri, Feb 21, 2014 at 4:26 PM, Dieter N?tzel wrote:
> Alex,
>
> shouldn't you send a pull request, that this land in 3.14-rc4?
> Just in case...
I'll send a pull request next week along with any other patches I've
accumulated since the last pull. I usually try and send a -fixes pull
once a wee
69 matches
Mail list logo
