Re: Planned Vega support in Linux

[Alex Deucher]

On Tue, Aug 8, 2017 at 11:46 PM, David Niklas  wrote:
> BTW: I'm on list, no need to CC.
>
> On Wed, 9 Aug 2017 10:38:23 +0900
> Michel Dänzer  wrote:
>
>> On 09/08/17 05:12 AM, David Niklas wrote:
>> > I know that currently some form of headless support already exists,
>> > but then I'd have to use crossfire (which does not work with the
>> > opensource driver AFAIK).
>>
>> You don't need CrossFire to make use of a GPU in a headless fashion.
>
> No, but you do if you intend to use your primary desktop machine and Vega
> supports only headless, or as Harry pointed out, a display driver (which,
> I am assuming means 2D only).

Full asic functionality is available for vega10 including displays in
the branch Harry pointed out.

> Besides, and as a side thought, I have had the temptation of using two
> GPUs for compute tasks since it's just silly to toss/sell a GPU that
> could be useful and is worth more to me than it's online value in dollars
> (I have to choose the only GPU that actually goes *down* in price)
>
>> OpenCL should support that out of the box, and in X the GPU can be used
>> for OpenGL apps via RandR 1.4 render offloading (obviously, you'll need
>> another GPU in the system that X can use for output).
>>
>
> You've lost me.
> Let my try to understand, and you correct me as I go astray.
> 1. X can send the OpenGL requests to another GPU while Vega does other
> things or idles mindlessly in headless mode.
> 2. X can send the OpenGL requests to the Vega GPU while the other GPU
> sends frames to the display from Vega.
>
> Also, do I need to configure X using RandR, or will it "just work" ...
> Stupid question, let me rephrase:
> What do I need to do to tell RandR to get X to work?

If you use the kernel branch mentioned above, X will detect all
relevant GPUs and you can use xrandr to dynamically configure what
GPU(s) you want to display with or render with at runtime.  You only
need X for display.  If you just want to use a GPU for offscreen
graphics rendering or compute work, you don't need to be running X.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Planned Vega support in Linux

[Alex Deucher]

On Tue, Aug 8, 2017 at 11:46 PM, David Niklas  wrote:
> BTW: I'm on list, no need to CC.
>
> On Tue, 8 Aug 2017 20:30:02 +
> "Deucher, Alexander"  wrote:
>> > From: David Niklas [mailto:do...@mail.com]
>> > Hello,
>> > I'm not seeking any secret info.
>> > I'm a Gentoo Linux user who wants to run some massively parallel
>> > experiments.
>> > I'm unwilling to wait and see what kind of support Linux gets because
>> > the annoying bitcoin miners tend to cause the price to go through the
>> > roof quickly.
>> > My current card is an AMD SI HD7780 by MSI.
>> > I know that currently some form of headless support already exists,
>> > but then I'd have to use crossfire (which does not work with the
>> > opensource driver AFAIK).
>> > I filed a ticket at AMD on 05/07/17 but AMD has not gotten back to me
>> > on this matter and like I said, if I wait then I risk having to buy
>> > something way out of my price range.
>> > --And I really have tried to wait till the last minute--
>> > Anything official or unofficial will do.
>> > I am planning to use the OpenCL language to do my MP experiments.
>>
>> I'm not quite sure what you are asking.  We released initial open
>> source support for vega10 months ago and it continues to evolve as new
>> SKUs are launched.
>
> I used AMD pro stack for sometime before the AMDGPU driver evolved to
> something useful. Believe me, I do well to ask[1].
>
>> It is expected that you can get a complete working
>> stack in open source at launch time for whatever sku you are interested
>> in.  Not all of the patches are upstream, but they are all public.
>
> Is the opensource driver you're thinking of at the url that harry gave
> me?
> What it the state? (beta, alpha, etc.).
> About how complete is it with respect to the other opensource GCN drivers?

It's the same driver.  However, kernel and other open source
components do not always align to product cycles so support may not be
upstream in the various open source projects yet.  The vega10 code
that is upstream doesn't not have full functionality for all vega10
skus or features because older kernels were released before all the
products were finalized.  The amd-staging-4.12 branch Harry pointed
out has the latest code which provides full functionality for the
asic.

>
>> OpenCL support is provided by the ROCm stack which you can get from the
>> gpuopen site.
>
> "We do not support ROCm with PCIe Gen 2 enabled CPUs such as the AMD
> Opteron, Phenom, Phenom II, Athlon, Athlon X2, Athlon II and Older Intel
> Xeon and Intel Core Architecture and Pentium CPUs."
>
> Ouch!
> Mine is a Phenom II 6 core 1090T.
> I can't go spending a ton on a new CPU, MB, RAM, and GPU (and I'd need a
> less hacked case too :)
> Granted I could get an i3, cheap the MB and RAM, but I've worked so hard
> for a great platform... 32GB RAM, 6 core Phenom II, HD 7780 GPU, RAID 5
> on 2TB HDs, Bluray drive, Mechanical keyboard, HP laser printer,
> 4800x4800dpi HP scanner...
> AMD is normally so good at compatibility too.
> Ok, I'm over it, what is doable at this point?

PCIe gen 3 is required for pcie atomics.  I'm not a ROCm expert so I'm
not sure if that is a hard requirement or only if you need platform
atomics.

Alex

>
>> Headless boards are supported just fine and have been
>> for years.  If you prefer packaged drivers, you can download the ROCm
>> stack from gpuopen or the pro stack from amd.com.  All stacks build on
>> the same open source kernel driver and other components.
>>
>> Alex
>>
>
> Good to know!
>
>
>
> [1] No offence, but AMD's gpu-pro would not allow the system to suspend
> (sleep), also I'd often get a black and white set of vertical lines
> through my display and the kernel would totally freeze (no sysreq). The
> worst part is that it would happen totally randomly (really).
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Fix framebuffer leak

[Nikhil Mahale]

Do not leak framebuffer if client provided crtc id found invalid.

Signed-off-by: Nikhil Mahale 
---
 drivers/gpu/drm/drm_plane.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 5dc8c43..e40c12f 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -601,6 +601,7 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
 
crtc = drm_crtc_find(dev, plane_req->crtc_id);
if (!crtc) {
+   drm_framebuffer_put(fb);
DRM_DEBUG_KMS("Unknown crtc ID %d\n",
  plane_req->crtc_id);
return -ENOENT;
-- 
2.6.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Planned Vega support in Linux

[David Niklas]

BTW: I'm on list, no need to CC.

On Tue, 8 Aug 2017 20:30:02 +
"Deucher, Alexander"  wrote:
> > From: David Niklas [mailto:do...@mail.com]
> > Hello,
> > I'm not seeking any secret info.
> > I'm a Gentoo Linux user who wants to run some massively parallel
> > experiments.
> > I'm unwilling to wait and see what kind of support Linux gets because
> > the annoying bitcoin miners tend to cause the price to go through the
> > roof quickly.
> > My current card is an AMD SI HD7780 by MSI.
> > I know that currently some form of headless support already exists,
> > but then I'd have to use crossfire (which does not work with the
> > opensource driver AFAIK).
> > I filed a ticket at AMD on 05/07/17 but AMD has not gotten back to me
> > on this matter and like I said, if I wait then I risk having to buy
> > something way out of my price range.
> > --And I really have tried to wait till the last minute--
> > Anything official or unofficial will do.
> > I am planning to use the OpenCL language to do my MP experiments.  
> 
> I'm not quite sure what you are asking.  We released initial open
> source support for vega10 months ago and it continues to evolve as new
> SKUs are launched. 

I used AMD pro stack for sometime before the AMDGPU driver evolved to
something useful. Believe me, I do well to ask[1].

> It is expected that you can get a complete working
> stack in open source at launch time for whatever sku you are interested
> in.  Not all of the patches are upstream, but they are all public.

Is the opensource driver you're thinking of at the url that harry gave
me?
What it the state? (beta, alpha, etc.).
About how complete is it with respect to the other opensource GCN drivers?

> OpenCL support is provided by the ROCm stack which you can get from the
> gpuopen site.

"We do not support ROCm with PCIe Gen 2 enabled CPUs such as the AMD
Opteron, Phenom, Phenom II, Athlon, Athlon X2, Athlon II and Older Intel
Xeon and Intel Core Architecture and Pentium CPUs."

Ouch!
Mine is a Phenom II 6 core 1090T.
I can't go spending a ton on a new CPU, MB, RAM, and GPU (and I'd need a
less hacked case too :)
Granted I could get an i3, cheap the MB and RAM, but I've worked so hard
for a great platform... 32GB RAM, 6 core Phenom II, HD 7780 GPU, RAID 5
on 2TB HDs, Bluray drive, Mechanical keyboard, HP laser printer,
4800x4800dpi HP scanner...
AMD is normally so good at compatibility too.
Ok, I'm over it, what is doable at this point?

> Headless boards are supported just fine and have been
> for years.  If you prefer packaged drivers, you can download the ROCm
> stack from gpuopen or the pro stack from amd.com.  All stacks build on
> the same open source kernel driver and other components.
> 
> Alex
> 

Good to know!



[1] No offence, but AMD's gpu-pro would not allow the system to suspend
(sleep), also I'd often get a black and white set of vertical lines
through my display and the kernel would totally freeze (no sysreq). The
worst part is that it would happen totally randomly (really).


pgpC9tW4Qzisx.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Planned Vega support in Linux

[David Niklas]

BTW: I'm on list, no need to CC.

On Wed, 9 Aug 2017 10:38:23 +0900
Michel Dänzer  wrote:

> On 09/08/17 05:12 AM, David Niklas wrote:
> > I know that currently some form of headless support already exists,
> > but then I'd have to use crossfire (which does not work with the
> > opensource driver AFAIK).  
> 
> You don't need CrossFire to make use of a GPU in a headless fashion.

No, but you do if you intend to use your primary desktop machine and Vega
supports only headless, or as Harry pointed out, a display driver (which,
I am assuming means 2D only).
Besides, and as a side thought, I have had the temptation of using two
GPUs for compute tasks since it's just silly to toss/sell a GPU that
could be useful and is worth more to me than it's online value in dollars
(I have to choose the only GPU that actually goes *down* in price)

> OpenCL should support that out of the box, and in X the GPU can be used
> for OpenGL apps via RandR 1.4 render offloading (obviously, you'll need
> another GPU in the system that X can use for output).
> 

You've lost me.
Let my try to understand, and you correct me as I go astray.
1. X can send the OpenGL requests to another GPU while Vega does other
things or idles mindlessly in headless mode.
2. X can send the OpenGL requests to the Vega GPU while the other GPU
sends frames to the display from Vega.

Also, do I need to configure X using RandR, or will it "just work" ...
Stupid question, let me rephrase:
What do I need to do to tell RandR to get X to work?

Thanks,
David


pgp2T8CKe25tb.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Planned Vega support in Linux

[Michel Dänzer]

On 09/08/17 05:12 AM, David Niklas wrote:
> I know that currently some form of headless support already exists, but
> then I'd have to use crossfire (which does not work with the opensource
> driver AFAIK).

You don't need CrossFire to make use of a GPU in a headless fashion.
OpenCL should support that out of the box, and in X the GPU can be used
for OpenGL apps via RandR 1.4 render offloading (obviously, you'll need
another GPU in the system that X can use for output).


-- 
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

[Bug 91375] [radeonsi] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_restrict_performance_levels_before_switch failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91375

--- Comment #11 from Alex Perez  ---
I also get the same message with 4.13.0-rc3

-- 
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 91375] [radeonsi] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_restrict_performance_levels_before_switch failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91375

--- Comment #10 from Alex Perez  ---
I also get the "[drm:.si_dpm_set_power_state] *ERROR*
si_restrict_performance_levels_before_switch failed"

...with 4.12.4, on Big Endian based powerpc64 machine (debian sid userland)

-- 
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] drm: make DRM_STM default n

[Michał Mirosław]

Default config value for all other drivers is N.

Signed-off-by: Michał Mirosław 
---
 drivers/gpu/drm/stm/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig
index 4b88223f9aed..5071df28532f 100644
--- a/drivers/gpu/drm/stm/Kconfig
+++ b/drivers/gpu/drm/stm/Kconfig
@@ -7,7 +7,6 @@ config DRM_STM
select DRM_PANEL_BRIDGE
select VIDEOMODE_HELPERS
select FB_PROVIDE_GET_FB_UNMAPPED_AREA
-   default y
 
help
  Enable support for the on-chip display controller on
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND PATCH] staging: vboxvideo: remove dead gamma lut code

[Peter Rosin]

On 2017-08-07 11:21, Daniel Vetter wrote:
> On Fri, Aug 04, 2017 at 12:45:06PM +0200, Peter Rosin wrote:
>> The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
>> no longer used. Remove the dead code that was not doing anything
>> sensible anyway.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  drivers/staging/vboxvideo/vbox_fb.c   | 15 ---
>>  drivers/staging/vboxvideo/vbox_mode.c |  5 -
>>  2 files changed, 20 deletions(-)
>>
>> [This time with an improved Cc list, sorry for the noise. For new
>>  people, please refer to https://lkml.org/lkml/2017/7/13/593 for
>>  context]
>>
>> Hi Daniel,
>>
>> Here it goes, but do you really need me to resend v5 14/14?
> 
> Well it's not yet on dri-devel, but our pre-merge CI bots can't read such
> instructions. They expect a clean new series that applies cleanly, as a
> top-post, when resending stuff.

Ok, noted for the next time. These things seem to vary from subsystem to
subsystem, so it's not trivial to get it right w/o investing serious time
looking things up. Anyway, sorry about the trouble.

> Anyway, applied.

Thanks!

Cheers,
Peter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".

[Dave Airlie]

On 9 August 2017 at 09:42, Joe Kniss  wrote:
> Because all drivers currently use gem objects for framebuffer planes,
> the virtual create_handle() is not required.  This change adds a
> struct drm_gem_object *gems[4] field to drm_framebuffer and removes
> create_handle() function pointer from drm_framebuffer_funcs.  The
> corresponding *_create_handle() function is removed from each driver.
>
> In many cases this change eliminates a struct *_framebuffer object,
> as the only need for the derived struct is the addition of the gem
> object pointer.

Why the libdrm in the tag? this isn't for libdrm.

This will break drivers that don't current implement the virtual at all.

I think vwmgfx.

The current code checks if the virtual is there before callng it, this code
just calls the gem code always.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101325

--- Comment #21 from Matt  ---
Can confirm this bug on multiple cards / drivers / kernels / Mesa versions
starting with Unreal 4.15.

Radeon 7870
Radeon R7 360
Radeon R9 380 (Using amdgpu)

with anything greater than Mesa 17. Mesa 13 works fine. 

Here's a recent dmesg from a box running Fedora 26 / 4.11 / Mesa 17.07 and a
Radeon 7870.

[  215.746258] WARNING: CPU: 1 PID: 2239 at
drivers/gpu/drm/radeon/radeon_object.c:84 radeon_ttm_bo_destroy+0xf6/0x100
[radeon]
[  215.746258] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables sunrpc
intel_rapl snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal
snd_hda_codec_hdmi intel_powerclamp snd_hda_intel snd_hda_codec coretemp
mei_wdt iTCO_wdt iTCO_vendor_support ppdev kvm snd_hda_core snd_hwdep irqbypass
snd_seq intel_cstate snd_seq_device snd_pcm mei_me intel_uncore snd_timer xpad
intel_rapl_perf joydev snd ff_memless mei lpc_ich i2c_i801 soundcore
[  215.746278]  parport_pc tpm_infineon ie31200_edac shpchp parport edac_core
tpm_tis tpm_tis_core video tpm dm_crypt amdkfd amd_iommu_v2 radeon
crct10dif_pclmul i2c_algo_bit crc32_pclmul drm_kms_helper crc32c_intel ttm
ghash_clmulni_intel drm r8169 ata_generic pata_acpi uas mii usb_storage
[  215.746286] CPU: 1 PID: 2239 Comm: UdpMess-eceiver Tainted: GW  
4.11.11-300.fc26.x86_64 #1
[  215.746286] Hardware name: Gigabyte Technology Co., Ltd. To be filled by
O.E.M./B75M-D3H, BIOS F14 04/17/2013
[  215.746287] Call Trace:
[  215.746288]  dump_stack+0x63/0x84
[  215.746289]  __warn+0xcb/0xf0
[  215.746290]  warn_slowpath_null+0x1d/0x20
[  215.746302]  radeon_ttm_bo_destroy+0xf6/0x100 [radeon]
[  215.746304]  ttm_bo_release_list+0xdb/0x200 [ttm]
[  215.746306]  ? ttm_bo_man_put_node+0x3f/0x50 [ttm]
[  215.746308]  ttm_bo_release+0x190/0x200 [ttm]
[  215.746310]  ttm_bo_unref+0x2c/0x30 [ttm]
[  215.746317]  radeon_bo_unref+0x39/0x70 [radeon]
[  215.746326]  radeon_gem_object_free+0x57/0x70 [radeon]
[  215.746330]  drm_gem_object_free+0x29/0x70 [drm]
[  215.746336]  drm_gem_object_unreference_unlocked+0x3a/0x70 [drm]
[  215.746341]  drm_gem_dmabuf_release+0x17/0x30 [drm]
[  215.746342]  dma_buf_release+0x58/0x1a0
[  215.746343]  __fput+0xdf/0x1e0
[  215.746345]  fput+0xe/0x10
[  215.746346]  task_work_run+0x76/0x90
[  215.746347]  do_exit+0x2e9/0xb90
[  215.746348]  do_group_exit+0x47/0xb0
[  215.746349]  get_signal+0x29f/0x640
[  215.746351]  do_signal+0x37/0x6a0
[  215.746352]  ? __check_object_size+0xbb/0x1b3
[  215.746354]  ? _copy_to_user+0x51/0x60
[  215.746355]  ? poll_select_copy_remaining+0xd6/0x140
[  215.746357]  exit_to_usermode_loop+0x76/0xb0
[  215.746358]  syscall_return_slowpath+0xa6/0xb0
[  215.746359]  entry_SYSCALL_64_fastpath+0xa7/0xa9
[  215.746360] RIP: 0033:0x7f0253686cd3
[  215.746360] RSP: 002b:7f014c084970 EFLAGS: 0293 ORIG_RAX:
0017
[  215.746361] RAX: fdfe RBX: 7f01942e2d80 RCX:
7f0253686cd3
[  215.746361] RDX:  RSI: 7f014c084998 RDI:
00dd
[  215.746362] RBP:  R08: 7f014c084988 R09:

[  215.746362] R10:  R11: 0293 R12:
7f0193d8ec00
[  215.746363] R13: 7ffdc4b94320 R14: 000f4240 R15:

[  215.746364] ---[ end trace 4a4848a1b1423a31 ]---

I'm unfamiliar with using apitrace, but if someone can give me proper reporting
instructions I can reproduce this bug on a wide range of hardware / software if
it would be helpful.

-- 
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 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101977

--- Comment #17 from Dave Airlie  ---
Enabling the UE4 linker script fixes this also. (It got disabled for 4.17).

It appears that versions the symbols on the UE side.

-- 
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 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101977

--- Comment #16 from Timothee Besset  ---
Thanks for the help and thorough investigation! I will follow up from there
with Epic to get this addressed UE4 side.

-- 
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] drm/exynos: forbid creating framebuffers from too small GEM buffers

[Inki Dae]

2017년 08월 08일 22:33에 Marek Szyprowski 이(가) 쓴 글:
> Hi all,
> 
> On 2017-07-12 12:09, Marek Szyprowski wrote:
>> Add a check if the framebuffer described by the provided drm_mode_fb_cmd2
>> structure fits into provided GEM buffers. Without this check it is
>> possible to create a framebuffer object from a small buffer and set it to
>> the hardware, what results in displaying system memory outside the
>> allocated GEM buffer.
>>
>> Signed-off-by: Marek Szyprowski 
>> CC: sta...@vger.kernel.org # v4.7+
> 
> Gentle ping.

Applied.

Thanks,
Inki Dae

> 
>> ---
>> This issue was there from the beggining, but the provided patch applies only
>> to v4.7+ kernels due to other changes in the fixed code.
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_fb.c | 14 +-
>>   1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> index d48fd7c918f8..73217c281c9a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> @@ -145,13 +145,19 @@ struct drm_framebuffer *
>>   exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
>> const struct drm_mode_fb_cmd2 *mode_cmd)
>>   {
>> +const struct drm_format_info *info = drm_get_format_info(dev, mode_cmd);
>>   struct exynos_drm_gem *exynos_gem[MAX_FB_BUFFER];
>>   struct drm_gem_object *obj;
>>   struct drm_framebuffer *fb;
>>   int i;
>>   int ret;
>>   -for (i = 0; i < drm_format_num_planes(mode_cmd->pixel_format); i++) {
>> +for (i = 0; i < info->num_planes; i++) {
>> +unsigned int height = (i == 0) ? mode_cmd->height :
>> + DIV_ROUND_UP(mode_cmd->height, info->vsub);
>> +unsigned long size = height * mode_cmd->pitches[i] +
>> + mode_cmd->offsets[i];
>> +
>>   obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
>>   if (!obj) {
>>   DRM_ERROR("failed to lookup gem object\n");
>> @@ -160,6 +166,12 @@ struct drm_framebuffer *
>>   }
>> exynos_gem[i] = to_exynos_gem(obj);
>> +
>> +if (size > exynos_gem[i]->size) {
>> +i++;
>> +ret = -EINVAL;
>> +goto err;
>> +}
>>   }
>> fb = exynos_drm_framebuffer_init(dev, mode_cmd, exynos_gem, i);
> 
> Best regards
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101977

Marek Olšák  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #15 from Marek Olšák  ---
Interesting. So it's a UE4 bug after all. If UE4 didn't export its own libelf
functions, it would work.

When the driver is loaded, the dynamic linker loads libelf, but since UE4
exports the same function names as libelf does, libelf functions are not loaded
at all and the functions from UE4 are exposed to the driver instead. The
driver, thinking it's calling libelf, is actually invoking the UE4 functions of
the same name.

A temporary workaround is to load the system libelf first by doing:

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libelf.so ./UE4Editor

It will have the opposite effect. UE4 will use system libelf instead of its
own, because the symbols conflict and the system one is loaded first.

This bug should be fixed in UE4 though.

I'm closing this bug, because there is nothing Mesa can do here.

-- 
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 6/9] dma-buf/dma-fence: Allow wait_any_timeout without default_wait

[Jason Ekstrand]

dma_fence_wait_any_timeout only relies on two things to work correctly:

 1) The SIGNALED flag to be set upon fence signal
 2) The callback list to get called upon fence signal

Both of these are part of the core dma-fence API so it should work fine
even with a non-default wait function.

Signed-off-by: Jason Ekstrand 
---
 drivers/dma-buf/dma-fence.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 57da14c..1218692 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -501,11 +501,6 @@ dma_fence_wait_any_timeout(struct dma_fence **fences, 
uint32_t count,
for (i = 0; i < count; ++i) {
struct dma_fence *fence = fences[i];
 
-   if (fence->ops->wait != dma_fence_default_wait) {
-   ret = -EINVAL;
-   goto fence_rm_cb;
-   }
-
cb[i].task = current;
if (dma_fence_add_callback(fence, [i].base,
   dma_fence_default_wait_cb)) {
-- 
2.5.0.400.gff86faf

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 8/9] drm/syncobj: Add a callback mechanism for replace_fence

[Jason Ekstrand]

It is useful in certain circumstances to know when the fence is replaced
in a syncobj.  Specifically, it may be useful to know when the fence
goes from NULL to something valid.  This does make syncobj_replace_fence
a little more expensive because it has to take a lock but, in the common
case where there is no callback list, it spends a very short amount of
time inside the lock.

Signed-off-by: Jason Ekstrand 
---
 drivers/gpu/drm/drm_syncobj.c | 51 ++-
 include/drm/drm_syncobj.h | 33 +++-
 2 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 25807f5..510dfc2 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -96,6 +96,46 @@ struct dma_fence *drm_syncobj_fence_get(struct drm_syncobj 
*syncobj)
 }
 EXPORT_SYMBOL(drm_syncobj_fence_get);
 
+static void drm_syncobj_add_callback_locked(struct drm_syncobj *syncobj,
+   struct drm_syncobj_cb *cb,
+   drm_syncobj_func_t func)
+{
+   cb->func = func;
+   list_add_tail(>node, >cb_list);
+}
+
+/**
+ * drm_syncobj_add_callback - adds a callback to syncobj::cb_list
+ * @syncobj: Sync object to which to add the callback
+ * @cb: Callback to add
+ * @func: Func to use when initializing the drm_syncobj_cb struct
+ *
+ * This adds a callback to be called next time the fence is replaced
+ */
+void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
+ struct drm_syncobj_cb *cb,
+ drm_syncobj_func_t func)
+{
+   spin_lock(>lock);
+   drm_syncobj_add_callback_locked(syncobj, cb, func);
+   spin_unlock(>lock);
+}
+EXPORT_SYMBOL(drm_syncobj_add_callback);
+
+/**
+ * drm_syncobj_add_callback - removes a callback to syncobj::cb_list
+ * @syncobj: Sync object from which to remove the callback
+ * @cb: Callback to remove
+ */
+void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
+struct drm_syncobj_cb *cb)
+{
+   spin_lock(>lock);
+   list_del_init(>node);
+   spin_unlock(>lock);
+}
+EXPORT_SYMBOL(drm_syncobj_remove_callback);
+
 /**
  * drm_syncobj_replace_fence - replace fence in a sync object.
  * @file_private: drm file private pointer.
@@ -108,13 +148,21 @@ void drm_syncobj_replace_fence(struct drm_syncobj 
*syncobj,
   struct dma_fence *fence)
 {
struct dma_fence *old_fence = NULL;
+   struct drm_syncobj_cb *cur, *tmp;
 
if (fence)
dma_fence_get(fence);
 
spin_lock(>lock);
+
old_fence = syncobj->fence;
syncobj->fence = fence;
+
+   list_for_each_entry_safe(cur, tmp, >cb_list, node) {
+   list_del_init(>node);
+   cur->func(syncobj, cur);
+   }
+
spin_unlock(>lock);
 
dma_fence_put(old_fence);
@@ -151,7 +199,7 @@ void drm_syncobj_free(struct kref *kref)
struct drm_syncobj *syncobj = container_of(kref,
   struct drm_syncobj,
   refcount);
-   dma_fence_put(syncobj->fence);
+   drm_syncobj_replace_fence(syncobj, NULL);
kfree(syncobj);
 }
 EXPORT_SYMBOL(drm_syncobj_free);
@@ -167,6 +215,7 @@ static int drm_syncobj_create(struct drm_file *file_private,
return -ENOMEM;
 
kref_init(>refcount);
+   INIT_LIST_HEAD(>cb_list);
spin_lock_init(>lock);
 
idr_preload(GFP_KERNEL);
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 1c81658..a81af76 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -28,6 +28,8 @@
 
 #include "linux/dma-fence.h"
 
+struct drm_syncobj_cb;
+
 /**
  * struct drm_syncobj - sync object.
  *
@@ -46,8 +48,13 @@ struct drm_syncobj {
 */
struct dma_fence *fence;
/**
+* @list
+* List of callbaks to call when the fence gets replaced
+*/
+   struct list_head cb_list;
+   /**
 * @spinlock:
-* locks fence.
+* locks fence and cb_list.
 */
spinlock_t lock;
/**
@@ -57,6 +64,25 @@ struct drm_syncobj {
struct file *file;
 };
 
+typedef void (*drm_syncobj_func_t)(struct drm_syncobj *syncobj,
+  struct drm_syncobj_cb *cb);
+
+/**
+ * struct drm_syncobj_cb - callback for drm_syncobj_add_callback
+ * @node: used by drm_syncob_add_callback to append this struct to
+ *   syncobj::cb_list
+ * @func: drm_syncobj_func_t to call
+ *
+ * This struct will be initialized by drm_syncobj_add_callback, additional
+ * data can be passed along by embedding drm_syncobj_cb in another struct.
+ * The callback will get called the next time drm_syncobj_replace_fence is
+ * called.
+ */
+struct drm_syncobj_cb {
+ 

[PATCH 7/9] drm/syncobj: Add a reset ioctl

[Jason Ekstrand]

This just resets the dma_fence to NULL so it looks like it's never been
signaled.  This will be useful once we add the new wait API for allowing
wait on "submit and signal" behavior.

Signed-off-by: Jason Ekstrand 
---
 drivers/gpu/drm/drm_internal.h |  2 ++
 drivers/gpu/drm/drm_ioctl.c|  2 ++
 drivers/gpu/drm/drm_syncobj.c  | 24 
 include/uapi/drm/drm.h |  6 ++
 4 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index f3c4e57..6e8bc4d 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -165,3 +165,5 @@ int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
   struct drm_file *file_private);
 int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_private);
+int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file_private);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 310f3ec..1acf6ac 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -659,6 +659,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET, drm_syncobj_reset_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 2f14e38..25807f5 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -613,3 +613,27 @@ drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
 
return ret;
 }
+
+int
+drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file_private)
+{
+   struct drm_syncobj_reset *args = data;
+   struct drm_syncobj *syncobj;
+
+   if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   return -ENODEV;
+
+   if (args->flags != 0)
+   return -EINVAL;
+
+   syncobj = drm_syncobj_find(file_private, args->handle);
+   if (!syncobj)
+   return -ENOENT;
+
+   drm_syncobj_replace_fence(syncobj, NULL);
+
+   drm_syncobj_put(syncobj);
+
+   return 0;
+}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 0757c1a..4b301b4 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -729,6 +729,11 @@ struct drm_syncobj_wait {
__u32 pad;
 };
 
+struct drm_syncobj_reset {
+   __u32 handle;
+   __u32 flags;
+};
+
 #if defined(__cplusplus)
 }
 #endif
@@ -852,6 +857,7 @@ extern "C" {
 #define DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD DRM_IOWR(0xC1, struct 
drm_syncobj_handle)
 #define DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE DRM_IOWR(0xC2, struct 
drm_syncobj_handle)
 #define DRM_IOCTL_SYNCOBJ_WAIT DRM_IOWR(0xC3, struct drm_syncobj_wait)
+#define DRM_IOCTL_SYNCOBJ_RESETDRM_IOWR(0xC4, struct 
drm_syncobj_reset)
 
 /**
  * Device specific ioctls should only be in their respective headers
-- 
2.5.0.400.gff86faf

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 9/9] drm/syncobj: Allow wait for submit and signal behavior

[Jason Ekstrand]

Vulkan VkFence semantics require that the application be able to perform
a CPU wait on work which may not yet have been submitted.  This is
perfectly safe because the CPU wait has a timeout which will get
triggered eventually if no work is ever submitted.  This behavior is
advantageous for multi-threaded workloads because, so long as all of the
threads agree on what fences to use up-front, you don't have the extra
cross-thread synchronization cost of thread A telling thread B that it
has submitted its dependent work and thread B is now free to wait.

Within a single process, this can be implemented in the userspace driver
by doing exactly the same kind of tracking the app would have to do
using posix condition variables or similar.  However, in order for this
to work cross-process (as is required by VK_KHR_external_fence), we need
to handle this in the kernel.

This commit adds a WAIT_FOR_SUBMIT flag to DRM_IOCTL_SYNCOBJ_WAIT which
instructs the IOCTL to wait for the syncobj to have a non-null fence and
then wait on the fence.  Combined with DRM_IOCTL_SYNCOBJ_RESET, you can
easily get the Vulkan behavior.

Signed-off-by: Jason Ekstrand 
---
 drivers/gpu/drm/drm_syncobj.c | 319 ++
 include/uapi/drm/drm.h|   1 +
 2 files changed, 293 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 510dfc2..ecfc43b 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_internal.h"
 #include 
@@ -104,6 +105,27 @@ static void drm_syncobj_add_callback_locked(struct 
drm_syncobj *syncobj,
list_add_tail(>node, >cb_list);
 }
 
+static int drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
+struct dma_fence **fence,
+struct drm_syncobj_cb *cb,
+drm_syncobj_func_t func)
+{
+   int ret;
+
+   spin_lock(>lock);
+   if (syncobj->fence) {
+   *fence = dma_fence_get(syncobj->fence);
+   ret = 1;
+   } else {
+   *fence = NULL;
+   drm_syncobj_add_callback_locked(syncobj, cb, func);
+   ret = 0;
+   }
+   spin_unlock(>lock);
+
+   return ret;
+}
+
 /**
  * drm_syncobj_add_callback - adds a callback to syncobj::cb_list
  * @syncobj: Sync object to which to add the callback
@@ -526,6 +548,255 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
>handle);
 }
 
+static int drm_syncobj_signaled(struct drm_syncobj *syncobj,
+   uint32_t wait_flags)
+{
+   struct dma_fence *fence;
+   int ret;
+
+   fence = drm_syncobj_fence_get(syncobj);
+   if (!fence) {
+   if (wait_flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT)
+   return 0;
+   else
+   return -EINVAL;
+   }
+
+   ret = dma_fence_is_signaled(fence) ? 1 : 0;
+
+   dma_fence_put(fence);
+
+   return ret;
+}
+
+struct syncobj_get_wait_cb {
+   struct drm_syncobj_cb base;
+   struct task_struct *task;
+   struct dma_fence **fence;
+};
+
+static void syncobj_get_wait_cb_func(struct drm_syncobj *syncobj,
+struct drm_syncobj_cb *wait_cb)
+{
+   struct syncobj_get_wait_cb *wait =
+   container_of(wait_cb, struct syncobj_get_wait_cb, base);
+
+   /* This happens inside the syncobj lock */
+   *wait->fence = dma_fence_get(syncobj->fence);
+   wake_up_process(wait->task);
+}
+
+static signed long
+drm_syncobj_get_fence_wait_timeout(struct drm_syncobj *syncobj,
+  struct dma_fence **fence,
+  signed long timeout)
+{
+   struct syncobj_get_wait_cb cb;
+   signed long ret;
+
+   if (timeout == 0) {
+   *fence = drm_syncobj_fence_get(syncobj);
+   if (*fence)
+   return 1;
+   return 0;
+   }
+
+   cb.task = current;
+   cb.fence = fence;
+
+   if (drm_syncobj_fence_get_or_add_callback(syncobj, fence, ,
+ syncobj_get_wait_cb_func)) {
+   /* We got the fence immediately. No callback was installed. */
+   return timeout;
+   }
+
+   ret = timeout;
+   while (ret > 0) {
+   set_current_state(TASK_INTERRUPTIBLE);
+
+   if (*fence)
+   break;
+
+   ret = schedule_timeout(ret);
+
+   if (ret > 0 && signal_pending(current))
+   ret = -ERESTARTSYS;
+   }
+
+   __set_current_state(TASK_RUNNING);
+
+   drm_syncobj_remove_callback(syncobj, );
+
+   

[PATCH 3/9] drm/syncobj: Remove file_private from replace_fence

[Jason Ekstrand]

It's completely unused.

Signed-off-by: Jason Ekstrand 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +--
 drivers/gpu/drm/drm_syncobj.c  | 5 ++---
 include/drm/drm_syncobj.h  | 3 +--
 3 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 0aa33ae..3314702 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1070,8 +1070,7 @@ static void amdgpu_cs_post_dependencies(struct 
amdgpu_cs_parser *p)
int i;
 
for (i = 0; i < p->num_post_dep_syncobjs; ++i) {
-   drm_syncobj_replace_fence(p->filp, p->post_dep_syncobjs[i],
- p->fence);
+   drm_syncobj_replace_fence(p->post_dep_syncobjs[i], p->fence);
}
 }
 
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index dafca83..7fdf7e8 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -99,8 +99,7 @@ EXPORT_SYMBOL(drm_syncobj_fence_get);
  *
  * This replaces the fence on a sync object.
  */
-void drm_syncobj_replace_fence(struct drm_file *file_private,
-  struct drm_syncobj *syncobj,
+void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
   struct dma_fence *fence)
 {
struct dma_fence *old_fence = NULL;
@@ -313,7 +312,7 @@ int drm_syncobj_import_sync_file_fence(struct drm_file 
*file_private,
return -ENOENT;
}
 
-   drm_syncobj_replace_fence(file_private, syncobj, fence);
+   drm_syncobj_replace_fence(syncobj, fence);
dma_fence_put(fence);
drm_syncobj_put(syncobj);
return 0;
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 422d631..1c81658 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -85,8 +85,7 @@ drm_syncobj_put(struct drm_syncobj *obj)
 struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
 u32 handle);
 struct dma_fence *drm_syncobj_fence_get(struct drm_syncobj *syncobj);
-void drm_syncobj_replace_fence(struct drm_file *file_private,
-  struct drm_syncobj *syncobj,
+void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
   struct dma_fence *fence);
 int drm_syncobj_find_fence(struct drm_file *file_private,
   u32 handle,
-- 
2.5.0.400.gff86faf

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/9] drm/syncobj: add sync obj wait interface. (v8)

[Jason Ekstrand]

From: Dave Airlie 

This interface will allow sync object to be used to back
Vulkan fences. This API is pretty much the vulkan fence waiting
API, and I've ported the code from amdgpu.

v2: accept relative timeout, pass remaining time back
to userspace.
v3: return to absolute timeouts.
v4: absolute zero = poll,
rewrite any/all code to have same operation for arrays
return -EINVAL for 0 fences.
v4.1: fixup fences allocation check, use u64_to_user_ptr
v5: move to sec/nsec, and use timespec64 for calcs.
v6: use -ETIME and drop the out status flag. (-ETIME
is suggested by ickle, I can feel a shed painting)
v7: talked to Daniel/Arnd, use ktime and ns everywhere.
v8: be more careful in the timeout calculations
use uint32_t for counter variables so we don't overflow
graciously handle -ENOINT being returned from dma_fence_wait_timeout

Signed-off-by: Dave Airlie 
Reviewed-by: Jason Ekstrand 
---
 drivers/gpu/drm/drm_internal.h |   2 +
 drivers/gpu/drm/drm_ioctl.c|   2 +
 drivers/gpu/drm/drm_syncobj.c  | 142 +
 include/uapi/drm/drm.h |  12 
 4 files changed, 158 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 068b685..f3c4e57 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -163,3 +163,5 @@ int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
   struct drm_file *file_private);
 int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_private);
+int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f7f150e..310f3ec 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
drm_syncobj_fd_to_handle_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 7fdf7e8..2f14e38 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1,5 +1,7 @@
 /*
  * Copyright 2017 Red Hat
+ * Parts ported from amdgpu (fence wait code).
+ * Copyright 2016 Advanced Micro Devices, Inc.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
@@ -31,6 +33,9 @@
  * that contain an optional fence. The fence can be updated with a new
  * fence, or be NULL.
  *
+ * syncobj's can be waited upon, where it will wait for the underlying
+ * fence.
+ *
  * syncobj's can be export to fd's and back, these fd's are opaque and
  * have no other use case, except passing the syncobj between processes.
  *
@@ -471,3 +476,140 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
return drm_syncobj_fd_to_handle(file_private, args->fd,
>handle);
 }
+
+/**
+ * drm_timeout_abs_to_jiffies - calculate jiffies timeout from absolute value
+ *
+ * @timeout_nsec: timeout nsec component in ns, 0 for poll
+ *
+ * Calculate the timeout in jiffies from an absolute time in sec/nsec.
+ */
+static signed long drm_timeout_abs_to_jiffies(int64_t timeout_nsec)
+{
+   ktime_t abs_timeout, now;
+   u64 timeout_ns, timeout_jiffies64;
+
+   /* make 0 timeout means poll - absolute 0 doesn't seem valid */
+   if (timeout_nsec == 0)
+   return 0;
+
+   abs_timeout = ns_to_ktime(timeout_nsec);
+   now = ktime_get();
+
+   if (!ktime_after(abs_timeout, now))
+   return 0;
+
+   timeout_ns = ktime_to_ns(ktime_sub(abs_timeout, now));
+
+   timeout_jiffies64 = nsecs_to_jiffies64(timeout_ns);
+   /*  clamp timeout to avoid infinite timeout */
+   if (timeout_jiffies64 >= MAX_SCHEDULE_TIMEOUT - 1)
+   return MAX_SCHEDULE_TIMEOUT - 1;
+
+   return timeout_jiffies64 + 1;
+}
+
+static int drm_syncobj_wait_fences(struct drm_device *dev,
+  struct drm_file *file_private,
+  struct drm_syncobj_wait *wait,
+  struct dma_fence **fences)
+{
+   signed long timeout = drm_timeout_abs_to_jiffies(wait->timeout_nsec);
+   signed long ret = 0;
+   uint32_t first = ~0;
+
+   if (wait->flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL) {
+   uint32_t i;
+   for (i = 0; i < 

[PATCH 4/9] i915: Add support for drm syncobjs

[Jason Ekstrand]

This commit adds support for waiting on or signaling DRM syncobjs as
part of execbuf.  It does so by hijacking the currently unused cliprects
pointer to instead point to an array of i915_gem_exec_fence structs
which containe a DRM syncobj and a flags parameter which specifies
whether to wait on it or to signal it.  This implementation
theoretically allows for both flags to be set in which case it waits on
the dma_fence that was in the syncobj and then immediately replaces it
with the dma_fence from the current execbuf.

v2:
 - Rebase on new syncobj API
v3:
 - Pull everything out into helpers
 - Do all allocation in gem_execbuffer2
 - Pack the flags in the bottom 2 bits of the drm_syncobj*
v4:
 - Prevent a potential race on syncobj->fence

Testcase: igt/gem_exec_fence/syncobj*
Signed-off-by: Jason Ekstrand 
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c|   3 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 146 -
 include/uapi/drm/i915_drm.h|  30 +-
 3 files changed, 171 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6a22f0e..f8f3d45 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -384,6 +384,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_FENCE:
case I915_PARAM_HAS_EXEC_CAPTURE:
case I915_PARAM_HAS_EXEC_BATCH_FIRST:
+   case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
/* For the time being all of these are always true;
 * if some supported hardware does not have one of these
 * features this value needs to be provided from
@@ -2733,7 +2734,7 @@ static struct drm_driver driver = {
 */
.driver_features =
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
-   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC,
+   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_SYNCOBJ,
.release = i915_driver_release,
.open = i915_driver_open,
.lastclose = i915_driver_lastclose,
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 26eedb1..936fb0b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -33,6 +33,7 @@
 
 #include 
 #include 
+#include 
 
 #include "i915_drv.h"
 #include "i915_gem_clflush.h"
@@ -1800,8 +1801,10 @@ static bool i915_gem_check_execbuffer(struct 
drm_i915_gem_execbuffer2 *exec)
return false;
 
/* Kernel clipping was a DRI1 misfeature */
-   if (exec->num_cliprects || exec->cliprects_ptr)
-   return false;
+   if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
+   if (exec->num_cliprects || exec->cliprects_ptr)
+   return false;
+   }
 
if (exec->DR4 == 0x) {
DRM_DEBUG("UXA submitting garbage DR4, fixing up\n");
@@ -2029,11 +2032,125 @@ eb_select_engine(struct drm_i915_private *dev_priv,
return engine;
 }
 
+static void __free_fence_array(struct drm_syncobj **fences, unsigned int n)
+{
+   while (n--)
+   drm_syncobj_put(ptr_mask_bits(fences[n], 2));
+   kvfree(fences);
+}
+
+static struct drm_syncobj **get_fence_array(struct drm_i915_gem_execbuffer2 
*args,
+   struct drm_file *file)
+{
+   const unsigned int nfences = args->num_cliprects;
+   struct drm_i915_gem_exec_fence __user *user;
+   struct drm_syncobj **fences;
+   unsigned int n;
+   int err;
+
+   if (!(args->flags & I915_EXEC_FENCE_ARRAY))
+   return NULL;
+
+   if (nfences > SIZE_MAX / sizeof(*fences))
+   return ERR_PTR(-EINVAL);
+
+   user = u64_to_user_ptr(args->cliprects_ptr);
+   if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
+   return ERR_PTR(-EFAULT);
+
+   fences = kvmalloc_array(args->num_cliprects, sizeof(*fences),
+   __GFP_NOWARN | GFP_TEMPORARY);
+   if (!fences)
+   return ERR_PTR(-ENOMEM);
+
+   for (n = 0; n < nfences; n++) {
+   struct drm_i915_gem_exec_fence fence;
+   struct drm_syncobj *syncobj;
+
+   if (__copy_from_user(, user++, sizeof(fence))) {
+   err = -EFAULT;
+   goto err;
+   }
+
+   syncobj = drm_syncobj_find(file, fence.handle);
+   if (!syncobj) {
+   DRM_DEBUG("Invalid syncobj handle provided\n");
+   err = -EINVAL;
+   goto err;
+   }
+
+   fences[n] = ptr_pack_bits(syncobj, fence.flags, 2);
+   }
+
+   return 

[PATCH 1/9] drm/syncobj: Rename fence_get to find_fence

[Jason Ekstrand]

The function has far more in common with drm_syncobj_find than with
any in the get/put functions.

Signed-off-by: Jason Ekstrand 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  2 +-
 drivers/gpu/drm/drm_syncobj.c  | 10 +-
 include/drm/drm_syncobj.h  |  6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index aeee684..0aa33ae 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -984,7 +984,7 @@ static int amdgpu_syncobj_lookup_and_add_to_sync(struct 
amdgpu_cs_parser *p,
 {
int r;
struct dma_fence *fence;
-   r = drm_syncobj_fence_get(p->filp, handle, );
+   r = drm_syncobj_find_fence(p->filp, handle, );
if (r)
return r;
 
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 89441bc..6f2a6041 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -97,9 +97,9 @@ void drm_syncobj_replace_fence(struct drm_file *file_private,
 }
 EXPORT_SYMBOL(drm_syncobj_replace_fence);
 
-int drm_syncobj_fence_get(struct drm_file *file_private,
- u32 handle,
- struct dma_fence **fence)
+int drm_syncobj_find_fence(struct drm_file *file_private,
+  u32 handle,
+  struct dma_fence **fence)
 {
struct drm_syncobj *syncobj = drm_syncobj_find(file_private, handle);
int ret = 0;
@@ -114,7 +114,7 @@ int drm_syncobj_fence_get(struct drm_file *file_private,
drm_syncobj_put(syncobj);
return ret;
 }
-EXPORT_SYMBOL(drm_syncobj_fence_get);
+EXPORT_SYMBOL(drm_syncobj_find_fence);
 
 /**
  * drm_syncobj_free - free a sync object.
@@ -309,7 +309,7 @@ int drm_syncobj_export_sync_file(struct drm_file 
*file_private,
if (fd < 0)
return fd;
 
-   ret = drm_syncobj_fence_get(file_private, handle, );
+   ret = drm_syncobj_find_fence(file_private, handle, );
if (ret)
goto err_put_fd;
 
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 2c3610a..922 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -82,9 +82,9 @@ struct drm_syncobj *drm_syncobj_find(struct drm_file 
*file_private,
 void drm_syncobj_replace_fence(struct drm_file *file_private,
   struct drm_syncobj *syncobj,
   struct dma_fence *fence);
-int drm_syncobj_fence_get(struct drm_file *file_private,
- u32 handle,
- struct dma_fence **fence);
+int drm_syncobj_find_fence(struct drm_file *file_private,
+  u32 handle,
+  struct dma_fence **fence);
 void drm_syncobj_free(struct kref *kref);
 
 #endif
-- 
2.5.0.400.gff86faf

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/9] drm/syncobj: Lock around drm_syncobj::fence

[Jason Ekstrand]

The atomic exchange operation we were doing before in replace_fence was
sufficient for the case where it raced with itself.  However, if you
have a race between a replace_fence and dma_fence_get(syncobj->fence),
you may end up with the entire replace_fence happening between the point
in time where the one thread gets the syncobj->fence pointer and when it
calls dma_fence_get() on it.  If this happens, then the reference may be
dropped before we get a chance to get a new one.

Signed-off-by: Jason Ekstrand 
---
 drivers/gpu/drm/drm_syncobj.c | 25 +++--
 include/drm/drm_syncobj.h |  6 ++
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 6f2a6041..dafca83 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -75,6 +75,22 @@ struct drm_syncobj *drm_syncobj_find(struct drm_file 
*file_private,
 }
 EXPORT_SYMBOL(drm_syncobj_find);
 
+struct dma_fence *drm_syncobj_fence_get(struct drm_syncobj *syncobj)
+{
+   struct dma_fence *fence;
+
+   /* Lock to prevent someone from replacing the fence and dropping
+* the syncobj's reference between when we get the dma_fence
+* pointer and wehen we have a chance to incref.
+*/
+   spin_lock(>lock);
+   fence = dma_fence_get(syncobj->fence);
+   spin_unlock(>lock);
+
+   return fence;
+}
+EXPORT_SYMBOL(drm_syncobj_fence_get);
+
 /**
  * drm_syncobj_replace_fence - replace fence in a sync object.
  * @file_private: drm file private pointer.
@@ -91,7 +107,11 @@ void drm_syncobj_replace_fence(struct drm_file 
*file_private,
 
if (fence)
dma_fence_get(fence);
-   old_fence = xchg(>fence, fence);
+
+   spin_lock(>lock);
+   old_fence = syncobj->fence;
+   syncobj->fence = fence;
+   spin_unlock(>lock);
 
dma_fence_put(old_fence);
 }
@@ -107,7 +127,7 @@ int drm_syncobj_find_fence(struct drm_file *file_private,
if (!syncobj)
return -ENOENT;
 
-   *fence = dma_fence_get(syncobj->fence);
+   *fence = drm_syncobj_fence_get(syncobj);
if (!*fence) {
ret = -EINVAL;
}
@@ -143,6 +163,7 @@ static int drm_syncobj_create(struct drm_file *file_private,
return -ENOMEM;
 
kref_init(>refcount);
+   spin_lock_init(>lock);
 
idr_preload(GFP_KERNEL);
spin_lock(_private->syncobj_table_lock);
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 922..422d631 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -46,6 +46,11 @@ struct drm_syncobj {
 */
struct dma_fence *fence;
/**
+* @spinlock:
+* locks fence.
+*/
+   spinlock_t lock;
+   /**
 * @file:
 * a file backing for this syncobj.
 */
@@ -79,6 +84,7 @@ drm_syncobj_put(struct drm_syncobj *obj)
 
 struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
 u32 handle);
+struct dma_fence *drm_syncobj_fence_get(struct drm_syncobj *syncobj);
 void drm_syncobj_replace_fence(struct drm_file *file_private,
   struct drm_syncobj *syncobj,
   struct dma_fence *fence);
-- 
2.5.0.400.gff86faf

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/9] drm/syncobj: Add full-featured wait support

[Jason Ekstrand]

This series contains the drm and i915 bits required to implement the
VK_KHR_external_semaphore and VK_KHR_external_fence extensions on top of
DRM sync objects.

Patches 1-3 are cleanups and fixes for the core syncobj APIs.

Patch 4 is the i915 patch that adds support for syncobj in the i915 driver.
I'm re-sending it because I've rebased the latest version on patches 1-3.

Patch 6 is technically not required by the end of the series but is needed
for i915 if we don't have patches 7-9.  I think it's a good and possibly
useful clean-up, but I'm more than willing to drop it in favor of 7-9.

Patch 7 adds a reset ioctl which allows the caller to reset the syncobj by
setting the fence to NULL.  This is needed to implement vkResetFences.

The real meat of the series is patches 8 and 9.  The previous wait
implementation would throw -EINVAL if you ever tried to wait on a syncobj
which did not yet have a dma_fence.  Patch 9 adds a new flag to the syncobj
which makes it so that, if it does not yet have a fence, it first waits for
a fence to show up and then waits on the fence.  This is needed to properly
implement VkWaitForFences behavior.

This series can be found as a branch here:

https://cgit.freedesktop.org/~jekstrand/linux/log/?h=drm-syncobj-wait-submit-v1

Patches to the Intel Vulkan driver to implement VK_KHR_external_fence on
top of this kernel interface can be found here:

https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/anv-external-fence

Cc: Chris Wilson 
Cc: Dave Airlie 

Dave Airlie (1):
  drm/syncobj: add sync obj wait interface. (v8)

Jason Ekstrand (8):
  drm/syncobj: Rename fence_get to find_fence
  drm/syncobj: Lock around drm_syncobj::fence
  drm/syncobj: Remove file_private from replace_fence
  i915: Add support for drm syncobjs
  dma-buf/dma-fence: Allow wait_any_timeout without default_wait
  drm/syncobj: Add a reset ioctl
  drm/syncobj: Add a callback mechanism for replace_fence
  drm/syncobj: Allow wait for submit and signal behavior

 drivers/dma-buf/dma-fence.c|   5 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   5 +-
 drivers/gpu/drm/drm_internal.h |   4 +
 drivers/gpu/drm/drm_ioctl.c|   4 +
 drivers/gpu/drm/drm_syncobj.c  | 522 -
 drivers/gpu/drm/i915/i915_drv.c|   3 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 146 +++-
 include/drm/drm_syncobj.h  |  46 ++-
 include/uapi/drm/drm.h |  19 ++
 include/uapi/drm/i915_drm.h|  30 +-
 10 files changed, 752 insertions(+), 32 deletions(-)

-- 
2.5.0.400.gff86faf

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101977

--- Comment #14 from Dave Airlie  ---
Yup once I hid the libelf symbols, it all works.

-- 
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 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101977

--- Comment #13 from Dave Airlie  ---
llvm seems fine, it seems to be libelf that is broken.

I've noticed UE4 exports it's own libelf symbols but I haven't determined that
is the problem yet.

-- 
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 97861] [amdgpu SI] purple line is visible on left side of the screen connected by HDMI

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97861

--- Comment #11 from Alex Deucher  ---
Is this still an issue with a newer kernel?  Audio support was added to SI
recently.

-- 
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: Planned Vega support in Linux

[Kai Wasserbäch]

Hey Harry,
Harry Wentland wrote on 08.08.2017 22:25:
> upstream kernels currently have only headless support. We're still
> working on getting our display driver accepted upstream but in the
> meantime you can compile it yourself from
> https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-4.12. With this
> you should have no issues booting to desktop with whatever displays you got.

can you or somebody else from AMD expand on what is – from your point of view –
missing before you can start upstreaming DAL/DC/display? If possible with a
rough time-frame.
Is there a page with a list of outstanding tasks? Maybe even low-hanging fruit
for new contributors (particularly tasks you haven't started internally so
there's no unnecessary overlap)?

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101977

--- Comment #12 from Marek Olšák  ---
.AMDGPU.config coming from LLVM is empty with UE4Editor. This assertion fails:

diff --git a/src/amd/common/ac_binary.c b/src/amd/common/ac_binary.c
index 618b5cf..2fbb575 100644
--- a/src/amd/common/ac_binary.c
+++ b/src/amd/common/ac_binary.c
@@ -148,6 +148,7 @@ void ac_elf_read(const char *elf_data, unsigned elf_size,
} else if (!strcmp(name, ".AMDGPU.config")) {
section_data = elf_getdata(section, section_data);
binary->config_size = section_data->d_size;
+   assert(binary->config_size);
binary->config = MALLOC(binary->config_size *
sizeof(unsigned char));
memcpy(binary->config, section_data->d_buf,
binary->config_size);
} else if (!strcmp(name, ".AMDGPU.disasm")) {

Any ideas?

-- 
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: Planned Vega support in Linux

[Harry Wentland]

Hi David,

upstream kernels currently have only headless support. We're still
working on getting our display driver accepted upstream but in the
meantime you can compile it yourself from
https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-4.12. With this
you should have no issues booting to desktop with whatever displays you got.

As for the rest of our driver Alex can probably give you a better
picture but I imagine pretty much everything should be working on Vega
on that tree.

Harry


On 2017-08-08 04:12 PM, David Niklas wrote:
> Hello,
> I'm not seeking any secret info.
> I'm a Gentoo Linux user who wants to run some massively parallel
> experiments.
> I'm unwilling to wait and see what kind of support Linux gets because
> the annoying bitcoin miners tend to cause the price to go through the roof
> quickly.
> My current card is an AMD SI HD7780 by MSI.
> I know that currently some form of headless support already exists, but
> then I'd have to use crossfire (which does not work with the opensource
> driver AFAIK).
> I filed a ticket at AMD on 05/07/17 but AMD has not gotten back to me on
> this matter and like I said, if I wait then I risk having to buy
> something way out of my price range.
> --And I really have tried to wait till the last minute--
> Anything official or unofficial will do.
> I am planning to use the OpenCL language to do my MP experiments.
> 
> Thanks,
> David
> 
> BTW: I got the emails to CC from the discussion:
> [RFC] Using DC in amdgpu for upcoming GPU
> so don't worry that I have an email harvester or something.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: Planned Vega support in Linux

[Deucher, Alexander]

> -Original Message-
> From: David Niklas [mailto:do...@mail.com]
> Sent: Tuesday, August 08, 2017 4:13 PM
> To: dri-devel@lists.freedesktop.org
> Cc: Deucher, Alexander; Bridgman, John; Deucher, Alexander; Cheng, Tony;
> Koenig, Christian; Wentland, Harry
> Subject: Planned Vega support in Linux
> 
> Hello,
> I'm not seeking any secret info.
> I'm a Gentoo Linux user who wants to run some massively parallel
> experiments.
> I'm unwilling to wait and see what kind of support Linux gets because
> the annoying bitcoin miners tend to cause the price to go through the roof
> quickly.
> My current card is an AMD SI HD7780 by MSI.
> I know that currently some form of headless support already exists, but
> then I'd have to use crossfire (which does not work with the opensource
> driver AFAIK).
> I filed a ticket at AMD on 05/07/17 but AMD has not gotten back to me on
> this matter and like I said, if I wait then I risk having to buy
> something way out of my price range.
> --And I really have tried to wait till the last minute--
> Anything official or unofficial will do.
> I am planning to use the OpenCL language to do my MP experiments.

I'm not quite sure what you are asking.  We released initial open source 
support for vega10 months ago and it continues to evolve as new SKUs are 
launched.  It is expected that you can get a complete working stack in open 
source at launch time for whatever sku you are interested in.  Not all of the 
patches are upstream, but they are all public.  OpenCL support is provided by 
the ROCm stack which you can get from the gpuopen site.  Headless boards are 
supported just fine and have been for years.  If you prefer packaged drivers, 
you can download the ROCm stack from gpuopen or the pro stack from amd.com.  
All stacks build on the same open source kernel driver and other components.

Alex

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 196615] amdgpu - resume from suspend is no longer working on rx480

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=196615

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) ---
Please attach your dmesg output.  How exactly does resume fail?

-- 
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

[pull] drm/msm: msm-fixes for 4.13

[Rob Clark]

Hi Dave,

a few fixes for 4.13..

The following changes since commit 16f73eb02d7e1765ccab3d2018e0bd98eb93d973:

  Linux 4.13-rc3 (2017-07-30 12:40:36 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~robclark/linux msm-fixes-4.13-rc3

for you to fetch changes up to 8f93e043d048b671c32c6f0a5102fefa800c4618:

  drm/msm: gpu: don't abuse dma_alloc for non-DMA allocations
(2017-08-01 19:39:00 -0400)


Archit Taneja (4):
  drm/msm/dsi: Calculate link clock rates with updated dsi->lanes
  drm/msm/mdp5: Fix typo in encoder_enable path
  drm/msm/mdp5: Drop clock names with "_clk" suffix
  drm/msm/adreno: Prevent unclocked access when retrieving timestamps

Arnd Bergmann (2):
  drm/msm: gpu: call qcom_mdt interfaces only for ARCH_QCOM
  drm/msm: gpu: don't abuse dma_alloc for non-DMA allocations

Dan Carpenter (2):
  drm/msm: fix an integer overflow test
  drm/msm: unlock on error in msm_gem_get_iova()

Hans Verkuil (2):
  drm/msm: fix WARN_ON in add_vma() with no iommu
  drm/msm: NULL pointer dereference in drivers/gpu/drm/msm/msm_gem_vma.c

Jordan Crouse (5):
  drm/msm: Remove some potentially blocked register ranges
  drm/msm: Allow hardware clock gating to be toggled
  drm/msm: Turn off hardware clock gating before reading A5XX registers
  drm/msm: args->fence should be args->flags
  drm/msm: Remove __user from __u64 data types

Rob Clark (1):
  drm/msm/mdp5: fix unclocked register access in _cursor_set()

Viresh Kumar (1):
  drm/msm/mdp5: Fix compilation warnings

 drivers/gpu/drm/msm/Kconfig |   2 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 181 ++--
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h   |   3 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  11 +-
 drivers/gpu/drm/msm/dsi/dsi_host.c  |  14 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|  12 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |   2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  12 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |   4 +-
 drivers/gpu/drm/msm/msm_gem.c   |  12 +-
 drivers/gpu/drm/msm/msm_gem_submit.c|   6 +-
 drivers/gpu/drm/msm/msm_gem_vma.c   |   2 +-
 include/uapi/drm/msm_drm.h  |   6 +-
 13 files changed, 119 insertions(+), 148 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 196125] [Regression] AMD Radeon RX 480 flickering on HDMI port with Linux 4.11.4

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=196125

--- Comment #6 from Peter Spiess-Knafl (p...@autistici.org) ---
Forgot to mention that I am using the displayport connector. So it does not
only affect HDMI.

-- 
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

Planned Vega support in Linux

[David Niklas]

Hello,
I'm not seeking any secret info.
I'm a Gentoo Linux user who wants to run some massively parallel
experiments.
I'm unwilling to wait and see what kind of support Linux gets because
the annoying bitcoin miners tend to cause the price to go through the roof
quickly.
My current card is an AMD SI HD7780 by MSI.
I know that currently some form of headless support already exists, but
then I'd have to use crossfire (which does not work with the opensource
driver AFAIK).
I filed a ticket at AMD on 05/07/17 but AMD has not gotten back to me on
this matter and like I said, if I wait then I risk having to buy
something way out of my price range.
--And I really have tried to wait till the last minute--
Anything official or unofficial will do.
I am planning to use the OpenCL language to do my MP experiments.

Thanks,
David

BTW: I got the emails to CC from the discussion:
[RFC] Using DC in amdgpu for upcoming GPU
so don't worry that I have an email harvester or something.


pgpi_deTrji8V.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 196615] amdgpu - resume from suspend is no longer working on rx480

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=196615

Peter Spiess-Knafl (p...@autistici.org) changed:

   What|Removed |Added

URL||https://git.kernel.org/pub/
   ||scm/linux/kernel/git/stable
   ||/linux-stable.git/commit/?h
   ||=linux-4.12.y=2dc1889ebf
   ||8501b0edf125e89a30e1cf3744a
   ||2a7

-- 
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 196615] amdgpu - resume from suspend is no longer working on rx480

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=196615

Peter Spiess-Knafl (p...@autistici.org) changed:

   What|Removed |Added

 CC||p...@autistici.org
 Regression|No  |Yes

--- Comment #1 from Peter Spiess-Knafl (p...@autistici.org) ---
I also started a discussion thread on the arch forum:

https://bbs.archlinux.org/viewtopic.php?pid=1729393#p1729393

-- 
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 101160] Venus PRO R9 M265X amdgpu: ring 0 test failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101160

--- Comment #5 from mercuriete  ---
ping?

-- 
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 196615] New: amdgpu - resume from suspend is no longer working on rx480

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=196615

Bug ID: 196615
   Summary: amdgpu - resume from suspend is no longer working on
rx480
   Product: Drivers
   Version: 2.5
Kernel Version: >= 4.11.3
  Hardware: Intel
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: p...@autistici.org
Regression: No

Hi!

Since 4.12.4 I can no longer resume from suspend using the amdgpu driver on my
rx 480.

I did a bisect and it revealed the following commit being the problem:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.12.y=2dc1889ebf8501b0edf125e89a30e1cf3744a2a7

Can someone help me with fixing that?

-- 
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 196125] [Regression] AMD Radeon RX 480 flickering on HDMI port with Linux 4.11.4

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=196125

Peter Spiess-Knafl (p...@autistici.org) changed:

   What|Removed |Added

 CC||p...@autistici.org

--- Comment #5 from Peter Spiess-Knafl (p...@autistici.org) ---
I can confirm this behaviour.

-- 
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

[PULL] drm-misc-next

[Sean Paul]

Hi Dave,
Here's the pull for the last week and a bit. It's rather large as I was on
vacation/moving last week. Although the patch count/diffstat is higher than
normal, we have a lot of medium-large sets included. That also explains why the
summary might seem a bit light.

Among the aforementioned sets, there are a few pretty awesome cleanups: 
lut/gamma dead code cleanup, dumb_mmap/destroy defaults, and the atomic property
shuffle into core from the helpers.

There are also 4 new UAPI changes, all low risk/new functionality. The armada
change doesn't change the size of the structs, so should be business as usual.
The fb_helper change is a nice improvement, and will simply expose more accurate
information about the display. vc4 ioctl is meant for debugging purposes, so
while it wil be helpful, it's not user facing. Finally, the format/modifier
property shouldn't trip anybody up since all sane userspace should skip over it
if they can't make use of it.


drm-misc-next-2017-08-08:
UAPI Changes:
- vc4: Add ioctl to allow attaching a label to a bo (Eric)
- Add new format/modifier blob plane property (Ben)
- armada: Use __u32/__u64 instead of uint32_t/uint64_t (Mikko)
- [kinda uapi] fb_helper: Expose display_info size via fb_info (David)

Core Changes:
- Default gem_dumb_[map_offset|destroy] as mmap/destroy implementations (Noralf)
- Simplify atomic properties by removing the helpers and handling in core 
(Daniel)

Driver Changes:
- stm: Add STM32 DSI controller driver (Phillipe)
- vc4: Add HDMI CEC support (Hans)
- rockchip: Refactor register init & soc version handling (Mark)
- misc: Remove .load_lut, .gamma_set, .gamma_get dead code (Peter)
- dw-hdmi: Add HDMI CEC support (Russell)

Cc: Philippe CORNU 
Cc: Hans Verkuil 
Cc: Eric Anholt 
Cc: Noralf Trønnes 
Cc: Ben Widawsky 
Cc: Mark yao 
Cc: Peter Rosin 
Cc: Russell King 
Cc: Mikko Rapeli 
Cc: David Lechner 
Cc: Daniel Vetter 

Cheers, Sean


The following changes since commit e6742e1021a5cec55fab50a0b115c65217488eda:

  drm: linux-next: build failure after merge of the drm-misc tree (2017-07-27 
08:27:11 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-08-08

for you to fetch changes up to 16fece0153d5b6573c3fcb8cfbe483f83ca8eb01:

  drm: Nuke drm_atomic_legacy_backoff (2017-08-08 14:49:29 +0200)


UAPI Changes:
- vc4: Add ioctl to allow attaching a label to a bo (Eric)
- Add new format/modifier blob plane property (Ben)
- armada: Use __u32/__u64 instead of uint32_t/uint64_t (Mikko)
- [kinda uapi] fb_helper: Expose display_info size via fb_info (David)

Core Changes:
- Default gem_dumb_[map_offset|destroy] as mmap/destroy implementations (Noralf)
- Simplify atomic properties by removing the helpers and handling in core 
(Daniel)

Driver Changes:
- stm: Add STM32 DSI controller driver (Phillipe)
- vc4: Add HDMI CEC support (Hans)
- rockchip: Refactor register init & soc version handling (Mark)
- misc: Remove .load_lut, .gamma_set, .gamma_get dead code (Peter)
- dw-hdmi: Add HDMI CEC support (Russell)

Cc: Philippe CORNU 
Cc: Hans Verkuil 
Cc: Eric Anholt 
Cc: Noralf Trønnes 
Cc: Ben Widawsky 
Cc: Mark yao 
Cc: Peter Rosin 
Cc: Russell King 
Cc: Mikko Rapeli 
Cc: David Lechner 
Cc: Daniel Vetter 


Arnd Bergmann (1):
  tinydrm: repaper: add CONFIG_THERMAL dependency

Arvind Yadav (1):
  drm/atmel-hlcdc : constify drm_plane_helper_funcs and drm_plane_funcs.

Ben Widawsky (2):
  drm: Plumb modifiers through plane init
  drm: Create a format/modifier blob

Chris Wilson (1):
  dma-buf/sync_file: Allow multiple sync_files to wrap a single dma-fence

Cihangir Akturk (1):
  drm/atmel-hlcdc: switch to drm_*{get,put} helpers

Daniel Vetter (8):
  drm: Fix kerneldoc for atomic_async_update
  drm: Don't update property values for atomic drivers
  drm: Handle properties in the core for atomic drivers
  drm: Nuke drm_atomic_helper_crtc_set_property
  drm: Nuke drm_atomic_helper_plane_set_property
  drm: Nuke drm_atomic_helper_connector_set_property
  drm: Nuke drm_atomic_helper_connector_dpms
  drm: Nuke drm_atomic_legacy_backoff

David Lechner (4):
  drm/fb: Fix pointer dereference before null check.
  drm/fb-helper: add new drm_setup_crtcs_fb() function
  drm/tinydrm: remove call to mipi_dbi_init() from mipi_dbi_spi_init()
  

[PATCH] gpu: host1x: fix error return code in host1x_probe()

[Gustavo A. R. Silva]

platform_get_irq() returns an error code, but the host1x driver
ignores it and always returns -ENXIO. This is not correct and,
prevents -EPROBE_DEFER from being propagated properly.

Notice that platform_get_irq() no longer returns 0 on error:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e330b9a6bb35dc7097a4f02cb1ae7b6f96df92af

Print and propagate the return value of platform_get_irq on failure.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/host1x/dev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 7782725..7f22c5c 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -134,8 +134,8 @@ static int host1x_probe(struct platform_device *pdev)
 
syncpt_irq = platform_get_irq(pdev, 0);
if (syncpt_irq < 0) {
-   dev_err(>dev, "failed to get IRQ\n");
-   return -ENXIO;
+   dev_err(>dev, "failed to get IRQ: %d\n", syncpt_irq);
+   return syncpt_irq;
}
 
host = devm_kzalloc(>dev, sizeof(*host), GFP_KERNEL);
-- 
2.5.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v1 1/2] uapi: drm: Add fourcc codes needed by Xilinx Video IP

[Jeff Mouroux]

Hi David,

Thanks for the feedback.   I'm not as familiar with the FB Dev infrastructure.  
 Thanks for bringing this to my attention.  

Jeff

-Original Message-
From: David Lechner [mailto:da...@lechnology.com] 
Sent: Monday, August 07, 2017 2:17 PM
To: Philipp Zabel ; Jeff Mouroux 
Cc: dri-devel@lists.freedesktop.org; daniel.vet...@intel.com; Jeff Mouroux 
; Noralf Trønnes 
Subject: Re: [PATCH v1 1/2] uapi: drm: Add fourcc codes needed by Xilinx Video 
IP

On 08/07/2017 10:13 AM, Philipp Zabel wrote:
> Hi Jeffrey,
> 
> On Fri, 2017-08-04 at 11:49 -0700, Jeffrey Mouroux wrote:
>> The Xilinx Video Mixer andn Xilinx Video Framebuffer DMA IP support 
>> video memory formats that are not represented in the current DRM 
>> fourcc library.  This patch adds those missing fourcc codes.
>>
>> Signed-off-by: Jeffrey Mouroux 
>> ---
>>   include/uapi/drm/drm_fourcc.h | 9 +
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm_fourcc.h 
>> b/include/uapi/drm/drm_fourcc.h index ef20abb..3e80130 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -112,6 +112,14 @@
>>   #define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /* 
>> [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
>>   
>>   #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /* 
>> [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
>> +#define DRM_FORMAT_AVUY fourcc_code('A', 'V', 'U', 'Y') /* 
>> [31:0] A:Cr:Cb:Y 8:8:8:8 little endian */
>> +#define DRM_FORMAT_VUY888   fourcc_code('V', 'U', '2', '4') /* [23:0] 
>> Cr:Cb:Y little endian */
>> +#define DRM_FORMAT_XVUY fourcc_code('X', 'V', '2', '4') /* [31:0] 
>> x:Cr:Cb:Y 8:8:8:8 little endian */
>> +#define DRM_FORMAT_XVUY2101010  fourcc_code('X', 'V', '3', '0') /* 
>> [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
>> +
>> +/* Grey scale */
>> +#define DRM_FORMAT_Y8   fourcc_code('G', 'R', 'E', 'Y') /* 8  
>> Greyscale */
> 
> That would be useful for me as well.

I'm also interested in 8-bit grayscale. I applied these patches then naively 
tried to add support for DRM_FORMAT_Y8 to a driver I am working on.

diff --git a/drivers/gpu/drm/tinydrm/st7586.c
b/drivers/gpu/drm/tinydrm/st7586.c
index 1b39d3f..f6db7be 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -56,6 +56,34 @@

  static const u8 st7586_lookup[] = { 0x7, 0x4, 0x2, 0x0 };

+static void st7586_gray8_to_gray332(u8 *dst, void *vaddr,
+   struct drm_framebuffer *fb,
+   struct drm_clip_rect *clip) {
...
+}
+
  static void st7586_xrgb_to_gray332(u8 *dst, void *vaddr,
struct drm_framebuffer *fb,
struct drm_clip_rect *clip) @@ -98,7 
+126,14 @@ static int st7586_buf_copy(void *dst, struct drm_framebuffer *fb,
 return ret;
 }

-   st7586_xrgb_to_gray332(dst, src, fb, clip);
+   switch(fb->format->format) {
+   case DRM_FORMAT_Y8:
+   st7586_gray8_to_gray332(dst, src, fb, clip);
+   break;
+   case DRM_FORMAT_XRGB:
+   st7586_xrgb_to_gray332(dst, src, fb, clip);
+   break;
+   }

 if (import_attach)
 ret = dma_buf_end_cpu_access(import_attach->dmabuf,
@@ -260,6 +295,7 @@ static void st7586_pipe_disable(struct 
drm_simple_display_pipe *pipe)
  }

  static const u32 st7586_formats[] = {
+   DRM_FORMAT_Y8,
 DRM_FORMAT_XRGB,
  };

@@ -290,7 +326,7 @@ static int st7586_init(struct device *dev, struct mipi_dbi 
*mipi,
 if (ret)
 return ret;

-   tdev->drm->mode_config.preferred_depth = 32;
+   tdev->drm->mode_config.preferred_depth = 8;
 mipi->rotation = rotation;

 drm_mode_config_reset(tdev->drm);


But it just caused a crash. (Note: had to set fb.lockless_register_fb=1 in the 
kernel command line to get stack trace.)


Console: switching to colour frame buffer device 22x16
Unable to handle kernel paging request at virtual address c4bd4158
pgd = c2e0c000
[c4bd4158] *pgd=c2dfd811, *pte=, *ppte=
Internal error: Oops: 7 [#1] PREEMPT ARM
Modules linked in: st7586(+) mipi_dbi tinydrm drm_kms_helper syscopyarea 
sysfill
rect sysimgblt fb_sys_fops ofpart drm backlight m25p80 spi_nor 
ti_ads7950 indust
rialio_triggered_buffer mtd da8xx kfifo_buf phy_generic pwm_beeper 
ohci_da8xx mu
sb_hdrc ohci_hcd usbcore pwm_tiehrpwm davinci_wdt phy_da8xx_usb 
pinctrl_da850_pu
pd rtc_omap leds_gpio led_class lego_ev3_battery industrialio tun 
libcomposite c
onfigfs udc_core usb_common autofs4
CPU: 0 PID: 126 Comm: systemd-udevd Tainted: GW 
4.13.0-rc2-dlech-e
v3+ #486
Hardware name: Generic DA850/OMAP-L138/AM18x
task: c3afd4a0 task.stack: 

[PATCH] drm/bridge: make drm_bridge_funcs const

[Bhumika Goyal]

Make these structures const as they are only stored in the funcs field
of drm_bridge structure, which is of type const.
Done using Coccinelle.

Signed-off-by: Bhumika Goyal 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c  | 2 +-
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index ee16635..58b4fb2 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -857,7 +857,7 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge)
return ret;
 }
 
-static struct drm_bridge_funcs adv7511_bridge_funcs = {
+static const struct drm_bridge_funcs adv7511_bridge_funcs = {
.enable = adv7511_bridge_enable,
.disable = adv7511_bridge_disable,
.mode_set = adv7511_bridge_mode_set,
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 36f5ccb..63c7a01 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -811,7 +811,7 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge 
*bridge)
return drm_bridge_attach(bridge->encoder, dsi->panel_bridge, bridge);
 }
 
-static struct drm_bridge_funcs dw_mipi_dsi_bridge_funcs = {
+static const struct drm_bridge_funcs dw_mipi_dsi_bridge_funcs = {
.mode_set = dw_mipi_dsi_bridge_mode_set,
.enable   = dw_mipi_dsi_bridge_enable,
.post_disable = dw_mipi_dsi_bridge_post_disable,
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/rockchip: make drm_connector_funcs structures const

[Bhumika Goyal]

Make these const as they are only passed to the function
drm_connector_init and the corresponding argument is of type const.
Done using Coccinelle

@match disable optional_qualifier@
identifier s;
@@
static struct drm_connector_funcs s = {...};

@ref@
position p;
identifier match.s;
@@
s@p

@good1@
identifier match.s;
expression e1,e2;
position ref.p;
@@
drm_connector_init(e1,e2,@p,...)

@bad depends on  !good1@
position ref.p;
identifier match.s;
@@
s@p

@depends on forall !bad disable optional_qualifier@
identifier match.s;
@@
static
+ const
struct drm_connector_funcs s;

Signed-off-by: Bhumika Goyal 
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 7149968..1a1a3dd 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -592,7 +592,7 @@ static void inno_hdmi_connector_destroy(struct 
drm_connector *connector)
drm_connector_cleanup(connector);
 }
 
-static struct drm_connector_funcs inno_hdmi_connector_funcs = {
+static const struct drm_connector_funcs inno_hdmi_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = inno_hdmi_probe_single_connector_modes,
.detect = inno_hdmi_connector_detect,
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/sun4i: make drm_connector_funcs structures const

[Bhumika Goyal]

Make these const as they are only passed to the function
drm_connector_init and the corresponding argument is of type const.
Done using Coccinelle

@match disable optional_qualifier@
identifier s;
@@
static struct drm_connector_funcs s = {...};

@ref@
position p;
identifier match.s;
@@
s@p

@good1@
identifier match.s;
expression e1,e2;
position ref.p;
@@
drm_connector_init(e1,e2,@p,...)

@bad depends on  !good1@
position ref.p;
identifier match.s;
@@
s@p

@depends on forall !bad disable optional_qualifier@
identifier match.s;
@@
static
+ const
struct drm_connector_funcs s;

Signed-off-by: Bhumika Goyal 
---
 drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 +-
 drivers/gpu/drm/sun4i/sun4i_tv.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 76362c0..4a456de 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -119,7 +119,7 @@ static int sun4i_rgb_mode_valid(struct drm_connector 
*connector,
drm_connector_cleanup(connector);
 }
 
-static struct drm_connector_funcs sun4i_rgb_con_funcs = {
+static const struct drm_connector_funcs sun4i_rgb_con_funcs = {
.dpms   = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy= sun4i_rgb_connector_destroy,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 73bfe7b..d246794 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -537,7 +537,7 @@ static int sun4i_tv_comp_mode_valid(struct drm_connector 
*connector,
drm_connector_cleanup(connector);
 }
 
-static struct drm_connector_funcs sun4i_tv_comp_connector_funcs = {
+static const struct drm_connector_funcs sun4i_tv_comp_connector_funcs = {
.dpms   = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy= sun4i_tv_comp_connector_destroy,
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: make drm_mode_config_func const

[Bhumika Goyal]

Make these structures const as they are only stored in the funcs field
of a drm_mode_config structure which is of type const.
Done using Coccinelle:

@match disable optional_qualifier@
identifier s;
@@
static struct drm_mode_config_funcs s = {...};

@ref@
position p;
identifier match.s;
@@
s@p

@good1@
identifier y;
position ref.p;
identifier match.s;
@@
struct drm_mode_config y = {...,.funcs=@p,...};

@good2@
struct drm_mode_config y;
identifier match.s;
position ref.p;
@@
y.funcs = @p

@bad depends on  !good1 && !good2@
position ref.p;
identifier match.s;
@@
s@p

@depends on forall !bad disable optional_qualifier@
identifier match.s;
@@
static
+ const
struct drm_mode_config_funcs s;

Signed-off-by: Bhumika Goyal 
---
 drivers/gpu/drm/arc/arcpgu_drv.c  | 2 +-
 drivers/gpu/drm/pl111/pl111_drv.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index e3c13aa..289eda5 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -31,7 +31,7 @@ static void arcpgu_fb_output_poll_changed(struct drm_device 
*dev)
drm_fbdev_cma_hotplug_event(arcpgu->fbdev);
 }
 
-static struct drm_mode_config_funcs arcpgu_drm_modecfg_funcs = {
+static const struct drm_mode_config_funcs arcpgu_drm_modecfg_funcs = {
.fb_create  = drm_fb_cma_create,
.output_poll_changed = arcpgu_fb_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index 29653fe..0ea3ca8 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -72,7 +72,7 @@
 
 #define DRIVER_DESC  "DRM module for PL111"
 
-static struct drm_mode_config_funcs mode_config_funcs = {
+static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = drm_fb_cma_create,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/virtio: make drm_fb_helper_funcs const

[Bhumika Goyal]

Make these structures const as they are only passed to the function
drm_fb_helper_prepare and the corresponding argument is of type const.
Done using Coccinelle

@match disable optional_qualifier@
identifier s;
@@
static struct drm_fb_helper_funcs s = {...};

@ref@
position p;
identifier match.s;
@@
s@p

@good1@
identifier match.s;
expression e1,e2;
position ref.p;
@@
drm_fb_helper_prepare(e1,e2,@p,...)

@bad depends on  !good1@
position ref.p;
identifier match.s;
@@
s@p

@depends on forall !bad disable optional_qualifier@
identifier match.s;
@@
static
+ const
struct drm_fb_helper_funcs s;

Signed-off-by: Bhumika Goyal 
---
 drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c 
b/drivers/gpu/drm/virtio/virtgpu_fb.c
index 046e28b..15d18fd 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fb.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
@@ -308,7 +308,7 @@ static int virtio_gpu_fbdev_destroy(struct drm_device *dev,
 
return 0;
 }
-static struct drm_fb_helper_funcs virtio_gpu_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs virtio_gpu_fb_helper_funcs = {
.fb_probe = virtio_gpufb_create,
 };
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/bridge: make drm_connector_funcs structures const

[Bhumika Goyal]

Make these const as they are only passed to the function
drm_connector_init and the corresponding argument is of type const.
Done using Coccinelle

@match disable optional_qualifier@
identifier s;
@@
static struct drm_connector_funcs s = {...};

@ref@
position p;
identifier match.s;
@@
s@p

@good1@
identifier match.s;
expression e1,e2;
position ref.p;
@@
drm_connector_init(e1,e2,@p,...)

@bad depends on  !good1@
position ref.p;
identifier match.s;
@@
s@p

@depends on forall !bad disable optional_qualifier@
identifier match.s;
@@
static
+ const
struct drm_connector_funcs s;

Signed-off-by: Bhumika Goyal 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index ff9792d..ee16635 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -785,7 +785,7 @@ static int adv7511_connector_get_modes(struct drm_connector 
*connector)
return adv7511_detect(adv, connector);
 }
 
-static struct drm_connector_funcs adv7511_connector_funcs = {
+static const struct drm_connector_funcs adv7511_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = adv7511_connector_detect,
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation

[Kirti Wankhede]

On 8/7/2017 11:13 PM, Alex Williamson wrote:
> On Mon, 7 Aug 2017 08:11:43 +
> "Zhang, Tina"  wrote:
> 
>> After going through the previous discussions, here are some summaries may be 
>> related to the current discussion:
>> 1. How does user mode figure the device capabilities between region and 
>> dma-buf?
>> VFIO_DEVICE_GET_REGION_INFO could tell if the mdev supports region case. 
>> Otherwise, the mdev supports dma-buf.
> 
> Why do we need to make this assumption?

Right, we should not make such assumption. Vendor driver might not
support both or disable console vnc ( for example, for performance
testing console VNC need to be disabled)

>  What happens when dma-buf is
> superseded?  What happens if a device supports both dma-buf and
> regions?  We have a flags field in vfio_device_gfx_plane_info, doesn't
> it make sense to use it to identify which field, between region_index
> and fd, is valid?  We could even put region_index and fd into a union
> with the flag bits indicating how to interpret the union, but I'm not
> sure everyone was onboard with this idea.  Seems like a waste of 4
> bytes not to do that though.
> 

Agree.

> Thinking further, is the user ever in a situation where they query the
> graphics plane info and can handle either a dma-buf or a region?  It
> seems more likely that the user needs to know early on which is
> supported and would then require that they continue to see compatible
> plane information...  Should the user then be able to specify whether
> they want a dma-buf or a region?  Perhaps these flag bits are actually
> input and the return should be -errno if the driver cannot produce
> something compatible.
> 
> Maybe we'd therefore define 3 flag bits: PROBE, DMABUF, REGION.  In
> this initial implementation, DMABUF or REGION would always be set by
> the user to request that type of interface.  Additionally, the QUERY
> bit could be set to probe compatibility, thus if PROBE and REGION are
> set, the vendor driver would return success only if it supports the
> region based interface.  If PROBE and DMABUF are set, the vendor driver
> returns success only if the dma-buf based interface is supported.  The
> value of the remainder of the structure is undefined for PROBE.
> Additionally setting both DMABUF and REGION is invalid.  Undefined
> flags bits must be validated as zero by the drivers for future use
> (thus if we later define DMABUFv2, an older driver should
> automatically return -errno when probed or requested).
> 

Are you saying all of this to be part of VFIO_DEVICE_QUERY_GFX_PLANE ioctl?

Let me summarize what we need, taking QEMU as reference:
1. From vfio_initfn(), for REGION case, get region info:
vfio_get_dev_region_info(.., VFIO_REGION_SUBTYPE_CONSOLE_REGION,
>console_opregion)

If above return success, setup console REGION and mmap.
I don't know what is required for DMABUF at this moment.

If console VNC is supported either DMABUF or REGION, initialize console
and register its callback operations:

static const GraphicHwOps vfio_console_ops = {
.gfx_update  = vfio_console_update_display,
};

vdev->console = graphic_console_init(DEVICE(vdev), 0, _console_ops,
vdev);

2. On above console registration, vfio_console_update_display() gets
called for each refresh cycle of console. In that:
- call ioctl(VFIO_DEVICE_QUERY_GFX_PLANE)
- if (queried size > 0), update QEMU console surface (for REGION case
read mmaped region, for DMABUF read surface using fd)


Alex, in your proposal above, my understanding is
ioctl(VFIO_DEVICE_QUERY_GFX_PLANE) with PROBE flag should be called in
step #1.
In step #2, ioctl(VFIO_DEVICE_QUERY_GFX_PLANE) will be without PROBE
flag, but either DMABUF or REGION flag based on what is returned as
supported by vendor driver in step #1. Is that correct?


> It seems like this handles all the cases, the user can ask what's
> supported and specifies the interface they want on every call.  The
> user therefore can also choose between region_index and fd and we can
> make that a union.
>
>> 2. For dma-buf, how to differentiate unsupported vs not initialized?
>> For dma-buf, when the mdev doesn't support some arguments, -EINVAL will be 
>> returned. And -errno will return when meeting other failures, like -ENOMEM.
>> If the mdev is not initialized, there won't be any returned err. Just zero 
>> all the fields in structure vfio_device_gfx_plane_info.
> 
> So we're relying on special values again :-\  For which fields is zero
> not a valid value?  I prefer the probe interface above unless there are
> better ideas.
> 

PROBE will be called during vdev initialization and after that
vfio_console_update_display() gets called at every console refresh
cycle. But until driver in guest is loaded, mmaped buffer/ DMABUF will
not be populated with correct surface data. In that case for QUERY,
vendor driver should return (atleast) size=0 which means there is
nothing to copy. Once guest driver is loaded and surface is created by
guest 

[PATCH 0/3] drm: make drm_connector_funcs structures const

[Bhumika Goyal]

Declare drm_connector_funcs structures as const.

Bhumika Goyal (3):
  drm/bridge: make drm_connector_funcs structures const
  drm/sun4i: make drm_connector_funcs structures const
  drm/rockchip: make drm_connector_funcs structures const

 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
 drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
 drivers/gpu/drm/sun4i/sun4i_rgb.c| 2 +-
 drivers/gpu/drm/sun4i/sun4i_tv.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation

[Alex Williamson]

On Tue, 8 Aug 2017 14:18:07 +0530
Kirti Wankhede  wrote:

> On 8/7/2017 11:13 PM, Alex Williamson wrote:
> > On Mon, 7 Aug 2017 08:11:43 +
> > "Zhang, Tina"  wrote:
> >   
> >> After going through the previous discussions, here are some summaries may 
> >> be related to the current discussion:
> >> 1. How does user mode figure the device capabilities between region and 
> >> dma-buf?
> >> VFIO_DEVICE_GET_REGION_INFO could tell if the mdev supports region case. 
> >> Otherwise, the mdev supports dma-buf.  
> > 
> > Why do we need to make this assumption?  
> 
> Right, we should not make such assumption. Vendor driver might not
> support both or disable console vnc ( for example, for performance
> testing console VNC need to be disabled)
> 
> >  What happens when dma-buf is
> > superseded?  What happens if a device supports both dma-buf and
> > regions?  We have a flags field in vfio_device_gfx_plane_info, doesn't
> > it make sense to use it to identify which field, between region_index
> > and fd, is valid?  We could even put region_index and fd into a union
> > with the flag bits indicating how to interpret the union, but I'm not
> > sure everyone was onboard with this idea.  Seems like a waste of 4
> > bytes not to do that though.
> >   
> 
> Agree.
> 
> > Thinking further, is the user ever in a situation where they query the
> > graphics plane info and can handle either a dma-buf or a region?  It
> > seems more likely that the user needs to know early on which is
> > supported and would then require that they continue to see compatible
> > plane information...  Should the user then be able to specify whether
> > they want a dma-buf or a region?  Perhaps these flag bits are actually
> > input and the return should be -errno if the driver cannot produce
> > something compatible.
> > 
> > Maybe we'd therefore define 3 flag bits: PROBE, DMABUF, REGION.  In
> > this initial implementation, DMABUF or REGION would always be set by
> > the user to request that type of interface.  Additionally, the QUERY
> > bit could be set to probe compatibility, thus if PROBE and REGION are
> > set, the vendor driver would return success only if it supports the
> > region based interface.  If PROBE and DMABUF are set, the vendor driver
> > returns success only if the dma-buf based interface is supported.  The
> > value of the remainder of the structure is undefined for PROBE.
> > Additionally setting both DMABUF and REGION is invalid.  Undefined
> > flags bits must be validated as zero by the drivers for future use
> > (thus if we later define DMABUFv2, an older driver should
> > automatically return -errno when probed or requested).
> >   
> 
> Are you saying all of this to be part of VFIO_DEVICE_QUERY_GFX_PLANE ioctl?
> 
> Let me summarize what we need, taking QEMU as reference:
> 1. From vfio_initfn(), for REGION case, get region info:
> vfio_get_dev_region_info(.., VFIO_REGION_SUBTYPE_CONSOLE_REGION,
> >console_opregion)
> 
> If above return success, setup console REGION and mmap.
> I don't know what is required for DMABUF at this moment.
> 
> If console VNC is supported either DMABUF or REGION, initialize console
> and register its callback operations:
> 
> static const GraphicHwOps vfio_console_ops = {
> .gfx_update  = vfio_console_update_display,
> };
> 
> vdev->console = graphic_console_init(DEVICE(vdev), 0, _console_ops,
> vdev);

I might structure it that vfio_initfn() would call
ioctl(VFIO_DEVICE_QUERY_GFX_PLANE) with the PROBE bit set with either
DMABUF or REGION set as the interface type in the flags field.  If
REGION is the probed interface and success is returned, then QEMU might
go look for regions of the appropriate type, however the
vfio_device_gfx_plane_info structure is canonical source for the region
index, so QEMU would probably be wise to use that and only use the
region type for consistency testing.

> 2. On above console registration, vfio_console_update_display() gets
> called for each refresh cycle of console. In that:
> - call ioctl(VFIO_DEVICE_QUERY_GFX_PLANE)
> - if (queried size > 0), update QEMU console surface (for REGION case
> read mmaped region, for DMABUF read surface using fd)

The ioctl would be called with REGION or DMABUF based on the initial
probe call, ex. we probed that REGION is supported and now we continue
to ask for region based updates.  QEMU would need to verify the region
index matches that already mapped, remapping a different region if
necessary, and interpret the graphics parameters to provide the screen
update.
 
> Alex, in your proposal above, my understanding is
> ioctl(VFIO_DEVICE_QUERY_GFX_PLANE) with PROBE flag should be called in
> step #1.
> In step #2, ioctl(VFIO_DEVICE_QUERY_GFX_PLANE) will be without PROBE
> flag, but either DMABUF or REGION flag based on what is returned as
> supported by vendor driver in step #1. Is that correct?

Yes, that's the idea.  Does it make sense/provide value?

> > It seems like 

[Bug 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101977

--- Comment #11 from Marek Olšák  ---
Samuel, can you share here what you found out when you were looking into the
issue? Thanks.

-- 
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] drm/vc4: Advertise supported modifiers for planes

[Daniel Stone]

The IN_FORMATS blob allows the kernel to advertise to userspace which
format/modifier combinations are supported, per plane. Use this to
advertise that we support both T_TILED and linear.

v2:
  - Only advertise T_TILED for RGB (Eric)
  - Actually turn on allow_fb_modifiers (Eric)

Signed-off-by: Daniel Stone 
---
 drivers/gpu/drm/vc4/vc4_kms.c   |  3 ++-
 drivers/gpu/drm/vc4/vc4_plane.c | 34 +-
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 893312e4e2d7..062e7993f61b 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -187,7 +187,7 @@ static struct drm_framebuffer *vc4_fb_create(struct 
drm_device *dev,
/* Make sure that the modifier in AddFB2 is consistent with the tiling
 * mode set through vc4_set_tiling_ioctl().
 */
-   if (mode_cmd.modifier[0] != tiling_ioctl) {
+   if (mode_cmd->modifier[0] != tiling_ioctl) {
DRM_DEBUG_KMS("Mismatch between user-provided modifier and "
  "tiling ioctl\n");
return ERR_PTR(-EINVAL);
@@ -224,6 +224,7 @@ int vc4_kms_load(struct drm_device *dev)
dev->mode_config.funcs = _mode_funcs;
dev->mode_config.preferred_depth = 24;
dev->mode_config.async_page_flip = true;
+   dev->mode_config.allow_fb_modifiers = true;
 
drm_mode_config_reset(dev);
 
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 2968b3ebb895..d769803ac3a5 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -863,6 +863,32 @@ vc4_update_plane(struct drm_plane *plane,
  ctx);
 }
 
+static bool vc4_format_mod_supported(struct drm_plane *plane,
+uint32_t format,
+uint64_t modifier)
+{
+   /* Support T_TILING for RGB formats only. */
+   switch (format) {
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_BGR565:
+   case DRM_FORMAT_ARGB1555:
+   case DRM_FORMAT_XRGB1555:
+   return true;
+   case DRM_FORMAT_YUV422:
+   case DRM_FORMAT_YVU422:
+   case DRM_FORMAT_YUV420:
+   case DRM_FORMAT_YVU420:
+   case DRM_FORMAT_NV12:
+   case DRM_FORMAT_NV16:
+   default:
+   return (modifier == DRM_FORMAT_MOD_LINEAR);
+   }
+}
+
 static const struct drm_plane_funcs vc4_plane_funcs = {
.update_plane = vc4_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -871,6 +897,7 @@ static const struct drm_plane_funcs vc4_plane_funcs = {
.reset = vc4_plane_reset,
.atomic_duplicate_state = vc4_plane_duplicate_state,
.atomic_destroy_state = vc4_plane_destroy_state,
+   .format_mod_supported = vc4_format_mod_supported,
 };
 
 struct drm_plane *vc4_plane_init(struct drm_device *dev,
@@ -882,6 +909,11 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev,
u32 num_formats = 0;
int ret = 0;
unsigned i;
+   static const uint64_t modifiers[] = {
+   DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED,
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+   };
 
vc4_plane = devm_kzalloc(dev->dev, sizeof(*vc4_plane),
 GFP_KERNEL);
@@ -902,7 +934,7 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev,
ret = drm_universal_plane_init(dev, plane, 0,
   _plane_funcs,
   formats, num_formats,
-  NULL, type, NULL);
+  modifiers, type, NULL);
 
drm_plane_helper_add(plane, _plane_helper_funcs);
 
-- 
2.13.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101377] Gigabyte R9 380 card fails to load, kernel reports bug

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101377

--- Comment #12 from j...@dev1ce.com ---
I've continued testing with a separate Sapphire Radeon R9 380 graphics card,
and cannot reproduce the hardware issue.  the latest kernel 4.12.1 through
4.12.5 all load the driver properly as a module with no special kernel
parameters present.

-- 
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] drm/vc4: Advertise supported modifiers for planes

[Daniel Stone]

The IN_FORMATS blob allows the kernel to advertise to userspace which
format/modifier combinations are supported, per plane. Use this to
advertise that we support both T_TILED and linear.

v2:
  - Only advertise T_TILED for RGB (Eric)
  - Actually turn on allow_fb_modifiers (Eric)

Signed-off-by: Daniel Stone 
---
 drivers/gpu/drm/vc4/vc4_kms.c   |  1 +
 drivers/gpu/drm/vc4/vc4_plane.c | 33 -
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 893312e4e2d7..ef82b5de71fd 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -224,6 +224,7 @@ int vc4_kms_load(struct drm_device *dev)
dev->mode_config.funcs = _mode_funcs;
dev->mode_config.preferred_depth = 24;
dev->mode_config.async_page_flip = true;
+   dev->mode_config.allow_fb_modifiers = true;
 
drm_mode_config_reset(dev);
 
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 2968b3ebb895..a21590991490 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -863,6 +863,31 @@ vc4_update_plane(struct drm_plane *plane,
  ctx);
 }
 
+static bool vc4_format_mod_supported(struct drm_plane *plane,
+uint32_t format,
+uint64_t modifier)
+{
+   /* Support T_TILING for RGB formats only. */
+   switch (format) {
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_BGR565:
+   case DRM_FORMAT_ARGB1555:
+   case DRM_FORMAT_XRGB1555:
+   return true;
+   case DRM_FORMAT_YUV422:
+   case DRM_FORMAT_YVU422:
+   case DRM_FORMAT_YUV420:
+   case DRM_FORMAT_YVU420:
+   case DRM_FORMAT_NV12:
+   case DRM_FORMAT_NV16:
+   return (modifier == DRM_FORMAT_MOD_LINEAR);
+   }
+}
+
 static const struct drm_plane_funcs vc4_plane_funcs = {
.update_plane = vc4_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -871,6 +896,7 @@ static const struct drm_plane_funcs vc4_plane_funcs = {
.reset = vc4_plane_reset,
.atomic_duplicate_state = vc4_plane_duplicate_state,
.atomic_destroy_state = vc4_plane_destroy_state,
+   .format_mod_supported = vc4_format_mod_supported,
 };
 
 struct drm_plane *vc4_plane_init(struct drm_device *dev,
@@ -882,6 +908,11 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev,
u32 num_formats = 0;
int ret = 0;
unsigned i;
+   static const uint64_t modifiers[] = {
+   DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED,
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+   };
 
vc4_plane = devm_kzalloc(dev->dev, sizeof(*vc4_plane),
 GFP_KERNEL);
@@ -902,7 +933,7 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev,
ret = drm_universal_plane_init(dev, plane, 0,
   _plane_funcs,
   formats, num_formats,
-  NULL, type, NULL);
+  modifiers, type, NULL);
 
drm_plane_helper_add(plane, _plane_helper_funcs);
 
-- 
2.13.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101977

--- Comment #10 from Timothee Besset  ---
A similar crash happens if UE4 is started in Vulkan mode:

https://gist.github.com/TTimo/28fa434142fb59e66ae469ed7f7ef034

SIGFPE happens because pipeline->shaders[4]->config.num_vgprs == 0, which is
consistent with the empty config reads from the LLVM shader compilation

-- 
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 6/6] [v4] drm/i915: Add support for CCS modifiers

[Daniel Stone]

Hi,

On 3 August 2017 at 12:00, Daniel Stone  wrote:
> On 1 August 2017 at 17:58, Ben Widawsky  wrote:
>> @@ -1240,6 +1253,19 @@ intel_sprite_plane_create(struct drm_i915_private 
>> *dev_priv,
>> plane_formats = skl_plane_formats;
>> num_plane_formats = ARRAY_SIZE(skl_plane_formats);
>> modifiers = skl_plane_format_modifiers;
>> +   } else if (INTEL_GEN(dev_priv) >= 9) {
>> +   intel_plane->can_scale = true;
>> +   state->scaler_id = -1;
>> +
>> +   intel_plane->update_plane = skl_update_plane;
>> +   intel_plane->disable_plane = skl_disable_plane;
>> +
>> +   plane_formats = skl_plane_formats;
>> +   num_plane_formats = ARRAY_SIZE(skl_plane_formats);
>> +   if (pipe >= PIPE_C)
>
>
> if (pipe >= PIPE_C || plane >= PLANE_SPRITE1)
>
> cf. skl_check_ccs_aux_surface() which rejects CCS on anything other
> than PRIMARY/SPRITE0.

Turns out that should be 1 rather than PLANE_SPRITE1.

Anyway, I've pulled out CCS modifiers for all sprite planes in this
series. Whilst actually testing it, I discovered DDB allocations were
hopelessly broken.

Starting with a 1920x1080 primary plane which had (at some point) had
a CCS surface on it, and moving to a 1920x1080 _linear_ primary plane
with a 256x256 CCS sprite plane, I ended up with a DDB split of 443
primary / 32 plane. Y-tiling needs 33 blocks for even 256x256, so it
didn't work.

Given that, I've removed advertisement of Y, Yf, Y_CCS and Y_CCS, in
order to not give userspace false hope. Once DDB allocation is fixed,
we can start advertising these modifiers.

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: make drm_bridge_funcs const

[Laurent Pinchart]

Hi Bhumika,

Thank you for the patch.

On Tuesday 08 Aug 2017 21:24:10 Bhumika Goyal wrote:
> Make these structures const as they are only stored in the funcs field
> of drm_bridge structure, which is of type const.
> Done using Coccinelle.
> 
> Signed-off-by: Bhumika Goyal 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c  | 2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index ee16635..58b4fb2
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -857,7 +857,7 @@ static int adv7511_bridge_attach(struct drm_bridge
> *bridge) return ret;
>  }
> 
> -static struct drm_bridge_funcs adv7511_bridge_funcs = {
> +static const struct drm_bridge_funcs adv7511_bridge_funcs = {
>   .enable = adv7511_bridge_enable,
>   .disable = adv7511_bridge_disable,
>   .mode_set = adv7511_bridge_mode_set,
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index 36f5ccb..63c7a01
> 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -811,7 +811,7 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge
> *bridge) return drm_bridge_attach(bridge->encoder, dsi->panel_bridge,
> bridge); }
> 
> -static struct drm_bridge_funcs dw_mipi_dsi_bridge_funcs = {
> +static const struct drm_bridge_funcs dw_mipi_dsi_bridge_funcs = {
>   .mode_set = dw_mipi_dsi_bridge_mode_set,
>   .enable   = dw_mipi_dsi_bridge_enable,
>   .post_disable = dw_mipi_dsi_bridge_post_disable,

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 0/3] dma-buf changes for ttm and amdgpu

[Deucher, Alexander]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, August 08, 2017 7:57 AM
> To: Alex Deucher
> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> sumit.sem...@linaro.org; Koenig, Christian; Deucher, Alexander
> Subject: Re: [PATCH 0/3] dma-buf changes for ttm and amdgpu
> 
> On Mon, Aug 07, 2017 at 05:32:20PM -0400, Alex Deucher wrote:
> > We have some changes in ttm and amdgpu that depend on these patches.
> > Sumit, can you pull these in via dma-buf or should I roll them up
> > through my amdgpu tree?
> 
> We could just throw them all into drm-misc too, that's kinda what it's for
> (dma-buf doesn't exist anymore, all the dma-buf stuff is in drm-misc now).
> And you have commit rights for that even :-)

Yeah, I just didn't want to step on Sumit's toes in case he preferred to handle 
dma-buf patches himself.

Alex

> -Daniel
> 
> >
> > Christian König (3):
> >   dma-buf: dma_fence_put is NULL safe
> >   dma-buf: add reservation_object_copy_fences
> >   dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2
> >
> >  drivers/dma-buf/reservation.c | 97
> +--
> >  include/linux/reservation.h   |  3 ++
> >  2 files changed, 78 insertions(+), 22 deletions(-)
> >
> > --
> > 2.5.5
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101787] colours all messed up

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101787

--- Comment #22 from 247  ---
at the end i just gave up and done a fresh install...problem solved now...

-- 
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 101484] [regression, bisected] Steam fails to render content, if mesa is compiled with -O2 -march=native (CPU with bmi instruction supported)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101484

Mike Lothian  changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk

--- Comment #17 from Mike Lothian  ---
Lucas the correct flag to disable BMI is -mno-bmi

-- 
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 101881] [regression] 32bit steam games segfault when launched with DRI_PRIME=1

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101881

--- Comment #19 from Mike Lothian  ---
So I tried dropping the -march=native and now it all works no matter what
version of GCC I use. So it looks like GCC 7+ is miscompiling 32bit apps with
-march=native 

I then added in -mbmi which broke things again and I finally tested with
-march=native -mno-bmi which worked

-- 
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 101382] [r300] Electronic super joy crash on startup(regression)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101382

--- Comment #6 from cosiek...@o2.pl ---
17.1.4-1 crash(core dump)
17.1.5-1 crash(core dump)

-- 
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

[GIT PULL] etnaviv-fixes for 4.13

[Lucas Stach]

Hi Dave,

a single etnaviv fix. Not really a regression fix, as the issue has been
present since day one, but as it's stable material I still think it
qualifies.

Regards,
Lucas

The following changes since commit 5669b9989eaa664cacbad6a85631550bccdad963:

  Merge branch 'drm-fixes-4.13' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2017-08-04 11:43:14 +1000)

are available in the git repository at:

  https://git.pengutronix.de/git/lst/linux etnaviv/fixes

for you to fetch changes up to d6f756e09f01ea7a0efbbcef269a1e384a35d824:

  drm/etnaviv: Fix off-by-one error in reloc checking (2017-08-08 15:56:00 
+0200)


Wladimir J. van der Laan (1):
  drm/etnaviv: Fix off-by-one error in reloc checking

 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: forbid creating framebuffers from too small GEM buffers

[Tobias Jakobi]

Hello Marek,

I have a similar patch in my tree, so this one is

Reviewed-by: Tobias Jakobi 

- Tobias


Marek Szyprowski wrote:
> Add a check if the framebuffer described by the provided drm_mode_fb_cmd2
> structure fits into provided GEM buffers. Without this check it is
> possible to create a framebuffer object from a small buffer and set it to
> the hardware, what results in displaying system memory outside the
> allocated GEM buffer.
> 
> Signed-off-by: Marek Szyprowski 
> CC: sta...@vger.kernel.org # v4.7+
> ---
> This issue was there from the beggining, but the provided patch applies only
> to v4.7+ kernels due to other changes in the fixed code.
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index d48fd7c918f8..73217c281c9a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -145,13 +145,19 @@ struct drm_framebuffer *
>  exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> const struct drm_mode_fb_cmd2 *mode_cmd)
>  {
> + const struct drm_format_info *info = drm_get_format_info(dev, mode_cmd);
>   struct exynos_drm_gem *exynos_gem[MAX_FB_BUFFER];
>   struct drm_gem_object *obj;
>   struct drm_framebuffer *fb;
>   int i;
>   int ret;
>  
> - for (i = 0; i < drm_format_num_planes(mode_cmd->pixel_format); i++) {
> + for (i = 0; i < info->num_planes; i++) {
> + unsigned int height = (i == 0) ? mode_cmd->height :
> +  DIV_ROUND_UP(mode_cmd->height, info->vsub);
> + unsigned long size = height * mode_cmd->pitches[i] +
> +  mode_cmd->offsets[i];
> +
>   obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
>   if (!obj) {
>   DRM_ERROR("failed to lookup gem object\n");
> @@ -160,6 +166,12 @@ struct drm_framebuffer *
>   }
>  
>   exynos_gem[i] = to_exynos_gem(obj);
> +
> + if (size > exynos_gem[i]->size) {
> + i++;
> + ret = -EINVAL;
> + goto err;
> + }
>   }
>  
>   fb = exynos_drm_framebuffer_init(dev, mode_cmd, exynos_gem, i);
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: forbid creating framebuffers from too small GEM buffers

[Marek Szyprowski]

Hi all,

On 2017-07-12 12:09, Marek Szyprowski wrote:

Add a check if the framebuffer described by the provided drm_mode_fb_cmd2
structure fits into provided GEM buffers. Without this check it is
possible to create a framebuffer object from a small buffer and set it to
the hardware, what results in displaying system memory outside the
allocated GEM buffer.

Signed-off-by: Marek Szyprowski 
CC: sta...@vger.kernel.org # v4.7+


Gentle ping.


---
This issue was there from the beggining, but the provided patch applies only
to v4.7+ kernels due to other changes in the fixed code.
---
  drivers/gpu/drm/exynos/exynos_drm_fb.c | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index d48fd7c918f8..73217c281c9a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -145,13 +145,19 @@ struct drm_framebuffer *
  exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
  const struct drm_mode_fb_cmd2 *mode_cmd)
  {
+   const struct drm_format_info *info = drm_get_format_info(dev, mode_cmd);
struct exynos_drm_gem *exynos_gem[MAX_FB_BUFFER];
struct drm_gem_object *obj;
struct drm_framebuffer *fb;
int i;
int ret;
  
-	for (i = 0; i < drm_format_num_planes(mode_cmd->pixel_format); i++) {

+   for (i = 0; i < info->num_planes; i++) {
+   unsigned int height = (i == 0) ? mode_cmd->height :
+DIV_ROUND_UP(mode_cmd->height, info->vsub);
+   unsigned long size = height * mode_cmd->pitches[i] +
+mode_cmd->offsets[i];
+
obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
if (!obj) {
DRM_ERROR("failed to lookup gem object\n");
@@ -160,6 +166,12 @@ struct drm_framebuffer *
}
  
  		exynos_gem[i] = to_exynos_gem(obj);

+
+   if (size > exynos_gem[i]->size) {
+   i++;
+   ret = -EINVAL;
+   goto err;
+   }
}
  
  	fb = exynos_drm_framebuffer_init(dev, mode_cmd, exynos_gem, i);


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/etnaviv: don't fail GPU bind when CONFIG_THERMAL isn't enabled

[Lucas Stach]

The stub functions returns -ENODEV when trying to register the cooling device,
thus failing the GPU bind, rendering the GPU subsystem unusable when
CONFIG_THERMAL isn't enabled.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index ada45fdd0eae..fc9a6a83dfc7 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1622,10 +1622,12 @@ static int etnaviv_gpu_bind(struct device *dev, struct 
device *master,
struct etnaviv_gpu *gpu = dev_get_drvdata(dev);
int ret;
 
-   gpu->cooling = thermal_of_cooling_device_register(dev->of_node,
+   if (IS_ENABLED(CONFIG_THERMAL)) {
+   gpu->cooling = thermal_of_cooling_device_register(dev->of_node,
(char *)dev_name(dev), gpu, _ops);
-   if (IS_ERR(gpu->cooling))
-   return PTR_ERR(gpu->cooling);
+   if (IS_ERR(gpu->cooling))
+   return PTR_ERR(gpu->cooling);
+   }
 
 #ifdef CONFIG_PM
ret = pm_runtime_get_sync(gpu->dev);
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 00/35] omapdrm: Deconstruct DSS features

[Laurent Pinchart]

Hi Tomi,

On Tuesday 08 Aug 2017 16:04:57 Tomi Valkeinen wrote:
> On 08/08/17 16:02, Laurent Pinchart wrote:
> >> Patch 9 doesn't compile, it's referring to DSI_MODEL_OMAP4 which is not
> >> defined.
> > 
> > I might have forgotten to compile-test all patches individually after
> > reordering them, I'm sorry for that. I'm fixing that now. If you can push
> > your -next branch with patches 2-8 I can rebase on top of that, otherwise
> > I'll keep the v4.13-rc2 base.
> 
> Please keep them based on v4.13-rc for now.

The easiest fix is likely to move "drm: omapdrm: dsi: Store DSI model and PLL 
hardware data in OF data" before "drm: omapdrm: dsi: Handle pin muxing 
internally". Could you review that patch ? If you're fine with it let's just 
move it.

> There are still some patches in my current branch of which I'm not 100% sure
> if I should push them (the OMAP_BO flags patches, ping on them ;), so I
> might end up rebasing.

I'll try to review those today.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 00/35] omapdrm: Deconstruct DSS features

[Tomi Valkeinen]

On 08/08/17 16:02, Laurent Pinchart wrote:

>> Patch 9 doesn't compile, it's referring to DSI_MODEL_OMAP4 which is not
>> defined.
> 
> I might have forgotten to compile-test all patches individually after 
> reordering them, I'm sorry for that. I'm fixing that now. If you can push 
> your 
> -next branch with patches 2-8 I can rebase on top of that, otherwise I'll 
> keep 
> the v4.13-rc2 base.

Please keep them based on v4.13-rc for now. There are still some patches
in my current branch of which I'm not 100% sure if I should push them
(the OMAP_BO flags patches, ping on them ;), so I might end up rebasing.

 Tomi



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 v3 00/35] omapdrm: Deconstruct DSS features

[Laurent Pinchart]

Hi Tomi,

On Tuesday 08 Aug 2017 15:56:10 Tomi Valkeinen wrote:
> On 05/08/17 01:43, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch series is a third version of the code previously posted as
> > "[PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform
> > code".
> > 
> > The omapdss/omapdrm initialization code is quite a mess. The physical
> > devices are instantiated from DT, but two virtual devices named omapdrm
> > and omapdss are instanciated from platform code to pass various pieces of
> > platform data to the drivers.
> > 
> > The omapdrm and omapdss platform devices are currently used to pass data
> > and function pointers from board code to the drivers for the purpose of
> > 
> > - identifying the OMAP SoC revision
> > - controlling the DSI pads
> > - configuring bus throughput
> > 
> > It turns out that all these can be handled in the omapdrm and omapdss
> > drivers without the need for platform data.
> > 
> > - The SoC revision is used to identify the version of various DSS IP
> > cores,
> > which can instead be done through compatible string matching (with the
> > help of soc_device_match() in two cases where ES version is needed).
> > 
> > - The DSI pads control can be performed by the driver directly without
> > calling board code, accessing the related registers through syscon.
> > 
> > - Bus throughput control is implemented in mach-omap2 as a no-op, so we
> > can
> > just drop the code.
> > 
> > This patch series starts with a new patch that fixes soc_device_match()
> > usage on OMAP2+. It turned out that OMAP2+ registers SoC device
> > attributes at late init time, making soc_device_match() impossible to use
> > for drivers at probe time, which is unfortunately the location where the
> > feature is most needed.
> > 
> > The next five patches (02/35 to 06/35) are small and simple unneeded or
> > unused code removal. The next two patches (07/35 and 08/35) are cleanups
> > that make sense by themselves and will be needed by later refactoring.
> 
> I've picked patches 2-8 (inclusive). I think those can be applied
> already, even if the rest of the series would need more work.

I agree, let's try to apply as many as possible.

> Patch 9 doesn't compile, it's referring to DSI_MODEL_OMAP4 which is not
> defined.

I might have forgotten to compile-test all patches individually after 
reordering them, I'm sorry for that. I'm fixing that now. If you can push your 
-next branch with patches 2-8 I can rebase on top of that, otherwise I'll keep 
the v4.13-rc2 base.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 00/35] omapdrm: Deconstruct DSS features

[Tomi Valkeinen]

Hi Laurent,

On 05/08/17 01:43, Laurent Pinchart wrote:
> Hello,
> 
> This patch series is a third version of the code previously posted as
> "[PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code".
> 
> The omapdss/omapdrm initialization code is quite a mess. The physical devices
> are instantiated from DT, but two virtual devices named omapdrm and omapdss
> are instanciated from platform code to pass various pieces of platform data to
> the drivers.
> 
> The omapdrm and omapdss platform devices are currently used to pass data and
> function pointers from board code to the drivers for the purpose of
> 
> - identifying the OMAP SoC revision
> - controlling the DSI pads
> - configuring bus throughput
> 
> It turns out that all these can be handled in the omapdrm and omapdss drivers
> without the need for platform data.
> 
> - The SoC revision is used to identify the version of various DSS IP cores,
> which can instead be done through compatible string matching (with the help of
> soc_device_match() in two cases where ES version is needed).
> 
> - The DSI pads control can be performed by the driver directly without calling
> board code, accessing the related registers through syscon.
> 
> - Bus throughput control is implemented in mach-omap2 as a no-op, so we can
> just drop the code.
> 
> This patch series starts with a new patch that fixes soc_device_match() usage
> on OMAP2+. It turned out that OMAP2+ registers SoC device attributes at late
> init time, making soc_device_match() impossible to use for drivers at probe
> time, which is unfortunately the location where the feature is most needed.
> 
> The next five patches (02/35 to 06/35) are small and simple unneeded or unused
> code removal. The next two patches (07/35 and 08/35) are cleanups that make
> sense by themselves and will be needed by later refactoring.

I've picked patches 2-8 (inclusive). I think those can be applied
already, even if the rest of the series would need more work.

Patch 9 doesn't compile, it's referring to DSI_MODEL_OMAP4 which is not
defined.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101881] [regression] 32bit steam games segfault when launched with DRI_PRIME=1

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101881

--- Comment #18 from Mike Lothian  ---
So with llvm only compiled with debugging switched on I get these stack traces
when trying to launch glxgears (32bit)

fireburn@axion ~ $ DISPLAY=:0 DRI_PRIME=1 glxgears-x86
*** Error in `glxgears-x86': malloc(): memory corruption: 0xeef062a0 ***
=== Backtrace: =
/lib32/libc.so.6(+0x6deb8)[0xf7a09eb8]
/lib32/libc.so.6(+0x75e94)[0xf7a11e94]
/lib32/libc.so.6(+0x7886a)[0xf7a1486a]
/lib32/libc.so.6(__libc_malloc+0x73)[0xf7a16043]
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/32/libstdc++.so.6(_Znwj+0x27)[0xf78260e7]
/usr/lib/llvm/6/lib32/libLLVMTarget.so.6(LLVMAddTargetLibraryInfo+0x34)[0xf5ed5b04]
/usr/lib32/dri/radeonsi_dri.so(+0x5025f7)[0xf70d25f7]
/usr/lib32/dri/radeonsi_dri.so(+0x4f8550)[0xf70c8550]
/usr/lib32/dri/radeonsi_dri.so(+0x511a62)[0xf70e1a62]
/usr/lib32/dri/radeonsi_dri.so(+0x30d4e0)[0xf6edd4e0]
/lib32/libpthread.so.0(+0x6572)[0xf767a572]
/lib32/libc.so.6(clone+0x66)[0xf7a93e66]
=== Memory map: 
08048000-0804c000 r-xp  103:02 2125930  
/usr/bin/glxgears-x86
0804c000-0804d000 r--p 3000 103:02 2125930  
/usr/bin/glxgears-x86
0804d000-0804e000 rw-p 4000 103:02 2125930  
/usr/bin/glxgears-x86
09062000-0918f000 rw-p  00:00 0  [heap]
eef0-eef21000 rw-p  00:00 0
eef21000-ef00 ---p  00:00 0
ef00-ef021000 rw-p  00:00 0
ef021000-ef10 ---p  00:00 0
ef10-ef20 rw-s 100612000 00:06 1629 
/dev/dri/renderD128
ef20-ef221000 rw-p  00:00 0
ef221000-ef30 ---p  00:00 0
ef393000-ef3b4000 rw-p  00:00 0
ef3b4000-ef3b5000 ---p  00:00 0
ef3b5000-efbb5000 rw-p  00:00 0
efbb5000-efbd5000 rw-s 1004a3000 00:06 1629 
/dev/dri/renderD128
efbd5000-efbf5000 rw-s 100483000 00:06 1629 
/dev/dri/renderD128
efbf5000-efc15000 rw-s 100463000 00:06 1629 
/dev/dri/renderD128
efc15000-efc35000 rw-s 100443000 00:06 1629 
/dev/dri/renderD128
efc35000-efc36000 ---p  00:00 0
efc36000-f0436000 rw-p  00:00 0
f0436000-f0437000 ---p  00:00 0
f0437000-f0c37000 rw-p  00:00 0
f0c37000-f0c38000 ---p  00:00 0
f0c38000-f1438000 rw-p  00:00 0
f1438000-f1439000 ---p  00:00 0
f1439000-f1c39000 rw-p  00:00 0
f1c39000-f1c3a000 ---p  00:00 0
f1c3a000-f243a000 rw-p  00:00 0
f243a000-f243e000 r-xp  103:02 2027611  
/usr/lib32/libtxc_dxtn.so
f243e000-f243f000 r--p 3000 103:02 2027611  
/usr/lib32/libtxc_dxtn.so
f243f000-f244 rw-p 4000 103:02 2027611  
/usr/lib32/libtxc_dxtn.so
f244-f2441000 ---p  00:00 0
f2441000-f2c41000 rw-p  00:00 0
f2c41000-f2d82000 rw-s  103:03 32243724 
/home/fireburn/.cache/mesa/index
f2d82000-f2d8d000 r-xp  103:02 1572971  
/lib32/libnss_files-2.25.so
f2d8d000-f2d8e000 r--p a000 103:02 1572971  
/lib32/libnss_files-2.25.so
f2d8e000-f2d8f000 rw-p b000 103:02 1572971  
/lib32/libnss_files-2.25.so
f2d8f000-f2d9b000 r-xp  103:02 1573408  
/lib32/libnss_nis-2.25.so
f2d9b000-f2d9c000 r--p b000 103:02 1573408  
/lib32/libnss_nis-2.25.so
f2d9c000-f2d9d000 rw-p c000 103:02 1573408  
/lib32/libnss_nis-2.25.so
f2d9d000-f2db4000 r-xp  103:02 1573338  
/lib32/libnsl-2.25.so
f2db4000-f2db5000 r--p 00016000 103:02 1573338  
/lib32/libnsl-2.25.so
f2db5000-f2db6000 rw-p 00017000 103:02 1573338  
/lib32/libnsl-2.25.so
f2db6000-f2db8000 rw-p  00:00 0
f2db8000-f2dc r-xp  103:02 1573337  
/lib32/libnss_compat-2.25.so
f2dc-f2dc1000 r--p 7000 103:02 1573337  
/lib32/libnss_compat-2.25.so
f2dc1000-f2dc2000 rw-p 8000 103:02 1573337  
/lib32/libnss_compat-2.25.so
f2dc2000-f2dc3000 ---p  00:00 0
f2dc3000-f35c3000 rw-p  00:00 0
f35c3000-f3629000 r-xp  103:02 2027917  
/usr/lib64/llvm/6/lib32/libLLVMAsmParser.so.6.0.0svn
f3629000-f362a000 r--p 00065000 103:02 2027917  
/usr/lib64/llvm/6/lib32/libLLVMAsmParser.so.6.0.0svn
f362a000-f362b000 rw-p 00066000 103:02 2027917  
/usr/lib64/llvm/6/lib32/libLLVMAsmParser.so.6.0.0svn
f362b000-f36cc000 r-xp  103:02 2013356  
/usr/lib64/llvm/6/lib32/libLLVMDebugInfoCodeView.so.6.0.0svn
f36cc000-f36ce000 r--p 000a 103:02 2013356   

Re: [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch.

On Tuesday 25 Jul 2017 10:01:19 Daniel Vetter wrote:
> It's dead code, the core handles all this directly now. This also
> allows us to unexport drm_atomic_helper_plane_set_property.

I assume you meant drm_atomic_plane_set_property. With that fixed,

Reviewed-by: Laurent Pinchart 

> Signed-off-by: Daniel Vetter 
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> Cc: Mali DP Maintainers 
> Cc: Boris Brezillon 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Ben Skeggs 
> Cc: Tomi Valkeinen 
> Cc: Laurent Pinchart 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: Yannick Fertre 
> Cc: Philippe Cornu 
> Cc: Jyri Sarha 
> Cc: "Ville Syrjälä" 
> Cc: Rongrong Zou 
> Cc: Shawn Guo 
> Cc: Alexey Brodkin 
> Cc: Eric Engestrom 
> Cc: Chris Wilson 
> Cc: Rob Clark 
> Cc: Archit Taneja 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: intel-...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: Thomas Hellstrom 
> Cc: Maxime Ripard 
> ---
>  drivers/gpu/drm/arm/malidp_planes.c |  1 -
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  1 -
>  drivers/gpu/drm/drm_atomic.c|  3 +-
>  drivers/gpu/drm/drm_atomic_helper.c | 55 --
>  drivers/gpu/drm/exynos/exynos_drm_plane.c   |  1 -
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  1 -
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  1 -
>  drivers/gpu/drm/i915/intel_display.c|  2 -
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  2 -
>  drivers/gpu/drm/nouveau/nv50_display.c  |  1 -
>  drivers/gpu/drm/omapdrm/omap_plane.c|  1 -
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c |  1 -
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  1 -
>  drivers/gpu/drm/sti/sti_cursor.c|  1 -
>  drivers/gpu/drm/sti/sti_gdp.c   |  1 -
>  drivers/gpu/drm/sti/sti_hqvdp.c |  1 -
>  drivers/gpu/drm/stm/ltdc.c  |  1 -
>  drivers/gpu/drm/tilcdc/tilcdc_plane.c   |  1 -
>  include/drm/drm_atomic.h|  3 --
>  include/drm/drm_atomic_helper.h |  3 --
>  20 files changed, 1 insertion(+), 81 deletions(-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/omap: dma-buf: Constify dma_buf_ops structures.

[Tomi Valkeinen]

On 02/07/17 09:19, Arvind Yadav wrote:
> dma_buf_ops are not supposed to change at runtime. All functions
> working with dma_buf_ops provided by  work with
> const dma_buf_ops. So mark the non-const structs as const.
> 
> File size before:
>text  data bss dec hex filename
>1240   112   01352 548 
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.o
> 
> File size After adding 'const':
>text  data bss dec hex filename
>1352 0   01352 548 
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.o
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c 
> b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> index 0dbe030..a03bc36 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
> @@ -154,7 +154,7 @@ static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
>   return omap_gem_mmap_obj(obj, vma);
>  }
>  
> -static struct dma_buf_ops omap_dmabuf_ops = {
> +static const struct dma_buf_ops omap_dmabuf_ops = {
>   .map_dma_buf = omap_gem_map_dma_buf,
>   .unmap_dma_buf = omap_gem_unmap_dma_buf,
>   .release = omap_gem_dmabuf_release,
> 

Thanks! I've picked this and the 3 other constifying patches to omapdrm
tree.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101977

--- Comment #9 from Timothee Besset  ---
(In reply to Samuel Pitoiset from comment #6)
> The issue can't be reproduced with the traces here as well. But if you build
> the UE4 editor from github, the issue can be reproduced with LLVM6.0svn.

Have you modified the traces to include the call that triggers the crash? The
traces I uploaded only recorded the GL calls up to the last call before the
crash is triggered, so unless you know how to manually add a call, they won't
cause a 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

Re: [PATCH v7] drm/omap: Rework the rotation-on-crtc hack

[Tomi Valkeinen]

On 07/08/17 13:20, Maarten Lankhorst wrote:

> I want/need to rework the core property handling, and this hack is
> getting in the way. But since it's a non-standard propety only used by
> legacy userspace we know that this will only every be called from
> ioctl code. And never on some other free-standing state struct, where
> this old hack wouldn't work either.
> 
> v2: don't forget zorder and get_property!
> 
> v3: Shadow the legacy state to avoid locking issues in get_property
> (Maarten).
> 
> v4: Review from Laurent
> - Move struct omap_crtc_state into omap_crtc.c
> - Clean up comments.
> - Don't forget to copy the shadowed state over on duplicate.
> 
> v5: Don't forget to update the reset handler (Maarten).
> v6: Update omap_crtc_state shadow values in omap_crtc_atomic_check (Maarten).
> v7:
> - Fix get_property to return 0 and set value in *val (Maarten).
> - Update comment in set_property for changes in v6 (Maarten).
> 
> Reviewed-by: Laurent Pinchart  (v4)
> Cc: Maarten Lankhorst 
> Cc: Tomi Valkeinen  Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 124 
> 
>  1 file changed, 85 insertions(+), 39 deletions(-)

Thanks, works now.

Reviewed-by: Tomi Valkeinen 

 Tomi



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 1/3] drm/bridge: make drm_connector_funcs structures const

[Laurent Pinchart]

Hi Bhumika,

Thank you for the patch.

On Tuesday 08 Aug 2017 16:58:30 Bhumika Goyal wrote:
> Make these const as they are only passed to the function
> drm_connector_init and the corresponding argument is of type const.
> Done using Coccinelle
> 
> @match disable optional_qualifier@
> identifier s;
> @@
> static struct drm_connector_funcs s = {...};
> 
> @ref@
> position p;
> identifier match.s;
> @@
> s@p
> 
> @good1@
> identifier match.s;
> expression e1,e2;
> position ref.p;
> @@
> drm_connector_init(e1,e2,@p,...)
> 
> @bad depends on  !good1@
> position ref.p;
> identifier match.s;
> @@
> s@p
> 
> @depends on forall !bad disable optional_qualifier@
> identifier match.s;
> @@
> static
> + const
> struct drm_connector_funcs s;
> 
> Signed-off-by: Bhumika Goyal 

I can't judge the semantic patch, but the C code change looks good to me.

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index ff9792d..ee16635
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -785,7 +785,7 @@ static int adv7511_connector_get_modes(struct
> drm_connector *connector) return adv7511_detect(adv, connector);
>  }
> 
> -static struct drm_connector_funcs adv7511_connector_funcs = {
> +static const struct drm_connector_funcs adv7511_connector_funcs = {
>   .dpms = drm_atomic_helper_connector_dpms,
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .detect = adv7511_connector_detect,

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] dma-buf changes for ttm and amdgpu

[Daniel Vetter]

On Mon, Aug 07, 2017 at 05:32:20PM -0400, Alex Deucher wrote:
> We have some changes in ttm and amdgpu that depend on these patches.
> Sumit, can you pull these in via dma-buf or should I roll them up
> through my amdgpu tree?

We could just throw them all into drm-misc too, that's kinda what it's for
(dma-buf doesn't exist anymore, all the dma-buf stuff is in drm-misc now).
And you have commit rights for that even :-)
-Daniel

> 
> Christian König (3):
>   dma-buf: dma_fence_put is NULL safe
>   dma-buf: add reservation_object_copy_fences
>   dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2
> 
>  drivers/dma-buf/reservation.c | 97 
> +--
>  include/linux/reservation.h   |  3 ++
>  2 files changed, 78 insertions(+), 22 deletions(-)
> 
> -- 
> 2.5.5
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101977

--- Comment #8 from Samuel Pitoiset  ---
Yes for both.

-- 
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 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101977

--- Comment #7 from Marek Olšák  ---
Does the issue occur with any of these:

R600_DEBUG=mono
R600_DEBUG=nooptvariant

-- 
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 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101977

--- Comment #6 from Samuel Pitoiset  ---
The issue can't be reproduced with the traces here as well. But if you build
the UE4 editor from github, the issue can be reproduced with LLVM6.0svn.

-- 
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/3] drm/etnaviv: add thermal dependency

[Lucas Stach]

Hi Arnd,

Am Mittwoch, den 26.07.2017, 15:53 +0200 schrieb Arnd Bergmann:
> When CONFIG_THERMAL is enabled as a loadable module, and etnaviv is
> built-in, we get a link error:
> 
> drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind':
> etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0x34): undefined reference to 
> `thermal_of_cooling_device_register'
> etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0xe0): undefined reference to 
> `thermal_cooling_device_unregister'
> drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_unbind':
> etnaviv_gpu.c:(.text.etnaviv_gpu_unbind+0xf0): undefined reference to 
> `thermal_cooling_device_unregister'
> 
> This adds a Kconfig dependency to prevent etnaviv from being built-in
> with CONFIG_THERMAL=m, while still allowing the valid configurations.
> Unfortunately, simply adding the dependency here breaks Kconfig through
> a dependency loop involving lots of symbols all the way until ACPI_VIDEO,
> which is the only video driver that explicitly selects 'THERMAL'. Turning
> this into a 'depends on' addresses the problem.
> For completeness, I'm also removing the redundant 'select THERMAL'
> from INTEL_MENLOW, so no other driver uses that statement.
> 
> Fixes: bcdfb5e56dc5 ("drm/etnaviv: add etnaviv cooling device")
> Signed-off-by: Arnd Bergmann 
> ---
> v2: spend more thought on ACPI_VIDEO dependencies, as we need another
> patch before this.
> ---
>  drivers/acpi/Kconfig| 2 +-
>  drivers/gpu/drm/etnaviv/Kconfig | 1 +
>  drivers/platform/x86/Kconfig| 1 -

I would like to take this patch, but I'm not sure why it includes x86
and ACPI hunks.

Regards,
Lucas

>  3 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index a8f5a40e2914..1282b2936164 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -184,7 +184,7 @@ config ACPI_VIDEO
>   tristate "Video"
>   depends on X86
>   depends on INPUT
> - select THERMAL
> + depends on THERMAL
>   select BACKLIGHT_CLASS_DEVICE
>   select BACKLIGHT_LCD_SUPPORT
>   default y
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
> index 71cee4e9fefb..1d6c744e7924 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -3,6 +3,7 @@ config DRM_ETNAVIV
>   tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
>   depends on DRM
>   depends on ARCH_MXC || ARCH_DOVE || (ARM && COMPILE_TEST)
> + depends on THERMAL || THERMAL=n
>   depends on MMU
>   select SHMEM
>   select SYNC_FILE
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 2d9fb46a8d11..d9238e9ff54a 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -532,7 +532,6 @@ config SENSORS_HDAPS
>  config INTEL_MENLOW
>   tristate "Thermal Management driver for Intel menlow platform"
>   depends on ACPI_THERMAL
> - select THERMAL
>   ---help---
> ACPI thermal management enhancement driver on
> Intel Menlow platform.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101977

--- Comment #5 from Marek Olšák  ---
This can't be reproduce with LLVM 6.0svn and Radeon Fury. Trying LLVM 3.9...

-- 
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 V2 12/23] drm/etnaviv: use 'sync points' for performance monitor requests

[Lucas Stach]

Am Samstag, den 22.07.2017, 11:53 +0200 schrieb Christian Gmeiner:
> With 'sync points' we can sample the reqeustes perform signals
> before and/or after the submited command buffer.
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 106 
> +++---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h |   1 +
>  2 files changed, 86 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 93e3f14c0599..c176781788ac 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1318,12 +1318,48 @@ void etnaviv_gpu_pm_put(struct etnaviv_gpu *gpu)
>   pm_runtime_put_autosuspend(gpu->dev);
>  }
>  
> +static void sync_point_perfmon_sample(struct etnaviv_gpu *gpu,
> + struct etnaviv_event *event, unsigned int flags)
> +{
> + const struct etnaviv_cmdbuf *cmdbuf = event->cmdbuf;
> + unsigned int i;
> +
> + for (i = 0; i < cmdbuf->nr_pmrs; i++) {
> + const struct etnaviv_perfmon_request *pmr = cmdbuf->pmrs + i;
> +
> + if (pmr->flags == flags)
> + etnaviv_perfmon_process(gpu, pmr);
> + }
> +}
> +
> +static void sync_point_perfmon_sample_pre(struct etnaviv_gpu *gpu,
> + struct etnaviv_event *event)
> +{
> + sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_PRE);
> +}
> +
> +static void sync_point_perfmon_sample_post(struct etnaviv_gpu *gpu,
> + struct etnaviv_event *event)
> +{
> + const struct etnaviv_cmdbuf *cmdbuf = event->cmdbuf;
> + unsigned int i;
> +
> + sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_POST);
> +
> + for (i = 0; i < cmdbuf->nr_pmrs; i++) {
> + const struct etnaviv_perfmon_request *pmr = cmdbuf->pmrs + i;
> +
> + *pmr->bo_vma = pmr->sequence;
> + }
> +}
> +
> +
>  /* add bo's to gpu's ring, and kick gpu: */
>  int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>   struct etnaviv_gem_submit *submit, struct etnaviv_cmdbuf *cmdbuf)
>  {
>   struct dma_fence *fence;
> - unsigned int event, i;
> + unsigned int i, nr_events, event[3];
>   int ret;
>  
>   ret = etnaviv_gpu_pm_get_sync(gpu);
> @@ -1339,9 +1375,21 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>*
>*/
>  
> - ret = event_alloc(gpu, 1, );
> - if (!ret) {
> - DRM_ERROR("no free event\n");
> +  /*
> +  * if there are performance monitor requests we need to have
> +  * - a sync point to re-configure gpu and process ETNA_PM_PROCESS_PRE
> +  *   requests.
> +  * - a sync point to re-configure gpu, process ETNA_PM_PROCESS_POST 
> requests
> +  *   and update the sequence number for userspace.
> +  */
> +  if (cmdbuf->nr_pmrs)
> + nr_events = 3;
> + else
> + nr_events = 1;

Indentation of comment and code is off here. Also I would prefer if
nr_events is just initialized to 1, so we can spare the else path.

> +
> + ret = event_alloc(gpu, nr_events, event);
> + if (ret < 0) {
> + DRM_ERROR("no free events\n");
>   goto out_pm_put;
>   }
>  
> @@ -1349,12 +1397,14 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>  
>   fence = etnaviv_gpu_fence_alloc(gpu);
>   if (!fence) {
> - event_free(gpu, event);
> + for (i = 0; i < nr_events; i++)
> + event_free(gpu, event[i]);
> +
>   ret = -ENOMEM;
>   goto out_unlock;
>   }
>  
> - gpu->event[event].fence = fence;
> + gpu->event[event[0]].fence = fence;
>   submit->fence = dma_fence_get(fence);
>   gpu->active_fence = submit->fence->seqno;
>  
> @@ -1364,7 +1414,19 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>   gpu->lastctx = cmdbuf->ctx;
>   }
>  
> - etnaviv_buffer_queue(gpu, event, cmdbuf);
> + if (cmdbuf->nr_pmrs) {
> + gpu->event[event[1]].sync_point = 
> _point_perfmon_sample_pre;
> + gpu->event[event[1]].cmdbuf = cmdbuf;
> + etnaviv_sync_point_queue(gpu, event[1]);
> + }
> +
> + etnaviv_buffer_queue(gpu, event[0], cmdbuf);
> +
> + if (cmdbuf->nr_pmrs) {
> + gpu->event[event[2]].sync_point = 
> _point_perfmon_sample_post;
> + gpu->event[event[2]].cmdbuf = cmdbuf;
> + etnaviv_sync_point_queue(gpu, event[2]);
> + }
>  
>   cmdbuf->fence = fence;
>   list_add_tail(>node, >active_cmd_list);
> @@ -1469,20 +1531,22 @@ static irqreturn_t irq_handler(int irq, void *data)
>   }
>  
>   fence = gpu->event[event].fence;
> - gpu->event[event].fence = NULL;
> - dma_fence_signal(fence);
> -
> - /*
> -  * Events can be processed out of order.  Eg,
> -  * - allocate 

Re: [PATCH v2 11/19] drm/i915: Use the drm_driver.dumb_destroy default

[Noralf Trønnes]

Den 07.08.2017 17.02, skrev Daniel Vetter:

On Sun, Aug 06, 2017 at 05:41:00PM +0200, Noralf Trønnes wrote:

drm_gem_dumb_destroy() is the drm_driver.dumb_destroy default,
so no need to set it.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Noralf Trønnes 

Reviewed-by: Daniel Vetter 

We haven't pulled drm-misc into drm-intel yet, so easier to merge to
drm-misc. Can you pls push it there?


Applied to drm-misc.
I do hope that people will tell me if they want to take a patch through
another tree than drm-misc rather than assume that I should know.

Noralf.


Thanks for doing this.
-Daniel


---
  drivers/gpu/drm/i915/i915_drv.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d82..4c96a72 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2755,7 +2755,6 @@ static struct drm_driver driver = {
  
  	.dumb_create = i915_gem_dumb_create,

.dumb_map_offset = i915_gem_mmap_gtt,
-   .dumb_destroy = drm_gem_dumb_destroy,
.ioctls = i915_ioctls,
.num_ioctls = ARRAY_SIZE(i915_ioctls),
.fops = _driver_fops,
--
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 15/19] drm/radeon: Use the drm_driver.dumb_destroy default

[Noralf Trønnes]

Den 07.08.2017 22.12, skrev Alex Deucher:

On Sun, Aug 6, 2017 at 11:41 AM, Noralf Trønnes  wrote:

drm_gem_dumb_destroy() is the drm_driver.dumb_destroy default,
so no need to set it.

Cc: Alex Deucher 
Cc: Christian König 
Signed-off-by: Noralf Trønnes 

Acked-by: Alex Deucher 


Thanks, applied to drm-misc.

Noralf.


---
  drivers/gpu/drm/radeon/radeon_drv.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index b401f16..f4becad 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -583,7 +583,6 @@ static struct drm_driver kms_driver = {
 .gem_close_object = radeon_gem_object_close,
 .dumb_create = radeon_mode_dumb_create,
 .dumb_map_offset = radeon_mode_dumb_mmap,
-   .dumb_destroy = drm_gem_dumb_destroy,
 .fops = _driver_kms_fops,

 .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
--
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 04/19] drm/sti: Use .dumb_map_offset and .dumb_destroy defaults

[Noralf Trønnes]

Den 07.08.2017 15.29, skrev Vincent ABRIOU:

Hi Noralf,

Thanks for the patch.
Acked-by: Vincent Abriou 


Thanks, applied to drm-misc.

Noralf.



On 08/06/2017 05:40 PM, Noralf Trønnes wrote:

This driver can use the drm_driver.dumb_destroy and
drm_driver.dumb_map_offset defaults, so no need to set them.

Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Signed-off-by: Noralf Trønnes 
---
   drivers/gpu/drm/sti/sti_drv.c | 2 --
   1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 06ef1e38..1700c54 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -175,8 +175,6 @@ static struct drm_driver sti_driver = {
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = _gem_cma_vm_ops,
.dumb_create = drm_gem_cma_dumb_create,
-   .dumb_map_offset = drm_gem_cma_dumb_map_offset,
-   .dumb_destroy = drm_gem_dumb_destroy,
.fops = _driver_fops,
   
   	.enable_vblank = sti_crtc_enable_vblank,




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 10/23] drm/etnaviv: add 'sync point' support

[Lucas Stach]

Am Samstag, den 22.07.2017, 11:53 +0200 schrieb Christian Gmeiner:
> In order to support performance counters in a sane way we need to provide
> a method to sync the GPU with the CPU. The GPU can process multpile command
> buffers/events per irq. With the help of a 'sync point' we can trigger an 
> event
> and stop the GPU/FE immediately. When the CPU is done with is processing it
> simply needs to restart the FE and the GPU will process the command stream.
> 
> Changes from v1 -> v2:
> - process sync point with a work item to keep irq as fast as possible
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 36 
> 
>  drivers/gpu/drm/etnaviv/etnaviv_drv.h|  1 +
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 25 ++
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h|  6 ++
>  4 files changed, 68 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> index ed9588f36bc9..9e7098e3207f 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> @@ -250,6 +250,42 @@ void etnaviv_buffer_end(struct etnaviv_gpu *gpu)
>   }
>  }
>  
> +/* Append a 'sync point' to the ring buffer. */
> +void etnaviv_sync_point_queue(struct etnaviv_gpu *gpu, unsigned int event)
> +{
> + struct etnaviv_cmdbuf *buffer = gpu->buffer;
> + unsigned int waitlink_offset = buffer->user_size - 16;
> + u32 dwords, target;
> +
> + /*
> +  * We need at most 3 dwords in the return target:
> +  * 1 event + 1 end + 1 wait + 1 link.
> +  */
> + dwords = 4;
> + target = etnaviv_buffer_reserve(gpu, buffer, dwords);
> +
> + /* Signal sync point event */
> + CMD_LOAD_STATE(buffer, VIVS_GL_EVENT, VIVS_GL_EVENT_EVENT_ID(event) |
> +VIVS_GL_EVENT_FROM_PE);
> +
> + /* Stop the FE to 'pause' the GPU */
> + CMD_END(buffer);
> +
> + /* Append waitlink */
> + CMD_WAIT(buffer);
> + CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
> + buffer->user_size - 4);
> +
> + /*
> +  * Kick off the 'sync point' command by replacing the previous
> +  * WAIT with a link to the address in the ring buffer.
> +  */
> + etnaviv_buffer_replace_wait(buffer, waitlink_offset,
> + VIV_FE_LINK_HEADER_OP_LINK |
> + VIV_FE_LINK_HEADER_PREFETCH(dwords),
> + target);
> +}
> +
>  /* Append a command buffer to the ring buffer. */
>  void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, unsigned int event,
>   struct etnaviv_cmdbuf *cmdbuf)
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h 
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> index 058389f93b69..f6cdd694ca51 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> @@ -101,6 +101,7 @@ int etnaviv_gem_new_userptr(struct drm_device *dev, 
> struct drm_file *file,
>  u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu);
>  u16 etnaviv_buffer_config_mmuv2(struct etnaviv_gpu *gpu, u32 mtlb_addr, u32 
> safe_addr);
>  void etnaviv_buffer_end(struct etnaviv_gpu *gpu);
> +void etnaviv_sync_point_queue(struct etnaviv_gpu *gpu, unsigned int event);
>  void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, unsigned int event,
>   struct etnaviv_cmdbuf *cmdbuf);
>  void etnaviv_validate_init(void);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index ce6c869e214f..bc1b96b4c7e9 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -25,6 +25,7 @@
>  #include "etnaviv_gpu.h"
>  #include "etnaviv_gem.h"
>  #include "etnaviv_mmu.h"
> +#include "etnaviv_perfmon.h"
>  #include "common.xml.h"
>  #include "state.xml.h"
>  #include "state_hi.xml.h"
> @@ -1353,6 +1354,7 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>   }
>  
>   gpu->event[event].fence = fence;
> + gpu->event[event].sync_point = NULL;
>   submit->fence = dma_fence_get(fence);
>   gpu->active_fence = submit->fence->seqno;
>  
> @@ -1398,6 +1400,23 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>   return ret;
>  }
>  
> +static void etnaviv_process_sync_point(struct etnaviv_gpu *gpu,
> + struct etnaviv_event *event)
> +{
> + u32 addr = gpu_read(gpu, VIVS_FE_DMA_ADDRESS);
> +
> + event->sync_point(gpu, event);
> + etnaviv_gpu_start_fe(gpu, addr + 2, 2);
> +}
> +
> +static void pmrs_worker(struct work_struct *work)
> +{
> + struct etnaviv_gpu *gpu = container_of(work, struct etnaviv_gpu,
> +pmrs_work);
> +
> + etnaviv_process_sync_point(gpu, >event[gpu->pmrs_event]);
> +}
> +
>  /*
>   * Init/Cleanup:
>   */
> @@ -1444,6 +1463,11 @@ static irqreturn_t irq_handler(int irq, void *data)
>  
>

Re: [PATCH V2 08/23] drm/etnaviv: copy pmrs from userspace

[Lucas Stach]

Am Samstag, den 22.07.2017, 11:53 +0200 schrieb Christian Gmeiner:
> Changes from v1 -> v2:
> - renamed submit_perfmon_request() to submit_perfmon_validate()
> - extended flags validation
> - added comment about offset 0
> - moved assigment of cmdbuf->nr_pmrs below the copy_from_user of the pmrs.
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 69 
> +++-
>  1 file changed, 67 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index 9c57b14dfcbf..91e35114d25c 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -21,6 +21,7 @@
>  #include "etnaviv_drv.h"
>  #include "etnaviv_gpu.h"
>  #include "etnaviv_gem.h"
> +#include "etnaviv_perfmon.h"
>  
>  /*
>   * Cmdstream submission:
> @@ -283,6 +284,54 @@ static int submit_reloc(struct etnaviv_gem_submit 
> *submit, void *stream,
>   return 0;
>  }
>  
> +static int submit_perfmon_validate(struct etnaviv_gem_submit *submit,
> + struct etnaviv_cmdbuf *cmdbuf,
> + const struct drm_etnaviv_gem_submit_pmr *pmrs,
> + u32 nr_pms)
> +{
> + u32 i;
> +
> + for (i = 0; i < nr_pms; i++) {
> + const struct drm_etnaviv_gem_submit_pmr *r = pmrs + i;
> + struct etnaviv_gem_submit_bo *bo;
> + int ret;
> +
> + ret = submit_bo(submit, r->read_idx, );
> + if (ret)
> + return ret;
> +
> + /* at offset 0 a sequence number gets stored used for userspace 
> sync */
> + if (r->read_offset == 0) {
> + DRM_ERROR("perfmon request: offset is 0");
> + return -EINVAL;
> + }
> +
> + if (r->read_offset >= bo->obj->base.size - sizeof(u32)) {
> + DRM_ERROR("perfmon request: offset %u outside object", 
> i);
> + return -EINVAL;
> + }
> +
> + if (!(r->flags & (ETNA_PM_PROCESS_PRE | ETNA_PM_PROCESS_POST))) 
> {

This isn't a proper validation, as it allows other bits to be set. This
should be:

if (r->flags & ~(ETNA_PM_PROCESS_PRE | ETNA_PM_PROCESS_POST))

> + DRM_ERROR("perfmon request: flags are not valid");
> + return -EINVAL;
> + }
> +
> + if (etnaviv_pm_req_validate(r)) {
> + DRM_ERROR("perfmon request: domain or signal not 
> valid");
> + return -EINVAL;
> + }
> +
> + cmdbuf->pmrs[i].flags = r->flags;
> + cmdbuf->pmrs[i].domain = r->domain;
> + cmdbuf->pmrs[i].signal = r->signal;
> + cmdbuf->pmrs[i].sequence = r->sequence;
> + cmdbuf->pmrs[i].offset = r->read_offset;
> + cmdbuf->pmrs[i].bo_vma = etnaviv_gem_vmap(>obj->base);
> + }
> +
> + return 0;
> +}
> +
>  static void submit_cleanup(struct etnaviv_gem_submit *submit)
>  {
>   unsigned i;
> @@ -306,6 +355,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
> *data,
>   struct etnaviv_drm_private *priv = dev->dev_private;
>   struct drm_etnaviv_gem_submit *args = data;
>   struct drm_etnaviv_gem_submit_reloc *relocs;
> + struct drm_etnaviv_gem_submit_pmr *pmrs;
>   struct drm_etnaviv_gem_submit_bo *bos;
>   struct etnaviv_gem_submit *submit;
>   struct etnaviv_cmdbuf *cmdbuf;
> @@ -347,11 +397,12 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, 
> void *data,
>*/
>   bos = kvmalloc_array(args->nr_bos, sizeof(*bos), GFP_KERNEL);
>   relocs = kvmalloc_array(args->nr_relocs, sizeof(*relocs), GFP_KERNEL);
> + pmrs = kvmalloc_array(args->nr_pmrs, sizeof(*pmrs), GFP_KERNEL);
>   stream = kvmalloc_array(1, args->stream_size, GFP_KERNEL);
>   cmdbuf = etnaviv_cmdbuf_new(gpu->cmdbuf_suballoc,
>   ALIGN(args->stream_size, 8) + 8,
> - args->nr_bos, 0);
> - if (!bos || !relocs || !stream || !cmdbuf) {
> + args->nr_bos, args->nr_pmrs);
> + if (!bos || !relocs || !pmrs || !stream || !cmdbuf) {
>   ret = -ENOMEM;
>   goto err_submit_cmds;
>   }
> @@ -373,6 +424,14 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, 
> void *data,
>   goto err_submit_cmds;
>   }
>  
> + ret = copy_from_user(pmrs, u64_to_user_ptr(args->pmrs),
> +  args->nr_pmrs * sizeof(*pmrs));
> + if (ret) {
> + ret = -EFAULT;
> + goto err_submit_cmds;
> + }
> + cmdbuf->nr_pmrs = args->nr_pmrs;
> +
>   ret = copy_from_user(stream, u64_to_user_ptr(args->stream),
>args->stream_size);
>   if (ret) {
> @@ -441,6 +500,10 @@ int 

Re: [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

[Vincent ABRIOU]

On 07/25/2017 10:01 AM, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now.
> 
> The only special case is nouveau and tda988x which used one function
> for both legacy modeset code and -nv50 atomic world instead of 2
> vtables. But amounts to exactly the same.
> 
> v2: Rebase over the panel/brideg refactorings in stm/ltdc.
> 
> Signed-off-by: Daniel Vetter 

[...]

>   drivers/gpu/drm/sti/sti_dvo.c  |  1 -
>   drivers/gpu/drm/sti/sti_hda.c  |  1 -
>   drivers/gpu/drm/sti/sti_hdmi.c |  1 -

Acked-by: Vincent Abriou 

BR
Vincent
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property

[Vincent ABRIOU]

On 07/25/2017 10:01 AM, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now. This also
> allows us to unexport drm_atomic_helper_plane_set_property.
> 
> Signed-off-by: Daniel Vetter 

[...]

>   drivers/gpu/drm/sti/sti_cursor.c|  1 -
>   drivers/gpu/drm/sti/sti_gdp.c   |  1 -
>   drivers/gpu/drm/sti/sti_hqvdp.c |  1 -

Acked-by: Vincent Abriou 

BR
Vincent
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/8] drm: Nuke drm_atomic_helper_connector_set_property

[Vincent ABRIOU]

On 07/25/2017 10:01 AM, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now. This also
> allows us to unexport drm_atomic_helper_connector_set_property.
> 
> The only special case is nouveau which used one function for both
> pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2
> vtables. But amounts to exactly the same.
> 
> What is rather strange here is how few drivers set this up, I suspect
> the earlier patch to handle properties in the core did end up fixing a
> pile of possible issues.
> 
> Signed-off-by: Daniel Vetter 

[...]

>   drivers/gpu/drm/sti/sti_hdmi.c  |  1 -

Acked-by: Vincent Abriou 

BR
Vincent
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 02/23] drm/etnaviv: make it possible to allocate multiple events

[Lucas Stach]

Am Samstag, den 22.07.2017, 11:53 +0200 schrieb Christian Gmeiner:
> This makes it possible to allocate multiple events under the event
> spinlock. This change is needed to support 'sync'-points.
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 31 ---
>  1 file changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index fa9c7bd98e9c..ab108b0ed573 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1137,10 +1137,12 @@ int etnaviv_gpu_fence_sync_obj(struct 
> etnaviv_gem_object *etnaviv_obj,
>   * event management:
>   */
>  
> -static unsigned int event_alloc(struct etnaviv_gpu *gpu)
> +static int event_alloc(struct etnaviv_gpu *gpu, unsigned nr_events,
> + unsigned int *events)
>  {
>   unsigned long ret, flags;
> - unsigned int event;
> + unsigned used, i;
> + int err = 0;
>  
>   ret = wait_for_completion_timeout(>event_free,
> msecs_to_jiffies(10 * 1));

This isn't obvious from the current code, but there are exactly as much
completions in the queue, as there are events. See initialization of the
completions in etnaviv_gpu_init(). This means the event allocation under
spinlock always succeeds if the wait hasn't timed out. To keep this
working you need to wait for the completion nr_event times, probably
changing this to an absolute timeout, so we don't lengthen the timeout
with the number of events.

> @@ -1149,16 +1151,24 @@ static unsigned int event_alloc(struct etnaviv_gpu 
> *gpu)
>  
>   spin_lock_irqsave(>event_spinlock, flags);
>  
> - /* find first free event */
> - event = find_first_zero_bit(gpu->event_bitmap, ETNA_NR_EVENTS);
> - if (event < ETNA_NR_EVENTS)
> + /* are there enough free events? */
> + used = bitmap_weight(gpu->event_bitmap, ETNA_NR_EVENTS);
> + if (used + nr_events > ETNA_NR_EVENTS) {
> + err = -EBUSY;
> + goto out;
> + }

This isn't necessary if you waited successfully for the completion to
signal nr_event times. The allocation is guaranteed to succeed in that
case. We just want an early return before even locking the spinlock,
giving back the already collected completions if one of the waits timed
out.

> +
> + for (i = 0; i < nr_events; i++) {
> + int event = find_first_zero_bit(gpu->event_bitmap, 
> ETNA_NR_EVENTS);
> +
> + events[i] = event;
>   set_bit(event, gpu->event_bitmap);
> - else
> - event = ~0U;
> + }
>  
> +out:
>   spin_unlock_irqrestore(>event_spinlock, flags);
>  
> - return event;
> + return err;
>  }
>  
>  static void event_free(struct etnaviv_gpu *gpu, unsigned int event)
> @@ -1327,10 +1337,9 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>*
>*/
>  
> - event = event_alloc(gpu);
> - if (unlikely(event == ~0U)) {
> + ret = event_alloc(gpu, 1, );
> + if (!ret) {
>   DRM_ERROR("no free event\n");
> - ret = -EBUSY;
>   goto out_pm_put;
>   }
>  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101881] [regression] 32bit steam games segfault when launched with DRI_PRIME=1

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101881

--- Comment #17 from Mike Lothian  ---
What arch would you recommend testing with?

-- 
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 2/7] drm/qxl: fix incorrect use of the lru_lock

[Liu, Monk]

Ack-by: Monk.Liu 


From: amd-gfx  on behalf of Christian 
König 
Sent: Tuesday, August 8, 2017 4:14:46 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Dave 
Airlie; Gerd Hoffmann
Subject: Re: [PATCH 2/7] drm/qxl: fix incorrect use of the lru_lock

Hi guys,

can I get an rb or at least an Acked-by for that one?

The code was obviously copied over from radeon where it wasn't correct
in the first place.

Thanks,
Christian.

Am 07.08.2017 um 17:48 schrieb Christian König:
> From: Christian König 
>
> The BO manager has its own lock and doesn't use the lru_lock.
>
> Signed-off-by: Christian König 
> ---
>   drivers/gpu/drm/qxl/qxl_ttm.c | 13 -
>   1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> index 0fdedee..07dc08d 100644
> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> @@ -454,15 +454,10 @@ void qxl_ttm_fini(struct qxl_device *qdev)
>   static int qxl_mm_dump_table(struct seq_file *m, void *data)
>   {
>struct drm_info_node *node = (struct drm_info_node *)m->private;
> - struct drm_mm *mm = (struct drm_mm *)node->info_ent->data;
> - struct drm_device *dev = node->minor->dev;
> - struct qxl_device *rdev = dev->dev_private;
> - struct ttm_bo_global *glob = rdev->mman.bdev.glob;
> + struct ttm_mem_type_manager *man = node->info_ent->data;
>struct drm_printer p = drm_seq_file_printer(m);
>
> - spin_lock(>lru_lock);
> - drm_mm_print(mm, );
> - spin_unlock(>lru_lock);
> + man->func->debug(man, );
>return 0;
>   }
>   #endif
> @@ -483,9 +478,9 @@ int qxl_ttm_debugfs_init(struct qxl_device *qdev)
>qxl_mem_types_list[i].show = _mm_dump_table;
>qxl_mem_types_list[i].driver_features = 0;
>if (i == 0)
> - qxl_mem_types_list[i].data = 
> qdev->mman.bdev.man[TTM_PL_VRAM].priv;
> + qxl_mem_types_list[i].data = 
> >mman.bdev.man[TTM_PL_VRAM];
>else
> - qxl_mem_types_list[i].data = 
> qdev->mman.bdev.man[TTM_PL_PRIV].priv;
> + qxl_mem_types_list[i].data = 
> >mman.bdev.man[TTM_PL_PRIV];
>
>}
>return qxl_debugfs_add_files(qdev, qxl_mem_types_list, i);


___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: bridge: synopsys/dw-hdmi: Provide default configuration function for HDMI 2.0 PHY

[Archit Taneja]

Hi,

On 08/08/2017 12:35 PM, Mark yao wrote:

On 2017年07月07日 23:47, Jose Abreu wrote:

Hi Archit,



Ping, Any update for this patch? Can it be landed?

This patch actually needed for rk3399 hdmi support


Sorry, missed this one.

There was a comment from Laurent mentioning whether we'd want to
put the PHY version in DT. There wasn't any response to that.

However, it seems like this commit shouldn't hurt if we do decide
to put PHY versions in DT later. Queuing it to drm-misc-next.

Archit



Best Regards
Mark


On 23-06-2017 10:36, Jose Abreu wrote:

Currently HDMI 2.0 PHYs do not have a default configuration function.

As *some* of the HDMI 2.0 PHYs have the same register layout as the 3D
PHYs we can provide the same default configuration function for both
and still let user overwrite this with custom configuration function
if needed.

If, for some reason, the PHY is custom or has a register different
register layout then custom configuration function *must* be provided
in order for the system to work correctly. As we prefer the pdata
provided configuration function over the internal one this change
will not make any impact in custom platforms.

This patch is based on today's drm-misc-next branch.

Signed-off-by: Jose Abreu 
Tested-by: Mark Yao 

This is needed for RK3399 support. Can you please apply it?

Best regards,
Jose Miguel Abreu


Cc: Kieran Bingham 
Cc: Laurent Pinchart 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Mark Yao 
Cc: Carlos Palminha 
Cc: Heiko Stübner 

Changes in v2:
- Rebased and refrased commit message
---

Hi All,

There as been a little confusion about dw-hdmi phys so I will expand a little 
bit
here so that I can base my decision about this patch and why does it only works
in some platforms.

First, if you read dw-hdmi.c code, you will see that there is an identification
register for the phy type being used. Unfortunatelly, this only states the phy 
type
and not the phy version.

Second, we have many HDMI 2.0 phys (so, same phy type: 0xf3) but, as you may 
have guessed,
HW team decided to change regbank between some versions.

Third and last, each phy in a SoC has unique characteristics, so each phy 
(event if
they are the same version) will have different PLL configuration parameters.

Given all this I managed to conclude that Mark's phy is still an HDMI 2.0 phy 
but with
the same register layout as previous 3D PHY's. I found at least 2 phys with the 
same
register layout and only 1 phy which has a different layout, so I think 
majority wins
here and we should let the default configuration function for HDMI 2.0 phys be 
the same
one as the 3D.

Short story: There is no way to correctly identify, at runtime, the phy version 
being
used by the controller so we can't provide a default configuration function. We 
can,
however assume that most of the HDMI 2.0 phys will have the 3D layout BUT each 
developer
must confirm that the layout in its SoC is the expected one and if not, provide 
a custom
configuration function.

Best regards,
Jose Miguel Abreu

  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ead1124..10c8d8c 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2170,6 +2170,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
  .name = "DWC HDMI 2.0 TX PHY",
  .gen = 2,
  .has_svsret = true,
+.configure = hdmi_phy_configure_dwc_hdmi_3d_tx,
  }, {
  .type = DW_HDMI_PHY_VENDOR_PHY,
  .name = "Vendor PHY",








--
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

[Bug 101881] [regression] 32bit steam games segfault when launched with DRI_PRIME=1

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101881

--- Comment #16 from Gregor Münch  ---
Since you compile with -march=native and using Skylake, you might also hit:
https://bugs.freedesktop.org/show_bug.cgi?id=101484

Just a guess though.

-- 
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