://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131014/191163.html
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
On 14.10.2013 21:14, Stephen Warren wrote:
> On 10/14/2013 08:00 AM, Thierry Reding wrote:
>> Yes, as long as the device tree files includes the most specific
>> value in the compatible this should still be possible. So we'd have
>> this:
>>
>> gr2d@5414 { compatible = "nvida,tegra114-gr2d",
>>
https://bugzilla.kernel.org/show_bug.cgi?id=60691
--- Comment #3 from Egor Y. Egorov ---
Created attachment 111031
--> https://bugzilla.kernel.org/attachment.cgi?id=111031&action=edit
dmesg from 3.12-rc5
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=60691
--- Comment #2 from Egor Y. Egorov ---
(In reply to Alex Deucher from comment #1)
> Looks like a duplicate of:
> https://bugs.freedesktop.org/show_bug.cgi?id=67187
This bug is closed now. But in my case bug not resolved. Reproduced on 3.11.5
and
2013/10/15 Inki Dae :
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> index c417c90..ba63c72 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> @@ -26,24 +26,23 @@
>>
This patch removes unnecessary runtime pm related function calls
from fimd_suspend and fimd_resume functions.
Changelog v2:
- use UNIVERSAL_DEV_PM_OPS macro instead.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 59 ++-
https://bugs.freedesktop.org/show_bug.cgi?id=68391
--- Comment #12 from Vladimir Ysikov ---
(In reply to comment #11)
> It seems that the commit 6e51c2a941955fd2a34d62437fc149e633e79ec7 "radeonsi:
> Allow Sinking pass to move preloaded const/res/sampl" by Vincent Lejeune has
> fixed this problem
https://bugzilla.kernel.org/show_bug.cgi?id=61811
--- Comment #23 from Bruno Wolff III ---
I have a Fedora bug for that issue. I'm starting to work on bisecting some
older kernel bugs and may bring it back to the kernel when I'm done. But I'm
starting on a sound / network / probable locking bug f
https://bugs.freedesktop.org/show_bug.cgi?id=63997
--- Comment #27 from bgunte...@gmail.com ---
I will say, as I'm going through the menus, the artifacts are not as bad as
they've been. so there is improvement!
a lot of stuff that was completely unreadable i'm now able to read.
close! i look for
https://bugs.freedesktop.org/show_bug.cgi?id=63997
--- Comment #26 from bgunte...@gmail.com ---
i can concur... still getting the artifacts; for me in XBMC GUI.
what else can we do to help?
Logs? etc...
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #14 from Mohammad AlSaleh ---
(In reply to comment #11)
> Created attachment 87616 [details] [review]
> possible fix
>
> Please try this patch and append radeon.audio=1 to the kernel command line
> in grub.
There appears to be a ser
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #13 from Mohammad AlSaleh ---
Created attachment 87633
--> https://bugs.freedesktop.org/attachment.cgi?id=87633&action=edit
partial kernel log (3.12rc5 + patch 87616)
--
You are receiving this mail because:
You are the assignee fo
https://bugzilla.kernel.org/show_bug.cgi?id=61811
--- Comment #22 from Dieter Nützel ---
(In reply to Bruno Wolff III from comment #0)
> I need to use radeon.agpmode=-1 with my rv280 based graphics card due to a
> long (2+ years) standing bug with the driver.
Hello Bruno,
isn't it then time to
The 'atomic' mechanism allows for multiple properties to be updated,
checked, and commited atomically. This will be the basis of atomic-
modeset and nuclear-pageflip.
The basic flow is:
state = dev->atomic_begin();
for (... one or more ...)
obj->set_property(obj, state, prop, value);
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #12 from Mohammad AlSaleh ---
(In reply to comment #10)
> (In reply to comment #6)
> > (In reply to comment #2)
> > > Did you started audio before enabling it with "xrandr --output HDMI-0
> > > --set
> > > audio auto" ?
>
> Had you
Ooops, the new problem is not so rare. It has now happened to me 3
times in an hour.
Marek
On Mon, Oct 14, 2013 at 9:13 PM, Marek Olšák wrote:
> I tested this and had over 1546 lockups followed by a successful GPU
> reset. Then the kernel probably crashed (judging by the fact ssh was
> dead). St
I tested this and had over 1546 lockups followed by a successful GPU
reset. Then the kernel probably crashed (judging by the fact ssh was
dead). Still, it's pretty impressive.
There is a new problem though. The X server sometimes gets stuck in
GEM_WAIT and waits forever, even if there were no lock
On 10/14/2013 07:55 AM, Thierry Reding wrote:
> On Fri, Oct 11, 2013 at 04:43:35PM -0600, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> This commit adds support for both DSI outputs found on Tegra. Only very
>>> minimal functionality is implemented, so advanced features
On 10/14/2013 08:00 AM, Thierry Reding wrote:
> On Mon, Oct 14, 2013 at 08:58:34AM +0300, Terje Bergström wrote:
>> On 12.10.2013 01:43, Stephen Warren wrote:
>>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
The gr2d hardware in Tegra114 is compatible with that of
Tegra20 and Tegra30. No
On 10/13/2013 11:58 PM, Terje Bergström wrote:
> On 12.10.2013 01:43, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> The gr2d hardware in Tegra114 is compatible with that of Tegra20 and
>>> Tegra30. No functionaly changes are required.
>>
>> Similarly here, if the HW is
On 10/12/2013 05:41 AM, Thierry Reding wrote:
> On Fri, Oct 11, 2013 at 04:19:19PM -0600, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> From: Mikko Perttunen
>>>
>>> Tegra114 TMDS configuration requires a new peak_current field
>>> and the driver current override bit
On 10/12/2013 05:24 AM, Thierry Reding wrote:
> On Fri, Oct 11, 2013 at 04:13:07PM -0600, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> Tegra114 uses a slightly updated version of host1x with an
>>> additional syncpoint.
>>
>>> drivers/gpu/host1x/hw/host1x02.c
On 10/12/2013 05:32 AM, Thierry Reding wrote:
> On Fri, Oct 11, 2013 at 04:14:27PM -0600, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> From: Mikko Perttunen
>>>
>>> The Tegra114 display controller is backwards-compatible with
>>> previous generations of the Tegra SoC
On Mon, Oct 14, 2013 at 5:32 AM, Christian König
wrote:
> From: Christian König
>
> Stop leaking IB memory and scratch register space when the test fails.
>
> Signed-off-by: Christian König
Both patches applied.
Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/cik.c | 3 +++
> 1 file changed, 3
From: Ville Syrjälä
The atomic modeset ioctl cna be used to push any number of new values
for object properties. The driver can then check the full device
configuration as single unit, and try to apply the changes atomically.
The ioctl simply takes a list of object IDs and property IDs and their
TODO: probably can split this up into prep patch which splits the
msm_queue_fence_cb out of gem..
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/mdp4/mdp4_crtc.c | 41 --
drivers/gpu/drm/msm/mdp4/mdp4_kms.c | 6 ++
drivers/gpu/drm/msm/mdp4/mdp4_kms.h | 1 +
dr
Break the mutable state of a crtc out into a separate structure
and use atomic properties mechanism to set crtc attributes. This
makes it easier to have some helpers for crtc->set_property()
and for checking for invalid params. The idea is that individual
drivers can wrap the state struct in thei
Break the mutable state of a plane out into a separate structure
and use atomic properties mechanism to set plane attributes. This
makes it easier to have some helpers for plane->set_property()
and for checking for invalid params. The idea is that individual
drivers can wrap the state struct in t
From: Ville Syrjälä
Refactor the code to check whether an object has a specific property
to a new function.
v1: original
v2: rebase on atomic -- Rob Clark
v3: EINVAL->ENOENT
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 27 +++
1 file changed, 15 insert
From: Ville Syrjälä
To avoid having to pass object types from userspace for atomic mode
setting ioctl, allow drm_mode_object_find() to look up an object of any
type. This will only work as long as the all object types share the ID
space.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crt
Split property values out into a different struct, so we can later
move property values into state structs. This will allow the
property values to stay in sync w/ the state updates which are
either discarded or atomically committed.
And since we are touching all the same code, add support for mut
Lifted from Russell King's armada drm driver, plus a couple others
added.
---
include/drm/drm_crtc.h | 40
1 file changed, 40 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e042d12..0ea61b3 100644
--- a/include/drm/drm_crt
Flag for range property types indicating that the value is a signed
integer rather than unsigned. For range properties, the signed flag
will trigger use of signed integer comparisions, to handle negative
values properly.
---
drivers/gpu/drm/drm_crtc.c | 15 +++
include/drm/drm_crtc.h
This indicates to userspace that the property is something that can
be set dynamically without requiring a "test" step to check if the
hw is capable. This allows a userspace compositor, such as weston,
to avoid an extra ioctl to check whether it needs to fall-back to
GPU to composite some surface
An object property is an id (idr) for a drm mode object. This
will allow a property to be used set/get a framebuffer, CRTC, etc.
---
drivers/gpu/drm/drm_crtc.c | 34 ++
include/drm/drm_crtc.h | 10 ++
include/uapi/drm/drm_mode.h | 1 +
3 files change
I'm not really sure if there exists any drm driver usable on m68k?
---
drivers/gpu/drm/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..61db9be 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -7,6 +
This patchset is the merging of Ville's atomic modeset ioctl, and
the drm_{crtc,plane}_state stuff from my original nuclear pageflip
RFC.
It is currently working on msm with an updated version of Ville's
glplane test app (removing cursor properties and atomic event):
https://github.com/robclark
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #11 from Alex Deucher ---
Created attachment 87616
--> https://bugs.freedesktop.org/attachment.cgi?id=87616&action=edit
possible fix
Please try this patch and append radeon.audio=1 to the kernel command line in
grub.
--
You are r
https://bugs.freedesktop.org/show_bug.cgi?id=68451
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi
On Mon, Oct 14, 2013 at 6:19 PM, Gary Mort wrote:
> Is there a repository for the SimpleFB drivers[the DRI driver and the plain
> framebuffer driver]?
Which drivers are you exactly talking about? Do you have links to the
patches? There're several independent projects called "simplefb". If
you
On Mon, Oct 14, 2013 at 12:50:41PM -0400, Alex Deucher wrote:
> On Fri, Sep 20, 2013 at 6:32 PM, Alex Deucher wrote:
> > On Thu, Aug 15, 2013 at 11:48 AM, Alex Deucher
> > wrote:
> >> The vrefresh field of the mode is 0 for most modes
> >> fetched from the EDID (e.g., established timings).
> >>
On Fri, Sep 20, 2013 at 6:32 PM, Alex Deucher wrote:
> On Thu, Aug 15, 2013 at 11:48 AM, Alex Deucher wrote:
>> The vrefresh field of the mode is 0 for most modes
>> fetched from the EDID (e.g., established timings).
>> When dealing with monitors that have a bogus preferred
>> mode, we may not al
https://bugs.freedesktop.org/show_bug.cgi?id=70088
--- Comment #12 from Krzysztof A. Sobiecki ---
(In reply to comment #11)
> Created attachment 87597 [details] [review]
> patch
>
> This is an improved version of the patch, please test.
Glamor acceleration with mesa + this patch works fine, wil
On Mon, Oct 14, 2013 at 9:44 AM, wrote:
> From: Ville Syrjälä
>
> The correct refresh rate for this mode is 75, not 85.
>
> Signed-off-by: Ville Syrjälä
For the series:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_edid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #37 from Alexandre Demers ---
(In reply to comment #36)
> (In reply to comment #30)
> > Is there any performance regression? If there isn't, I'm okay with the
> > revert.
>
> I've run with the original commit 7948ed (+ little workaro
On Mon, Oct 14, 2013 at 6:41 PM, Paul Rogers wrote:
> On Mon, Oct 14, 2013, at 12:22 AM, Daniel Vetter wrote:
>> On Sun, Oct 13, 2013 at 8:50 PM, Paul Rogers
>> wrote:
>> > Arguments: i815, kernel 2.6.34.14, XOrg-7.2, driver xf86-video-i810-
>> > 1.6.5/1.7.4
>>
>> I've "fixed" this in
>>
>> commi
By the same token, I'm also interested in finding a repository the
latest DRI Panel Driver code.
As I understand it, the DRI Panel Driver implements:
A generic CRTC driver along with a few implementations of that Driver
for different LCD panels.
A method for those drivers to inform a central
https://bugzilla.kernel.org/show_bug.cgi?id=63011
--- Comment #3 from Mikko Rapeli ---
Oh, forgot to mention that the problem shows up via docking station DVI port
and external HP/Compaq LA2306x display.
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=63011
--- Comment #2 from Mikko Rapeli ---
No, userspace has not been updated. Problem is easy to reproduce and kernel is
causing it. Bisect is incomplete but maybe this has some information to you:
$ git bisect log
git bisect start
# bad: [ad81f0545ef
Is there a repository for the SimpleFB drivers[the DRI driver and the
plain framebuffer driver]?
I'd like to play around with it for a project - I discovered it via a
google search which pointed me to some archived e-mails on this list -
but those e-mails just contained the patches and I'd rat
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #10 from Alex Deucher ---
(In reply to comment #6)
> (In reply to comment #2)
> > Did you started audio before enabling it with "xrandr --output HDMI-0 --set
> > audio auto" ?
Had you started audio playback in the application before
https://bugs.freedesktop.org/show_bug.cgi?id=64600
--- Comment #16 from Peter Wu ---
Created attachment 87609
--> https://bugs.freedesktop.org/attachment.cgi?id=87609&action=edit
R600_DEBUG=cs cl-program-tester struct-copy.cl
The parameter tests passes when the struct contains one member, but
https://bugzilla.kernel.org/show_bug.cgi?id=63011
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 from
https://bugs.freedesktop.org/show_bug.cgi?id=64600
--- Comment #15 from Peter Wu ---
Created attachment 87607
--> https://bugs.freedesktop.org/attachment.cgi?id=87607&action=edit
Piglit: test copying a struct (with at least three fields)
This is a smaller test case that highlights one specific
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> index c417c90..ba63c72 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> @@ -26,24 +26,23 @@
> * exynos specific encoder str
On Mon, 2013-10-14 at 17:39 +0300, Ville Syrjälä wrote:
> On Mon, Oct 14, 2013 at 04:59:13PM +0300, Imre Deak wrote:
> > On Mon, 2013-09-30 at 17:44 +0300, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > Sprite planes support 180 degree rotation. The lower layers are no
2013/10/14 Sean Paul :
> On Mon, Oct 14, 2013 at 8:42 AM, Inki Dae wrote:
>> Hi, Sean.
>>
>>
>> It's a great patch set.:) That's exactly what we want. So I'd like to merge
>> all patch set to exynos-drm-next if there is no design issue about next
>> week. And then we can add additional minor patch
Today's linux-next merge of the drm tree got conflicts in
drivers/gpu/drm/i915/intel_drv.h
caused by commits e1264eb (Revert "drm/i915: Delay disabling of VGA memory
until vgacon->fbcon handoff is done"), 20ddf66 (drm/i915: Make
intel_crtc_active() available outside intel_pm.c), 18442d0 (
Today's linux-next merge of the drm-intel tree got conflicts in:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel_drv.h
caused by commits e1264eb (Revert "drm/i915: Delay disabling of VGA memory
until vgacon->fbcon handoff is done"
On Mon, Oct 14, 2013 at 04:59:13PM +0300, Imre Deak wrote:
> On Mon, 2013-09-30 at 17:44 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Sprite planes support 180 degree rotation. The lower layers are now in
> > place, so hook in the standard rotation property to expos
On Mon, Oct 14, 2013 at 8:42 AM, Inki Dae wrote:
> Hi, Sean.
>
>
> It's a great patch set.:) That's exactly what we want. So I'd like to merge
> all patch set to exynos-drm-next if there is no design issue about next
> week. And then we can add additional minor patches from others.
>
> Before that
On Fri, Oct 11, 2013 at 04:33:33PM -0600, Stephen Warren wrote:
> On 10/07/2013 02:34 AM, Thierry Reding wrote:
> > Add a driver for simple panels. Such panels can have a regulator that
> > provides the supply voltage and a separate GPIO to enable the panel.
> > Optionally the panels can have a bac
On Mon, Oct 14, 2013 at 08:58:34AM +0300, Terje Bergström wrote:
> On 12.10.2013 01:43, Stephen Warren wrote:
> > On 10/07/2013 02:34 AM, Thierry Reding wrote:
> >> The gr2d hardware in Tegra114 is compatible with that of Tegra20 and
> >> Tegra30. No functionaly changes are required.
> > Similarly
On Mon, 2013-09-30 at 17:44 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Sprite planes support 180 degree rotation. The lower layers are now in
> place, so hook in the standard rotation property to expose the feature
> to the users.
>
> Signed-off-by: Ville Syrjälä
> --
On Fri, Oct 11, 2013 at 04:43:35PM -0600, Stephen Warren wrote:
> On 10/07/2013 02:34 AM, Thierry Reding wrote:
> > This commit adds support for both DSI outputs found on Tegra. Only very
> > minimal functionality is implemented, so advanced features like ganged
> > mode won't work.
> >
> > Due to
https://bugzilla.kernel.org/show_bug.cgi?id=62721
--- Comment #7 from Egor Y. Egorov ---
(In reply to Alex Deucher from comment #2)
> Are you sure cb51bb7107aa040f9779be931e3bd6a7b50e0f69 is the correct commit?
> That commit only affects the debugfs output. If you don't access those
> debugfs fi
On Mon, Oct 14, 2013 at 04:46:50PM +0300, Imre Deak wrote:
> On Mon, 2013-09-30 at 17:44 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > drm_rotation_simplify() can be used to eliminate unsupported rotation
> > flags. It will check if any unsupported flags are present,
On Mon, 2013-09-30 at 17:44 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> drm_rotation_simplify() can be used to eliminate unsupported rotation
> flags. It will check if any unsupported flags are present, and if so
> it will modify the rotation to an alternate form by addi
On Fri, Oct 11, 2013 at 04:37:35PM -0600, Stephen Warren wrote:
> On 10/07/2013 02:34 AM, Thierry Reding wrote:
> > This driver adds support to perform calibration of the MIPI pads for CSI
> > and DSI.
>
> > diff --git a/drivers/gpu/host1x/mipi.c b/drivers/gpu/host1x/mipi.c
>
> > +int tegra_mipi_
From: Ville Syrjälä
I got very confused when I tried to compare the EST modes with the spec.
Bring over a comment from xf86EdidModes.c that actually describes some
of history where these things came from.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 9 +
1 file changed
From: Ville Syrjälä
Also check the est3 modes whose presence is indicated by bit 0.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 98d05f8..1988865 100
I was staring at the est modes a bit and noticed a few small bugs.
Also the modes in our lists confused the hell out of me (esp. the
1152x870 vs 1152x864 issue) until I thought to go digging through
xf86EdidModes.c where the history is actually documented.
Looks like the >=0 vs >0 issue was also
From: Ville Syrjälä
The correct refresh rate for this mode is 75, not 85.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9e81609..98d05f8 100644
--- a/
https://bugs.freedesktop.org/show_bug.cgi?id=70088
Vadim Girlin changed:
What|Removed |Added
Attachment #87148|0 |1
is obsolete|
Am 14.10.2013 11:32, schrieb Christian König:
From: Christian König
Stop fiddling with jiffies, always wait for
RADEON_FENCE_JIFFIES_TIMEOUT.
Consolidate the two wait sequence implementations into just one
function.
Activate all waiters and remember if the reset was already done instead
of
Hi, Sean.
It's a great patch set.:) That's exactly what we want. So I'd like to merge
all patch set to exynos-drm-next if there is no design issue about next
week. And then we can add additional minor patches from others.
Before that, can you re-send all patch set like below?
1. Do not r
This patch modifies the gr2d to reserve a base for syncpoint.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/drm/gr2d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/drm/gr2d.c b/drivers/gpu/host1x/drm/gr2d.c
index 7efd97b..337e1ad 100644
--- a/dri
This patch adds a separate ioctl for delivering syncpoint base number
to user space. If the syncpoint does not have an associated base, the
function returns -ENXIO.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/drm/drm.c | 25 +
include/uapi/drm/tegra_drm.h | 26 +
This patch adds support for hardware syncpoint bases. This creates
a simple mechanism to stall the command FIFO until an operation is
completed.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/dev.h | 2 ++
drivers/gpu/host1x/hw/channel_hw.c | 19 +
d
Functions host1x_syncpt_request() and _host1x_syncpt_alloc() have
been taking a separate boolean flag ('client_managed') for indicating
if the syncpoint value should be tracked by the host1x driver.
This patch converts the field into generic 'flags' field so that
we can easily add more information
The host1x driver uses currently syncpoints statically from host1x point of
view. If we do a wait inside a job, it always has a constant value to wait.
host1x supports also doing relative syncpoint waits with respect to syncpoint
bases. This allows doing multiple operations inside a single submit a
https://bugs.freedesktop.org/show_bug.cgi?id=70035
Tasev changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #9 from Mohammad AlSaleh ---
It is worth noting that the (frozen) frame is still signaled and audio starts
looping after the freeze. Which maybe indicate an endless loop.
Also, when the freeze is not instant, audio keeps working seco
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #8 from Mohammad AlSaleh ---
Created attachment 87594
--> https://bugs.freedesktop.org/attachment.cgi?id=87594&action=edit
dmesg (audio + no dpm)
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #7 from Mohammad AlSaleh ---
Created attachment 87593
--> https://bugs.freedesktop.org/attachment.cgi?id=87593&action=edit
dmesg (audio+dpm)
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #6 from Mohammad AlSaleh ---
(In reply to comment #2)
> Did you started audio before enabling it with "xrandr --output HDMI-0 --set
> audio auto" ?
radeon.audio=1 seems to have no effect!
Passing it does not enable audio. And using
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #5 from Mohammad AlSaleh ---
(In reply to comment #1)
> Please attach your xorg log and dmesg output. If this is a regression can
> you use git to bisect?
I don't think I have enough free space to clone the kernel. So bisection is n
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #4 from Mohammad AlSaleh ---
Created attachment 87591
--> https://bugs.freedesktop.org/attachment.cgi?id=87591&action=edit
Xorg.0.log (current run with DPM)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #3 from Mohammad AlSaleh ---
Created attachment 87590
--> https://bugs.freedesktop.org/attachment.cgi?id=87590&action=edit
dmesg (current run with DPM)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=63011
Bug ID: 63011
Summary: radeon: horizontal stripes when updating screen
Product: Drivers
Version: 2.5
Kernel Version: 3.11.5
Hardware: All
OS: Linux
Tree: Mainl
From: Christian König
Stop fiddling with jiffies, always wait for RADEON_FENCE_JIFFIES_TIMEOUT.
Consolidate the two wait sequence implementations into just one function.
Activate all waiters and remember if the reset was already done instead of
trying to reset from only one thread.
v2: clear res
From: Christian König
Stop leaking IB memory and scratch register space when the test fails.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/cik.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index b874ccd..8f393df
Ok, that one was easy to fix. Please apply the attached patch as well.
Going to send out both for inclusion in 3.12 in a minute.
Christian.
Am 13.10.2013 22:16, schrieb Marek Olšák:
This seems to be better. It can do about 3-5 resets correctly, then
the GPU resuming fails:
[ 246.882780] [drm
https://bugs.freedesktop.org/show_bug.cgi?id=68792
--- Comment #11 from Grigori Goronzy ---
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > (In reply to comment #5)
> > > > You have to enable VDPAU output as well.
> > >
> > > Sorry, but where and how?
> > >
https://bugzilla.kernel.org/show_bug.cgi?id=60827
--- Comment #8 from archie...@gmail.com ---
I did some more digging : the hibernation problem is already present in kernel
3.9.11 while it is absent in 3.9.9. So, it seems that it was introduced either
in 3.9.10 or 3.9.11. The last kernel that I co
https://bugs.freedesktop.org/show_bug.cgi?id=67187
Christian König changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #19 from Christian
https://bugs.freedesktop.org/show_bug.cgi?id=70439
--- Comment #2 from Christian König ---
Did you started audio before enabling it with "xrandr --output HDMI-0 --set
audio auto" ?
--
You are receiving this mail because:
You are the assignee for the bug.
On Sun, Oct 13, 2013 at 8:50 PM, Paul Rogers wrote:
> Ancient history, I know, apologies for that, but I can't see my way to a
> solution and need help.
>
> Arguments: i815, kernel 2.6.34.14, XOrg-7.2, driver
> xf86-video-i810-1.6.5/1.7.4
>
> I'm hitting the old buffer reclaim deadlock problem. I
98 matches
Mail list logo
