On 2014ë
11ì 20ì¼ 23:23, Andrzej Hajda wrote:
> On 11/20/2014 02:56 PM, Inki Dae wrote:
>> On 2014ë
11ì 20ì¼ 22:19, Andrzej Hajda wrote:
>>> On 11/20/2014 11:24 AM, Inki Dae wrote:
This patch makes kms drivers to be independent drivers.
For this, it removes all register codes to
Hi Javier,
On 2014ë
11ì 20ì¼ 23:06, Javier Martinez Canillas wrote:
> Hello Inki,
>
> On Thu, Nov 20, 2014 at 2:56 PM, Inki Dae wrote:
>>> If you try to build exynosdrm as module you will receive errors due to
>>> multiple definitions of init_module, ie module_init/module_*_driver
>>> macro
Hi Javier,
On 2014ë
11ì 18ì¼ 22:53, Javier Martinez Canillas wrote:
> The Exynos DRM driver register its sub-devices platform drivers in
> the probe function but after commit 43c0767 ("of/platform: Move
> platform devices under /sys/devices/platform"), this is causing
> a deadlock in __driver
On 2014ë
11ì 20ì¼ 22:19, Andrzej Hajda wrote:
> On 11/20/2014 11:24 AM, Inki Dae wrote:
>> This patch makes kms drivers to be independent drivers.
>> For this, it removes all register codes to kms drivers
>> from exynos_drm_drv module and adds module_init/exit
>> for each kms driver so that ea
On Thu, Nov 20, 2014 at 03:55:06PM -0500, Rob Clark wrote:
> The intention is that drivers can set crtc_state->mode_changed in their
> atomic_check() fxns if they encounter a scenario that requires full
> modeset.
>
> Signed-off-by: Rob Clark
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm
On Thu, Nov 20, 2014 at 03:55:07PM -0500, Rob Clark wrote:
> In disable_outputs() we need to shut down the outgoing encoder, not the
> incoming one (we have already swapped-state at this point). Without
> this, we end up telling the driver to crtc->dpms(OFF) without first
> encoder->dpms(OFF), and
>From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Thu, 13 Nov 2014 22:21:54 +0900
Subject: [PATCH] drm/ttm: Avoid memory allocation from shrinker functions.
Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid
deadlock.") caused BUG_ON
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/ec5890d5/attachment-0001.html>
From: Gustavo Padovan
The component must be deleted if the probe fails.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exyno
From: Gustavo Padovan
exynos_drm_component_add() correctly checks if a component is present on
drm_component_list however it release the lock right after the check
and before we add the new component to the list. That just creates room
to add the same component more than once to the list.
The lo
From: Gustavo Padovan
DP was leaked everytime function returns EPROBE_DEFER, free it before
returning.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/ex
From: Gustavo Padovan
Registering the Exynos DRM subdevices platform drivers in the probe
function is causing an infinite loop. Fix this by moving it to the
exynos_drm_init() function to register the drivers on module init.
Registering drivers in the probe functions causes a deadlock in the pare
From: Gustavo Padovan
This reverts commit cea24824ab432f8acabb254d6805e9aa756de6af.
Moving subdriver probe to exynos_drm_platform_probe() was making
exynos_drm_device_subdrv_probe() fail because the platform data wasn't set
yet. It only gets set in exynos_drm_load.
We need to find a smarter way
From: Gustavo Padovan
This reverts commit 06a2f5c2c4e0cb4ff38ca3769ae1f81cc2d030cf and
f7c2f36f4395f12d8ecb25c28ee88ec87b457089.
These two patches were trying to fix an issue that was causing an
infinite loop at the load of the exynos-drm but they were not tackling the
source of the problem.
A
From: Gustavo Padovan
These patches were tested both in drm-exynos-next and linux-next (with
drm-exynos-next merged in) and it solves the infinite loop and parent device
lock deadlock. It was tested with Ajay's DP patches applied. A tree based on
drm-exynos-next can be found here:
https://git.ke
2014-11-13 Inki Dae :
> This patch fixes null pointer dereference issue incurred
> when ipp driver is enabled and Exynos drm driver is closed.
>
> Non kms driver should register its own sub driver to setup necessary
> resources, which is done by load(). So null pointer dereference
> occurs when i
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/42a0929f/attachment.html>
This code was in drm_plane_helper, but missing from drm_atomic_helper,
causing various crashes when the plane was already disabled. Just copy
over the quick return there to prevent a crash.
Signed-off-by: Jasper St. Pierre
Reviewed-by: Rob Clark
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_atomic
Exynos5: Use pmu_system_controller phandle for
>>>> dp phy
>>>> 36391a5 Add linux-next specific files for 20141119
>>>> 9b1ced1 Merge branch 'akpm/master'
>>>> 282497e mm: add strictlimit knob
>>>
>>> used exynos_defconfig
Use 'for' statemant instead of hard-coded 'if' statement.
Changelog v3:
- none
Changelog v2:
- none
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_
This patch makes vidi driver to be independent driver.
For this, it removes register codes to vidi driver
from exynos_drm_drv module and adds module_init/exit
for vidi driver so that this driver can be called
independently.
In addition, this patch adds component support to vidi driver
so that this
This patch makes non kms drivers to be independent drivers.
For this, it removes all register codes to non kms drivers
from exynos_drm_drv module and adds module_init/exit
for each non kms driver so that each non kms driver can be
called independently.
In addition, this patch adds non kms register
This patch makes kms drivers to be independent drivers.
For this, it removes all register codes to kms drivers
from exynos_drm_drv module and adds module_init/exit
for each kms driver so that each kms driver can be
called independently.
Changelog v3:
- Use module_platform_driver macro instead modu
Hi all,
This patch set separeates sub drivers into independent drivers.
patch 1/4:
- make all kms drivers - fimd, hdmi, dp and dsi - to be independent
drivers.
patch 2/4:
- make all non kms drivers - g2d and ipp - to be independent drivers.
patch 3/4:
- make vidi drive
Hello,
For completeness I'll comment what we talked with Kevin on IRC
since probably this is the same issue that Paolo is facing.
On 11/20/2014 05:41 PM, Kevin Hilman wrote:
> Peach # setenv preboot "usb start; sleep 1"setenv bootargs console=tty1
> console=ttySAC3,115200 debug earlyprintk rw ro
Hello Paolo,
On 11/20/2014 04:57 PM, Paolo Pisati wrote:
> On Thu, Nov 20, 2014 at 03:22:23PM +0530, Vivek Gautam wrote:
>>
>> On linux-samsung tree the only patch that's missing apart from dptx-phy
>> patches
>> is the syscon patch from Pankaj Dubey:
>> b784b98 mfd: syscon: Decouple syscon inter
https://bugzilla.kernel.org/show_bug.cgi?id=88501
--- Comment #8 from business.kid at gmail.com ---
Yes. I tested in order
1. 3.18.0-rc4 with no patch - white 2nd time.
2. 3.18.0-rc4 with the boot option - dark every time
3. 3.18.0-rc4 with your patch applied and no boot option - white 2nd time
4
In disable_outputs() we need to shut down the outgoing encoder, not the
incoming one (we have already swapped-state at this point). Without
this, we end up telling the driver to crtc->dpms(OFF) without first
encoder->dpms(OFF), and that makes some hw quite unhappy.
v2: missing WARN_ON() hunk and
On Thu, Nov 20, 2014 at 03:22:23PM +0530, Vivek Gautam wrote:
>
> On linux-samsung tree the only patch that's missing apart from dptx-phy
> patches
> is the syscon patch from Pankaj Dubey:
> b784b98 mfd: syscon: Decouple syscon interface from platform devices
>
> So with below git hash, linux-sam
On Thu, Nov 20, 2014 at 3:55 PM, Rob Clark wrote:
> In disable_outputs() we need to shut down the outgoing encoder, not the
> incoming one (we have already swapped-state at this point). Without
> this, we end up telling the driver to crtc->dpms(OFF) without first
> encoder->dpms(OFF), and that ma
Hello Inki,
On 11/20/2014 04:06 PM, Inki Dae wrote:
>> BTW, it would be great if exynos-drm-next is pulled in linux-next. That is
>> what most people use to test integration issues so you can catch earlier any
>> regression that may arise.
>>
>> You have to email Stephen Rothwell and point to
>
This patch implements the virtual GEM driver with PRIME sharing which
allows vgem to import a gem object from other drivers for the purpose
of mmap-ing them to userspace.
Reviewed-by: Stéphane Marchesin
Signed-off-by: Adam Jackson
Signed-off-by: Ben Widawsky
Signed-off-by: Zach Reizner
---
d
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/91225cb7/attachment.html>
In disable_outputs() we need to shut down the outgoing encoder, not the
incoming one (we have already swapped-state at this point). Without
this, we end up telling the driver to crtc->dpms(OFF) without first
encoder->dpms(OFF), and that makes some hw quite unhappy.
Reviewed-by: Daniel Vetter
Sig
The intention is that drivers can set crtc_state->mode_changed in their
atomic_check() fxns if they encounter a scenario that requires full
modeset.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_atomic_helper.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/dri
https://bugzilla.kernel.org/show_bug.cgi?id=88501
--- Comment #7 from Alex Deucher ---
The code should be fine as is. Are you sure you tested the right kernel?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=88501
--- Comment #6 from business.kid at gmail.com ---
Created attachment 158261
--> https://bugzilla.kernel.org/attachment.cgi?id=158261&action=edit
Your patch slightly adjusted
This seems to work. I know little of C, and less of graphics programmin
Hello Inki,
On 11/20/2014 03:07 PM, Inki Dae wrote:
> Could you re-base this patch on top of exynos-drm-next? I tried to
> separate sub drivers into independent drivers but it seems that we need
> more times. So I will merge your patch.
>
Sure, I'll rebase on top of exynos-drm-next and re-post s
On 11/20/2014 02:56 PM, Inki Dae wrote:
> On 2014ë
11ì 20ì¼ 22:19, Andrzej Hajda wrote:
>> On 11/20/2014 11:24 AM, Inki Dae wrote:
>>> This patch makes kms drivers to be independent drivers.
>>> For this, it removes all register codes to kms drivers
>>> from exynos_drm_drv module and adds modu
ific files for 20141119
>>> 9b1ced1 Merge branch 'akpm/master'
>>> 282497e mm: add strictlimit knob
>>
>> used exynos_defconfig
>>
>
> Same here.
>
>>>
>>> With this display works for me.
>>> Without $Subject patch i get lo
Hello Inki,
On Thu, Nov 20, 2014 at 2:56 PM, Inki Dae wrote:
>> If you try to build exynosdrm as module you will receive errors due to
>> multiple definitions of init_module, ie module_init/module_*_driver
>> macros can be used once per module.
>
> Ah, right. we had ever tried same way before but
On 11/20/2014 11:24 AM, Inki Dae wrote:
> This patch makes kms drivers to be independent drivers.
> For this, it removes all register codes to kms drivers
> from exynos_drm_drv module and adds module_init/exit
> for each kms driver so that each kms driver can be
> called independently.
>
> Changel
On Fri, Nov 07, 2014 at 07:43:04PM +0100, Thomas Meyer wrote:
>
> drm_intel_gem_bo_free() crashes because the list bo_gem->vma_list is not
> yet initialised, but the error path tries to free it.
>
> See also https://bugs.freedesktop.org/show_bug.cgi?id=75844
>
> Reviewed-by: Chris Wilson
> Sign
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/ddb19643/attachment-0001.html>
Hi Dave,
More radeon patches for 3.19. Highlights:
- More CI dpm fixes
- Initial DPM fan control for SI/CI (disabled by default)
- GPUVM multi-ring efficiency improvements
- Some cursor fixes
The following changes since commit cc5ac1ca79b4976ed3a779d7ea157f078207b56b:
Merge branch 'amdkfd-v6'
Hi,
On Thu, Nov 20, 2014 at 12:36 PM, Vivek Gautam
wrote:
> Hi Javier, Kevin,
>
>
>
> On Wed, Nov 19, 2014 at 10:22 PM, Javier Martinez Canillas
> wrote:
>> [adding Paolo and Vivek as cc]
>>
>> Hello,
>>
>> On 11/18/2014 07:41 PM, Kevin Hilman wrote:
>>>
>>> It fixes the DRM deadlock, issue for
Hi,
I was thinking of adding a function to drm_encoder_slave.c for attaching
the slave endcoder based on its device_node.
This would make the i2c slave encoder adding more elegant in device tree
based environments.
My idea is to use the function in tilcdc_slave.c.
I am just wondering if someon
David and the maintainers of mga_dma.c I am wondering about remove this
function and whether I can or do I need to keep it around for other parts of
this driver to work. In addition I will paste the function below from your
convience.
Nick
#if 0
FIXME: Still needed?
*/
static void mga_freelist_
Hi Javier, Kevin,
On Wed, Nov 19, 2014 at 10:22 PM, Javier Martinez Canillas
wrote:
> [adding Paolo and Vivek as cc]
>
> Hello,
>
> On 11/18/2014 07:41 PM, Kevin Hilman wrote:
>>
>> It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
>> it proceeds to panic in the workqueue
Hi Dave,
Just two small fixes for radeon.
The following changes since commit bcfef97398972de555e6e1dbf4dac33f0db38d52:
Merge tag 'drm/tegra/for-3.18-rc5' of
git://people.freedesktop.org/~tagr/linux into drm-fixes (2014-11-14 07:03:02
+1000)
are available in the git repository at:
git://
s scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/e7edd061/attachment.html>
Javier Martinez Canillas writes:
> Hello,
>
> For completeness I'll comment what we talked with Kevin on IRC
> since probably this is the same issue that Paolo is facing.
>
> On 11/20/2014 05:41 PM, Kevin Hilman wrote:
>> Peach # setenv preboot "usb start; sleep 1"setenv bootargs
>> console=tty1
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/3cbf636d/attachment.sig>
l the goodness of a well-tested code base for free and you can
simply pass in the request_{threaded_,}irq()'s dev parameter.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/31163462/attachment.sig>
It happens on occasion that developers of generic user-space applications
abuse the dumb buffer API to get hold of drm buffers that they can both
mmap() and use for GPU acceleration, using the assumptions that dumb buffers
and buffers available for GPU are
a) The same type and can be aribtrarily ty
Op 20-11-14 om 05:06 schreef Michael Marineau:
> On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst
> wrote:
>> Hey,
>>
>> On 19-11-14 07:43, Michael Marineau wrote:
>>> On 3.18-rc kernel's I have been intermittently experiencing GPU
>>> lockups shortly after startup, accompanied with one or both
This is an oversight from
commit f52b69f1ecfdd7ef6867a257620258c09e569552
Author: Daniel Vetter
Date: Wed Nov 19 18:38:08 2014 +0100
drm/atomic: Don't overrun the connector array when hotplugging
Cc: Dave Airlie
Cc: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic
tachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/89b61ef0/attachment-0001.sig>
This adds binding documentation for Rockchip SoC VOP driver.
Signed-off-by: Mark Yao
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem
Changes in v3: None
Changes in v4: None
Changes in v5: None
Changes in v6: None
Changes in v7: No
On Thu, Nov 20, 2014 at 3:57 AM, Thierry Reding
wrote:
> On Sun, Nov 16, 2014 at 09:18:47AM -0500, Rob Clark wrote:
>> On Fri, Nov 14, 2014 at 5:42 PM, Hai Li wrote:
>> > All the sub-systems in mdss share the same irq. This change provides
>> > the sub-systems with the interfaces to register/unre
This add a display subsystem comprise the all display interface nodes.
Signed-off-by: Mark Yao
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
the graphics subsystem.
Changes in v3: None
Changes in v4: None
Changes in v5: None
Changes in v6: None
Cha
This patch adds the basic structure of a DRM Driver for Rockchip Socs.
Signed-off-by: Mark Yao
Signed-off-by: Daniel Kurtz
Acked-by: Daniel Vetter
Reviewed-by: Rob Clark
---
Changes in v2:
- use the component framework to defer main drm driver probe
until all VOP devices have been probed.
-
This a series of patches is a DRM Driver for Rockchip Socs, add support
for vop devices. Future patches will add additional encoders/connectors,
such as eDP, HDMI.
The basic "crtc" for rockchip is a "VOP" - Video Output Processor.
the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two s
xynos_defconfig
>
Same here.
>>
>> With this display works for me.
>> Without $Subject patch i get lookup in drm.
>>
I tested with today linux-next (next-20141120) and display is indeed
working for me. So it seems that whatever caused the error in the
phy-exyno
Op 20-11-14 om 00:08 schreef Tobias Klausmann:
> On 19.11.2014 09:10, Maarten Lankhorst wrote:
>> ...
>> On the EDITED patch from fixed-fences-for-bisect, can you do the following:
>>
>> In nouveau/nv84_fence.c function nv84_fence_context_new, remove
>>
>> fctx->base.sequence = nv84_fence_read(chan
https://bugzilla.kernel.org/show_bug.cgi?id=88501
--- Comment #5 from business.kid at gmail.com ---
Yes, this fixes the issue on 3.18-rc4
No, it does not. I get the same behaviour - first time it blanks to dark, every
other time it blanks to white.
I am a very rusty amateur at C, but I will ad
de?
Thanks a ton,
- Rian
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/c3ff2a63/attachment.html>
rm: dts: Exynos5: Use pmu_system_controller phandle for dp
> phy
> 36391a5 Add linux-next specific files for 20141119
> 9b1ced1 Merge branch 'akpm/master'
> 282497e mm: add strictlimit knob
>
> With this display works for me.
> Without $Subject patch i get lookup in drm.
On November 19, 2014 5:57:13 PM SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Wed, 19 Nov 2014 17:50:19 +0100
>
> The vfree() function performes also input parameter validation. Thus the test
> around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
On November 19, 2014 5:42:26 PM SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Wed, 19 Nov 2014 17:33:32 +0100
>
> The vunmap() function performes also input parameter validation. Thus the test
> around the call is not needed.
>
> This issue was detected by using the Coccinelle software
On November 19, 2014 5:28:59 PM SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Wed, 19 Nov 2014 17:05:20 +0100
>
> The drm_fbdev_cma_hotplug_event() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call is not needed.
>
> This issue wa
if (fw)
> - release_firmware(fw);
> + release_firmware(fw);
> return edid;
> }
>
Reviewed-by: Thierry Reding
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/a928aba2/attachment.html>
Checksumming was disabled for CEA blocks by
commit 4a638b4e38234233f5c7e6705662fbc0b58d80c2
Author: Adam Jackson
Date: Tue May 25 16:33:09 2010 -0400
drm/edid: Allow non-fatal checksum errors in CEA blocks
If only the checksum is wrong, reading twice should result in identical
data, where
Signed-off-by: Stefan Brüns
---
drivers/gpu/drm/drm_edid.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b072041..3a10f3f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1232,1
The function will also be used by a later patch, so factor it out.
Signed-off-by: Stefan Brüns
---
drivers/gpu/drm/drm_edid.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ec4f91f..b072041 100644
There is no need to dump the whole EDID block in case it contains no
information. Just print a single line stating the block is empty instead
of 8 lines containing only zeroes.
Signed-off-by: Stefan Brüns
---
drivers/gpu/drm/drm_edid.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141120/325769e8/attachment-0001.html>
ailure in Unreal Engine code. Not obviously directly
related to the driver.
--
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/20141120/78e80678/attachment.html>
s well, not sure), and with ARB_gs5, into SAMP as well.
--
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/20141120/1d4ba617/attachment.html>
s/dri-devel/attachments/20141120/9881d46b/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=88481
--- Comment #9 from Christopher Frömmel ---
Thanks to everyone involved. Report and fix within 20 hours. Awesome!
--
You are receiving this mail because:
You are watching the assignee of the bug.
u 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/20141120/2a7a23f8/attachment.html>
On 19.11.2014 09:10, Maarten Lankhorst wrote:
> ...
> On the EDITED patch from fixed-fences-for-bisect, can you do the following:
>
> In nouveau/nv84_fence.c function nv84_fence_context_new, remove
>
> fctx->base.sequence = nv84_fence_read(chan);
>
> and add back
>
> nouveau_bo_wr32(priv->bo, chan-
83 matches
Mail list logo
