https://bugzilla.kernel.org/show_bug.cgi?id=84981
--- Comment #3 from Apostolos B. ---
one more:
Oct 04 01:31:42 mainland kernel: general protection fault: [#1] PREEMPT
SMP
Oct 04 01:31:42 mainland kernel: Modules linked in: vboxdrv(O) btrfs xor
raid6_pq uas usb_storage mousedev cfg80211
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141003/5ae5a5b4/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141003/7aae55b9/attachment.html>
(This is a v2 of patch "drm/nouveau/disp/nv50: Add PFB writes")
This fix a GPU lockup on 9400M (NVAC) when using acceleration, see
https://bugs.freedesktop.org/show_bug.cgi?id=27501
v2:
- Move code to subdev/fb/nv50.c as suggested by Roy Spliet;
- Remove arbitrary writes to 100c18/100c24 as
On Fri, Oct 03, 2014 at 01:39:21PM +0200, Daniel Vetter wrote:
> On Fri, Oct 3, 2014 at 11:42 AM, Andrzej Hajda wrote:
> > But this is an issue closely connected with component framework.
> > Component framework separates master component probe and drm device
> > initialization. As a result PM
because
> that
> > opens possibilities for deadlocks (e.g. a process could deadlock a
> compositor
> > by passing a fence that it never triggers). Android sync driver solves
> this by
> > having a separate CONFIG_SW_SYNC_USER that can be used for testing.
> >
> > Here's a simple test by Google:
> >
> https://android.googlesource.com/platform/system/core/+/master/libsync/sync_test.c
>
> Hm, usually we expose such test interfaces through debugfs - that way
> production system won't ever ship with it (since there's too many exploits
> in there, especially with secure boot). But since you need it for
> validation tests (at least for the i915 suite) it should always be there
> when you need it.
>
> Exposing this as a configurable driver in dev is imo a no-go. But we
> should be able to easily convert this into a few debugfs files, so not too
> much fuzz hopefully.
>
> > And this is their userspace wrapper lib:
> >
> https://android.googlesource.com/platform/system/core/+/master/libsync/sync.c
> >
> https://android.googlesource.com/platform/system/core/+/master/libsync/include/sync/sync.h
> >
> > Would that go to libdrm now...?
>
> Imo it would make sense. At least we kinda want to use fences outside of
> Android, and a separate library project feels like overkill.
>
> > > Aside: Will you be at XDC or linux plumbers? Either would be a perfect
> > > place to discuss plans and ideas - I'll attend both.
> >
> > I wasn't going to, but let's see. The former is pretty soon and the
> latter is
> > sold out. At least Andy Ritger from Nvidia is coming to XDC for sure,
> and he's
> > been involved in our internal discussions around these topics. So I
> suggest you
> > have a chat with him at least! :)
>
> I'll definitely have a chat (and some beers) with Andy, been a while I've
> last seen him ;-)
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141003/2ec9b33e/attachment-0001.html>
On Fri, Oct 3, 2014 at 11:42 AM, Andrzej Hajda wrote:
> On 10/03/2014 10:31 AM, Daniel Vetter wrote:
>> On Fri, Oct 03, 2014 at 10:24:09AM +0200, Andrzej Hajda wrote:
>>> The main intent of this patchset is to allow use of suspend/resume drm
>>> driver
>>> callbacks in KMS drivers, as these
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141003/bc7ab433/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=85491
--- Comment #6 from Alex Deucher ---
(In reply to Zermond from comment #5)
> (In reply to Alex Deucher from comment #4)
> > Can you narrow down when the problem started? Even better, can you bisect?
>
> As soon as I updated the kernel. At
http://lists.freedesktop.org/archives/dri-devel/2013-January/033572.html
Dear All,
Please, never do pointless stuff like that.
I don't know what exactly are written in the "CEA guidelines"
mentioned in the above posts (AFAIK one cannot get a copy of them for
free legally), but no one should
On 10/03/2014 10:31 AM, Daniel Vetter wrote:
> On Fri, Oct 03, 2014 at 10:24:09AM +0200, Andrzej Hajda wrote:
>> The main intent of this patchset is to allow use of suspend/resume drm driver
>> callbacks in KMS drivers, as these callbacks seems to me the best place
>> to implement suspend/resume
Hi Dave,
It looks like you missed my last 3.18 pull from 9/24. This one
includes those patches and a few more on top. The additional patches are:
- Maarten's radeon fence updates
- Some additional debugging output
>From the previous pull request:
- Re-enable some dpm features that were
Hi Dave,
Bunch of fixes for 3.18. Major parts:
- ppgtt fixes (but full ppgtt is for 3.19) from Chris, Michel, ...
- hdmi pixel replication fixes (Clint Taylor)
- leftover i830M patches from Ville
- small things all over
I'll be travelling the next two weeks (xdc) but should be around
a few days
Hi Dave,
Two leftover core patches for 3.18, Clint found one more troublesome hdmi
mode and some cleanup patch from Andrzej.
Cheers, Daniel
The following changes since commit 7a42e83d36d2d0a68622320900dc4e880b1d920a:
Merge branch 'for-airlied-next' of
On Thu, Oct 02, 2014 at 04:15:26PM +0200, David Herrmann wrote:
> Hi
>
> On Tue, Sep 30, 2014 at 4:49 PM, Andrzej Hajda wrote:
> > The patch replaces direct access to driver_features field
> > by calls to helper function.
> >
> > Signed-off-by: Andrzej Hajda
>
> Looks good:
>
> Reviewed-by:
On Fri, Oct 03, 2014 at 10:24:09AM +0200, Andrzej Hajda wrote:
> The main intent of this patchset is to allow use of suspend/resume drm driver
> callbacks in KMS drivers, as these callbacks seems to me the best place
> to implement suspend/resume functionality in drm driver.
> Implementing this
The NXP TDA998x HDMI transmitter may transmit audio to the HDMI link
from 2 different sources, I2S and S/PDIF.
This patch set adds an interface between the HDMI transmitter and
the HDMI CODEC.
The interface is used by the TDA998x driver to update the audio
constraints from the display
This patch interfaces the HDMI transmitter with the audio system.
Signed-off-by: Jean-Francois Moine
---
.../devicetree/bindings/drm/i2c/tda998x.txt| 18 ++
drivers/gpu/drm/i2c/Kconfig| 1 +
drivers/gpu/drm/i2c/tda998x_drv.c | 264
During system suspend after connector switch off its dpms field
is set to connector previous dpms state. To properly resume dpms field
should be set to its actual state (off) before resuming to previous dpms state.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 8
The patch removes master PM callbacks as their functionality
is already duplicated by suspend/resume drm callbacks.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 29 -
1 file changed, 29 deletions(-)
diff --git
Implementing suspend/resume functionality in componentized drm drivers using
master component PM callbacks is problematic because those callbacks can be
called asynchronously regardless of existence/state of drm device.
The patch re-enables suspend/resume drm driver callbacks in drivers with
Currently suspend and resume callbacks are called only if driver have
modeset feature disabled.
This patch moves the check directly to i915 driver, it will allow to
remove the check from the core in the future.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/i915_drv.c | 6 ++
1 file
The main intent of this patchset is to allow use of suspend/resume drm driver
callbacks in KMS drivers, as these callbacks seems to me the best place
to implement suspend/resume functionality in drm driver.
Implementing this functionality in master component driver PM ops is problematic
as those
The audio constraints of the HDMI interface are defined by the EDID
which is sent by the connected device.
The HDMI transmitters may have one or many audio sources.
This patch adds two functions to the HDMI CODEC:
- it updates the audio constraints from the EDID,
- it gives the audio source 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/20141003/68cc686a/attachment.html>
ybe today :)
--
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/20141003/46da9514/attachment.html>
Hi Linus,
Nothing too major or scary,
one i915 regression fix, nouveau has a tmds regression fix, along with a
regression fix for the runtime pm code for optimus laptops not restoring
the display hw correctly.
Dave.
The following changes since commit
desktop.org/archives/dri-devel/attachments/20141003/bc5ec67b/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=85491
--- Comment #5 from Zermond ---
(In reply to Alex Deucher from comment #4)
> Can you narrow down when the problem started? Even better, can you bisect?
As soon as I updated the kernel. At version 3.11, everything was fine with
version 3.16 of
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141003/058fa762/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141003/e190b1e9/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141003/b5db7a40/attachment-0001.html>
32 matches
Mail list logo
