Re: [PATCH 1/3] dma-fence: Reserve 0 as a special NO_CONTEXT token
Am 08.04.2017 um 20:00 schrieb Chris Wilson: On Sat, Apr 08, 2017 at 07:49:37PM +0200, Christian König wrote: Am 08.04.2017 um 18:26 schrieb Chris Wilson: Reserve 0 for general use a token meaning that the fence doesn't belong to an ordered timeline (fence context). NAK, we kept context allocation cheap to avoid exactly that. However, they result in very sparse mappings. Which is perfectly fine at least for how we use this in Radeon and Amdgpu. The fence context is used as key for a hashtable, even when the context is only used once we want an evenly distribution over all of them. Please elaborate further why it should be necessary now. Because I want to efficiently exclude them from comparisons as demonstrated by this small series as there may be several hundred such fences as dependencies for this job. That would horrible break Amdgpu, Radeon and the GPU scheduler because all of them assume that context numbers are unique. So that is a clear NAK from my side, Christian. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [regression] Re: 4.11-rc0, thinkpad x220: GPU hang
On Mon 2017-03-06 12:23:41, Chris Wilson wrote:
> On Mon, Mar 06, 2017 at 01:10:48PM +0100, Pavel Machek wrote:
> > On Mon 2017-03-06 11:15:28, Chris Wilson wrote:
> > > On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > > > mplayer stopped working after a while. Dmesg says:
> > > > > >
> > > > > > [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at
> > > >
> > > > Now I'm pretty sure it is a regression in v4.11-rc0. Any ideas what to
> > > > try? Bisect will be slow and nasty :-(.
> > >
> > > I came the conclusion that #99671 is the ring HEAD overtaking the TAIL,
> > > and under the presumption that your bug matches (as the symptoms do):
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > index 4ffa35faff49..62e31a7438ac 100644
> > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > @@ -782,10 +782,10 @@ static void i9xx_submit_request(struct
> > > drm_i915_gem_request *request)
> > > {
> > > struct drm_i915_private *dev_priv = request->i915;
> > >
> > > - i915_gem_request_submit(request);
> > > -
> > > GEM_BUG_ON(!IS_ALIGNED(request->tail, 8));
> > > I915_WRITE_TAIL(request->engine, request->tail);
> > > +
> > > + i915_gem_request_submit(request);
> > > }
> > >
> > > static void i9xx_emit_breadcrumb(struct drm_i915_gem_request *req, u32
> > > *cs)
> >
> > I applied it as:
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 91bc4ab..9c49c7a 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -1338,9 +1338,9 @@ static void i9xx_submit_request(struct
> > drm_i915_gem_request *request)
> > {
> > struct drm_i915_private *dev_priv = request->i915;
> >
> > - i915_gem_request_submit(request);
> > -
> > I915_WRITE_TAIL(request->engine, request->tail);
> > +
> > + i915_gem_request_submit(request);
> > }
> >
> > static void i9xx_emit_breadcrumb(struct drm_i915_gem_request *req,
> >
> > Hmm. But your next mail suggest that it may not be smart to try to
> > boot it? :-).
>
> Don't bother, it'll promptly hang.
Any news here? 4.11-rc5 is actually usable on the hardware (unlike
-rc1), not sure what changed.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/13] devicetree/bindings: display: Document common panel properties
Hi Laurent, Pardon for reviving this old thread. I've noticed a couple of things which might want some attention. On 19 November 2016 at 03:28, Laurent Pinchart wrote: > + > +- panel-timing: Most display panels are restricted to a single resolution and > + require specific display timings. The panel-timing subnode expresses those > + timings as specified in the timing subnode section of the display timing > + bindings defined in > + Documentation/devicetree/bindings/display/display-timing.txt. Cannot find such a file in linux-next. Perhaps you meant Documentation/devicetree/bindings/display/panel/display-timing.txt? Documentation/devicetree/bindings/display/panel/panel.txt includes a "rotation" property, which we might want to fold here. Regards, Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: panels: Add MAINTAINERS entry for LVS panel driver
Hi Thierry, I don't mean to stir up anything, just voicing "my 2c" as they say. On 7 April 2017 at 18:33, Thierry Reding wrote: > Ever since the simple-panel binding was introduced, which is now about > 3 1/2 years ago, Do you have a link to these discussions? Your blog article does not have any links and I only found the "Runtime Interpreted Power Sequences" thread. That in itself does not cover the pros/cons of storing HW information* within DT. Personally, the idea of having hardware information* in DT does not sound all that bad. The simple panel driver(s) can use those properties and any panels that require anything more complex will still need their own driver. For better or for worse, there's already a handful of drivers and bindings that rely on/provide these. Using that information consistently across the board, would be of a benefit, IMHO. But at the end of the day, might as well go with whatever RobH and the DT folk are happy with. It's on them to maintain the DT ABI ;-) Regards, Emil * Display dimensions, display timings and even delays for the power sequence. Not too sure on that last one though. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] drm/msm: msm-next for 4.12
Hi Dave, Noteworthy changes this time: 1) 4k support for newer chips (ganging up hwpipes and mixers) 2) using OPP bindings for gpu 3) more prep work towards per-process pagetables Note that this includes the patches that where in the fixes pull for 4.11. One of those patches moved around some code that is touched by later patches for 4.12 so you'd hit a merge conflict when -fixes and -next collide.. It might be easier for me to rebase this on top of fixes? The following changes since commit 0168778115687486575a6831df865dbc4f5369fe: Merge branch 'drm-next-4.12' of git://people.freedesktop.org/~agd5f/linux into drm-next (2017-04-07 05:49:12 +1000) are available in the git repository at: git://people.freedesktop.org/~robclark/linux msm-next for you to fetch changes up to 98db803f6413e6d4bf1f590ea57e9e7dfe1eb32b: msm/drm: gpu: Dynamically locate the clocks from the device tree (2017-04-08 06:59:37 -0400) Archit Taneja (26): drm/msm/dsi: Fix bug in dsi_mgr_phy_enable drm/msm/mdp5: Update SSPP_MAX value drm/msm/mdp5: Bring back pipe_lock to mdp5_plane struct drm/msm/mdp5: describe LM instances in mdp5_cfg drm/msm/mdp5: Add structs for hw Layer Mixers drm/msm/mdp5: Start using mdp5_hw_mixer drm/msm/mdp5: Simplify LM <-> PP mapping drm/msm/mdp5: Clean up interface assignment drm/msm/mdp5: Remove the pipeline stuff in mdp5_ctl drm/msm/mdp5: subclass CRTC state drm/msm/mdp5: Prepare for dynamic assignment of mixers drm/msm/mdp5: Assign INTF and CTL in encoder's atomic_check() drm/msm/mdp5: Add more stuff to CRTC state drm/msm/mdp5: Start using parameters from CRTC state drm/msm/mdp5: Remove mixer/intf pointers from mdp5_ctl drm/msm/mdp5: Add a CAP for Source Split drm/msm/mdp5: Add optional 'right' Layer Mixer in CRTC state drm/msm/mdp5: Create mdp5_hwpipe_mode_set drm/msm/mdp5: Assign a 'right hwpipe' to plane state drm/msm/mdp5: Configure 'right' hwpipe drm/msm/mdp5: Prepare Layer Mixers for source split drm/msm/mdp5: Stage right side hwpipes on Right-side Layer Mixer drm/msm/mdp5: Stage border out on base stage if CRTC has 2 LMs drm/msm/mdp5: Assign 'right' mixer to CRTC state drm/msm/mdp5: Reset CTL blend registers before configuring them drm/msm/mdp5: Enable 3D mux in mdp5_ctl Arnd Bergmann (1): drm/msm: adreno: fix build error without debugfs Daniel Vetter (2): drm/msm: switch to postclose drm/msm: Simplify vblank event delivery Jordan Crouse (11): drm/msm: Fix wrong pointer check in a5xx_destroy drm/msm: Don't increase priv->num_aspaces until we know that it fits drm/msm: Pass interrupt status to a5xx_rbbm_err_irq() drm/msm: Support 64 bit iova in RD_CMDSTREAM_ADDR drm/msm: Don't allow zero sized buffer objects drm/msm: Make sure to detach the MMU during GPU cleanup drm/msm: Reference count address spaces drm/msm: Add MSM_PARAM_GMEM_BASE drm/msm: Hard code the GPU "slow frequency" drm/msm: gpu: Use OPP tables if we can msm/drm: gpu: Dynamically locate the clocks from the device tree Rob Clark (6): drm/msm/gpu: move suspend/resume into debugfs->show drm/msm/gpu: use pm-runtime drm/msm/adreno: reset ringbuffer in hw_init drm/msm: convert to iommu_map_sg drm/msm: pm runtime support for iommu drm/msm: move submit fence wait out of struct_mutex Vinay Simha BN (1): drm/msm/hdmi: redefinitions of macros not required drivers/gpu/drm/msm/Makefile| 1 + drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 - drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 4 - drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 28 +- drivers/gpu/drm/msm/adreno/adreno_device.c | 126 +-- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 70 ++-- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 2 +- drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +- drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 7 - drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c| 12 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 2 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 81 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 8 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c | 30 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 466 +++- drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 192 ++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 21 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 66 ++-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 123 +-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 53 ++- drivers/gpu/drm/msm/mdp/mdp5/mdp5_mixer.c | 172 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_mixer.h | 47 +++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_p
Re: [linux-next drm/vmwgfx] Hang up at boot.
Hi!
A fix for this regression has been put together and I think it's already
in drm-misc.
Thanks,
/Thomas
On 04/09/2017 01:25 PM, Tetsuo Handa wrote:
> Hello.
>
> I'm getting a boot failure (console stops) as of next-20170403~69.
> next-20170403~70 and next-20170331 boot normally.
> Would you check commit 8a2398eb335c11b1b33b860ff472c53c6b1bcc43("Merge
> remote-tracking branch 'drm-misc/for-linux-next'") ?
>
> --
> %G[1.584230] ioc0: LSI53C1030 B0: Capabilities={Initiator}
> [1.646821] scsi host2: ioc0: LSI53C1030 B0, FwRev=01032920h, Ports=1,
> MaxQ=128, IRQ=17
> [1.691469] [drm] DMA map mode: Using physical TTM page addresses.
> [1.693089] [drm] Capabilities:
> [1.693865] [drm] Rect copy.
> [1.694586] [drm] Cursor.
> [1.695213] [drm] Cursor bypass.
> [1.696115] [drm] Cursor bypass 2.
> [1.697379] [drm] 8bit emulation.
> [1.698346] [drm] Alpha cursor.
> [1.699141] [drm] 3D.
> [1.699830] [drm] Extended Fifo.
> [1.700639] [drm] Multimon.
> [1.701323] [drm] Pitchlock.
> [1.702023] [drm] Irq mask.
> [1.702739] [drm] Display Topology.
> [1.703639] [drm] GMR.
> [1.704252] [drm] Traces.
> [1.704914] [drm] GMR2.
> [1.705793] [drm] Screen Object 2.
> [1.706730] [drm] Command Buffers.
> [1.707551] [drm] Command Buffers 2.
> [1.708662] [drm] Guest Backed Resources.
> [1.709635] [drm] DX Features.
> [1.710546] [drm] Max GMR ids is 64
> [1.711339] [drm] Max number of GMR pages is 65536
> [1.712407] [drm] Max dedicated hypervisor surface memory is 0 kiB
> [1.714454] [drm] Maximum display memory size is 32768 kiB
> [1.715703] [drm] VRAM at 0xe800 size is 8192 kiB
> [1.716862] [drm] MMIO at 0xfe00 size is 256 kiB
> [1.718114] [drm] global init.
> [1.719083] [TTM] Zone kernel: Available graphics memory: 1885344 kiB
> [1.720698] [TTM] Initializing pool allocator
> [1.721683] [TTM] Initializing DMA pool allocator
> [1.722839] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [1.724307] [drm] No driver support for vblank timestamp query.
> [1.724914] ata2.00: ATAPI: VMware Virtual IDE CDROM Drive, 0001, max
> UDMA/33
> [1.727793] [drm] Screen Target Display device initialized
> [1.729269] [drm] width 1280
> [1.730888] ata2.00: configured for UDMA/33
> [1.730889] [drm] height 768
> [1.730896] [drm] bpp 32
> [1.734822] scsi: waiting for bus probes to complete ...
> [1.739548] scsi 1:0:0:0: CD-ROMNECVMWar VMware IDE CDR10 1.00
> PQ: 0 ANSI: 5
> [1.747967] [drm] Fifo max 0x0004 min 0x1000 cap 0x077f
> [1.751168] [drm] Using command buffers with DMA pool.
> [1.752321] [drm] DX: yes.
> [1.752997] [drm] Atomic: yes
> %G
> --
>
> I'm using VMware Workstation 12 Player 12.5.5 build-5234757 on Windows 8.1.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dma-fence: Reserve 0 as a special NO_CONTEXT token
On Sun, Apr 09, 2017 at 09:08:53AM +0200, Christian König wrote: > Am 08.04.2017 um 20:00 schrieb Chris Wilson: > >On Sat, Apr 08, 2017 at 07:49:37PM +0200, Christian König wrote: > >>Am 08.04.2017 um 18:26 schrieb Chris Wilson: > >>>Reserve 0 for general use a token meaning that the fence doesn't belong > >>>to an ordered timeline (fence context). > >>NAK, we kept context allocation cheap to avoid exactly that. > >However, they result in very sparse mappings. > > Which is perfectly fine at least for how we use this in Radeon and Amdgpu. > > The fence context is used as key for a hashtable, even when the > context is only used once we want an evenly distribution over all of > them. The ht is a more expensive solution. > >>Please elaborate further why it should be necessary now. > >Because I want to efficiently exclude them from comparisons as > >demonstrated by this small series as there may be several hundred such > >fences as dependencies for this job. > > That would horrible break Amdgpu, Radeon and the GPU scheduler > because all of them assume that context numbers are unique. Why would it break if it respected the trivial notion of an unordered timeline? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs
Pekka Paalanen writes: > we need some kind of a database to recognize HMDs in any case, right? > It would be best if the database was shared, so that everyone could > recognize all HMDs, at least as far as one can do that based on EDID. Yeah, I think you've got some good ideas here. Here are some questions which this raises: * What should we do with an HMD which is in the database but for which no application is installed on the host? * Entries in the database should probably have names an versions, so that clients could have some way to identify whether they support what has been connected. Would providing the manufacturer ID and product codes be sufficient here? * Should the database be visible and managed over X? Or should it be hidden from clients and only visible to the X server? * We want to generate events when the HMD is plugged in; how should clients select for these? > If we had such a database, perhaps interfaced with a library, when how > about Xorg using that library to automatically recognize and hide HMDs? > That library would of course be also used by all HMD-supporting Wayland > servers. I'm not sure a library is necessary, if the database was a directory full of files. > If there was such a library, maybe it could also handle EDID parsing > once and for all... a libinput for outputs? Yeah, not a terrible idea, but possibly more yak shaving than we really need to get into here. > Btw. I was also told at #openhmd that some HMDs do not appear as > connected outputs until you specifically turn it on via USB. So there > is going to be a hotplug, and you'd want to avoid sending that to > normal X11 clients so that they won't race with the special VR client > grabbing it. It'd still get 'hot plugged' in the X server when enabled over USB, so we'll want to hide that from regular clients in some way. -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dma-fence: Reserve 0 as a special NO_CONTEXT token
Am 09.04.2017 um 18:02 schrieb Chris Wilson: On Sun, Apr 09, 2017 at 09:08:53AM +0200, Christian König wrote: Am 08.04.2017 um 20:00 schrieb Chris Wilson: On Sat, Apr 08, 2017 at 07:49:37PM +0200, Christian König wrote: Am 08.04.2017 um 18:26 schrieb Chris Wilson: Reserve 0 for general use a token meaning that the fence doesn't belong to an ordered timeline (fence context). NAK, we kept context allocation cheap to avoid exactly that. However, they result in very sparse mappings. Which is perfectly fine at least for how we use this in Radeon and Amdgpu. The fence context is used as key for a hashtable, even when the context is only used once we want an evenly distribution over all of them. The ht is a more expensive solution. Not when the fences without contexts are rare. Please elaborate further why it should be necessary now. Because I want to efficiently exclude them from comparisons as demonstrated by this small series as there may be several hundred such fences as dependencies for this job. That would horrible break Amdgpu, Radeon and the GPU scheduler because all of them assume that context numbers are unique. Why would it break if it respected the trivial notion of an unordered timeline? You seem to miss the point. We already had that discussion and decided against using no-context fences. Now we have a whole bunch of cases over different drivers/components where we assume uniqueness of fence contexts. If you change this without fixing all those cases they will just subtle break, probably without anybody noticing the problem immediately. So if you don't want to scan all drivers for such cases (and I know at least three of hand) and fix them before that patch then that is a clear no-go for this patch. I suggest to just use two separate fence contexts for you clflush problem in i915. We have a similar situation in the GPU scheduler solve it the same way. Regards, Christian. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] i915: flush gem obj freeing workqueues to add accuracy to the i915 shrinker
On Fri, Apr 07, 2017 at 04:30:11PM +0100, Chris Wilson wrote:
> Not getting hangs is a good sign, but lockdep doesn't like it:
>
> [ 460.684901] WARNING: CPU: 1 PID: 172 at kernel/workqueue.c:2418
> check_flush_dependency+0x92/0x130
> [ 460.684924] workqueue: PF_MEMALLOC task 172(kworker/1:1H) is flushing
> !WQ_MEM_RECLAIM events:__i915_gem_free_work [i915]
>
> If I allocated the workqueue with WQ_MEM_RELCAIM, it complains bitterly
> as well.
So in PF_MEMALLOC context we can't flush a workqueue with
!WQ_MEM_RECLAIM.
system_wq = alloc_workqueue("events", 0, 0);
My point is synchronize_rcu_expedited will still push its work in
the same system_wq workqueue...
/* Marshall arguments & schedule the expedited grace period. */
rew.rew_func = func;
rew.rew_rsp = rsp;
rew.rew_s = s;
INIT_WORK_ONSTACK(&rew.rew_work, wait_rcu_exp_gp);
schedule_work(&rew.rew_work);
It's also using schedule_work, so either the above is a false
positive, or we've still a problem with synchronize_rcu_expedited,
just a reproducible issue anymore after we stop running it under the
struct_mutex.
Even synchronize_sched will wait on the system_wq if
synchronize_rcu_expedited has been issued in parallel by some other
code, it's just there's no check for it because it's not invoking
flush_work to wait.
The deadlock happens if we flush_work() while holding any lock that
may be taken by any of the workqueues that could be queued there. i915
makes sure to flush_work only if the struct_mutex was released (not
my initial version) but we're not checking if any of the other
system_wq workqueues could possibly taking a lock that may have been
hold during the allocation that invoked reclaim, I suppose that is the
problem left, but I don't see how flush_work is special about it,
synchronize_rcu_expedited would still have the same issue no? (despite
no lockdep warning)
I suspect this means synchronize_rcu_expedited() is not usable in
reclaim context and lockdep should warn if PF_MEMALLOC is set when
synchronize_rcu_expedited/synchronize_sched/synchronize_rcu are
called.
Probably to fix this we should create a private workqueue for both RCU
and i915 and stop sharing the system_wq with the rest of the system
(and of course set WQ_MEM_RECLAIM in both workqueues). This makes sure
when we call synchronize_rcu_expedited; flush_work from the shrinker,
we won't risk waiting on other random work that may be taking locks
that are hold by the code that invoked reclaim during an allocation.
The macro bug of waiting on system_wq 100% of the time while always
holding the struct_mutex is gone, but we need to perfect this further
and stop using the system_wq for RCU and i915 shrinker work.
> We do need it for shrinker_count as well. If we just report 0 objects,
Yes the shrinker_count too.
> the shrinker_scan callback will be skipped, iirc. All we do need it for
> direct calls to i915_gem_shrink() which themselves may or may not be
> underneath the struct_mutex at the time.
Yes.
> I don't follow,
>
> static inline struct task_struct *__mutex_owner(struct mutex *lock)
> {
> return (struct task_struct *)(atomic_long_read(&lock->owner) & ~0x07);
> }
>
> The atomic read is equivalent to READ_ONCE(). What's broken here? (I
> guess strict aliasing and pointer cast?)
That was an oversight, atomic64_read does READ_ONCE internally (as it
should of course being an atomic read). I didn't recall it uses
atomic_long_read.
Thanks,
Andrea
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] intel: remove dead code
Signed-off-by: Eric Engestrom
---
intel/intel_bufmgr_gem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index e260f2dc..45a26da1 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -655,15 +655,14 @@ drm_intel_gem_bo_busy(drm_intel_bo *bo)
ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_BUSY, &busy);
if (ret == 0) {
bo_gem->idle = !busy.busy;
return busy.busy;
} else {
return false;
}
- return (ret == 0 && busy.busy);
}
static int
drm_intel_gem_bo_madvise_internal(drm_intel_bufmgr_gem *bufmgr_gem,
drm_intel_bo_gem *bo_gem, int state)
{
struct drm_i915_gem_madvise madv;
--
Cheers,
Eric
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/virtio: remove not needed 'ret' var
From: Gustavo Padovan
virtio_gpu_cursor_plane_update() doesn't need to know the exact
value of virtio_gpu_object_reserve() return, just if it is zero or
not. Thus just use the function direct in the return.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index adcdbd0..76d5fed 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -197,7 +197,6 @@ static void virtio_gpu_cursor_plane_update(struct drm_plane
*plane,
struct virtio_gpu_fence *fence = NULL;
struct virtio_gpu_object *bo = NULL;
uint32_t handle;
- int ret = 0;
if (plane->state->crtc)
output = drm_crtc_to_virtio_gpu_output(plane->state->crtc);
@@ -221,8 +220,7 @@ static void virtio_gpu_cursor_plane_update(struct drm_plane
*plane,
cpu_to_le32(plane->state->crtc_w),
cpu_to_le32(plane->state->crtc_h),
0, 0, &fence);
- ret = virtio_gpu_object_reserve(bo, false);
- if (!ret) {
+ if (!virtio_gpu_object_reserve(bo, false)) {
reservation_object_add_excl_fence(bo->tbo.resv,
&fence->f);
dma_fence_put(&fence->f);
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 2/7] drm/virtio: support async cursor updates
From: Gustavo Padovan
Short circuit the update path for cursors and use the drm async update
infrastructure.
Signed-off-by: Gustavo Padovan
---
I wrote this mostly for testing purposes, not sure if its something that
we actually for virtio.
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 76d5fed..4d6e40b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -260,6 +260,46 @@ static void virtio_gpu_cursor_plane_update(struct
drm_plane *plane,
virtio_gpu_cursor_ping(vgdev, output);
}
+static int virtio_gpu_cursor_plane_async_check(struct drm_plane *plane,
+ struct drm_plane_state
*new_state)
+{
+ struct virtio_gpu_output *output;
+
+ if (!plane->state->crtc)
+ return -EINVAL;
+
+ output = drm_crtc_to_virtio_gpu_output(plane->state->crtc);
+ if (!output)
+ return -EINVAL;
+
+ if (plane->state->fb != new_state->fb)
+ return -EINVAL;
+
+ return 0;
+}
+
+static void virtio_gpu_cursor_plane_async_update(struct drm_plane *plane,
+struct drm_plane_state
*new_state)
+{
+ struct drm_device *dev = plane->dev;
+ struct virtio_gpu_device *vgdev = dev->dev_private;
+ struct virtio_gpu_output *output = NULL;
+
+ output = drm_crtc_to_virtio_gpu_output(plane->state->crtc);
+ if (WARN_ON(!output))
+ return;
+
+ if (plane->state->fb != new_state->fb)
+ return;
+
+ DRM_DEBUG("move +%d+%d\n", plane->state->crtc_x, plane->state->crtc_y);
+
+ output->cursor.hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_MOVE_CURSOR);
+ output->cursor.pos.x = cpu_to_le32(plane->state->crtc_x);
+ output->cursor.pos.y = cpu_to_le32(plane->state->crtc_y);
+ virtio_gpu_cursor_ping(vgdev, output);
+}
+
static const struct drm_plane_helper_funcs virtio_gpu_primary_helper_funcs = {
.atomic_check = virtio_gpu_plane_atomic_check,
.atomic_update = virtio_gpu_primary_plane_update,
@@ -268,6 +308,8 @@ static const struct drm_plane_helper_funcs
virtio_gpu_primary_helper_funcs = {
static const struct drm_plane_helper_funcs virtio_gpu_cursor_helper_funcs = {
.atomic_check = virtio_gpu_plane_atomic_check,
.atomic_update = virtio_gpu_cursor_plane_update,
+ .atomic_async_check = virtio_gpu_cursor_plane_async_check,
+ .atomic_async_update= virtio_gpu_cursor_plane_async_update,
};
struct drm_plane *virtio_gpu_plane_init(struct virtio_gpu_device *vgdev,
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 5/7] drm/msm: update cursors asynchronously through atomic
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
mdp5_update_cursor_plane_legacy() did but through atomic.
Cc: Rob Clark
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 141 --
1 file changed, 54 insertions(+), 87 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 60a5451..c72bc99 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -31,15 +31,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
struct drm_rect *src, struct drm_rect *dest);
-static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,
- struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h,
- struct drm_modeset_acquire_ctx *ctx);
-
static void set_scanout_locked(struct drm_plane *plane,
struct drm_framebuffer *fb);
@@ -253,7 +244,7 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
};
static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
- .update_plane = mdp5_update_cursor_plane_legacy,
+ .update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = mdp5_plane_destroy,
.set_property = drm_atomic_helper_plane_set_property,
@@ -430,11 +421,64 @@ static void mdp5_plane_atomic_update(struct drm_plane
*plane,
}
}
+static int mdp5_plane_atomic_async_check(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+ struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
+ struct drm_crtc_state *crtc_state;
+
+ crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+ state->crtc);
+ if (WARN_ON(!crtc_state))
+ return -EINVAL;
+
+ if (!crtc_state->active)
+ return -EINVAL;
+
+ mdp5_state = to_mdp5_plane_state(state);
+
+ /* don't use fast path if we don't have a hwpipe allocated yet */
+ if (!mdp5_state->hwpipe)
+ return -EINVAL;
+
+ /* only allow changing of position(crtc x/y or src x/y) in fast path */
+ if (plane->state->crtc != state->crtc ||
+ !state->fb || plane->state->fb != state->fb)
+ return -EINVAL;
+
+ return 0;
+}
+
+static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
+{
+ struct drm_plane_state *state = plane->state;
+
+ if (plane_enabled(state)) {
+ struct mdp5_ctl *ctl;
+ int ret;
+
+ ret = mdp5_plane_mode_set(plane,
+ state->crtc, state->fb,
+ &state->src, &state->dst);
+ WARN_ON(ret < 0);
+
+ ctl = mdp5_crtc_get_ctl(state->crtc);
+
+ mdp5_ctl_commit(ctl, mdp5_plane_get_flush(plane));
+ }
+
+ *to_mdp5_plane_state(plane->state) =
+ *to_mdp5_plane_state(new_state);
+}
+
static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
.prepare_fb = mdp5_plane_prepare_fb,
.cleanup_fb = mdp5_plane_cleanup_fb,
.atomic_check = mdp5_plane_atomic_check,
.atomic_update = mdp5_plane_atomic_update,
+ .atomic_async_check = mdp5_plane_atomic_async_check,
+ .atomic_async_update = mdp5_plane_atomic_async_update,
};
static void set_scanout_locked(struct drm_plane *plane,
@@ -882,83 +926,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
return ret;
}
-static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,
- struct drm_crtc *crtc, struct drm_framebuffer *fb,
- int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h,
- struct drm_modeset_acquire_ctx *ctx)
-{
- struct drm_plane_state *plane_state, *new_plane_state;
- struct mdp5_plane_state *mdp5_pstate;
- struct drm_crtc_state *crtc_state = crtc->state;
- int ret;
-
- if (!crtc_state->active || drm_atomic_crtc_needs_modeset(crtc_state))
- goto slow;
-
- plane_state = plane->state;
- mdp5_pstate = to_mdp5_plane
[RFC 7/7] drm/vc4: update cursors asynchronously through atomic
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.
Cc: Eric Anholt
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/vc4/vc4_plane.c | 94 -
1 file changed, 27 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index d34cd53..e33c75b 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -735,70 +735,27 @@ void vc4_plane_async_set_fb(struct drm_plane *plane,
struct drm_framebuffer *fb)
vc4_state->dlist[vc4_state->ptr0_offset] = addr;
}
-static const struct drm_plane_helper_funcs vc4_plane_helper_funcs = {
- .atomic_check = vc4_plane_atomic_check,
- .atomic_update = vc4_plane_atomic_update,
-};
-
-static void vc4_plane_destroy(struct drm_plane *plane)
-{
- drm_plane_helper_disable(plane);
- drm_plane_cleanup(plane);
-}
-
-/* Implements immediate (non-vblank-synced) updates of the cursor
- * position, or falls back to the atomic helper otherwise.
- */
-static int
-vc4_update_plane(struct drm_plane *plane,
-struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h,
-struct drm_modeset_acquire_ctx *ctx)
+static int vc4_plane_atomic_async_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
{
- struct drm_plane_state *plane_state;
- struct vc4_plane_state *vc4_state;
-
- if (plane != crtc->cursor)
- goto out;
-
- plane_state = plane->state;
- vc4_state = to_vc4_plane_state(plane_state);
-
- if (!plane_state)
- goto out;
+ if (plane != state->crtc->cursor)
+ return -EINVAL;
- /* No configuring new scaling in the fast path. */
- if (crtc_w != plane_state->crtc_w ||
- crtc_h != plane_state->crtc_h ||
- src_w != plane_state->src_w ||
- src_h != plane_state->src_h) {
- goto out;
- }
+ if (!plane->state)
+ return -EINVAL;
- if (fb != plane_state->fb) {
- drm_atomic_set_fb_for_plane(plane->state, fb);
- vc4_plane_async_set_fb(plane, fb);
- }
+ return 0;
+}
- /* Set the cursor's position on the screen. This is the
-* expected change from the drm_mode_cursor_universal()
-* helper.
-*/
- plane_state->crtc_x = crtc_x;
- plane_state->crtc_y = crtc_y;
+static void vc4_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
+{
+ struct vc4_plane_state *vc4_state = to_vc4_plane_state(plane->state);
- /* Allow changing the start position within the cursor BO, if
-* that matters.
-*/
- plane_state->src_x = src_x;
- plane_state->src_y = src_y;
+ if (plane->state->fb != new_state->fb)
+ vc4_plane_async_set_fb(plane, new_state->fb);
- /* Update the display list based on the new crtc_x/y. */
- vc4_plane_atomic_check(plane, plane_state);
+ plane->state->fb = new_state->fb;
/* Note that we can't just call vc4_plane_write_dlist()
* because that would smash the context data that the HVS is
@@ -810,20 +767,23 @@ vc4_update_plane(struct drm_plane *plane,
&vc4_state->hw_dlist[vc4_state->pos2_offset]);
writel(vc4_state->dlist[vc4_state->ptr0_offset],
&vc4_state->hw_dlist[vc4_state->ptr0_offset]);
+}
- return 0;
+static const struct drm_plane_helper_funcs vc4_plane_helper_funcs = {
+ .atomic_check = vc4_plane_atomic_check,
+ .atomic_update = vc4_plane_atomic_update,
+ .atomic_async_check = vc4_plane_atomic_async_check,
+ .atomic_async_update = vc4_plane_atomic_async_update,
+};
-out:
- return drm_atomic_helper_update_plane(plane, crtc, fb,
- crtc_x, crtc_y,
- crtc_w, crtc_h,
- src_x, src_y,
- src_w, src_h,
- ctx);
+static void vc4_plane_destroy(struct drm_plane *plane)
+{
+ drm_plane_helper_disable(plane);
+ drm_plane_cleanup(plane);
}
static const struct drm_plane_funcs vc4_plane_funcs = {
- .update_plane = vc4_update_plane,
+ .update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = vc4_plane_destroy,
.set_property = NULL,
--
[RFC 6/7] drm/msm: remove mdp5_cursor_plane_funcs
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.
Cc: Rob Clark
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index c72bc99..371c301 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -243,19 +243,6 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
.atomic_print_state = mdp5_plane_atomic_print_state,
};
-static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
- .update_plane = drm_atomic_helper_update_plane,
- .disable_plane = drm_atomic_helper_disable_plane,
- .destroy = mdp5_plane_destroy,
- .set_property = drm_atomic_helper_plane_set_property,
- .atomic_set_property = mdp5_plane_atomic_set_property,
- .atomic_get_property = mdp5_plane_atomic_get_property,
- .reset = mdp5_plane_reset,
- .atomic_duplicate_state = mdp5_plane_duplicate_state,
- .atomic_destroy_state = mdp5_plane_destroy_state,
- .atomic_print_state = mdp5_plane_atomic_print_state,
-};
-
static int mdp5_plane_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *new_state)
{
@@ -965,16 +952,9 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev,
mdp5_plane->nformats = mdp_get_formats(mdp5_plane->formats,
ARRAY_SIZE(mdp5_plane->formats), false);
- if (type == DRM_PLANE_TYPE_CURSOR)
- ret = drm_universal_plane_init(dev, plane, 0xff,
- &mdp5_cursor_plane_funcs,
- mdp5_plane->formats, mdp5_plane->nformats,
- type, NULL);
- else
- ret = drm_universal_plane_init(dev, plane, 0xff,
- &mdp5_plane_funcs,
- mdp5_plane->formats, mdp5_plane->nformats,
- type, NULL);
+ ret = drm_universal_plane_init(dev, plane, 0xff, &mdp5_plane_funcs,
+ mdp5_plane->formats,
+ mdp5_plane->nformats, type, NULL);
if (ret)
goto fail;
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 4/7] drm/i915: remove intel_cursor_plane_funcs
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.
Cc: Daniel Vetter
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c854c87..26d20e5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13379,17 +13379,6 @@ const struct drm_plane_funcs intel_plane_funcs = {
.atomic_destroy_state = intel_plane_destroy_state,
};
-static const struct drm_plane_funcs intel_cursor_plane_funcs = {
- .update_plane = drm_atomic_helper_update_plane,
- .disable_plane = drm_atomic_helper_disable_plane,
- .destroy = intel_plane_destroy,
- .set_property = drm_atomic_helper_plane_set_property,
- .atomic_get_property = intel_plane_atomic_get_property,
- .atomic_set_property = intel_plane_atomic_set_property,
- .atomic_duplicate_state = intel_plane_duplicate_state,
- .atomic_destroy_state = intel_plane_destroy_state,
-};
-
static struct intel_plane *
intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
{
@@ -13636,7 +13625,7 @@ intel_cursor_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
cursor->disable_plane = intel_disable_cursor_plane;
ret = drm_universal_plane_init(&dev_priv->drm, &cursor->base,
- 0, &intel_cursor_plane_funcs,
+ 0, &intel_plane_funcs,
intel_cursor_formats,
ARRAY_SIZE(intel_cursor_formats),
DRM_PLANE_TYPE_CURSOR,
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 1/7] drm/atomic: initial support for asynchronous plane update
From: Gustavo Padovan
In some cases, like cursor updates, it is interesting to update the
plane in an asynchronous fashion to avoid big delays.
The current queued update could be still waiting for a fence to signal and
thus block and subsequent update until its scan out. In cases like this if
we update the cursor synchronously it will cause significant delays on
some platforms that would be noticed by the final user.
This patch creates a fast path to jump ahead the current queued state and
do single planes updates without going through all atomic step in
drm_atomic_helper_commit().
For now only single plane updates are supported and only if there is no
update to that plane in the queued state.
We plan to support async PageFlips through this interface as well in the
near future.
Cc: Daniel Vetter
Cc: Rob Clark
Cc: Eric Anholt
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_atomic.c | 75
drivers/gpu/drm/drm_atomic_helper.c | 41 +
include/drm/drm_atomic.h | 4 ++
include/drm/drm_atomic_helper.h | 2 +
include/drm/drm_modeset_helper_vtables.h | 47
5 files changed, 169 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f32506a..cae0122 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -631,6 +631,79 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
return 0;
}
+static bool drm_atomic_async_check(struct drm_atomic_state *state)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc_commit *commit;
+ struct drm_plane *__plane, *plane = NULL;
+ struct drm_plane_state *__plane_state, *plane_state = NULL;
+ const struct drm_plane_helper_funcs *funcs;
+ int i, n_planes = 0;
+
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ if (drm_atomic_crtc_needs_modeset(crtc_state))
+ return false;
+ }
+
+ for_each_new_plane_in_state(state, __plane, __plane_state, i) {
+ n_planes++;
+ plane = __plane;
+ plane_state = __plane_state;
+ }
+
+ if (!plane || n_planes != 1)
+ return false;
+
+ if (!plane->state->crtc)
+ return false;
+
+ if (plane_state->fence)
+ return false;
+
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ if (plane->crtc != crtc)
+ continue;
+
+ spin_lock(&crtc->commit_lock);
+ commit = list_first_entry_or_null(&crtc->commit_list,
+ struct drm_crtc_commit,
+ commit_entry);
+ if (!commit) {
+ spin_unlock(&crtc->commit_lock);
+ continue;
+ }
+ spin_unlock(&crtc->commit_lock);
+
+ for_each_plane_in_state(crtc_state->state, __plane,
+ __plane_state, i) {
+ if (__plane == plane) {
+ return false;
+ }
+ }
+ }
+
+ /* Not configuring new scaling in the async path. */
+ if (plane->state->crtc_w != plane_state->crtc_w ||
+ plane->state->crtc_h != plane_state->crtc_h ||
+ plane->state->src_w != plane_state->src_w ||
+ plane->state->src_h != plane_state->src_h) {
+ return false;
+ }
+
+ funcs = plane->helper_private;
+
+ if (!funcs->atomic_async_update)
+ return false;
+
+ if (funcs->atomic_async_check) {
+ if (funcs->atomic_async_check(plane, plane_state) < 0)
+ return false;
+ }
+
+ return true;
+}
+
static void drm_atomic_crtc_print_state(struct drm_printer *p,
const struct drm_crtc_state *state)
{
@@ -1591,6 +1664,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
+ state->async_update = drm_atomic_async_check(state);
+
return ret;
}
EXPORT_SYMBOL(drm_atomic_check_only);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 8be9719..a79e06c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1235,6 +1235,36 @@ static void commit_work(struct work_struct *work)
}
/**
+ * drm_atomic_helper_async_commit - commit state asynchronously
+ *
+ * This function commits a state asynchronously. It should be used
+ * on a state only when drm_atomic_async_check() succeds. Async
+ * commits are not supposed to swap the states like normal sync commits,
+ * but just do in-place change on the current state.
+ */
+void drm_atomic_helper_async_commit(struct drm_device *dev,
+
[RFC 3/7] drm/i915: update cursors asynchronously through atomic
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
intel_legacy_cursor_update() did but through atomic.
Cc: Daniel Vetter
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 58
drivers/gpu/drm/i915/intel_display.c | 147 +-
2 files changed, 79 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index cfb4729..37924bb 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -246,11 +246,69 @@ static void intel_plane_atomic_update(struct drm_plane
*plane,
}
}
+static int intel_plane_atomic_async_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct drm_crtc *crtc = plane->state->crtc;
+ struct drm_crtc_state *crtc_state = crtc->state;
+
+ if (plane->type != DRM_PLANE_TYPE_CURSOR)
+ return -EINVAL;
+
+ /*
+* When crtc is inactive or there is a modeset pending,
+* wait for it to complete in the slowpath
+*/
+ if (!crtc_state->active || to_intel_crtc_state(crtc_state)->update_pipe)
+ return -EINVAL;
+
+ /* Only changing fb should be in the fastpath. */
+ if (plane->state->crtc != state->crtc ||
+ !plane->state->fb != !state->fb)
+ return -EINVAL;
+
+ return 0;
+}
+
+static void intel_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
+{
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ struct drm_crtc *crtc = plane->state->crtc;
+ struct drm_framebuffer *old_fb;
+ struct i915_vma *old_vma;
+
+ old_fb = plane->state->fb;
+ old_vma = to_intel_plane_state(plane->state)->vma;
+
+ i915_gem_track_fb(intel_fb_obj(old_fb), intel_fb_obj(new_state->fb),
+ intel_plane->frontbuffer_bit);
+
+ plane->state->fb = new_state->fb;
+ *to_intel_plane_state(plane->state) = *to_intel_plane_state(new_state);
+ new_state->fb = old_fb;
+ to_intel_plane_state(new_state)->vma = old_vma;
+
+ plane->state->visible = new_state->visible;
+
+ if (plane->state->visible) {
+ trace_intel_update_plane(plane, to_intel_crtc(crtc));
+ intel_plane->update_plane(plane,
+ to_intel_crtc_state(crtc->state),
+ to_intel_plane_state(plane->state));
+ } else {
+ trace_intel_disable_plane(plane, to_intel_crtc(crtc));
+ intel_plane->disable_plane(plane, crtc);
+ }
+}
+
const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
.prepare_fb = intel_prepare_plane_fb,
.cleanup_fb = intel_cleanup_plane_fb,
.atomic_check = intel_plane_atomic_check,
.atomic_update = intel_plane_atomic_update,
+ .atomic_async_check = intel_plane_atomic_async_check,
+ .atomic_async_update = intel_plane_atomic_async_update,
};
/**
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e217d04..c854c87 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12993,13 +12993,29 @@ static int intel_atomic_commit(struct drm_device *dev,
int ret = 0;
/*
-* The intel_legacy_cursor_update() fast path takes care
+* The atomic async update fast path takes care
* of avoiding the vblank waits for simple cursor
* movement and flips. For cursor on/off and size changes,
* we want to perform the vblank waits so that watermark
* updates happen during the correct frames. Gen9+ have
* double buffered watermarks and so shouldn't need this.
*/
+ if (state->async_update) {
+ ret = mutex_lock_interruptible(&dev->struct_mutex);
+ if (ret)
+ return ret;
+
+ ret = drm_atomic_helper_prepare_planes(dev, state);
+ mutex_unlock(&dev->struct_mutex);
+
+ drm_atomic_helper_async_commit(dev, state);
+
+ mutex_lock(&dev->struct_mutex);
+ drm_atomic_helper_cleanup_planes(dev, state);
+ mutex_unlock(&dev->struct_mutex);
+ return 0;
+ }
+
if (INTEL_GEN(dev_priv) < 9)
state->legacy_cursor_update = false;
@@ -13141,6 +13157,9 @@ intel_prepare_plane_fb(struct drm_plane *plane,
}
}
+ if (new_state->state->async_update)
+ return 0;
+
if (!obj && !old_obj)
return 0;
@@ -13360,132 +13379,8 @@ const struct drm_plane_funcs inte
[RFC 0/7] drm: asynchronous atomic plane update
From: Gustavo Padovan Hi, First version of Asynchronous Plane Update over Atomic. Here I looked to msm, vc4 and i915 to identify a common pattern to create atomic helpers for async updates. So in patch 1 drm_atomic_async_check() and drm_atomic_helper_async_commit() are introduced along with driver's plane hooks: ->atomic_async_check() and ->atomic_async_commit(). For now we only support async update for one plane at a time and there can't be any update for that plane in the current pending commit. Also the async update can't modify the CRTC so no modesets are allowed. Then the other patches add support for it in the drivers. I did virtio mostly for testing. i915 have been converted and I've been using the it for four days already without any problem. I tried to run i-g-t on it but as of now drm-misc-next is failing a bit already. I'll get back to this for v2. vc4 and msm are only build tested. TODO - async updates when an update for the same plane is already queued - improve i-g-t tests where needed - support async page flips (that can be done after uptreaming this part) Comments are welcome! Regards, Gustavo --- Gustavo Padovan (7): drm/atomic: initial support for asynchronous plane update drm/virtio: support async cursor updates drm/i915: update cursors asynchronously through atomic drm/i915: remove intel_cursor_plane_funcs drm/msm: update cursors asynchronously through atomic drm/msm: remove mdp5_cursor_plane_funcs drm/vc4: update cursors asynchronously through atomic drivers/gpu/drm/drm_atomic.c | 75 ++ drivers/gpu/drm/drm_atomic_helper.c | 41 drivers/gpu/drm/i915/intel_atomic_plane.c | 58 +++ drivers/gpu/drm/i915/intel_display.c | 158 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 165 ++ drivers/gpu/drm/vc4/vc4_plane.c | 94 + drivers/gpu/drm/virtio/virtgpu_plane.c| 42 include/drm/drm_atomic.h | 4 + include/drm/drm_atomic_helper.h | 2 + include/drm/drm_modeset_helper_vtables.h | 47 + 10 files changed, 373 insertions(+), 313 deletions(-) -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/11] drm/sun4i: Support two display pipelines
Hi,
On Thu, Mar 9, 2017 at 10:40 PM, Maxime Ripard
wrote:
> On Thu, Mar 09, 2017 at 07:20:30PM +0800, Chen-Yu Tsai wrote:
>> On Thu, Mar 9, 2017 at 6:36 PM, Maxime Ripard
>> wrote:
>> > Hi,
>> >
>> > On Thu, Mar 09, 2017 at 06:05:32PM +0800, Chen-Yu Tsai wrote:
>> >> Some Allwinner SoCs have two display pipelines (frontend -> backend ->
>> >> tcon).
>> >>
>> >> Previously we only supported one pipeline. This patch extends the
>> >> current driver to support two. It extends the tcon and backend pointers
>> >> in sun4i_drv into arrays, and makes the related bind functions store
>> >> the pointer into said arrays based on the id fetched from the device
>> >> tree. In the case of the tcons, it falls back to a first come order
>> >> if no encoders that can be used for differentiating the tcons are
>> >> defined. The driver's depth-first traversal of the of graph, coupled
>> >> with the increasing address ordering of the of graph endpoints, and
>> >> the fact that tcon0 should always be enabled for the tcon/encoder
>> >> mux to be accessible, means that tcon1 would always come after tcon0.
>> >>
>> >> Assignment of the device structure into sun4i_drv is moved to the end
>> >> of the bind function, when all possible error checks have passed.
>> >>
>> >> This patch also drops a trailing 0 in one of the backend probe messages.
>> >>
>> >> Signed-off-by: Chen-Yu Tsai
>> >> ---
>> >> drivers/gpu/drm/sun4i/sun4i_backend.c | 9 +++--
>> >> drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
>> >> drivers/gpu/drm/sun4i/sun4i_drv.h | 6 --
>> >> drivers/gpu/drm/sun4i/sun4i_tcon.c| 25 +
>> >> 4 files changed, 29 insertions(+), 13 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
>> >> b/drivers/gpu/drm/sun4i/sun4i_backend.c
>> >> index f3c92d54c8e4..8d22efd5a9cc 100644
>> >> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
>> >> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
>> >> @@ -350,12 +350,15 @@ static int sun4i_backend_bind(struct device *dev,
>> >> struct device *master,
>> >> if (!backend)
>> >> return -ENOMEM;
>> >> dev_set_drvdata(dev, backend);
>> >> - drv->backend = backend;
>> >>
>> >> backend->id = sun4i_backend_of_get_id(dev->of_node);
>> >> if (backend->id < 0)
>> >> return backend->id;
>> >>
>> >> + /* We only support SUN4I_DRM_MAX_PIPELINES number of backends */
>> >> + if (backend->id >= SUN4I_DRM_MAX_PIPELINES)
>> >> + return -EINVAL;
>> >> +
>> >> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> >> regs = devm_ioremap_resource(dev, res);
>> >> if (IS_ERR(regs))
>> >> @@ -364,7 +367,7 @@ static int sun4i_backend_bind(struct device *dev,
>> >> struct device *master,
>> >> backend->regs = devm_regmap_init_mmio(dev, regs,
>> >> &sun4i_backend_regmap_config);
>> >> if (IS_ERR(backend->regs)) {
>> >> - dev_err(dev, "Couldn't create the backend0 regmap\n");
>> >> + dev_err(dev, "Couldn't create the backend regmap\n");
>> >> return PTR_ERR(backend->regs);
>> >> }
>> >>
>> >> @@ -413,6 +416,8 @@ static int sun4i_backend_bind(struct device *dev,
>> >> struct device *master,
>> >> }
>> >> }
>> >>
>> >> + drv->backend[backend->id] = backend;
>> >> +
>> >> /* Reset the registers */
>> >> for (i = 0x800; i < 0x1000; i += 4)
>> >> regmap_write(backend->regs, i, 0);
>> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
>> >> b/drivers/gpu/drm/sun4i/sun4i_drv.c
>> >> index 767bbadcc85d..c15ecb8343d7 100644
>> >> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
>> >> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
>> >> @@ -271,7 +271,7 @@ static int sun4i_drv_probe(struct platform_device
>> >> *pdev)
>> >> struct device_node *np = pdev->dev.of_node;
>> >> int i, count = 0;
>> >>
>> >> - for (i = 0;; i++) {
>> >> + for (i = 0; i < SUN4I_DRM_MAX_PIPELINES; i++) {
>> >> struct device_node *pipeline = of_parse_phandle(np,
>> >>
>> >> "allwinner,pipelines",
>> >> i);
>> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h
>> >> b/drivers/gpu/drm/sun4i/sun4i_drv.h
>> >> index 5df50126ff52..ec1c08af47e1 100644
>> >> --- a/drivers/gpu/drm/sun4i/sun4i_drv.h
>> >> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
>> >> @@ -16,9 +16,11 @@
>> >> #include
>> >> #include
>> >>
>> >> +#define SUN4I_DRM_MAX_PIPELINES 2
>> >> +
>> >> struct sun4i_drv {
>> >> - struct sun4i_backend*backend;
>> >> - struct sun4i_tcon *tcon;
>> >> + struct sun4i_backend*backend[SUN4I_DRM_MAX_PIPELINES];
>> >> + struct sun4i_tcon *tcon[SUN4I_DRM_MAX_PIPELINES];
>> >>
>> >> struct drm_fbdev_cma*fbdev;
>> >> };
>> >> diff --git a/drivers/gpu/drm/sun4i/
[PATCH v4 2/2] crypto: hw_random - Add new Exynos RNG driver
Replace existing hw_ranndom/exynos-rng driver with a new, reworked one. This is a driver for pseudo random number generator block which on Exynos4 chipsets must be seeded with some value. On newer Exynos5420 chipsets it might seed itself from true random number generator block but this is not implemented yet. New driver is a complete rework to use the crypto ALGAPI instead of hw_random API. Rationale for the change: 1. hw_random interface is for true RNG devices. 2. The old driver was seeding itself with jiffies which is not a reliable source for randomness. 3. Device generates five random 32-bit numbers in each pass but old driver was returning only one 32-bit number thus its performance was reduced. Compatibility with DeviceTree bindings is preserved. New driver does not use runtime power management but manually enables and disables the clock when needed. This is preferred approach because using runtime PM just to toggle clock is huge overhead. Another difference is reseeding itself with generated random data periodically and during resuming from system suspend (previously driver was re-seeding itself again with jiffies). Signed-off-by: Krzysztof Kozlowski Reviewed-by: Stephan Müller Reviewed-by: PrasannaKumar Muralidharan --- MAINTAINERS | 8 + drivers/char/hw_random/Kconfig | 14 -- drivers/char/hw_random/Makefile | 1 - drivers/char/hw_random/exynos-rng.c | 231 - drivers/crypto/Kconfig | 15 ++ drivers/crypto/Makefile | 1 + drivers/crypto/exynos-rng.c | 389 7 files changed, 413 insertions(+), 246 deletions(-) delete mode 100644 drivers/char/hw_random/exynos-rng.c create mode 100644 drivers/crypto/exynos-rng.c diff --git a/MAINTAINERS b/MAINTAINERS index affecc6d59f4..371fda859d43 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10977,6 +10977,14 @@ L: alsa-de...@alsa-project.org (moderated for non-subscribers) S: Supported F: sound/soc/samsung/ +SAMSUNG EXYNOS PSEUDO RANDOM NUMBER GENERATOR (RNG) DRIVER +M: Krzysztof Kozlowski +L: linux-cry...@vger.kernel.org +L: linux-samsung-...@vger.kernel.org +S: Maintained +F: drivers/crypto/exynos-rng.c +F: Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt + SAMSUNG FRAMEBUFFER DRIVER M: Jingoo Han L: linux-fb...@vger.kernel.org diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig index 0cafe08919c9..bdae802e7154 100644 --- a/drivers/char/hw_random/Kconfig +++ b/drivers/char/hw_random/Kconfig @@ -294,20 +294,6 @@ config HW_RANDOM_POWERNV If unsure, say Y. -config HW_RANDOM_EXYNOS - tristate "EXYNOS HW random number generator support" - depends on ARCH_EXYNOS || COMPILE_TEST - depends on HAS_IOMEM - default HW_RANDOM - ---help--- - This driver provides kernel-side support for the Random Number - Generator hardware found on EXYNOS SOCs. - - To compile this driver as a module, choose M here: the - module will be called exynos-rng. - - If unsure, say Y. - config HW_RANDOM_TPM tristate "TPM HW Random Number Generator support" depends on TCG_TPM diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile index 5f52b1e4e7be..6f1eecc2045c 100644 --- a/drivers/char/hw_random/Makefile +++ b/drivers/char/hw_random/Makefile @@ -24,7 +24,6 @@ obj-$(CONFIG_HW_RANDOM_OCTEON) += octeon-rng.o obj-$(CONFIG_HW_RANDOM_NOMADIK) += nomadik-rng.o obj-$(CONFIG_HW_RANDOM_PSERIES) += pseries-rng.o obj-$(CONFIG_HW_RANDOM_POWERNV) += powernv-rng.o -obj-$(CONFIG_HW_RANDOM_EXYNOS) += exynos-rng.o obj-$(CONFIG_HW_RANDOM_HISI) += hisi-rng.o obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o diff --git a/drivers/char/hw_random/exynos-rng.c b/drivers/char/hw_random/exynos-rng.c deleted file mode 100644 index 23d358553b21.. --- a/drivers/char/hw_random/exynos-rng.c +++ /dev/null @@ -1,231 +0,0 @@ -/* - * exynos-rng.c - Random Number Generator driver for the exynos - * - * Copyright (C) 2012 Samsung Electronics - * Jonghwa Lee - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - * - */ - -#include -#include -#include -#include -#include -#include -#include -#include - -#define EX
[linux-next drm/vmwgfx] Hang up at boot.
Hello.
I'm getting a boot failure (console stops) as of next-20170403~69.
next-20170403~70 and next-20170331 boot normally.
Would you check commit 8a2398eb335c11b1b33b860ff472c53c6b1bcc43("Merge
remote-tracking branch 'drm-misc/for-linux-next'") ?
--
%G[1.584230] ioc0: LSI53C1030 B0: Capabilities={Initiator}
[1.646821] scsi host2: ioc0: LSI53C1030 B0, FwRev=01032920h, Ports=1,
MaxQ=128, IRQ=17
[1.691469] [drm] DMA map mode: Using physical TTM page addresses.
[1.693089] [drm] Capabilities:
[1.693865] [drm] Rect copy.
[1.694586] [drm] Cursor.
[1.695213] [drm] Cursor bypass.
[1.696115] [drm] Cursor bypass 2.
[1.697379] [drm] 8bit emulation.
[1.698346] [drm] Alpha cursor.
[1.699141] [drm] 3D.
[1.699830] [drm] Extended Fifo.
[1.700639] [drm] Multimon.
[1.701323] [drm] Pitchlock.
[1.702023] [drm] Irq mask.
[1.702739] [drm] Display Topology.
[1.703639] [drm] GMR.
[1.704252] [drm] Traces.
[1.704914] [drm] GMR2.
[1.705793] [drm] Screen Object 2.
[1.706730] [drm] Command Buffers.
[1.707551] [drm] Command Buffers 2.
[1.708662] [drm] Guest Backed Resources.
[1.709635] [drm] DX Features.
[1.710546] [drm] Max GMR ids is 64
[1.711339] [drm] Max number of GMR pages is 65536
[1.712407] [drm] Max dedicated hypervisor surface memory is 0 kiB
[1.714454] [drm] Maximum display memory size is 32768 kiB
[1.715703] [drm] VRAM at 0xe800 size is 8192 kiB
[1.716862] [drm] MMIO at 0xfe00 size is 256 kiB
[1.718114] [drm] global init.
[1.719083] [TTM] Zone kernel: Available graphics memory: 1885344 kiB
[1.720698] [TTM] Initializing pool allocator
[1.721683] [TTM] Initializing DMA pool allocator
[1.722839] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.724307] [drm] No driver support for vblank timestamp query.
[1.724914] ata2.00: ATAPI: VMware Virtual IDE CDROM Drive, 0001, max
UDMA/33
[1.727793] [drm] Screen Target Display device initialized
[1.729269] [drm] width 1280
[1.730888] ata2.00: configured for UDMA/33
[1.730889] [drm] height 768
[1.730896] [drm] bpp 32
[1.734822] scsi: waiting for bus probes to complete ...
[1.739548] scsi 1:0:0:0: CD-ROMNECVMWar VMware IDE CDR10 1.00
PQ: 0 ANSI: 5
[1.747967] [drm] Fifo max 0x0004 min 0x1000 cap 0x077f
[1.751168] [drm] Using command buffers with DMA pool.
[1.752321] [drm] DX: yes.
[1.752997] [drm] Atomic: yes
%G
--
I'm using VMware Workstation 12 Player 12.5.5 build-5234757 on Windows 8.1.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm_modeset_lock oops in next
* Maarten Lankhorst [170408 01:55]:
> Hey,
>
> Op 07-04-17 om 17:56 schreef Tony Lindgren:
> > Hi,
> >
> > Looks like current next now oopses at least for omapdrm
> > when starting X. Reverting commit d20afeb3e2f9 ("Merge
> > remote-tracking branch 'drm-misc/for-linux-next'") makes
> > things work again.
> >
> > Any ideas what might be causing the oops below?
> Looks like fallout from the acquire_ctx patches?
>
> Could you test the below?
Yes thanks Daniel Vetter already posted a similar fix as
"[PATCH] drm: Only take cursor locks when the cursor plane exists".
Regards,
Tony
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/2] crypto: hw_random - Add new Exynos RNG driver
Hi, This is a follow up of my questions around exynos-rng [1]. Changes since v3: = 1. New patch: 1/2 for ALIGN_DOWN macro. The change in metag architecture was not compiled. Please test it. 2. Dropped patches touching ARM defconfig as they are not changing and they pollute this submission. 3. Utilize all seed provided by kcapi (suggested by Stephan Müller). 4. Drop dev->ctx (suggested by PrasannaKumar Muralidharan). 5. Remove any printks from set_seed callback as this might be a way for unprivileged user to pollute the log (suggested by Stephan). 6. Minor cleanups: initialize 'read' variable in exynos_rng_reseed() for readability (it is not strictly required). 7. Add review tags from Stephen and PrasannaKumar. Changes since v2: = 1. Do not re-use random numbers for re-seed (neither for system resume nor for periodic re-seed). Instead the driver will just generate new random numbers (suggested by Stephan Müller). Suspend path tested with suspend-to-freeze, not real suspend. Testing on Trats2 would be welcomed. Changes since v1: = 1. Re-work the code for seeding after system resume, following suggestions and review by Stephan Müller. 2. Re-seed itself from time to time (every 100 ms), suggested by Stephan Müller. 3. Use a define for retries (Bartlomiej Zolnierkiewicz). 4. Add some docs. Description: The existing exynos-rng has many issues. The most important one is that it is a pseudo RNG device but uses hw_random interface which does not allow proper seeding. The RNG module on Exynos4 requires seeding. On newer SoCs (like Exynos5420) it can seed itself from a true RNG. Converting the existing driver to use TRNG would effectively drop support for Exynos4 and break compatibility with existing users. Instead I decided to convert it to crypto API. In the future I hope to add support for seeding from TRNG module. Tested with app [2]. Patches are independent. I will take the defconfig changes (2/3 and 3/3) through samsung-soc tree. Best regards, Krzysztof [1] https://www.spinics.net/lists/arm-kernel/msg569641.html [2] https://www.spinics.net/lists/arm-kernel/msg571184.html Krzysztof Kozlowski (2): linux/kernel.h: Add ALIGN_DOWN macro crypto: hw_random - Add new Exynos RNG driver MAINTAINERS | 8 + arch/metag/kernel/stacktrace.c | 2 - drivers/char/hw_random/Kconfig | 14 -- drivers/char/hw_random/Makefile | 1 - drivers/char/hw_random/exynos-rng.c | 231 - drivers/crypto/Kconfig | 15 ++ drivers/crypto/Makefile | 1 + drivers/crypto/exynos-rng.c | 389 drivers/gpu/drm/udl/udl_fb.c| 2 +- include/linux/kernel.h | 1 + include/video/udlfb.h | 2 +- 11 files changed, 416 insertions(+), 250 deletions(-) delete mode 100644 drivers/char/hw_random/exynos-rng.c create mode 100644 drivers/crypto/exynos-rng.c -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] linux/kernel.h: Add ALIGN_DOWN macro
Few parts of kernel define their own macro for aligning down so provide
a common define for this, with the same usage and assumptions as existing
ALIGN.
Convert also three existing implementations to this one.
Signed-off-by: Krzysztof Kozlowski
---
The metag change was not even compiled due to lack of cross compiler.
---
arch/metag/kernel/stacktrace.c | 2 --
drivers/gpu/drm/udl/udl_fb.c | 2 +-
include/linux/kernel.h | 1 +
include/video/udlfb.h | 2 +-
4 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/metag/kernel/stacktrace.c b/arch/metag/kernel/stacktrace.c
index 91ffc4b75c33..09d67b7f51ca 100644
--- a/arch/metag/kernel/stacktrace.c
+++ b/arch/metag/kernel/stacktrace.c
@@ -31,8 +31,6 @@ static void tbi_boing_init(void)
}
#endif
-#define ALIGN_DOWN(addr, size) ((addr)&(~((size)-1)))
-
/*
* Unwind the current stack frame and store the new register values in the
* structure passed as argument. Unwinding is equivalent to a function return,
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index d05abc69e305..4a6500362564 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -37,7 +37,7 @@ struct udl_fbdev {
};
#define DL_ALIGN_UP(x, a) ALIGN(x, a)
-#define DL_ALIGN_DOWN(x, a) ALIGN(x-(a-1), a)
+#define DL_ALIGN_DOWN(x, a) ALIGN_DOWN(x, a)
/** Read the red component (0..255) of a 32 bpp colour. */
#define DLO_RGB_GETRED(col) (uint8_t)((col) & 0xFF)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4c26dc3a8295..3d9f8420f973 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -47,6 +47,7 @@
/* @a is a power of 2 value */
#define ALIGN(x, a)__ALIGN_KERNEL((x), (a))
+#define ALIGN_DOWN(x, a) __ALIGN_KERNEL((x) - ((a) - 1), (a))
#define __ALIGN_MASK(x, mask) __ALIGN_KERNEL_MASK((x), (mask))
#define PTR_ALIGN(p, a)((typeof(p))ALIGN((unsigned long)(p),
(a)))
#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
diff --git a/include/video/udlfb.h b/include/video/udlfb.h
index f9466fa54ba4..3ea90aea5617 100644
--- a/include/video/udlfb.h
+++ b/include/video/udlfb.h
@@ -92,6 +92,6 @@ struct dlfb_data {
/* remove these once align.h patch is taken into kernel */
#define DL_ALIGN_UP(x, a) ALIGN(x, a)
-#define DL_ALIGN_DOWN(x, a) ALIGN(x-(a-1), a)
+#define DL_ALIGN_DOWN(x, a) ALIGN_DOWN(x, a)
#endif
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/udl: Fix unaligned memory access in udl_render_hline
On SPARC, the udl driver filled my kernel log with these messages: [186668.910612] Kernel unaligned access at TPC[76609c] udl_render_hline+0x13c/0x3a0 Use put_unaligned_be16 to avoid them. On x86 this results in the same code, but on SPARC the compiler emits two single-byte stores. Signed-off-by: Jonathan Neuschäfer --- drivers/gpu/drm/udl/udl_transfer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/udl/udl_transfer.c b/drivers/gpu/drm/udl/udl_transfer.c index 917dcb978c2c..0c87b1ac6b68 100644 --- a/drivers/gpu/drm/udl/udl_transfer.c +++ b/drivers/gpu/drm/udl/udl_transfer.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include "udl_drv.h" @@ -163,7 +164,7 @@ static void udl_compress_hline16( const u8 *const start = pixel; const uint16_t repeating_pixel_val16 = pixel_val16; - *(uint16_t *)cmd = cpu_to_be16(pixel_val16); + put_unaligned_be16(pixel_val16, cmd); cmd += 2; pixel += bpp; -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 195231] Continuous messages of "*ERROR* UVD not responding, trying to reset the VCPU!!!" and frozen screen
Dear Alex and other developers,
On Thu, Apr 6, 2017 at 1:03 AM, wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=195231
>
> --- Comment #9 from Rogério Brito (rbr...@ime.usp.br) ---
> (In reply to Alex Deucher from comment #2)
>> Please attach your xorg log and dmesg output. Does appending radeon.runpm=0
>> on the kernel command line in grub help?
>
> Dear Alex and other developers, do you need any extra information from me? I
> will do my best to gather anything that may be helpful in fixing this bug.
I just installed Ubuntu's precompiled and unpatched kernel 4.11-rc5
and the messages of "UVD not responding" like in the subject persist,
also with the whole system hanging.
If I append radeon.runpm=0, the system does boot, but the messages are
still there. It is, though, taking ages to boot, compared to what it
used to be.
Once again, if anybody wants me to try any kernel, just tell me and I
will do my best.
I will update the information that I grab and/or those that people ask
me and put those at this bug on bugzilla
(https://bugzilla.kernel.org/show_bug.cgi?id=195231).
Thanks,
Rogério.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: DRM Display driver for Intel FPGA Video and Image Processing Suite
Hi Daniel Thanks for the time and patience for reviewing my changes. I would ensure that subsequent patches will not have the same mail problems. I have some question on the validation methods. Since my drivers are processing the images with an FPGA would running the tests with https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-and-validation be relevant? The display images are streamed to the monitor via a Display Port connector thus I don' t think it is virtual. The FPGA is programmed to run with a proprietary Display Port IP. The driver just feeds it with display data. I would take your advice in implementing it in the small drivers, but since its new are there any special cases that I would have to look out for in implementing this driver in the drm-misc ? >-Original Message- >From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of >Daniel >Vetter >Sent: Saturday, April 8, 2017 12:32 AM >To: Ong, Hean Loong >Cc: Vetter, Daniel ; airl...@linux.ie; dri- >de...@lists.freedesktop.org >Subject: Re: DRM Display driver for Intel FPGA Video and Image Processing Suite > >On Thu, Apr 6, 2017 at 8:29 AM, Ong, Hean Loong >wrote: >> Hi All, >> >> Any comments for the patch below? > >Seems the same version that I already reviewed. My comment about not sending >inline was more for the next version, especially once it's about applying the >patch, attached patches are a bit of a pain (since they break the tooling >here). >-Daniel >> >> Thanks >> >> Hean Loong >> >> On Tue, 2017-04-04 at 04:01 +, Ong, Hean Loong wrote: >>> Hi All, >>> >>> Apologies for the attachment earlier. Below are the inline changes >>> for the patch >>> >>> From 0de293e3646a1780ed603cf8e1f2a19d9aebbe83 Mon Sep 17 00:00:00 >>> 2001 >>> From: Ong, Hean Loong >>> Date: Thu, 30 Mar 2017 18:02:22 +0800 >>> Subject: [PATCHv0] Intel FPGA Video and Image Processing Suite Frame >>> Buffer II driver >>> >>> Signed-off-by: Ong, Hean Loong >>> --- >>> drivers/gpu/drm/Kconfig |2 + >>> drivers/gpu/drm/Makefile |1 + >>> drivers/gpu/drm/ivip/Kconfig | 22 >>> drivers/gpu/drm/ivip/Makefile |9 ++ >>> drivers/gpu/drm/ivip/intel_vip_conn.c | 145 ++ >>> drivers/gpu/drm/ivip/intel_vip_core.c | 215 >>> + >>> drivers/gpu/drm/ivip/intel_vip_crtc.c | 161 >>> >>> drivers/gpu/drm/ivip/intel_vip_drv.h | 55 + >>> drivers/gpu/drm/ivip/intel_vip_of.c | 146 ++ >>> 9 files changed, 756 insertions(+), 0 deletions(-) create mode >>> 100644 drivers/gpu/drm/ivip/Kconfig create mode 100644 >>> drivers/gpu/drm/ivip/Makefile create mode 100644 >>> drivers/gpu/drm/ivip/intel_vip_conn.c >>> create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c >>> create mode 100644 drivers/gpu/drm/ivip/intel_vip_crtc.c >>> create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h >>> create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c >>> >>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index >>> ebfe840..c487507 100644 >>> --- a/drivers/gpu/drm/Kconfig >>> +++ b/drivers/gpu/drm/Kconfig >>> @@ -167,6 +167,8 @@ source "drivers/gpu/drm/nouveau/Kconfig" >>> >>> source "drivers/gpu/drm/i915/Kconfig" >>> >>> +source "drivers/gpu/drm/ivip/Kconfig" >>> + >>> config DRM_VGEM >>> tristate "Virtual GEM provider" >>> depends on DRM >>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile >>> index b9ae428..945cf53 100644 >>> --- a/drivers/gpu/drm/Makefile >>> +++ b/drivers/gpu/drm/Makefile >>> @@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/ >>> obj-$(CONFIG_DRM_MGA)+= mga/ >>> obj-$(CONFIG_DRM_I810) += i810/ >>> obj-$(CONFIG_DRM_I915) += i915/ >>> +obj-$(CONFIG_DRM_IVIP) += ivip/ >>> obj-$(CONFIG_DRM_MGAG200) += mgag200/ >>> obj-$(CONFIG_DRM_VC4) += vc4/ >>> obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/ diff --git >>> a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig new >>> file mode 100644 index 000..ddf3cb5 >>> --- /dev/null >>> +++ b/drivers/gpu/drm/ivip/Kconfig >>> @@ -0,0 +1,22 @@ >>> +config DRM_IVIP >>> +tristate "Intel FGPA Video and Image Processing" >>> +depends on DRM >>> +select DRM_GEM_CMA_HELPER >>> +select DRM_KMS_HELPER >>> +select DRM_KMS_FB_HELPER >>> +select DRM_KMS_CMA_HELPER >>> +help >>> +Choose this option if you have a Intel FPGA Arria 10 >>> system >>> +and above with a Display Port IP. This does not >>> support legacy >>> +Intel FPGA Cyclone V display port. Currently only >>> single frame >>> +buffer is supported. Note that ACPI and X_86 >>> architecture is yet >>> +to be supported. >>> + >>> +config DRM_IVIP_OF >>> +tristate "Intel FGPA Video and Image Processing Open >>> Firmware Systems" >>> +
[Bug 195295] USB device insertion turns on discrete Radeon GPU
https://bugzilla.kernel.org/show_bug.cgi?id=195295 --- Comment #1 from Michel Dänzer (mic...@daenzer.net) --- Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100618] Dead Island crash after starting a new game
https://bugs.freedesktop.org/show_bug.cgi?id=100618 --- Comment #1 from Michel Dänzer --- What are the symptoms of the crash? Can you get a backtrace? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm: Check mode object lease status in all master ioctl paths
Daniel Vetter writes: > I think it'd be good if we could consolidate all the lease checking into > drm_mode_object_find (respectively __drm_mode_object_find). We'd need to > wire up the fpriv to be able to do that, but we could upstream that patch > right away before anything else. That should take care of most of the > checks in this patch here. Hrm. Without some major changes, the effect of this will be to have the lessee see only the objects which it holds a lease on. I think that's OK as the lessor will be doing object filtering for its clients, however it's not what Dave and I discussed, so I just want to make him aware that the kernel is going to be simpler than originally planned. We had originally discussed having the lessee see the un-leased objects, but to have them reported with different status. -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm: Add drm_object lease infrastructure
On 03/04/17 01:31 AM, Keith Packard wrote: > Daniel Vetter writes: > >> I'm also not sure whether we really want sub-leases in v1, that's easy >> to add later on, but for now just complicates stuff. Main compositor >> should be a full master, VR can be the first lease level, we don't >> need more I think for now? > > We've discussed how leases might be used to implement multi-user > support, so offering sub-leases means that environment could also > support leasing resources out from the users session. > > We also just don't know how useful it might be until we explore the > space a bit more. It should only be added upstream once it's clear that it's useful. > Given that it takes years to get new features into distributions, I > tend to error on the side of generality. Why would it take years? Distros seem to generally use the latest upstream kernel release available at release/freeze. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm: dw-hdmi: various improvements
Hi, On 04/07/2017 07:49 PM, Romain Perier wrote: This set of patches split the stream handling functions in two parts. It introduces new callbacks that are specific to each variant, one for I2S and one for AHB. Then, as requested by the datasheet for the I2S variant, it adds support for gating the audio sampler clock when the audio stream is enabled and disabled. This patches series is the continuity of the following discussion: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/493550.html Since these aren't fixes, could you make sure to redo the patches over: git://anongit.freedesktop.org/drm-misc drm-misc-next The dw-hdmi driver is now under drivers/gpu/drm/bridge/synopsis/ Thanks, Archit Romain Perier (2): drm: dw-hdmi: add specific I2S and AHB functions for stream handling drm: dw-hdmi: Gate audio clock from the I2S enablement callbacks drivers/gpu/drm/bridge/dw-hdmi.c | 45 +--- 1 file changed, 37 insertions(+), 8 deletions(-) -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Add Laurent and Andrzej as maintainers for bridge drivers
On 05.04.2017 13:23, Archit Taneja wrote: > Add Laurent and Andrzej as maintainers for DRM bridge chip drivers. They > actively review and contribute to bridge drivers and the bridge API. > > Cc: Laurent Pinchart > Cc: Andrzej Hajda > Signed-off-by: Archit Taneja Acked-by: Andrzej Hajda -- Regards Andrzej > --- > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index d0d9ed8d2459..59d323d8567a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4169,6 +4169,8 @@ F: drivers/gpu/drm/ast/ > > DRM DRIVERS FOR BRIDGE CHIPS > M: Archit Taneja > +M: Laurent Pinchart > +M: Andrzej Hajda > S: Maintained > T: git git://anongit.freedesktop.org/drm/drm-misc > F: drivers/gpu/drm/bridge/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100611] [ALL][BAT][bisected] all systems on CI fails on certain test
https://bugs.freedesktop.org/show_bug.cgi?id=100611 --- Comment #4 from Jani Saarinen --- Fix works, closed -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100611] [ALL][BAT][bisected] all systems on CI fails on certain test
https://bugs.freedesktop.org/show_bug.cgi?id=100611 Jani Saarinen changed: What|Removed |Added Status|RESOLVED|VERIFIED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100611] [ALL][BAT][bisected] all systems on CI fails on certain test
https://bugs.freedesktop.org/show_bug.cgi?id=100611 Jani Saarinen changed: What|Removed |Added Status|VERIFIED|CLOSED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] MAINTAINERS: Update maintainers/reviewers for bridge drivers
Add Laurent as a reviewer and Andrzej as a maintainer for DRM bridge chip drivers. They actively review and contribute to bridge drivers and the bridge API. Acked-by: Andrzej Hajda Acked-by: Laurent Pinchart Acked-by: Sean Paul Signed-off-by: Archit Taneja --- v2: - Collected Acks. Changed Laurent to reviewer. - I'm going to queue this to drm-misc-next. Sent this patch mostly for book-keeping MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4ea82b26cc2e..c36dfaeef26b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4168,6 +4168,8 @@ F:drivers/gpu/drm/ast/ DRM DRIVERS FOR BRIDGE CHIPS M: Archit Taneja +M: Andrzej Hajda +R: Laurent Pinchart S: Maintained T: git git://anongit.freedesktop.org/drm/drm-misc F: drivers/gpu/drm/bridge/ -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100618] Dead Island crash after starting a new game
https://bugs.freedesktop.org/show_bug.cgi?id=100618 --- Comment #2 from at...@t-online.de --- Created attachment 130769 --> https://bugs.freedesktop.org/attachment.cgi?id=130769&action=edit crash log of Dead Island -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100618] Dead Island crash after starting a new game
https://bugs.freedesktop.org/show_bug.cgi?id=100618 --- Comment #3 from at...@t-online.de --- I added the crash log of the game. There is no error at the end. The Game seems to crash while compiling shaders. Let me know if I could do any more to help with this bug or if you need more infos of my system. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 195231] Continuous messages of "*ERROR* UVD not responding, trying to reset the VCPU!!!" and frozen screen
https://bugzilla.kernel.org/show_bug.cgi?id=195231 Christian König (deathsim...@vodafone.de) changed: What|Removed |Added CC||deathsim...@vodafone.de --- Comment #11 from Christian König (deathsim...@vodafone.de) --- Well bisecting which patch caused the break would be a good idea. To start that I suggest you try to compile kernel 4.4 by yourself first. That should also yield a temporary solution until we can narrow down the root cause. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100618] Dead Island crash after starting a new game
https://bugs.freedesktop.org/show_bug.cgi?id=100618 --- Comment #4 from Michel Dänzer --- Can you try attaching gdb to the game process and getting a backtrace of the crash? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
