Hi Linus,
send one yesterday, it bounced due to LF mail fail (linux-foundation.org),
hopefully this one makes it.
i915 fixes, a few display regressions
vmwgfx, possible loop forever fix
nouveau, one userspace interface fix.
Dave.
The following changes since commit 59753a805499f1ffbca4ac0a24b3d
Hi everyone,
X.Org will join the Outreach Program for Women (OPW) in Round 9 (December
2014 - March 2015). The OPW is "open to anyone who was
assigned female at birth and anyone who identifies as a woman, genderqueer,
genderfluid, or genderfree regardless of gender presentation or assigned sex
at
vel/attachments/20140905/68b36b0a/attachment.html>
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/8bf11e1d/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140905/bbfc012b/attachment.html>
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/4862337b/attachment.html>
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/20140905/cc0cf9f0/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/e07f52e3/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/b22eda4d/attachment.html>
From: Johannes Berg
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware state through
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/35a0e43c/attachment.html>
ference, this is the IB we're talking about:
http://pastebin.com/jFWk9bU5
--
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
On Fri, 2014-09-05 at 11:40 +0200, Jonas Gorski wrote:
> On Fri, Sep 5, 2014 at 10:50 AM, Johannes Berg
> wrote:
> > From: Johannes Berg
>
> Can't you just send from the correct address? ;p
Not easily :)
> How about the following to avoid negative options:
>
> config DEV_COREDUMP
>boo
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/64f324b5/attachment.html>
On Fri, Sep 5, 2014 at 10:50 AM, Johannes Berg
wrote:
> From: Johannes Berg
Can't you just send from the correct address? ;p
(snip)
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 4e7f0ff83ae7..134f763d90fd 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/5e7b13cf/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/422c8919/attachment.html>
On Fri, 31 Jan 2014, Alex Deucher wrote:
> On Thu, Jan 30, 2014 at 6:46 PM, Stefan Demharter
> wrote:
>> Saves the current state of the mux and restores it upon resume from
>> hibernation.
>> This is needed for muxed systems because the state of the mux doesn't
>> survive a
>> hibernation-resum
While in real life, we could never fail to grab the newly created mutex,
ww_mutex fault injection has no way to know this. Which could result
that kernels built with CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y might fail to
acquire the new crtc lock. Which results in bad things when the locks
are dropped.
On Fri, Sep 05, 2014 at 07:59:45AM -0400, Rob Clark wrote:
> While in real life, we could never fail to grab the newly created mutex,
> ww_mutex fault injection has no way to know this. Which could result
> that kernels built with CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y might fail to
> acquire the new cr
At driver init no one can access modeset objects and we're
single-threaded. So locking is just cargo-culting here. Worse, with
the new ww mutexes and ww mutex slowpath debugging the mutex_lock
might actually fail, and we don't have the full-blown ww recovery
dance.
Which then leads to fireworks wh
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/2d35e3ea/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=82711
EmanueL Czirai changed:
What|Removed |Added
CC||somelinuxbugs at riseup.net
--- Comment
r the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/9432b998/attachment.html>
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/7de9ba42/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/9ba8a4a3/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=82711
--- Comment #10 from Mike Cloaked ---
The nouveau-dri package in my system was actually updated after I sent this
report (actually three days after my last comment), and therefore presumably
compiled for the new kernel.
[2014-08-21 20:40] [PACMAN
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/64c7e6ab/attachment.html>
From: Gustavo Padovan
This is the beginning of the work to prepare i915 for the upcoming
atomic modesetting API. Here we split the plane update fucntions in
the check and commit states.
v2: use struct intel_plane_state to keep states between check and
commit stages.
v3: take Ville's comments:
From: Gustavo Padovan
This new struct will be the storage of src and dst coordinates
between the check and commit stages of a plane update.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_drv.h | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915
From: Gustavo Padovan
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
This commit splits intel_update_plane() and its commit part can still
fail due to the fb pinning proc
From: Gustavo Padovan
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
The commit part can still fail, but that should be solved in another
upcoming patch.
Signed-off-by:
From: Gustavo Padovan
As a preparation for atomic updates we need to split the code to check
everything we are going to commit first. This patch starts the work to
split intel_primary_plane_setplane() into check() and commit() parts.
More work is expected on this to get a better split of the two
//lists.freedesktop.org/archives/dri-devel/attachments/20140905/a5fc9598/attachment.html>
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/899aff3a/attachment.html>
From: Gustavo Padovan
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
The commit part can still fail, but that should be solved in another
upcoming patch.
Signed-off-by:
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/7a876377/attachment.html>
8f31c4f7dc498710e75b
For this look, here:
http://lists.freedesktop.org/archives/mesa-dev/2014-August/065823.html
Greetings and happy 'bisecting'...;-)
Dieter
--
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/20140905/1df3fb46/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140905/97f440e7/attachment.html>
>
> Greetings and happy 'bisecting'...;-)
>
> Dieter
So what is the solution for that after one month? Simply to use -O0 maybe :)
--
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/20140905/bc5a4aaa/attachment.html>
commit/
> > > ?id=d55f77b503ab7b59ecdd8f31c4f7dc498710e75b
> >
> > For this look, here:
> >
> > http://lists.freedesktop.org/archives/mesa-dev/2014-August/065823.html
> >
> > Greetings and happy 'bisecting'...;-)
> >
> > Dieter
>
> So what is the solution for that after one month? Simply to use -O0 maybe :)
Ping Jason Ekstrand, maybe 8-)
--
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/20140905/7e393b0e/attachment.html>
t; >
> > > http://lists.freedesktop.org/archives/mesa-dev/2014-August/065823.html
> > >
> > > Greetings and happy 'bisecting'...;-)
> > >
> > > Dieter
> >
> > So what is the solution for that after one month? Simply to use -O0 maybe
> > :)
>
> Ping Jason Ekstrand, maybe 8-)
Ping.
--
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/20140905/e013bfe6/attachment-0001.html>
On Fri, Sep 05, 2014 at 10:50:54AM +0200, Johannes Berg wrote:
> From: Johannes Berg
>
> Many devices run firmware and/or complex hardware, and most of that
> can have bugs. When it misbehaves, however, it is often much harder
> to debug than software running on the host.
>
> Introduce a "device
Michel D?nzer writes:
> On 30.08.2014 22:59, Mikael Pettersson wrote:
> > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption
> > after a while in X + firefox. This still occurs with yesterday's HEAD
> > of Linus' repo. 3.16 and ealier kernels are fine.
> >
> > I ra
The userspace drm.h include doesn't prefix the drm directory. This can lead
to compile failures as /usr/include/drm/ isn't in the standard gcc include
paths. Fix it to be , which matches the rest of the driver drm
header files that get installed into /usr/include/drm.
Red Hat Bugzilla: https://b
On 09/04, Stephen Boyd wrote:
>
> I don't understand why we need to hold the prepare lock around
> the kref_put(), so I changed the flow so that we don't do this
> when we unregister a clock.
Ok we hold the prepare mutex to make sure get and put are serialized.
Good. Here's the interdiff to move
46 matches
Mail list logo
