[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

[bugzilla-daemon]

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

--- Comment #1 from Michel Dänzer  ---
Can you bisect which Mesa Git commit introduced the issue?

-- 
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 102300] Missing 1920x1080_59.94Hz mode (Second monitor shows black screen but has signal)

[bugzilla-daemon]

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

--- Comment #4 from Michel Dänzer  ---
Please attach the Xorg configuration snippets you created in
/etc/X11/xorg.conf.d and/or /usr/share/X11/xorg.conf.d , in particular anything
related to a mode named "1920x1080_60.00".

-- 
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 196635] amdgpu clinfo hangs with SI

[bugzilla-daemon]

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

--- Comment #12 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Janpieter Sollie from comment #11)
> disabling CIK support in my kernel and upgrading it to rc6 solved the
> problem.
> Probably CIK and SI are not really cooperating properly yet.

Weird, does rc6 still work with CIK support enabled?

-- 
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 98324] [DC] amd-staging-4.7: problems with unblanking displays when monitors are switched off

[bugzilla-daemon]

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

--- Comment #6 from Darren Salt  ---
That patch makes no difference to this problem.

-- 
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 101731] System freeze with AMDGPU when playing The Witcher 3

[bugzilla-daemon]

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

--- Comment #33 from Shmerl  ---
Created attachment 133707
  --> https://bugs.freedesktop.org/attachment.cgi?id=133707=edit
Save file near freeze area (Devil's Pit, Velen)

Just turn around a bit, especially looking at direction of the sun seems to
trigger the freeze.

-- 
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 101731] System freeze with AMDGPU when playing The Witcher 3

[bugzilla-daemon]

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

--- Comment #32 from Shmerl  ---
The problem still happen with kernel 4.13:

penGL renderer string: AMD Radeon (TM) RX 480 Graphics (POLARIS10 / DRM 3.18.0
/ 4.13.0-rc5-amd64, LLVM 5.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.0-devel
(git-f24cf82d6d)

I'm using latest Wine master with needed patches.

-- 
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 0/3] constify drm i2c_device_id

[Arvind Yadav]

Hi Daniel,


On Tuesday 22 August 2017 12:01 PM, Daniel Vetter wrote:

On Sat, Aug 19, 2017 at 11:58:17PM +0530, Arvind Yadav wrote:

i2c_device_id are not supposed to change at runtime. All functions
working with i2c_device_id provided by  work with
const i2c_device_id. So mark the non-const structs as const.

All applied.

btw I think this isn't your first series, and we're trying to keep some of
the trivial mistakes around in drm, as an easy way for newbies to get into
the subsystem with their first patch.

We'd like more regular contributors to tackle some of the more involved
cleanup tasks, which should also be more valuable to the subsystem:

file:///home/daniel/linux/src/Documentation/output/gpu/todo.html#todo

I want to contribute drm and others subsystem. If you can guide me.
It will helpful for me.

Cheers, Daniel


Arvind Yadav (3):
   [PATCH 1/3] drm: i2c: ch7006: constify i2c_device_id
   [PATCH 2/3] drm: i2c: sil164: constify i2c_device_id
   [PATCH 3/3] drm: i2c: tda998x: constify i2c_device_id

  drivers/gpu/drm/i2c/ch7006_drv.c  | 2 +-
  drivers/gpu/drm/i2c/sil164_drv.c  | 2 +-
  drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

--
2.7.4

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

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

Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter

[Bjorn Helgaas]

On Mon, Aug 21, 2017 at 11:53:01AM +0100, Lorenzo Pieralisi wrote:
> On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:
> > A system without PCI legacy resources (e.g. ARM64) may find that no
> > default/boot VGA device has been marked, because the VGA arbiter
> > checks for legacy resource decoding before marking a card as default.
> 
> I do not understand this paragraph, in particular:
> 
> - "A system without PCI legacy resources (e.g. ARM64)". What does this
>   mean ? I take this as "ARM64 does not support IO space"; if a PCI host
>   bridge supports IO space, there is nothing from an architectural
>   point of view that prevents an MMIO based IO space implementation to
>   work on ARM64. It is PCI bridge specific, not arch specific.

This reference to ARM64 is the same thing I stumbled over.  Maybe it
could be written along the lines of:

  The VGA arbiter selects a default VGA device that is enabled and
  reachable via the legacy VGA resources (mem 0xa-0xb, io
  0x3b0-0x3bb, io 0x3c0-0x3df, etc).

  If there is no such device, e.g., because there's no enabled VGA
  device, the host bridge doesn't support access to those legacy
  resources, or a PCI-PCI bridge doesn't have VGA Enable set, a
  platform may select an arbitrary device by calling
  vga_set_default_device().

Then I think this patch changes the previous behavior by allowing the
arbiter to select a device that is enabled and has a driver but may
not be reachable via the legacy VGA resources.

I don't know what all the consequences of that would be, but it does
muddy the VGA arbiter waters a bit.  AIUI, the main reason for the
arbiter is to allow multiple legacy VGA devices by manipulating bridge
VGA Enable bits so only one receives the legacy resources at a time.

These devices that do not need the legacy resources don't need that
special treatment because they don't care about the bridge VGA Enable
bits and several can coexist in the system with no need for VGA
arbitration.

I guess the powerpc fixup_vga() already selects a device that doesn't
need the VGA resources, so we already have that situation.

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

Re: [PATCH v4 0/5] Support for LEGO MINDSTORMS EV3 LCD display

[Sekhar Nori]

On Monday 07 August 2017 11:09 PM, David Lechner wrote:

>   ARM: dts: da850-lego-ev3: Add node for LCD display
>   ARM: davinci_all_defconfig: enable tinydrm and ST7586

Queuing these two patches (4/5 and 5/5) through davinci tree.

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

Re: [PATCH 15/15] usb: make device_type const

[Heikki Krogerus]

On Sat, Aug 19, 2017 at 01:52:26PM +0530, Bhumika Goyal wrote:
> Make this const as it is only stored in the type field of a device
> structure, which is const.
> Done using Coccinelle.
> 
> Signed-off-by: Bhumika Goyal 

Acked-by: Heikki Krogerus 

> ---
>  drivers/usb/common/ulpi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> index 930e8f3..4aa5195 100644
> --- a/drivers/usb/common/ulpi.c
> +++ b/drivers/usb/common/ulpi.c
> @@ -135,7 +135,7 @@ static void ulpi_dev_release(struct device *dev)
>   kfree(to_ulpi_dev(dev));
>  }
>  
> -static struct device_type ulpi_dev_type = {
> +static const struct device_type ulpi_dev_type = {
>   .name = "ulpi_device",
>   .groups = ulpi_dev_attr_groups,
>   .release = ulpi_dev_release,

Thanks,

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

[Bug 196733] GM107 video card displays blank screen after 4.12 update with error EDID checksum

[bugzilla-daemon]

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

Ilia Mirkin (imir...@alum.mit.edu) changed:

   What|Removed |Added

 CC||imir...@alum.mit.edu

--- Comment #1 from Ilia Mirkin (imir...@alum.mit.edu) ---
You need

https://github.com/skeggsb/linux/commit/13a86519202c5d119d83640d6f781f3181205d2c

(which is in 4.13-rcN)

-- 
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 196733] New: GM107 video card displays blank screen after 4.12 update with error EDID checksum

[bugzilla-daemon]

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

Bug ID: 196733
   Summary: GM107 video card displays blank screen after 4.12
update with error EDID checksum
   Product: Drivers
   Version: 2.5
Kernel Version: 4.12.8
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: mrlhwlibe...@gmail.com
Regression: No

Created attachment 258057
  --> https://bugzilla.kernel.org/attachment.cgi?id=258057=edit
dmesg

After upgrading from kernel 4.11 to 4.12, I cannot use discrete video card mode
for my Thinkpad P50 with GM107 GPU (Quandro M1000M). It will boot into blank
screen for the laptop screen. In the external screen, the console will display
some very weird font. Startx will result in blank screen again.

I tried dmesg and found error message. Full dmesg is attached.


[2.897407] nouveau :01:00.0: NVIDIA GM107 (117310a2)


[3.242850] nouveau :01:00.0: eDP-1: EDID is invalid:
[3.242851]  [00] BAD  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[3.242852]  [00] BAD  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[3.242852]  [00] BAD  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[3.242852]  [00] BAD  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[3.242853]  [00] BAD  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[3.242853]  [00] BAD  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[3.242854]  [00] BAD  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[3.242854]  [00] BAD  00 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 ff
[3.242855] nouveau :01:00.0: DRM: DDC responded, but no EDID for eDP-1

Downgrading to kernel 4.11.5, the GPU in discrete mode works fine. It doesn't
have the EDID invalid error. 
The error persists even on the latest 4.12.8.
The hybrid mode GPU works fine for both kernels though.

-- 
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 98324] [DC] amd-staging-4.7: problems with unblanking displays when monitors are switched off

[bugzilla-daemon]

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

--- Comment #5 from dwagner  ---
JFYI: A patch attached to report
https://bugs.freedesktop.org/show_bug.cgi?id=102323 provided some improved
behaviour regarding switched-off HDMI displays.

-- 
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 102323] [DC] System crashes when woken up from S3 sleep while HDMI display is switched off

[bugzilla-daemon]

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

--- Comment #3 from dwagner  ---
The good news: Your draft fix works for me - the system no longer crashes when
woken up from S3 with HDMI display off. Thanks a lot for this really important
fix.


The mediocre news: Lots of scary messages are logged by amdgpu, as reported by
"dmesg". I'll split this into separate parts:

Part 1: Scary amdgpu messages when booting (with display on, only console, no
X11):

[1.246652] amdgpu: [powerplay] 
failed to send message 309 ret is 254 
[1.246670] amdgpu: [powerplay] 
failed to send pre message 14e ret is 254 
...
[1.298809] [ cut here ]
[1.298817] WARNING: CPU: 14 PID: 156 at
drivers/gpu/drm/drm_mode_object.c:237 drm_object_property_set_value+0x5d/0x70
[drm]
[1.298817] Modules linked in: amdgpu(+) i2c_algo_bit ttm drm_kms_helper
syscopyarea sysfillrect sysimgblt fb_sys_fops drm xfs libcrc32c crc32c_generic
crc32c_intel dm_crypt dm_mod dax nvme nvme_core i2c_dev
[1.298824] CPU: 14 PID: 156 Comm: modprobe Not tainted 4.13.0-rc5-amd+ #4
[1.298824] Hardware name: System manufacturer System Product Name/PRIME
X370-PRO, BIOS 0807 07/19/2017
[1.298825] task: 8807f69fd280 task.stack: c90003f1c000
[1.298831] RIP: 0010:drm_object_property_set_value+0x5d/0x70 [drm]
[1.298831] RSP: 0018:c90003f1f850 EFLAGS: 00010246
[1.298832] RAX: a04b4c80 RBX: 8807f54da000 RCX:
8807f54da148
[1.298832] RDX:  RSI: 8807f7295a80 RDI:
8807f54da028
[1.298833] RBP: c90003f1f850 R08: 0009 R09:
8807f6f08500
[1.298833] R10: 8807fa650b90 R11: 0039 R12:
8807f58d
[1.298833] R13:  R14: 8807f54da028 R15:
8807f58d
[1.298834] FS:  7fd4b38cdb40() GS:88081ef8()
knlGS:
[1.298834] CS:  0010 DS:  ES:  CR0: 80050033
[1.298835] CR2:  CR3: 0007f6f15000 CR4:
003406e0
[1.298835] Call Trace:
[1.298876]  amdgpu_dm_add_sink_to_freesync_module+0x8f/0x1c0 [amdgpu]
[1.298909]  amdgpu_dm_update_connector_after_detect+0xb9/0x200 [amdgpu]
[1.298941]  amdgpu_dm_initialize_drm_device+0x355/0x650 [amdgpu]
[1.298943]  ? printk+0x52/0x6e
[1.298974]  ? mod_freesync_create+0x13e/0x190 [amdgpu]
[1.299005]  amdgpu_dm_init+0x15f/0x270 [amdgpu]
[1.299035]  dm_hw_init+0x12/0x20 [amdgpu]
[1.299061]  amdgpu_device_init+0xd12/0x1550 [amdgpu]
[1.299063]  ? alloc_pages_current+0x6a/0xd0
[1.299064]  ? kmalloc_order_trace+0x2f/0xe0
[1.299089]  amdgpu_driver_load_kms+0x8b/0x2d0 [amdgpu]
[1.299095]  drm_dev_register+0x146/0x1d0 [drm]
[1.299120]  amdgpu_pci_probe+0x113/0x150 [amdgpu]
[1.299122]  local_pci_probe+0x42/0xa0
[1.299122]  ? pci_assign_irq+0x2b/0x120
[1.299124]  pci_device_probe+0x18d/0x1a0
[1.299126]  driver_probe_device+0x2ff/0x450
[1.299127]  __driver_attach+0xa4/0xe0
[1.299128]  ? driver_probe_device+0x450/0x450
[1.299129]  bus_for_each_dev+0x6e/0xb0
[1.299129]  driver_attach+0x1e/0x20
[1.299130]  bus_add_driver+0x1d0/0x270
[1.299131]  ? 0xa0577000
[1.299132]  driver_register+0x60/0xe0
[1.299132]  ? 0xa0577000
[1.299133]  __pci_register_driver+0x4c/0x50
[1.299158]  amdgpu_init+0x91/0xa4 [amdgpu]
[1.299159]  do_one_initcall+0x50/0x190
[1.299160]  ? __vunmap+0x81/0xb0
[1.299162]  ? kmem_cache_alloc_trace+0x14a/0x1b0
[1.299162]  ? vfree+0x2e/0x70
[1.299164]  do_init_module+0x5f/0x1e9
[1.299165]  load_module+0x24de/0x2af0
[1.299167]  SyS_finit_module+0x101/0x120
[1.299168]  ? SyS_finit_module+0x101/0x120
[1.299170]  entry_SYSCALL_64_fastpath+0x13/0x94
[1.299171] RIP: 0033:0x7fd4b2fb5029
[1.299171] RSP: 002b:7ffc74de13c8 EFLAGS: 0246 ORIG_RAX:
0139
[1.299172] RAX: ffda RBX: 0003 RCX:
7fd4b2fb5029
[1.299172] RDX:  RSI: 006d5440 RDI:
0004
[1.299172] RBP: 0005 R08:  R09:
0013
[1.299173] R10: 0004 R11: 0246 R12:
7ffc74de03c0
[1.299173] R13: 7ffc74de03a0 R14: 0005 R15:
006d60c0
[1.299174] Code: 71 08 74 2b 83 ef 01 b8 01 00 00 00 48 83 c7 01 eb 0a 48
83 c0 01 48 39 34 c1 74 16 48 39 f8 4c 63 c0 75 ee b8 ea ff ff ff 5d c3 <0f> ff
eb c0 45 31 c0 4a 89 94 c1 c8 00 00 00 31 c0 5d c3 0f 1f 
[1.299187] ---[ end trace 0bc506e4ed8edf88 ]---



Part 2: Scary amdgpu messages when waking system up after doing:
* "echo mem >/sys/power/state" (with display on, only console, no X11)
* switch off HDMI display

[  120.175798] amdgpu: [powerplay] 
failed to send message 309 ret is 254 
[  120.175816] amdgpu: [powerplay] 
failed to send pre message 14e ret is 254 

[PATCH 2/2] drm/amdgpu/ci: tidy up some limit checks

[Dan Carpenter]

This is partly to silence a static checker warning:

drivers/gpu/drm/amd/amdgpu/ci_dpm.c:4553 ci_set_mc_special_registers()
error: buffer overflow 'table->mc_reg_address' 16 <= 16

The story is that it's valid to exit the loop with "j" less than or equal
to SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE".  That value for "j" gets saved
as table->last.  We're not allow to access "table->mc_reg_address[j]"
when j == SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE because that's one past
the end of the array.

The tests for "if (j > SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)" in
ci_set_mc_special_registers() are always false because we start with
j less than the array size and we increment it once so at most it can be
equal.

Then there is a bogus check in ci_register_patching_mc_seq() where
it complains if "table->last >= SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE".
The "table->last" value can't possibly be greater than the array size
and it is allowed to be equal to it.  So let's just remove that test
entirely.

Signed-off-by: Dan Carpenter 
---
Not tested.  Please review this one carefully.

diff --git a/drivers/gpu/drm/amd/amdgpu/ci_dpm.c 
b/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
index cb508a211b2f..c885388bdc3c 100644
--- a/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
@@ -4546,10 +4546,10 @@ static int ci_set_mc_special_registers(struct 
amdgpu_device *adev,
table->mc_reg_table_entry[k].mc_data[j] 
|= 0x100;
}
j++;
-   if (j > SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)
-   return -EINVAL;
 
if (adev->mc.vram_type != AMDGPU_VRAM_TYPE_GDDR5) {
+   if (j >= SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)
+   return -EINVAL;
table->mc_reg_address[j].s1 = mmMC_PMG_AUTO_CMD;
table->mc_reg_address[j].s0 = mmMC_PMG_AUTO_CMD;
for (k = 0; k < table->num_entries; k++) {
@@ -4725,8 +4725,6 @@ static int ci_register_patching_mc_seq(struct 
amdgpu_device *adev,
((adev->pdev->device == 0x67B0) ||
 (adev->pdev->device == 0x67B1))) {
for (i = 0; i < table->last; i++) {
-   if (table->last >= SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)
-   return -EINVAL;
switch (table->mc_reg_address[i].s1) {
case mmMC_SEQ_MISC1:
for (k = 0; k < table->num_entries; k++) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/radeon/ci: tidy up some limit checks

[Dan Carpenter]

This is partly to silence a static checker warning:

drivers/gpu/drm/amd/amdgpu/ci_dpm.c:4553 ci_set_mc_special_registers()
error: buffer overflow 'table->mc_reg_address' 16 <= 16

The story is that it's valid to exit the loop with "j" less than or equal
to SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE".  That value for "j" gets saved
as table->last.  We're not allow to access "table->mc_reg_address[j]"
when j == SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE because that's one past
the end of the array.

The tests for "if (j > SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)" in
ci_set_mc_special_registers() are always false because we start with
j less than the array size and we increment it once so at most it can be
equal.

Then there is a bogus check in ci_register_patching_mc_seq() where
it complains if "table->last >= SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE".
The "table->last" value can't possibly be greater than the array size
and it is allowed to be equal to it.  So let's just remove that test
entirely.

Signed-off-by: Dan Carpenter 
---
Not tested.  Please review this one carefully.

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index c97fbb2ab48b..d3136e020d5a 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -4342,10 +4342,10 @@ static int ci_set_mc_special_registers(struct 
radeon_device *rdev,
table->mc_reg_table_entry[k].mc_data[j] 
|= 0x100;
}
j++;
-   if (j > SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)
-   return -EINVAL;
 
if (!pi->mem_gddr5) {
+   if (j >= SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)
+   return -EINVAL;
table->mc_reg_address[j].s1 = MC_PMG_AUTO_CMD 
>> 2;
table->mc_reg_address[j].s0 = MC_PMG_AUTO_CMD 
>> 2;
for (k = 0; k < table->num_entries; k++) {
@@ -4521,8 +4521,6 @@ static int ci_register_patching_mc_seq(struct 
radeon_device *rdev,
((rdev->pdev->device == 0x67B0) ||
 (rdev->pdev->device == 0x67B1))) {
for (i = 0; i < table->last; i++) {
-   if (table->last >= SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)
-   return -EINVAL;
switch(table->mc_reg_address[i].s1 >> 2) {
case MC_SEQ_MISC1:
for (k = 0; k < table->num_entries; k++) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101026] RX 550 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

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

--- Comment #3 from dwagner  ---
One more cosmetic note: Despite HDMI 2 modes with up to 600MHz working fine for
me, now, log messages emitted still talk about "max TMDS clock 300MHz", but
other messages and the display clearly indicate that in fact up to 600MHz are
in use.

-- 
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 101026] RX 550 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

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

--- Comment #2 from dwagner  ---
I just wanted to mention here that I currently use an RX 460 GPU to drive an
HDMI display at 3840x2160 60Hz, this became possible some time ago when DC code
was merged into the open source amdgpu driver. (BTW: HDMI audio also works for
me.)

I use a kernel compiled from
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next as of
"commit  94097b0f7f1bfa54b3b1f8b0d74bbd271a0564e4".

So I think this bug-report could be closed with "works with bleeding edge
amdgpu version, 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 102300] Missing 1920x1080_59.94Hz mode (Second monitor shows black screen but has signal)

[bugzilla-daemon]

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

f...@mt2015.com changed:

   What|Removed |Added

Summary|Second monitor shows black  |Missing 1920x1080_59.94Hz
   |screen but has signal   |mode (Second monitor shows
   ||black screen but has
   ||signal)

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

[Daniel Vetter]

Actually adding mailing lists ...

On Tue, Aug 22, 2017 at 9:39 PM, Daniel Vetter  wrote:
> Hi Bram,
>
> Adding mailing lists, private mails to maintainers doesn't scale.
>
> On Tue, Aug 22, 2017 at 9:12 PM, Bram Vlerick  wrote:
>> Hi Daniel,
>>
>> I was looking through the documentation at
>> https://01.org/linuxgraphics/gfx-docs/drm/ looking for an usefull way of
>> getting more familiar with DRM/KMS. I noticed the VKMS stuff in the TODO.
>>
>> I was wondering which functionality you had in mind that this driver would
>> expose / which helpers you had in mind. (drm_simple_kms_helpers?)
>>
>> As suggested I've already read through vgem. And used it to get an initial
>> module started. Are there any other good suggestions?
>
> There's multiple reasons for creating vkms. One would be as an example
> driver, the other would be to test/validate various bits of kms
> infrastructure in the kernel, i.e. create a hw neutral way to to
> validate the igt gpu tests we have against vkms. In short a rather
> open-ended task, you can do whatever you want to. But probably makes
> more sense to do something you find personally interesting or useful,
> otherwise it's hard to judge what makes sense (since it's such an open
> project), and it's hard to stay motivated.
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5] drm: kirin: Add mode_valid logic to avoid mode clocks we can't generate

[John Stultz]

Currently the hikey dsi logic cannot generate accurate byte
clocks values for all pixel clock values. Thus if a mode clock
is selected that cannot match the calculated byte clock, the
device will boot with a blank screen.

This patch uses the new mode_valid callback (many thanks to
Jose Abreu for upstreaming it!) to ensure we don't select
modes we cannot generate.

Also, since the ade crtc code will adjust the mode in mode_set,
this patch also adds a mode_fixup callback which we use to make
sure we are validating the mode clock that will eventually be
used.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Rob Clark 
Cc: Xinliang Liu 
Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: Jose Abreu 
Cc: Archit Taneja 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Sean Paul 
Signed-off-by: John Stultz 
---
v2: Reworked to calculate if modeclock matches the phy's
byteclock, rather then using a whitelist of known modes.

v3: Reworked to check across all possible crtcs (even though for
us there is only one), and use mode_fixup instead of a custom
function, as suggested by Jose and Daniel.

v4: Fixes and improved error handling as suggested by Jose.

v5: Small typo fix noted by Sean
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c| 67 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 14 ++
 2 files changed, 81 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index f77dcfa..b4c7af3 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -603,6 +603,72 @@ static void dsi_encoder_enable(struct drm_encoder *encoder)
dsi->enable = true;
 }
 
+static enum drm_mode_status dsi_encoder_phy_mode_valid(
+   struct drm_encoder *encoder,
+   const struct drm_display_mode *mode)
+{
+   struct dw_dsi *dsi = encoder_to_dsi(encoder);
+   struct mipi_phy_params phy;
+   u32 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
+   u32 req_kHz, act_kHz, lane_byte_clk_kHz;
+
+   /* Calculate the lane byte clk using the adjusted mode clk */
+   memset(, 0, sizeof(phy));
+   req_kHz = mode->clock * bpp / dsi->lanes;
+   act_kHz = dsi_calc_phy_rate(req_kHz, );
+   lane_byte_clk_kHz = act_kHz / 8;
+
+   DRM_DEBUG_DRIVER("Checking mode %ix%i-%i@%i clock: %i...",
+   mode->hdisplay, mode->vdisplay, bpp,
+   drm_mode_vrefresh(mode), mode->clock);
+
+   /*
+* Make sure the adjusted mode clock and the lane byte clk
+* have a common denominator base frequency
+*/
+   if (mode->clock/dsi->lanes == lane_byte_clk_kHz/3) {
+   DRM_DEBUG_DRIVER("OK!\n");
+   return MODE_OK;
+   }
+
+   DRM_DEBUG_DRIVER("BAD!\n");
+   return MODE_BAD;
+}
+
+static enum drm_mode_status dsi_encoder_mode_valid(struct drm_encoder *encoder,
+   const struct drm_display_mode *mode)
+
+{
+   const struct drm_crtc_helper_funcs *crtc_funcs = NULL;
+   struct drm_crtc *crtc = NULL;
+   struct drm_display_mode adj_mode;
+   enum drm_mode_status ret;
+
+   /*
+* The crtc might adjust the mode, so go through the
+* possible crtcs (technically just one) and call
+* mode_fixup to figure out the adjusted mode before we
+* validate it.
+*/
+   drm_for_each_crtc(crtc, encoder->dev) {
+   /*
+* reset adj_mode to the mode value each time,
+* so we don't adjust the mode twice
+*/
+   drm_mode_copy(_mode, mode);
+
+   crtc_funcs = crtc->helper_private;
+   if (crtc_funcs && crtc_funcs->mode_fixup)
+   if (!crtc_funcs->mode_fixup(crtc, mode, _mode))
+   return MODE_BAD;
+
+   ret = dsi_encoder_phy_mode_valid(encoder, _mode);
+   if (ret != MODE_OK)
+   return ret;
+   }
+   return MODE_OK;
+}
+
 static void dsi_encoder_mode_set(struct drm_encoder *encoder,
 struct drm_display_mode *mode,
 struct drm_display_mode *adj_mode)
@@ -622,6 +688,7 @@ static int dsi_encoder_atomic_check(struct drm_encoder 
*encoder,
 
 static const struct drm_encoder_helper_funcs dw_encoder_helper_funcs = {
.atomic_check   = dsi_encoder_atomic_check,
+   .mode_valid = 

[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

[bugzilla-daemon]

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

har...@gmx.de changed:

   What|Removed |Added

Summary|WarThunder freezes always   |WarThunder freezes at
   |with vblank_mode=2  |start, with activated vsync
   ||(vblank_mode=2)

-- 
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 102358] WarThunder freezes always with vblank_mode=2

[bugzilla-daemon]

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

har...@gmx.de changed:

   What|Removed |Added

Summary|WarThunder freezes always   |WarThunder freezes always
   |with vblanc=1   |with vblank_mode=2

-- 
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 100991] [snb] GPU hangs in "ositorWorkQueue"

[bugzilla-daemon]

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

Matt Turner  changed:

   What|Removed |Added

  Component|Drivers/DRI/i915|Drivers/DRI/i965
   Assignee|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes
   |.org|ktop.org
 QA Contact|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes
   |.org|ktop.org

-- 
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 v3 0/1] drm/i915: Deal with upside-down mounted LCD panels

[Hans de Goede]

Hi All,

When I last send this patch not everyone was enthusiastic about this
patch. As already mentioned in the v2 discussion, solving this in userspace
is not really feasible since there is no single place to fix it there, it
will need fixing in at least 6 different places from the top of my head
(basically any app/server/"driver" talking directly to kms needs fixing)
Also fixing it in userspace will be quite complicated even in a single
consumer of the kms API.

It has been 3 months since my last version and no other solution has
materialized, so I would like to move forward with this patch.

The only technical objection against my previous version was that it
did not fix the subpixel order reported to userspace, that has been
fixed in this version and it has been rebased on top of the latest
drm-intel-next-queued.

Regards,

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

[PATCH v3] drm/i915: Deal with upside-down mounted LCD panels

[Hans de Goede]

On some (Bay Trail) devices the LCD panel is mounted upside-down.

This commit uses the code to read back the initial rotation of the
primary plane in get_initial_plane_config from Ville Syrjala's
"drm/fb-helper: Inherit rotation wip" patch and when re-using the
initial fb it stores that in intel_crtc.initial_rotation.

It adds an intel_plane_get_rotation helper which combines this
initial_rotation with any rotation requested by userspace and
uses this in all places which look at a planes rotation, thus
transparently dealing with upside-down LCD panels without requiring
any user-space or fbcon changes.

This fixes the kernel boot messages switching from being shown the right
way up in efifb to being shown upside down as soon as a native kms driver
loads, as well as any graphics displayed by userspace being upside-down.

Note this only deals with upside-down LCD panels / 180 degrees
rotation as the hardware in question only supports 180 degrees
rotation in hardware. The one model known which has a panel mounted
with 90/270 degrees rotation will need to be fully dealt with in
userspace, even the firmware boot screen / menus are rotated 90 degrees
on this one and there simply is nothing the kernel can do about this.

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=94894
Cc: Ville Syrjala 
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Fix brown paperbag bug s/val & mask/val & ~mask/ to clear old rotation bits
Changes in v3:
-Rebase on current (2017 aug. 22) drm-intel-next-queued
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  7 ++-
 drivers/gpu/drm/i915/intel_display.c  | 91 +--
 drivers/gpu/drm/i915/intel_drv.h  | 32 +++
 drivers/gpu/drm/i915/intel_fbc.c  |  2 +-
 drivers/gpu/drm/i915/intel_pm.c   |  6 +-
 drivers/gpu/drm/i915/intel_sprite.c   | 14 ++---
 6 files changed, 121 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index ee76fab7bb6f..824aaba5112b 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -116,6 +116,7 @@ int intel_plane_atomic_check_with_state(struct 
intel_crtc_state *crtc_state,
struct intel_plane *intel_plane = to_intel_plane(plane);
const struct drm_display_mode *adjusted_mode =
_state->base.adjusted_mode;
+   unsigned int rotation = intel_plane_get_rotation(state);
int ret;
 
/*
@@ -135,7 +136,7 @@ int intel_plane_atomic_check_with_state(struct 
intel_crtc_state *crtc_state,
intel_state->clip.y2 =
crtc_state->base.enable ? crtc_state->pipe_src_h : 0;
 
-   if (state->fb && drm_rotation_90_or_270(state->rotation)) {
+   if (state->fb && drm_rotation_90_or_270(rotation)) {
struct drm_format_name_buf format_name;
 
if (state->fb->modifier != I915_FORMAT_MOD_Y_TILED &&
@@ -164,8 +165,8 @@ int intel_plane_atomic_check_with_state(struct 
intel_crtc_state *crtc_state,
 
/* CHV ignores the mirror bit when the rotate bit is set :( */
if (IS_CHERRYVIEW(dev_priv) &&
-   state->rotation & DRM_MODE_ROTATE_180 &&
-   state->rotation & DRM_MODE_REFLECT_X) {
+   rotation & DRM_MODE_ROTATE_180 &&
+   rotation & DRM_MODE_REFLECT_X) {
DRM_DEBUG_KMS("Cannot rotate and reflect at the same time\n");
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3b95cf953335..c3d9c27248d7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2277,7 +2277,7 @@ void intel_add_fb_offsets(int *x, int *y,
 
 {
const struct intel_framebuffer *intel_fb = 
to_intel_framebuffer(state->base.fb);
-   unsigned int rotation = state->base.rotation;
+   unsigned int rotation = intel_plane_get_rotation(>base);
 
if (drm_rotation_90_or_270(rotation)) {
*x += intel_fb->rotated[plane].x;
@@ -2330,7 +2330,7 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
const struct drm_i915_private *dev_priv = 
to_i915(state->base.plane->dev);
const struct drm_framebuffer *fb = state->base.fb;
unsigned int cpp = fb->format->cpp[plane];
-   unsigned int rotation = state->base.rotation;
+   unsigned int rotation = intel_plane_get_rotation(>base);
unsigned int pitch = intel_fb_pitch(fb, plane, rotation);
 
WARN_ON(new_offset > old_offset);
@@ -2434,7 +2434,7 @@ u32 intel_compute_tile_offset(int *x, int *y,
struct intel_plane *intel_plane = to_intel_plane(state->base.plane);
struct drm_i915_private *dev_priv = to_i915(intel_plane->base.dev);
const struct drm_framebuffer *fb = state->base.fb;
-   unsigned int rotation = state->base.rotation;
+   unsigned int 

Re: Etnaviv crashes on glmark2

[Fabio Estevam]

On Tue, Aug 22, 2017 at 9:47 AM, Fabio Estevam  wrote:
> Hi,
>
> I am running kernel 4.12.8 and mesa 17.1.6 on a imx6q, but glmark2
> never runs successfully until the end. It always crashes like this:
>
> ** Failed to set swap interval. Results may be bounded above by refresh rate.
> [conditionals] fragment-steps=0:vertex-steps=0: FPS: 63 FrameTime: 15.873 ms
> [  288.732107] Unable to handle kernel paging request at virtual
> address 00e71a74
> [  288.739394] pgd = ee52c000
> [  288.742115] [00e71a74] *pgd=
> [  288.745782] Internal error: Oops: 5 [#1] SMP ARM
> [  288.750409] Modules linked in:
> [  288.753481] CPU: 0 PID: 221 Comm: glmark2-es2-drm Not tainted 4.12.8 #1
> [  288.760101] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [  288.766635] task: ee420c40 task.stack: ee4f
> [  288.771181] PC is at page_mapping+0xc/0xa4
> [  288.775291] LR is at set_page_dirty+0x14/0xc8

If I use the generic drm_gem_cma_free_object() function instead the
error does not happen anymore:
https://pastebin.com/edx37jNG

Not sure if this is a valid fix though. Any comments?

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

[Bug 98324] [DC] amd-staging-4.7: problems with unblanking displays when monitors are switched off

[bugzilla-daemon]

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

Darren Salt  changed:

   What|Removed |Added

 Attachment #127405|0   |1
is obsolete||

--- Comment #4 from Darren Salt  ---
Created attachment 133673
  --> https://bugs.freedesktop.org/attachment.cgi?id=133673=edit
Kernel log showing blanking & as-if-reconnected unblanking.

-- 
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 102323] [DC] System crashes when woken up from S3 sleep while HDMI display is switched off

[bugzilla-daemon]

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

--- Comment #2 from Harry Wentland  ---
Thanks for reporting this. I've seen this myself and been debugging it a bit. I
have a patch but am not completely happy with it as it seems like it leaves a
pipe running in some cases when we should disable it.

Anyways, it might be worth a try and is attached.

-- 
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 102323] [DC] System crashes when woken up from S3 sleep while HDMI display is switched off

[bugzilla-daemon]

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

--- Comment #1 from Harry Wentland  ---
Created attachment 133672
  --> https://bugs.freedesktop.org/attachment.cgi?id=133672=edit
Draft fix

-- 
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 98324] [DC] amd-staging-4.7: problems with unblanking displays when monitors are switched off

[bugzilla-daemon]

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

--- Comment #3 from Darren Salt  ---
Created attachment 133671
  --> https://bugs.freedesktop.org/attachment.cgi?id=133671=edit
Kernel log showing normal blank & unblank.

-- 
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 98324] [DC] amd-staging-4.7: problems with unblanking displays when monitors are switched off

[bugzilla-daemon]

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

--- Comment #2 from Darren Salt  ---
Currently running amd-staging-drm-next 0313e8bfbbdd. The behaviour is now
improved, though is still regressed vs. mainline.

Unblanking works. If I allow the problem monitor to display “no signal”, it
becomes effectively disconnected, and becomes reconnected (as if physically
freshly connected) on unblanking.

-- 
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 9/9] drm/exynos: simplify set_pixfmt() in DECON and FIMD drivers

[Tobias Jakobi]

DRM core already checks the validity of the pixelformat.

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 8 +---
 3 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 66ceca0af2a0..3dfba34be24d 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -277,13 +277,11 @@ static void decon_win_set_pixfmt(struct decon_context 
*ctx, unsigned int win,
val |= WINCONx_BURSTLEN_16WORD;
break;
case DRM_FORMAT_ARGB:
+   default:
val |= WINCONx_BPPMODE_32BPP_A;
val |= WINCONx_WSWP_F | WINCONx_BLD_PIX_F | WINCONx_ALPHA_SEL_F;
val |= WINCONx_BURSTLEN_16WORD;
break;
-   default:
-   DRM_ERROR("Proper pixel format is not set\n");
-   return;
}
 
DRM_DEBUG_KMS("cpp = %u\n", fb->format->cpp[0]);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 4662d55ed988..615efcf7782a 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -309,16 +309,11 @@ static void decon_win_set_pixfmt(struct decon_context 
*ctx, unsigned int win,
val |= WINCONx_BURSTLEN_16WORD;
break;
case DRM_FORMAT_BGRA:
+   default:
val |= WINCONx_BPPMODE_32BPP_BGRA | WINCONx_BLD_PIX |
WINCONx_ALPHA_SEL;
val |= WINCONx_BURSTLEN_16WORD;
break;
-   default:
-   DRM_DEBUG_KMS("invalid pixel size so using unpacked 24bpp.\n");
-
-   val |= WINCONx_BPPMODE_24BPP_xRGB;
-   val |= WINCONx_BURSTLEN_16WORD;
-   break;
}
 
DRM_DEBUG_KMS("cpp = %d\n", fb->format->cpp[0]);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9b83d1846589..91c62e7afdd5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -583,18 +583,12 @@ static void fimd_win_set_pixfmt(struct fimd_context *ctx, 
unsigned int win,
val |= WINCONx_BURSTLEN_16WORD;
break;
case DRM_FORMAT_ARGB:
+   default:
val |= WINCON1_BPPMODE_25BPP_A1888
| WINCON1_BLD_PIX | WINCON1_ALPHA_SEL;
val |= WINCONx_WSWP;
val |= WINCONx_BURSTLEN_16WORD;
break;
-   default:
-   DRM_DEBUG_KMS("invalid pixel size so using unpacked 24bpp.\n");
-
-   val |= WINCON0_BPPMODE_24BPP_888;
-   val |= WINCONx_WSWP;
-   val |= WINCONx_BURSTLEN_16WORD;
-   break;
}
 
/*
-- 
2.13.0

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

[PATCH v2 8/9] drm/exynos: consistent use of cpp

[Tobias Jakobi]

A recent commit (272725c7db4da1fd3229d944fc76d2e98e3a144e) has removed
the use of 'bits_per_pixel' in DRM. However the corresponding Exynos
driver code still uses the ambiguous 'bpp', even though it is now
initialized from fb->cpp[0].

Consistenly use 'cpp' in FIMD, DECON7 and DECON5433 drivers.

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 12 ++--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|  6 +++---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  8 
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 62b50e0685b0..66ceca0af2a0 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -286,7 +286,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, 
unsigned int win,
return;
}
 
-   DRM_DEBUG_KMS("bpp = %u\n", fb->format->cpp[0] * 8);
+   DRM_DEBUG_KMS("cpp = %u\n", fb->format->cpp[0]);
 
/*
 * In case of exynos, setting dma-burst to 16Word causes permanent
@@ -329,7 +329,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
struct decon_context *ctx = crtc->ctx;
struct drm_framebuffer *fb = state->base.fb;
unsigned int win = plane->index;
-   unsigned int bpp = fb->format->cpp[0];
+   unsigned int cpp = fb->format->cpp[0];
unsigned int pitch = fb->pitches[0];
dma_addr_t dma_addr = exynos_drm_fb_dma_addr(fb, 0);
u32 val;
@@ -365,11 +365,11 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
writel(val, ctx->addr + DECON_VIDW0xADD1B0(win));
 
if (!(ctx->out_type & IFTYPE_HDMI))
-   val = BIT_VAL(pitch - state->crtc.w * bpp, 27, 14)
-   | BIT_VAL(state->crtc.w * bpp, 13, 0);
+   val = BIT_VAL(pitch - state->crtc.w * cpp, 27, 14)
+   | BIT_VAL(state->crtc.w * cpp, 13, 0);
else
-   val = BIT_VAL(pitch - state->crtc.w * bpp, 29, 15)
-   | BIT_VAL(state->crtc.w * bpp, 14, 0);
+   val = BIT_VAL(pitch - state->crtc.w * cpp, 29, 15)
+   | BIT_VAL(state->crtc.w * cpp, 14, 0);
writel(val, ctx->addr + DECON_VIDW0xADD2(win));
 
decon_win_set_pixfmt(ctx, win, fb);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 3e88269fdc2e..4662d55ed988 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -321,7 +321,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, 
unsigned int win,
break;
}
 
-   DRM_DEBUG_KMS("bpp = %d\n", fb->format->cpp[0] * 8);
+   DRM_DEBUG_KMS("cpp = %d\n", fb->format->cpp[0]);
 
/*
 * In case of exynos, setting dma-burst to 16Word causes permanent
@@ -398,7 +398,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
unsigned int last_x;
unsigned int last_y;
unsigned int win = plane->index;
-   unsigned int bpp = fb->format->cpp[0];
+   unsigned int cpp = fb->format->cpp[0];
unsigned int pitch = fb->pitches[0];
 
if (ctx->suspended)
@@ -418,7 +418,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
val = (unsigned long)exynos_drm_fb_dma_addr(fb, 0);
writel(val, ctx->regs + VIDW_BUF_START(win));
 
-   padding = (pitch / bpp) - fb->width;
+   padding = (pitch / cpp) - fb->width;
 
/* buffer size */
writel(fb->width + padding, ctx->regs + VIDW_WHOLE_X(win));
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e88597f6d356..9b83d1846589 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -718,13 +718,13 @@ static void fimd_update_plane(struct exynos_drm_crtc 
*crtc,
unsigned long val, size, offset;
unsigned int last_x, last_y, buf_offsize, line_size;
unsigned int win = plane->index;
-   unsigned int bpp = fb->format->cpp[0];
+   unsigned int cpp = fb->format->cpp[0];
unsigned int pitch = fb->pitches[0];
 
if (ctx->suspended)
return;
 
-   offset = state->src.x * bpp;
+   offset = state->src.x * cpp;
offset += state->src.y * pitch;
 
/* buffer start address */
@@ -743,8 +743,8 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
state->crtc.w, state->crtc.h);
 
/* buffer size */
-   buf_offsize = pitch - (state->crtc.w * bpp);
-   line_size = state->crtc.w * bpp;
+   buf_offsize = pitch - (state->crtc.w * cpp);
+   line_size = state->crtc.w * cpp;
val = VIDW_BUF_SIZE_OFFSET(buf_offsize) |

[PATCH v2 7/9] drm/exynos: add BYTE_PITCH cap for all supported planes

[Tobias Jakobi]

Both FIMD and DECON5433 support a pitch in bytes.

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5792ca88ab7a..62b50e0685b0 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -546,6 +546,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
ctx->configs[win].num_pixel_formats = ARRAY_SIZE(decon_formats);
ctx->configs[win].zpos = win;
ctx->configs[win].type = decon_win_types[tmp];
+   ctx->configs[win].capabilities = 
EXYNOS_DRM_PLANE_CAP_BYTE_PITCH;
 
ret = exynos_plane_init(drm_dev, >planes[win], win,
>configs[win]);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 60f93cad6643..e88597f6d356 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -986,6 +986,7 @@ static int fimd_bind(struct device *dev, struct device 
*master, void *data)
ctx->configs[i].num_pixel_formats = ARRAY_SIZE(fimd_formats);
ctx->configs[i].zpos = i;
ctx->configs[i].type = fimd_win_types[i];
+   ctx->configs[i].capabilities = EXYNOS_DRM_PLANE_CAP_BYTE_PITCH;
ret = exynos_plane_init(drm_dev, >planes[i], i,
>configs[i]);
if (ret)
-- 
2.13.0

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

[PATCH v2 6/9] drm/exynos: introduce BYTE_PITCH capability

[Tobias Jakobi]

In some of subdrivers we compute something like 'pitch / cpp' at some
point, silently assuming that the pitch (which is in bytes) is
divisible by the buffer's cpp. This must not be true, in particular
it depends on the underlying hardware.

If userspace should request such a setup, we should communicate this.

Introduce a new cap which indicates that the hardware supports a
pitch with 'byte-granularity'. If the cap is not set, assume that
we need a pitch aligned to cpp.

We set this cap in a later patch for the drivers/planes which
support it.

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 43afab4bebc3..ec32632485d2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -92,6 +92,7 @@ struct exynos_drm_plane {
 #define EXYNOS_DRM_PLANE_CAP_SCALE (1 << 1)
 #define EXYNOS_DRM_PLANE_CAP_ZPOS  (1 << 2)
 #define EXYNOS_DRM_PLANE_CAP_TILE  (1 << 3)
+#define EXYNOS_DRM_PLANE_CAP_BYTE_PITCH(1 << 4)
 
 /*
  * Exynos DRM plane configuration structure.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 133af72f5c90..17e47b8f0d6a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -185,6 +185,16 @@ exynos_drm_plane_check_format(const struct 
exynos_drm_plane_config *config,
 {
struct drm_framebuffer *fb = state->base.fb;
 
+   /*
+* Some blocks only allow to specify a buffer pitch in terms
+* of pixels. In these cases, we need to ensure that the pitch
+* provided by userspace is divisible by the cpp.
+*/
+   if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_BYTE_PITCH)) {
+   if (fb->pitches[0] % fb->format->cpp[0])
+   return -ENOTSUPP;
+   }
+
switch (fb->modifier) {
case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_TILE))
-- 
2.13.0

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

[PATCH v2 5/9] drm/exynos: mixer: remove src offset from mixer_graph_buffer()

[Tobias Jakobi]

We always translate the dma address such that the offsets of
the source image are zero. Hence we can remove manipulation of
the MXR_GRAPHIC_SXY(win) register and just zero them once
in mixer_win_reset().

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 8d68de85bada..a540e50ceadc 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -584,7 +584,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
unsigned long flags;
unsigned int win = plane->index;
unsigned int x_ratio = 0, y_ratio = 0;
-   unsigned int src_x_offset, src_y_offset, dst_x_offset, dst_y_offset;
+   unsigned int dst_x_offset, dst_y_offset;
dma_addr_t dma_addr;
unsigned int fmt;
u32 val;
@@ -618,12 +618,10 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
dst_x_offset = state->crtc.x;
dst_y_offset = state->crtc.y;
 
-   /* converting dma address base and source offset */
+   /* translate dma address base s.t. the source image offset is zero */
dma_addr = exynos_drm_fb_dma_addr(fb, 0)
+ (state->src.x * fb->format->cpp[0])
+ (state->src.y * fb->pitches[0]);
-   src_x_offset = 0;
-   src_y_offset = 0;
 
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
__set_bit(MXR_BIT_INTERLACE, >flags);
@@ -654,11 +652,6 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
val |= MXR_GRP_WH_V_SCALE(y_ratio);
mixer_reg_write(res, MXR_GRAPHIC_WH(win), val);
 
-   /* setup offsets in source image */
-   val  = MXR_GRP_SXY_SX(src_x_offset);
-   val |= MXR_GRP_SXY_SY(src_y_offset);
-   mixer_reg_write(res, MXR_GRAPHIC_SXY(win), val);
-
/* setup offsets in display image */
val  = MXR_GRP_DXY_DX(dst_x_offset);
val |= MXR_GRP_DXY_DY(dst_y_offset);
@@ -735,6 +728,10 @@ static void mixer_win_reset(struct mixer_context *ctx)
if (test_bit(MXR_BIT_VP_ENABLED, >flags))
mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_VP_ENABLE);
 
+   /* set all source image offsets to zero */
+   mixer_reg_write(res, MXR_GRAPHIC_SXY(0), 0);
+   mixer_reg_write(res, MXR_GRAPHIC_SXY(1), 0);
+
spin_unlock_irqrestore(>reg_slock, flags);
 }
 
-- 
2.13.0

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

[PATCH v2 4/9] drm/exynos: mixer: simplify mixer_graph_buffer()

[Tobias Jakobi]

DRM core already checks in drm_atomic_plane_check() if the
pixelformat is valid. Hence we can collapse the default case
of the switch statement with the XRGB case.

No functional change.

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index beef4d6c41ca..8d68de85bada 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -606,12 +606,9 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
 
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ARGB:
+   default:
fmt = MXR_FORMAT_ARGB;
break;
-
-   default:
-   DRM_DEBUG_KMS("pixelformat unsupported by mixer\n");
-   return;
}
 
/* ratio is already checked by common plane code */
-- 
2.13.0

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

[PATCH v2 3/9] drm/exynos: mixer: simplify vp_video_buffer()

[Tobias Jakobi]

DRM core already checks in drm_atomic_plane_check() if the
pixelformat is valid. Hence we can drop the default case of
the switch statement and collapse most of the code.

Also rename the two booleans to reflect what true/false
actually means, and to avoid mixing CrCb/NV21 descriptions.

No functional change.

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 26 ++
 1 file changed, 6 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 4c894d97aba3..beef4d6c41ca 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -484,32 +484,18 @@ static void vp_video_buffer(struct mixer_context *ctx,
unsigned int priority = state->base.normalized_zpos + 1;
unsigned long flags;
dma_addr_t luma_addr[2], chroma_addr[2];
-   bool tiled_mode = false;
-   bool crcb_mode = false;
+   bool is_tiled, is_nv21;
u32 val;
 
-   switch (fb->format->format) {
-   case DRM_FORMAT_NV12:
-   crcb_mode = false;
-   break;
-   case DRM_FORMAT_NV21:
-   crcb_mode = true;
-   break;
-   default:
-   DRM_ERROR("pixel format for vp is wrong [%d].\n",
-   fb->format->format);
-   return;
-   }
-
-   if (fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
-   tiled_mode = true;
+   is_nv21 = (fb->format->format == DRM_FORMAT_NV21);
+   is_tiled = (fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE);
 
luma_addr[0] = exynos_drm_fb_dma_addr(fb, 0);
chroma_addr[0] = exynos_drm_fb_dma_addr(fb, 1);
 
if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
__set_bit(MXR_BIT_INTERLACE, >flags);
-   if (tiled_mode) {
+   if (is_tiled) {
luma_addr[1] = luma_addr[0] + 0x40;
chroma_addr[1] = chroma_addr[0] + 0x40;
} else {
@@ -529,8 +515,8 @@ static void vp_video_buffer(struct mixer_context *ctx,
vp_reg_writemask(res, VP_MODE, val, VP_MODE_LINE_SKIP);
 
/* setup format */
-   val = (crcb_mode ? VP_MODE_NV21 : VP_MODE_NV12);
-   val |= (tiled_mode ? VP_MODE_MEM_TILED : VP_MODE_MEM_LINEAR);
+   val = (is_nv21 ? VP_MODE_NV21 : VP_MODE_NV12);
+   val |= (is_tiled ? VP_MODE_MEM_TILED : VP_MODE_MEM_LINEAR);
vp_reg_writemask(res, VP_MODE, val, VP_MODE_FMT_MASK);
 
/* setting size of input image */
-- 
2.13.0

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

[PATCH v2 2/9] drm/exynos: mixer: enable NV12MT support for the video plane

[Tobias Jakobi]

The video processor supports a tiled version of the NV12 format,
known as NV12MT in V4L2 terms. The support was removed in commit
083500baefd5f4c215a5a93aef2492c1aa775828 due to not being a real
pixel format, but rather NV12 with a special memory layout.

With the introduction of FB modifiers, we can now properly support
this format again.

Tested with a hacked up modetest from libdrm's test suite on
an ODROID-X2 (Exynos4412).

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 ++
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 27 +++
 drivers/gpu/drm/exynos/exynos_mixer.c |  6 +-
 4 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a93de321706b..43afab4bebc3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -91,6 +91,7 @@ struct exynos_drm_plane {
 #define EXYNOS_DRM_PLANE_CAP_DOUBLE(1 << 0)
 #define EXYNOS_DRM_PLANE_CAP_SCALE (1 << 1)
 #define EXYNOS_DRM_PLANE_CAP_ZPOS  (1 << 2)
+#define EXYNOS_DRM_PLANE_CAP_TILE  (1 << 3)
 
 /*
  * Exynos DRM plane configuration structure.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 73217c281c9a..a958818d552b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -250,4 +250,6 @@ void exynos_drm_mode_config_init(struct drm_device *dev)
 
dev->mode_config.funcs = _drm_mode_config_funcs;
dev->mode_config.helper_private = _drm_mode_config_helpers;
+
+   dev->mode_config.allow_fb_modifiers = true;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 611b6fd65433..133af72f5c90 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -180,6 +180,29 @@ static struct drm_plane_funcs exynos_plane_funcs = {
 };
 
 static int
+exynos_drm_plane_check_format(const struct exynos_drm_plane_config *config,
+ struct exynos_drm_plane_state *state)
+{
+   struct drm_framebuffer *fb = state->base.fb;
+
+   switch (fb->modifier) {
+   case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
+   if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_TILE))
+   return -ENOTSUPP;
+   break;
+
+   case DRM_FORMAT_MOD_LINEAR:
+   break;
+
+   default:
+   DRM_ERROR("unsupported pixel format modifier");
+   return -ENOTSUPP;
+   }
+
+   return 0;
+}
+
+static int
 exynos_drm_plane_check_size(const struct exynos_drm_plane_config *config,
struct exynos_drm_plane_state *state)
 {
@@ -223,6 +246,10 @@ static int exynos_plane_atomic_check(struct drm_plane 
*plane,
/* translate state into exynos_state */
exynos_plane_mode_set(exynos_state);
 
+   ret = exynos_drm_plane_check_format(exynos_plane->config, exynos_state);
+   if (ret)
+   return ret;
+
ret = exynos_drm_plane_check_size(exynos_plane->config, exynos_state);
return ret;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index c6d6f6d42900..4c894d97aba3 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -148,7 +148,8 @@ static const struct exynos_drm_plane_config 
plane_configs[MIXER_WIN_NR] = {
.pixel_formats = vp_formats,
.num_pixel_formats = ARRAY_SIZE(vp_formats),
.capabilities = EXYNOS_DRM_PLANE_CAP_SCALE |
-   EXYNOS_DRM_PLANE_CAP_ZPOS,
+   EXYNOS_DRM_PLANE_CAP_ZPOS |
+   EXYNOS_DRM_PLANE_CAP_TILE,
},
 };
 
@@ -500,6 +501,9 @@ static void vp_video_buffer(struct mixer_context *ctx,
return;
}
 
+   if (fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
+   tiled_mode = true;
+
luma_addr[0] = exynos_drm_fb_dma_addr(fb, 0);
chroma_addr[0] = exynos_drm_fb_dma_addr(fb, 1);
 
-- 
2.13.0

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

[PATCH v2 0/9] drm/exynos: misc fixes and more

[Tobias Jakobi]

Hello,

this is the second iteration of [1], with the following changes:
- split patch 3/8 (suggested by Inki)
- zero init registers in patch 4/8 (suggested by Inki)
- rephrased commit description of patch 5/8 to make it more
  clear that this behaviour depends on the hw
- replace zero with linear modifier in patch 2/8


Summary:
(a) Enables support for NV12MT in the mixer.
(b) Sanitizes buffer pitch for HW with restrictions.
(c) Misc fixes

With best wishes,
Tobias

[1] https://www.spinics.net/lists/linux-samsung-soc/msg60235.html


Tobias Jakobi (9):
  drm/exynos: mixer: fix chroma comment in vp_video_buffer()
  drm/exynos: mixer: enable NV12MT support for the video plane
  drm/exynos: mixer: simplify vp_video_buffer()
  drm/exynos: mixer: simplify mixer_graph_buffer()
  drm/exynos: mixer: remove src offset from mixer_graph_buffer()
  drm/exynos: introduce BYTE_PITCH capability
  drm/exynos: add BYTE_PITCH cap for all supported planes
  drm/exynos: consistent use of cpp
  drm/exynos: simplify set_pixfmt() in DECON and FIMD drivers

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 17 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 13 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 ++
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 17 --
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 37 +
 drivers/gpu/drm/exynos/exynos_mixer.c | 48 +--
 7 files changed, 75 insertions(+), 61 deletions(-)

-- 
2.13.0

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

[PATCH v2 1/9] drm/exynos: mixer: fix chroma comment in vp_video_buffer()

[Tobias Jakobi]

The current comment sounds like the division op is done to
compensate for some hardware erratum. But the chroma plane
having half the height of the luma plane is just the way
NV12/NV21 is defined, so clarify this behaviour.

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index a998a8dd783c..c6d6f6d42900 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -532,7 +532,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
/* setting size of input image */
vp_reg_write(res, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) |
VP_IMG_VSIZE(fb->height));
-   /* chroma height has to reduced by 2 to avoid chroma distorions */
+   /* the chroma plane for NV12/NV21 is half the height of the luma plane 
*/
vp_reg_write(res, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) |
VP_IMG_VSIZE(fb->height / 2));
 
-- 
2.13.0

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

Re: [PATCH] drm/ttm: Add helper functions to populate/map in one call

[Tom St Denis]

ping?  Haven't seen any comments on amd-gfx or dri-devel.

Cheers,
Tom


On 18/08/17 10:07 AM, Tom St Denis wrote:

These functions replace a section of common code found
in radeon/amdgpu drivers (and possibly others) as part
of the ttm_tt_*populate() callbacks.

Signed-off-by: Tom St Denis 
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 41 
  include/drm/ttm/ttm_page_alloc.h | 11 ++
  2 files changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 871599826773..6a660d196d87 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -920,6 +920,47 @@ void ttm_pool_unpopulate(struct ttm_tt *ttm)
  }
  EXPORT_SYMBOL(ttm_pool_unpopulate);
  
+int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)

+{
+   unsigned i;
+   int r;
+
+   r = ttm_pool_populate(>ttm);
+   if (r)
+   return r;
+
+   for (i = 0; i < tt->ttm.num_pages; i++) {
+   tt->dma_address[i] = dma_map_page(dev, tt->ttm.pages[i],
+ 0, PAGE_SIZE,
+ DMA_BIDIRECTIONAL);
+   if (dma_mapping_error(dev, tt->dma_address[i])) {
+   while (i--) {
+   dma_unmap_page(dev, tt->dma_address[i],
+  PAGE_SIZE, DMA_BIDIRECTIONAL);
+   tt->dma_address[i] = 0;
+   }
+   ttm_pool_unpopulate(>ttm);
+   return -EFAULT;
+   }
+   }
+   return 0;
+}
+EXPORT_SYMBOL(ttm_populate_and_map_pages);
+
+void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt)
+{
+   unsigned i;
+   
+   for (i = 0; i < tt->ttm.num_pages; i++) {
+   if (tt->dma_address[i]) {
+   dma_unmap_page(dev, tt->dma_address[i],
+  PAGE_SIZE, DMA_BIDIRECTIONAL);
+   }
+   }
+   ttm_pool_unpopulate(>ttm);
+}
+EXPORT_SYMBOL(ttm_unmap_and_unpopulate_pages);
+
  int ttm_page_alloc_debugfs(struct seq_file *m, void *data)
  {
struct ttm_page_pool *p;
diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 49a828425fa2..8695918ea629 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -83,6 +83,17 @@ extern int ttm_dma_page_alloc_debugfs(struct seq_file *m, 
void *data);
  extern int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev);
  extern void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device 
*dev);
  
+

+/**
+ * Populates and DMA maps pages to fullfil a ttm_dma_populate() request
+ */
+int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt);
+
+/**
+ * Unpopulates and DMA unmaps pages as part of a
+ * ttm_dma_unpopulate() request */
+void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt);
+
  #else
  static inline int ttm_dma_page_alloc_init(struct ttm_mem_global *glob,
  unsigned max_pages)



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

Re: [Intel-gfx] [PATCH] drm: Release driver tracking before making the object available again

[Joonas Lahtinen]

+ Sean

On Mon, 2017-08-21 at 18:16 +0200, Daniel Vetter wrote:
> On Sat, Aug 19, 2017 at 01:05:58PM +0100, Chris Wilson wrote:
> > This is the same bug as we fixed in commit f6cd7daecff5 ("drm: Release
> > driver references to handle before making it available again"), but now
> > the exposure is via the PRIME lookup tables. If we remove the
> > object/handle from the PRIME lut, then a new request for the same
> > object/fd will generate a new handle, thus for a short window that
> > object is known to userspace by two different handles. Fix this by
> > releasing the driver tracking before PRIME.
> > 
> > Fixes: 0ff926c7d4f0 ("drm/prime: add exported buffers to current fprivs
> > imported buffer list (v2)")
> > Signed-off-by: Chris Wilson 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: Rob Clark 
> > Cc: Ville Syrjälä 
> > Cc: Thierry Reding 
> > Cc: sta...@vger.kernel.org
> 
> Do we have an evil igt for this? I guess since the old one didn't have
> one, this new race is also hard to reproduce ...
> 
> Reviewed-by: Daniel Vetter 

Pushed this to drm-misc-fixes (and drm-misc-next for I am a monkey with
a keyboard), thanks for the patch and review.

Sean, you can blame it on me when/if there is trouble caused by the
patch being in both branches. Hopefully next merge will cause less
headache.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: Add helper functions to populate/map in one call

[Christian König]

Reviewed-by: Christian König  for this one as 
well as the two patches for radeon and amdgpu.


Feel free to also add my Acked-by to the nouveau patch.

Regards,
Christian.

Am 22.08.2017 um 13:13 schrieb Tom St Denis:

ping? Haven't seen any comments on amd-gfx or dri-devel.

Cheers,
Tom


On 18/08/17 10:07 AM, Tom St Denis wrote:

These functions replace a section of common code found
in radeon/amdgpu drivers (and possibly others) as part
of the ttm_tt_*populate() callbacks.

Signed-off-by: Tom St Denis 
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 41 


  include/drm/ttm/ttm_page_alloc.h | 11 ++
  2 files changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c

index 871599826773..6a660d196d87 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -920,6 +920,47 @@ void ttm_pool_unpopulate(struct ttm_tt *ttm)
  }
  EXPORT_SYMBOL(ttm_pool_unpopulate);
  +int ttm_populate_and_map_pages(struct device *dev, struct 
ttm_dma_tt *tt)

+{
+unsigned i;
+int r;
+
+r = ttm_pool_populate(>ttm);
+if (r)
+return r;
+
+for (i = 0; i < tt->ttm.num_pages; i++) {
+tt->dma_address[i] = dma_map_page(dev, tt->ttm.pages[i],
+  0, PAGE_SIZE,
+  DMA_BIDIRECTIONAL);
+if (dma_mapping_error(dev, tt->dma_address[i])) {
+while (i--) {
+dma_unmap_page(dev, tt->dma_address[i],
+   PAGE_SIZE, DMA_BIDIRECTIONAL);
+tt->dma_address[i] = 0;
+}
+ttm_pool_unpopulate(>ttm);
+return -EFAULT;
+}
+}
+return 0;
+}
+EXPORT_SYMBOL(ttm_populate_and_map_pages);
+
+void ttm_unmap_and_unpopulate_pages(struct device *dev, struct 
ttm_dma_tt *tt)

+{
+unsigned i;
+
+for (i = 0; i < tt->ttm.num_pages; i++) {
+if (tt->dma_address[i]) {
+dma_unmap_page(dev, tt->dma_address[i],
+   PAGE_SIZE, DMA_BIDIRECTIONAL);
+}
+}
+ttm_pool_unpopulate(>ttm);
+}
+EXPORT_SYMBOL(ttm_unmap_and_unpopulate_pages);
+
  int ttm_page_alloc_debugfs(struct seq_file *m, void *data)
  {
  struct ttm_page_pool *p;
diff --git a/include/drm/ttm/ttm_page_alloc.h 
b/include/drm/ttm/ttm_page_alloc.h

index 49a828425fa2..8695918ea629 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -83,6 +83,17 @@ extern int ttm_dma_page_alloc_debugfs(struct 
seq_file *m, void *data);
  extern int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev);
  extern void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct 
device *dev);

  +
+/**
+ * Populates and DMA maps pages to fullfil a ttm_dma_populate() request
+ */
+int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt 
*tt);

+
+/**
+ * Unpopulates and DMA unmaps pages as part of a
+ * ttm_dma_unpopulate() request */
+void ttm_unmap_and_unpopulate_pages(struct device *dev, struct 
ttm_dma_tt *tt);

+
  #else
  static inline int ttm_dma_page_alloc_init(struct ttm_mem_global *glob,
unsigned max_pages)



___
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

Etnaviv crashes on glmark2

[Fabio Estevam]

Hi,

I am running kernel 4.12.8 and mesa 17.1.6 on a imx6q, but glmark2
never runs successfully until the end. It always crashes like this:

** Failed to set swap interval. Results may be bounded above by refresh rate.
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 63 FrameTime: 15.873 ms
[  288.732107] Unable to handle kernel paging request at virtual
address 00e71a74
[  288.739394] pgd = ee52c000
[  288.742115] [00e71a74] *pgd=
[  288.745782] Internal error: Oops: 5 [#1] SMP ARM
[  288.750409] Modules linked in:
[  288.753481] CPU: 0 PID: 221 Comm: glmark2-es2-drm Not tainted 4.12.8 #1
[  288.760101] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[  288.766635] task: ee420c40 task.stack: ee4f
[  288.771181] PC is at page_mapping+0xc/0xa4
[  288.775291] LR is at set_page_dirty+0x14/0xc8
[  288.779656] pc : []lr : []psr: 2013
[  288.779656] sp : ee4f1cd0  ip : ee4f1ce0  fp : ee4f1cdc
[  288.791138] r10:   r9 : 0cdd  r8 : f5b8a000
[  288.796370] r7 :   r6 : 0001  r5 : 1400  r4 : 00e71a60
[  288.802902] r3 : efe71a50  r2 : 0001  r1 :   r0 : 00e71a60
[  288.809436] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  288.816576] Control: 10c5387d  Table: 3e52c04a  DAC: 0051
[  288.822328] Process glmark2-es2-drm (pid: 221, stack limit = 0xee4f0210)
[  288.829034] Stack: (0xee4f1cd0 to 0xee4f2000)
[  288.833399] 1cc0: ee4f1cf4
ee4f1ce0 c01e05f4 c01f23ac
[  288.841586] 1ce0: f5b8d374 1400 ee4f1d24 ee4f1cf8 c04fa11c
c01e05ec  ee584000
[  288.849772] 1d00: ee584000 ee58419c 0200 0100 ee58419c
ef0d7c00 ee4f1d3c ee4f1d28
[  288.857957] 1d20: c0526ce8 c04fa07c ee58419c ee584000 ee4f1d6c
ee4f1d40 c052807c c0526c94
[  288.866143] 1d40: c0527fb0 ee4a ee584000 ee584000 ee4a0070
ee566c1c ee4f1e60 40086409
[  288.874329] 1d60: ee4f1d84 ee4f1d70 c04f9e34 c0527fbc 
ee4a ee4f1db4 ee4f1d88
[  288.882514] 1d80: c04fa2e8 c04f9e18 0001  c04fa274
40086409 ee584000 ee4a0584
[  288.890700] 1da0:  ee566d24 ee4f1dd4 ee4f1db8 c04fa39c
c04fa268 ee584000 ee566c00
[  288.898885] 1dc0: ee4a ee566d24 ee4f1df4 ee4f1dd8 c04fa434
c04fa330 ee566c28 ee566c00
[  288.907071] 1de0: 0010 ee584000 ee4f1e1c ee4f1df8 c04fa4cc
c04fa3e8  
[  288.915256] 1e00: 0008 c0a415d0 ee566c00 ee4f1e60 ee4f1e2c
ee4f1e20 c04fa9f4 c04fa478
[  288.923442] 1e20: ee4f1f0c ee4f1e30 c04fb478 c04fa9d8 e280
0001 c0c2cd88 c016d468
[  288.931628] 1e40: ee4f1e84 0051 c04fa9cc 0008 ee4a
0009 beb30958 ee4f1e60
[  288.939814] 1e60: 0010   c1649450 6013
c024ac90 ee4f1ec4 ee4f1e88
[  288.947999] 1e80: c016f878 c016f294   
  c0e22d35
[  288.956184] 1ea0: c024b020 ffea eee4e2e0  ee4ebc68
0008 ee4f1efc ee4f1ec8
[  288.964370] 1ec0: c024aca0 c016f790   c024abe0
ee5a1540 ee4ebc68 ee5a1540
[  288.972556] 1ee0: ee4ebc68 beb30958 ef0d3768 ee59fb80 c0239a44
0006 ee4f 
[  288.980741] 1f00: ee4f1f7c ee4f1f10 c0239048 c04fb298 0020
 ee4f1f64 ee5a1548
[  288.988927] 1f20: c0206e20 ee421054 c0e7d180 ee421080 ee420c40
  
[  288.997112] 1f40: ee4f1f5c ee4f1f50 ee421054 c0e7d180 ee4f1f84
ee59fb80 0006 ee59fb80
[  289.005297] 1f60: 40086409 beb30958 ee4f  ee4f1fa4
ee4f1f80 c0239a44 c0238fb8
[  289.013483] 1f80: 02139378 beb30958 40086409 0036 c0107e04
ee4f  ee4f1fa8
[  289.021668] 1fa0: c0107c60 c0239a14 02139378 beb30958 0006
40086409 beb30958 
[  289.029854] 1fc0: 02139378 beb30958 40086409 0036 01905fc8
014d7890  014d1030
[  289.038041] 1fe0: b6e7d014 beb30918 b6e66560 b6c566c8 6010
0006 ca400482 0c0200a0
[  289.046220] Backtrace:
[  289.048686] [] (page_mapping) from []
(set_page_dirty+0x14/0xc8)
[  289.056446] [] (set_page_dirty) from []
(drm_gem_put_pages+0xac/0xf8)
[  289.064630]  r5:1400 r4:f5b8d374
[  289.068225] [] (drm_gem_put_pages) from []
(etnaviv_gem_shmem_release+0x60/0x6c)
[  289.077366]  r10:ef0d7c00 r9:ee58419c r8:0100 r7:0200
r6:ee58419c r5:ee584000
[  289.085201]  r4:ee584000 r3:
[  289.088790] [] (etnaviv_gem_shmem_release) from
[] (etnaviv_gem_free_object+0xcc/0x1b4)
[  289.098536]  r5:ee584000 r4:ee58419c
[  289.102123] [] (etnaviv_gem_free_object) from
[] (drm_gem_object_free+0x28/0x6c)
[  289.111264]  r10:40086409 r9:ee4f1e60 r8:ee566c1c r7:ee4a0070
r6:ee584000 r5:ee584000
[  289.119100]  r4:ee4a r3:c0527fb0
[  289.122688] [] (drm_gem_object_free) from []
(drm_gem_object_put_unlocked+0x8c/0xc8)
[  289.132172]  r5:ee4a r4:
[  289.135759] [] (drm_gem_object_put_unlocked) from
[] (drm_gem_object_handle_put_unlocked+0x78/0xb8)
[  289.146548]  r7:ee566d24 r6: r5:ee4a0584 r4:ee584000
[  289.152218] [] (drm_gem_object_handle_put_unlocked) from
[] (drm_gem_object_release_handle+0x58/0x90)

[Bug 102358] WarThunder freezes always with vblanc=1

[bugzilla-daemon]

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

Bug ID: 102358
   Summary: WarThunder freezes always with vblanc=1
   Product: Mesa
   Version: git
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: har...@gmx.de
QA Contact: dri-devel@lists.freedesktop.org

On latest mesa git (17.3-dev) WarThunder freezes with vsync activated.

The main problem: 
a system consumes significantly more power (+90W in my case), with vsync
deactivated.

Switching back to mesa 17.2-rc5 or disabling vsync (vblanc=0), are solutions to
make it work, atm.

Here my system specs:
(glxinfo |grep OpenGL)

OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon (TM) R9 380 Series (TONGA / DRM 3.19.0 /
4.13.0-rc5+, LLVM 6.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.0-devel
(git-46a8c4ef81)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.3.0-devel (git-46a8c4ef81)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.3.0-devel
(git-46a8c4ef81)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:

-- 
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 196635] amdgpu clinfo hangs with SI

[bugzilla-daemon]

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

Janpieter Sollie (janpieter.sol...@dommel.be) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |PATCH_ALREADY_AVAILABLE

--- Comment #11 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
the problem SEEMS to be with CIK support and upgrade to rc6 ...
disabling CIK support in my kernel and upgrading it to rc6 solved the problem.
Probably CIK and SI are not really cooperating properly yet.

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

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

[Lucas Stach]

Am Dienstag, den 22.08.2017, 11:58 +0200 schrieb Christian Gmeiner:
[...]
> >> @@ -1444,6 +1463,11 @@ static irqreturn_t irq_handler(int irq, void *data)
> >>
> >>   dev_dbg(gpu->dev, "event %u\n", event);
> >>
> >> + if (gpu->event[event].sync_point) {
> >> + gpu->pmrs_event = event;
> >> + etnaviv_queue_work(gpu->drm, 
> >> >pmrs_work);
> >
> > If the handler is delayed we might handle multiple events per
> > invocation, in which case the events might not be in order. E.g. the FE
> > stop event might be event 30, while the FE start event might be event 0.
> > In that case you would execute the FE start before the FE stop has been
> > queued -> not good. You need to make sure that your PMRS events are
> > processed in the correct order.
> >
> 
> I thought about this problem for some time and I do not fully get your
> point - sorry.
> 
> First there is no FE start event. I am using 'sync' points for pre and
> post pmrs points.

You are right. I was just about to type up a lengthy explanation of what
I meant, but while thinking it through I realized that my assumptions
where invalid. As both the PRE and POST events stop the FE, the GPU can
never get ahead of the event workers.

Please scratch my earlier comments.

Regards,
Lucas

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

Re: [PATCH v4 4/4] drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()

[Hans de Goede]

Hi,

On 22-08-17 11:00, Imre Deak wrote:

On Sun, Aug 20, 2017 at 02:59:20PM +0200, Hans de Goede wrote:





diff --git a/arch/x86/platform/intel/iosf_mbi.c 
b/arch/x86/platform/intel/iosf_mbi.c
index a952ac199741..a5361fd11e6e 100644
--- a/arch/x86/platform/intel/iosf_mbi.c
+++ b/arch/x86/platform/intel/iosf_mbi.c
@@ -218,19 +218,15 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct 
notifier_block *nb)
  }
  EXPORT_SYMBOL(iosf_mbi_register_pmic_bus_access_notifier);
  
-int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb)

+int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
+   struct notifier_block *nb)
  {
-   int ret;
+   WARN_ON(!mutex_is_locked(_mbi_punit_mutex));


Missed to change this to iosf_mbi_assert_punit_acquired(). The rest
looks ok to me. I can change the above while applying, no need to
resend for this.


Cool, thank you.

Regards,

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

[Christian Gmeiner]

Hi Lucas

2017-08-08 12:34 GMT+02:00 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);
>> +
>> + 

Re: [PATCHv2 0/9] omapdrm: hdmi4: add CEC support

[Tomi Valkeinen]

Hi Hans,

>> 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 11/08/17 13:57, Tomi Valkeinen wrote:
>>
>>> I'm doing some testing with this series on my panda. One issue I see is
>>> that when I unload the display modules, I get:
>>>
>>> [   75.180206] platform 58006000.encoder: enabled after unload, idling
>>> [   75.187896] platform 58001000.dispc: enabled after unload, idling
>>> [   75.198242] platform 5800.dss: enabled after unload, idling
>>
>> This one is caused by hdmi_cec_adap_enable() never getting called with
>> enable=false when unloading the modules. Should that be called
>> explicitly in hdmi4_cec_uninit, or is the CEC framework supposed to call it?
> 
> Nicely found!
> 
> The cec_delete_adapter() function calls 
> __cec_s_phys_addr(CEC_PHYS_ADDR_INVALID)
> which would normally call adap_enable(false), except when the device node was
> already unregistered, in which case it just returns immediately.
> 
> The patch below should fix this. Let me know if it works, and I'll post a 
> proper
> patch and get that in for 4.14 (and possible backported as well, I'll have to
> look at that).

Thanks, this fixes the issue.

I again saw "HDMICORE: omapdss HDMICORE error: operation stopped when
reading edid" when I loaded the modules. My panda also froze just now
when unloading the display modules, and it doesn't react to sysrq.

After testing a bit without the CEC patches, I saw the above error, so I
don't think it's related to your patches.

I can't test with a TV, so no CEC for me... But otherwise I think the
series works ok now, and looks ok. So I'll apply, but it's a bit late
for the next merge window, so I'll aim for 4.15 with this.

 Tomi

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

Re: [PATCH v4 4/4] drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()

[Imre Deak]

On Sun, Aug 20, 2017 at 02:59:20PM +0200, Hans de Goede wrote:
> intel_uncore_forcewake_reset() does forcewake puts and gets as such
> we need to make sure that no-one tries to access the PUNIT->PMIC bus
> (on systems where this bus is shared) while it runs, otherwise bad
> things happen.
> 
> Normally this is taken care of by the i915_pmic_bus_access_notifier()
> which does an intel_uncore_forcewake_get(FORCEWAKE_ALL) when some other
> driver tries to access the PMIC bus, so that later forcewake gets are
> no-ops (for the duration of the bus access).
> 
> But intel_uncore_forcewake_reset gets called in 3 cases:
> 1) Before registering the pmic_bus_access_notifier
> 2) After unregistering the pmic_bus_access_notifier
> 3) To reset forcewake state on a GPU reset
> 
> In all 3 cases the i915_pmic_bus_access_notifier() protection is
> insufficient.
> 
> This commit fixes this race by calling iosf_mbi_punit_acquire() before
> calling intel_uncore_forcewake_reset(). In the case where it is called
> directly after unregistering the pmic_bus_access_notifier, we need to
> hold the punit-lock over both calls to avoid a race where
> intel_uncore_fw_release_timer() may execute between the 2 calls.
> 
> To allow holding the lock over both calls we need an unlocked
> variant of iosf_mbi_unregister_pmic_bus_access_notifier. Since
> intel_uncore.c is the only user of this function, we simply
> modify it in this commit. Doing this in a separate commit would
> require first adding an unlocked variant, then this commit and
> then removing the unused normal variant.
> 
> Signed-off-by: Hans de Goede 
> Reviewed-by: Imre Deak 
> ---
> Changes in v2:
> -Rebase on current (July 6th 2017) drm-next
> 
> Changes in v3:
> -Keep punit acquired / locked over the unregister + forcewake_reset
>  call combo to avoid a race hitting between the 2 calls
> -This requires modifying iosf_mbi_unregister_pmic_bus_access_notifier
>  to not take the lock itself, since we are the only users this is done
>  in this same commit
> 
> Changes in v4:
> -Fix missing rename in doc-comment
> -Add and use iosf_mbi_assert_punit_acquired() helper
> -Add missing acquiqre surrounding intel_uncore_forcewake_reset() inside
>  intel_uncore_check_forcewake_domains()
> -Add Imre's Reviewed-by
> ---
>  arch/x86/include/asm/iosf_mbi.h   | 20 +---
>  arch/x86/platform/intel/iosf_mbi.c| 20 +++-
>  drivers/gpu/drm/i915/intel_uncore.c   | 17 +
>  drivers/gpu/drm/i915/selftests/intel_uncore.c |  3 +++
>  4 files changed, 44 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h
> index c313cac36f56..0f0de4303180 100644
> --- a/arch/x86/include/asm/iosf_mbi.h
> +++ b/arch/x86/include/asm/iosf_mbi.h
> @@ -139,11 +139,17 @@ void iosf_mbi_punit_release(void);
>  int iosf_mbi_register_pmic_bus_access_notifier(struct notifier_block *nb);
>  
>  /**
> - * iosf_mbi_register_pmic_bus_access_notifier - Unregister PMIC bus notifier
> + * iosf_mbi_register_pmic_bus_access_notifier_unlocked - Unregister PMIC bus
> + *   notifier
> + *
> + * Note the caller must call iosf_mbi_punit_acquire() before calling this
> + * to ensure the bus is inactive before unregistering (and call
> + * iosf_mbi_punit_release() afterwards).
>   *
>   * @nb: notifier_block to unregister
>   */
> -int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb);
> +int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
> + struct notifier_block *nb);
>  
>  /**
>   * iosf_mbi_call_pmic_bus_access_notifier_chain - Call PMIC bus notifier 
> chain
> @@ -153,6 +159,11 @@ int iosf_mbi_unregister_pmic_bus_access_notifier(struct 
> notifier_block *nb);
>   */
>  int iosf_mbi_call_pmic_bus_access_notifier_chain(unsigned long val, void *v);
>  
> +/**
> + * iosf_mbi_assert_punit_acquired - Assert that the P-Unit has been acquired.
> + */
> +void iosf_mbi_assert_punit_acquired(void);
> +
>  #else /* CONFIG_IOSF_MBI is not enabled */
>  static inline
>  bool iosf_mbi_available(void)
> @@ -191,7 +202,8 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct 
> notifier_block *nb)
>  }
>  
>  static inline
> -int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb)
> +int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
> + struct notifier_block *nb)
>  {
>   return 0;
>  }
> @@ -202,6 +214,8 @@ int iosf_mbi_call_pmic_bus_access_notifier_chain(unsigned 
> long val, void *v)
>   return 0;
>  }
>  
> +static inline void iosf_mbi_assert_punit_acquired(void) {}
> +
>  #endif /* CONFIG_IOSF_MBI */
>  
>  #endif /* IOSF_MBI_SYMS_H */
> diff --git a/arch/x86/platform/intel/iosf_mbi.c 
> b/arch/x86/platform/intel/iosf_mbi.c
> index a952ac199741..a5361fd11e6e 100644
> --- a/arch/x86/platform/intel/iosf_mbi.c
> +++ 

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

[Christian Gmeiner]

Hi Lucas,

2017-08-22 10:39 GMT+02:00 Lucas Stach :
> Hi Christian,
>
> Am Dienstag, den 22.08.2017, 10:27 +0200 schrieb Christian Gmeiner:
>> Hi Lucas.
>>
>> Thanks for your review - hopefully there will be only one last v3
>> series of that patches.
>
> Yep, I would really like to merge this series. It's been in the making
> for long enough. :)
>
>> 2017-08-08 12:00 GMT+02:00 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.
>> >
>>
>> Makes sense but I not really sure how to best implement an absolute
>> timeout. We could wait
>> absolute timeout / nr_events in each wait_for_completion_timeout(..) call.
>
> I think we should just keep the 10sec timeout regardless of the number
> of events. If we don't acquire the needed events after 10secs, it's
> probably fine to give up.
>

Yeah :)

>> >> @@ -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.
>> >
>>
>> Yes - feels more elegant that way.
>>
>> >> +
>> >> + 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;
>> >>   }
>> >>
>> >
>> >
>>
>> What about something like this:
>
> A few notes inline.
>
>>
>> static int event_alloc(struct etnaviv_gpu *gpu, unsigned nr_events,
>> unsigned int *events)
>> {
>> unsigned long flags;
>> unsigned i;
>> int err = 0;
>>
>> for (i = 0; i < nr_events; i++) {
>> unsigned long ret;
>   timeout = msecs_to_jiffies(10 * 1);
>>
>> ret = wait_for_completion_timeout(>event_free,
>> msecs_to_jiffies(10 * 1));
>   ^^ 

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

[Lucas Stach]

Hi Christian,

Am Dienstag, den 22.08.2017, 10:27 +0200 schrieb Christian Gmeiner:
> Hi Lucas.
> 
> Thanks for your review - hopefully there will be only one last v3
> series of that patches.

Yep, I would really like to merge this series. It's been in the making
for long enough. :)

> 2017-08-08 12:00 GMT+02:00 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.
> >
> 
> Makes sense but I not really sure how to best implement an absolute
> timeout. We could wait
> absolute timeout / nr_events in each wait_for_completion_timeout(..) call.

I think we should just keep the 10sec timeout regardless of the number
of events. If we don't acquire the needed events after 10secs, it's
probably fine to give up.

> >> @@ -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.
> >
> 
> Yes - feels more elegant that way.
> 
> >> +
> >> + 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;
> >>   }
> >>
> >
> >
> 
> What about something like this:

A few notes inline.

> 
> static int event_alloc(struct etnaviv_gpu *gpu, unsigned nr_events,
> unsigned int *events)
> {
> unsigned long flags;
> unsigned i;
> int err = 0;
> 
> for (i = 0; i < nr_events; i++) {
> unsigned long ret;
  timeout = msecs_to_jiffies(10 * 1);
> 
> ret = wait_for_completion_timeout(>event_free,
> msecs_to_jiffies(10 * 1));
  ^^ use timeout here
> if (!ret) {
> dev_err(gpu->dev, "wait_for_completion_timeout failed");
> err = -EBUSY;
> goto out;
> }

If we waited successfully, wait_for_completion_timeout will 

Re: [PATCH V2 12/23] drm/etnaviv: use 'sync points' for performance monitor requests

[Christian Gmeiner]

2017-08-08 12:49 GMT+02:00 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.
>

Both will be fixed in V3.

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

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

[Christian Gmeiner]

2017-08-08 12:13 GMT+02:00 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))

Fixed in v3

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

Re: [PATCH 0/9] drm/syncobj: Add full-featured wait support (v2)

[Christian König]

Am 21.08.2017 um 23:42 schrieb Jason Ekstrand:



On Wed, Aug 16, 2017 at 1:10 PM, Jason Ekstrand > wrote:


On Wed, Aug 16, 2017 at 9:53 AM, Christian König
> wrote:


[SNIP]

See a wait_queue is a callback mechanism anyway, so
you are wrapping a callback mechanism inside another
callback mechanism and that makes not really much sense.


Fair enough.  There is one little snag though:  We need
to wait on sync objects and fences at the same time in
order for WAIT_ANY | WAIT_FOR_SUBMIT to work.  I see two
options here:

 1) Convert dma-fence to use waitqueue instead of its
callback mechanism and add a wait_queue_any.  A quick
grep for dma_fence_add_callback says that this would
affect four drivers.


The more I think about it, the less sense using waitqueues
makes.  The fundamental problem here is that the event we are
waiting on is actually the concatenation of two events:
submit and signal.  Since we are waiting on several of these
pairs of concatenated events simultaneously, the only two
options we have are to either combine them into one event
(the proxy approach) or to implement a wait which is capable
of handling both at the same time.  I don't see a way to do
the latter with wait queues.


Agree completely.

Essentially we would need to enable wait_event_* to wait for
multiple events and then convert all the fence callback stuff
to wait_event structures.

But that is certainly outside the scope of this patchset, so
feel free to go ahead with the approach of waiting manually
(but please without the bugs).


Well, the patches I sent last night should do just that.  It's
mostly the original approach but with the bugfixes from versions 3
and 4. Modulo finding additional bugs, I think they should be good
to go.

ping?
I just way to much to do at the moment (as usually). Feel free to add an 
Acked-by: Christian König  to the patches in 
the meantime, but an detailed review would have to wait a bit.


Sorry for the delay,
Christian.
___
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

[Christian Gmeiner]

Hi Lucas.

Thanks for your review - hopefully there will be only one last v3
series of that patches.

2017-08-08 12:00 GMT+02:00 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.
>

Makes sense but I not really sure how to best implement an absolute
timeout. We could wait
absolute timeout / nr_events in each wait_for_completion_timeout(..) call.

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

Yes - feels more elegant that way.

>> +
>> + 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;
>>   }
>>
>
>

What about something like this:

static int event_alloc(struct etnaviv_gpu *gpu, unsigned nr_events,
unsigned int *events)
{
unsigned long flags;
unsigned i;
int err = 0;

for (i = 0; i < nr_events; i++) {
unsigned long ret;

ret = wait_for_completion_timeout(>event_free,
msecs_to_jiffies(10 * 1));
if (!ret) {
dev_err(gpu->dev, "wait_for_completion_timeout failed");
err = -EBUSY;
goto out;
}
}

spin_lock_irqsave(>event_spinlock, flags);

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);
}

spin_unlock_irqrestore(>event_spinlock, flags);

out:
return err;
}

greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info
___
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

[Gerd Hoffmann]

  Hi,

> These are both from Gerd.  Gerd, do you have any objection to using a
> union to provide either the dmabuf fd or region index?

No.

> > It's like we want to propose a general interface used to share
> > guest's buffer with host. And the
> > general interface, so far, has two choice: region and dma-buf. So
> > each mdev likes this interface
> > can implement one kind of it and gets the benefit from the general
> > interface.
> > So, if we think about this, the difference in user mode should be
> > as little as possible.
> 
> The difference seems pretty minimal here, the user probes supported
> interface types, and explicitly picks one by requesting updates using
> that interface type.  The difference is only in the interpretation of
> one dword field.  Furthermore, we're not limiting ourselves to these
> two interface types, this same API could support dmabuf-v2 if we
> define
> a flag bit for it and define the structure of the interface union.

Yep, using the flags is more future-proof and continues to work in case
another interface type shows up (unlike looking for a gfx region being
present).

> > Agree, that's a good proposal, which can handle all the cases.
> > I'm just not sure about the usage case of "on every call". In
> > previous discussion, it seems we think static is enough.
> 
> Is it somehow a problem for the user to set the type bit in the flag
> on
> every call?

Not at all.

cheers,
  Gerd

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

[Bug 100991] [snb] GPU hangs in "ositorWorkQueue"

[bugzilla-daemon]

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

tompl...@gmail.com changed:

   What|Removed |Added

   Priority|medium  |high
 CC||tompl...@gmail.com

-- 
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 100991] [snb] GPU hangs in "ositorWorkQueue"

[bugzilla-daemon]

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

tompl...@gmail.com changed:

   What|Removed |Added

   Assignee|intel-3d-bugs@lists.freedes |dri-devel@lists.freedesktop
   |ktop.org|.org
 QA Contact|intel-3d-bugs@lists.freedes |dri-devel@lists.freedesktop
   |ktop.org|.org
  Component|Drivers/DRI/i965|Drivers/DRI/i915

-- 
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 98324] [DC] amd-staging-4.7: problems with unblanking displays when monitors are switched off

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

Summary|amd-staging-4.7: problems   |[DC] amd-staging-4.7:
   |with unblanking displays|problems with unblanking
   |when monitors are switched  |displays when monitors are
   |off |switched off
 CC||harry.wentl...@amd.com

-- 
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 102323] [DC] System crashes when woken up from S3 sleep while HDMI display is switched off

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com
Summary|System crashes when woken   |[DC] System crashes when
   |up from S3 sleep while HDMI |woken up from S3 sleep
   |display is switched off |while HDMI display is
   ||switched off

-- 
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: virtio: constify drm_fb_helper_funcs

[Daniel Vetter]

On Mon, Aug 21, 2017 at 04:37:32PM +0530, Arvind Yadav wrote:
> drm_fb_helper_funcs are not supposed to change at runtime.
> All functions working with drm_fb_helper_funcs provided
> by  work with const drm_fb_helper_funcs.
> So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 
> ---
>  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 33df067..61f33ec 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_fb.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
> @@ -309,7 +309,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 = {

I have this patch already from someone else. Please create your patches
against linux-next to avoid this kind of duplicated work.

Thanks, Daniel
>   .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

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

Re: [PATCH 0/3] constify drm i2c_device_id

[Daniel Vetter]

On Sat, Aug 19, 2017 at 11:58:17PM +0530, Arvind Yadav wrote:
> i2c_device_id are not supposed to change at runtime. All functions
> working with i2c_device_id provided by  work with
> const i2c_device_id. So mark the non-const structs as const.

All applied.

btw I think this isn't your first series, and we're trying to keep some of
the trivial mistakes around in drm, as an easy way for newbies to get into
the subsystem with their first patch.

We'd like more regular contributors to tackle some of the more involved
cleanup tasks, which should also be more valuable to the subsystem:

file:///home/daniel/linux/src/Documentation/output/gpu/todo.html#todo

Cheers, Daniel

> 
> Arvind Yadav (3):
>   [PATCH 1/3] drm: i2c: ch7006: constify i2c_device_id
>   [PATCH 2/3] drm: i2c: sil164: constify i2c_device_id
>   [PATCH 3/3] drm: i2c: tda998x: constify i2c_device_id
> 
>  drivers/gpu/drm/i2c/ch7006_drv.c  | 2 +-
>  drivers/gpu/drm/i2c/sil164_drv.c  | 2 +-
>  drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> -- 
> 2.7.4
> 
> ___
> 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

Re: drm, fbdev emulation and drm_dev_unplug()

[Daniel Vetter]

On Mon, Aug 21, 2017 at 08:53:08PM +0200, Noralf Trønnes wrote:
> Hi,
> 
> I'm looking into what happens if fbdev has open file handles when
> drm_dev_unplug() is called. udl is the only user of drm_dev_unplug(),
> but AFAICT it will keel over if unplugged with a /dev/fb handle open
> since fbdev is torn down during drm_driver->unload.
> 
> My first attempt was to rely on the drm_device ref counting and tear
> down fbdev in drm_driver->release. This requires that a ref is taken on
> drm_device in _ops.fb_open and dropped in _ops.fb_release.
> The problem is that .fb_release is called under console_lock(), which
> means that unregister_framebuffer() will deadlock (assuming last ref on
> drm_device here). Trying to do trickery with console_lock to get this
> through is bound to be painful, so a straightforward solution is to fork
> of fbdev teardown to a worker.
> Since we are already in drm_driver->release, this won't work.
> 
> My next idea is to refcount struct drm_fb_helper, take one ref on
> drm_device and handle the lifetime of fbdev that way. Now it's possible to
> do teardown in a worker and when that's done, drop the ref on drm_device.
> The plan was to make this ref counting optional for drivers.
> 
> Is ref counting drm_fb_helper a good/bad idea, or is there another
> solution to this?

I think we'd need to do something similar to what we do with the main drm
devices:

- On unplug we unregister the framebuffer to stop any userspace apps from
  opening it and creating new references.

- Every time someone opens the /dev/fb0 node for our emulated fbdev, we
  call drm_dev_ref(), and drm_dev_unref() on close.

- We need to sprinkle drm_dev_is_unplugged() checks over all the fbdev
  entry points.

- Getting this right for the mmaps will be additional fun, but then we
  don't really get that right for drm either ...

- (Aside, those should be rename to _get()/_put() for ocd consistency,
  it's the prefererred refcounting naming convention in the kernel).

I have no idea whether fbdev supports this, it was kinda created before
hotplug was a thing :-( But from a quick look we do have fb_open/close
callbacks in fb_ops, so this should be doable.

Cheers, Daniel
-- 
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