Re: drm_modeset_lock oops in next

[Maarten Lankhorst]

Op 08-04-17 om 18:46 schreef Tony Lindgren:
> * Maarten Lankhorst  [170408 01:55]:
>> Hey,
>>
>> Op 07-04-17 om 17:56 schreef Tony Lindgren:
>>> Hi,
>>>
>>> Looks like current next now oopses at least for omapdrm
>>> when starting X. Reverting commit d20afeb3e2f9 ("Merge
>>> remote-tracking branch 'drm-misc/for-linux-next'") makes
>>> things work again.
>>>
>>> Any ideas what might be causing the oops below?
>> Looks like fallout from the acquire_ctx patches?
>>
>> Could you test the below?
> Yes thanks Daniel Vetter already posted a similar fix as
> "[PATCH] drm: Only take cursor locks when the cursor plane exists".
>
> Regards,
>
> Tony

Yeah saw it later, no worries. :)

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

[Bug 100638] Shadow of mordor crash Mesa: User error: GL_INVALID_VALUE in glFlushMappedBufferRange(offset 2097060 + length 480 > mapped length 2097152)

[bugzilla-daemon]

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

Bug ID: 100638
   Summary: Shadow of mordor crash Mesa: User error:
GL_INVALID_VALUE in glFlushMappedBufferRange(offset
2097060 + length 480 > mapped length 2097152)
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: edisonalva...@arnet.com.ar
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 130770
  --> https://bugs.freedesktop.org/attachment.cgi?id=130770&action=edit
dmesg

It crashes randomly if I reset the graphics settings to default it doesn't
happen again for some time, then it crashes again and I have to reset the
settings because it won't start.
I using DAL/DC kernel staging from git 4.9.20, but it happens with other
kernels.

-- 
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 100638] Shadow of mordor crash Mesa: User error: GL_INVALID_VALUE in glFlushMappedBufferRange(offset 2097060 + length 480 > mapped length 2097152)

[bugzilla-daemon]

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

--- Comment #1 from alvarex  ---
Created attachment 130771
  --> https://bugs.freedesktop.org/attachment.cgi?id=130771&action=edit
xorg log

-- 
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: [RFC 1/7] drm/atomic: initial support for asynchronous plane update

[Emil Velikov]

Hi Gustavo,

Mostly some documentation suggestions below. Hope that I've not lost
the plot and they seem ok :-)

On 10 April 2017 at 01:24, Gustavo Padovan  wrote:

> +static bool drm_atomic_async_check(struct drm_atomic_state *state)
> +{

/* FIXME: we support single plane updates for now */
> +   if (!plane || n_planes != 1)
> +   return false;
> +

> +   if (!funcs->atomic_async_update)
> +   return false;


> +void drm_atomic_helper_async_commit(struct drm_device *dev,
> +   struct drm_atomic_state *state)
> +{
> +   struct drm_plane *plane;
> +   struct drm_plane_state *plane_state;
> +   const struct drm_plane_helper_funcs *funcs;
> +   int i;
> +
> +   for_each_new_plane_in_state(state, plane, plane_state, i) {
> +   funcs = plane->helper_private;
> +
> +   plane->state->src_x = plane_state->src_x;
> +   plane->state->src_y = plane_state->src_y;
> +   plane->state->crtc_x = plane_state->crtc_x;
> +   plane->state->crtc_y = plane_state->crtc_y;
> +
> +   if (funcs && funcs->atomic_async_update)
> +   funcs->atomic_async_update(plane, plane_state);

This looks a bit strange. We don't want to change any state if the
hook is missing right?
Actually the if will always be true, since we've already validated
that in drm_atomic_async_check().

Should we unconditionally call funcs->atomic_async_update()?


> @@ -172,6 +174,8 @@ struct drm_atomic_state {
> struct drm_device *dev;
> bool allow_modeset : 1;
> bool legacy_cursor_update : 1;
> +   bool legacy_set_config : 1;
Seems unused in this patch. Introduce at a later stage?


> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -1048,6 +1048,53 @@ struct drm_plane_helper_funcs {
>  */
> void (*atomic_disable)(struct drm_plane *plane,
>struct drm_plane_state *old_state);
> +
> +   /**
> +* @atomic_async_check:
> +*
> +* Drivers should use this function check if the plane state
s/use this function check/set this function pointer/

> +* can be updated in a async fashion.
> +*
> +* This hook is called by drm_atomic_async_check() in the process
> +* to figure out if an given update can be committed asynchronously,
s/in the process to figure out if an/to establish if a/ s/,/./

> +* that is, if it can jump ahead the state currently queued for
> +* update.
> +*
> +* Check drm_atomic_async_check() to see what is already there
> +* to discover potential async updates.
Remove these two sentences? They don't seem to bring much.

> +*
> +* RETURNS:
> +*
> +* Return 0 on success and -EINVAL if the update can't be async.
s/if the update can't be async/on error/

> +* Error return doesn't mean that the update can't be applied,
> +* it just mean that it can't be an async one.
> +*
Any error returned indicates that the update can not be applied in
asynchronous manner.
Side-note: suggest who/how to retry synchronously ?

> +* FIXME:
> +*  - It only works for single plane updates
> +*  - It can't do async update if the plane is already being update
> +*  by the queued state
> +*  - Async Pageflips are not supported yet
> +*/
> +   int (*atomic_async_check)(struct drm_plane *plane,
> + struct drm_plane_state *state);
> +
> +   /**
> +* @atomic_async_update:
> +*
> +* Drivers should use this functions to perform asynchronous
As above - drivers do not use this function. They only provide the
function pointer, right?

> +* updates of planes, that is jump ahead the currently queued
> +* state for and update the plane.
> +*
> +* This hook is called by drm_atomic_helper_async_commit().
> +*
> +* Note that differently from the 
> &drm_plane_helper_funcs.atomic_update
s/differently from the/unlike/

> +* this hook takes the new &drm_plane_state as parameter. When doing
> +* async_update drivers shouldn't replace the &drm_plane_state but
> +* just, update the current one with the new plane configurations in
s/just,// or s/just,/simply/

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

[Bug 100593] corruption in total war warhammer when using mesa 17.1 - git

[bugzilla-daemon]

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

--- Comment #5 from Gregor Münch  ---
Some people reported this should actually got fixed by
0fb5a505fac7be0a1831b565019f0f04369e56bd, but looks like it isnt for all. 
https://bugs.freedesktop.org/show_bug.cgi?id=100531

Will test myself in some days...

-- 
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: panels: Add MAINTAINERS entry for LVS panel driver

[Thierry Reding]

On Sun, Apr 09, 2017 at 01:31:40PM +0100, Emil Velikov wrote:
> Hi Thierry,
> 
> I don't mean to stir up anything, just voicing "my 2c" as they say.
> 
> On 7 April 2017 at 18:33, Thierry Reding  wrote:
> 
> > Ever since the simple-panel binding was introduced, which is now about
> > 3 1/2 years ago,
> 
> Do you have a link to these discussions? Your blog article does not
> have any links and I only found the "Runtime Interpreted Power
> Sequences" thread.
> That in itself does not cover the pros/cons of storing HW information*
> within DT.

There's some discussion here:


https://lists.freedesktop.org/archives/dri-devel/2013-November/049509.html

which continues here:


https://lists.freedesktop.org/archives/dri-devel/2013-December/050082.html

There are a couple of earlier threads, though, that discuss similar
issues. This one seems to be the earliest I can find that is publicly
archived:

http://www.spinics.net/lists/devicetree/msg08497.html

Going over all these threads again wasn't a very pleasant experience. I
realize how much time I already spent discussing these, and I don't have
any desire to repeat that discussion.

We've had these differences ever since the very beginning. So we're now
again going in circles.

The main concern back at the time was that having to specify timings in
the driver would result in a complete mess because we have zillions of
panels that we need to support. That's turned out to be a complete non-
issue. We've got something on the order of 50 or 60 drivers supported in
the simple-panel driver, and for everything that's more complicated we
have a handful of separate drivers, all fairly simple as well.

So while I understand why people want to put all this information into
DT, we've repeatedly discussed the disadvantages that this would have.
And while we were never able to get everyone to agree, the current
solution has had enough agreement that we merged it. And it turned out
to be good enough. There's nothing in panel-lvds that I can see that
fundamentally changes this.

> Personally, the idea of having hardware information* in DT does not
> sound all that bad. The simple panel driver(s) can use those
> properties and any panels that require anything more complex will
> still need their own driver.

Again, the point is that you're going to have to modify the driver in
any case, because you need to support the new compatible string. Without
that compatible string you have zero information about the panel, and
matching on a generic one isn't going to give you a working panel. So if
you're already going to have to support a panel in a driver, why not go
all the way and fully describe its capabilities and properties? We do it
for all other devices. Panels are not at all special.

> For better or for worse, there's already a handful of drivers and
> bindings that rely on/provide these. Using that information
> consistently across the board, would be of a benefit, IMHO.

Would you mind pointing out which ones these are? I'm aware of only a
couple that seemed to have sneeked in because people were trying to
side-step adding drm/panel support for their boards, so I don't think
that qualifies as a reason to rethink how drm/panel works.

Thierry


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

[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

[bugzilla-daemon]

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

--- Comment #11 from Michel Dänzer  ---
When R600_DEBUG=check_vm catches a VM fault, it generates a report in
~/ddebug_dumps/ , please attach that here.

A similar report from something like GALLIUM_DDEBUG="pipelined 1" might
give more information.

-- 
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: DRM Display driver for Intel FPGA Video and Image Processing Suite

[Daniel Vetter]

On Mon, Apr 10, 2017 at 9:49 AM, Ong, Hean Loong
 wrote:
> Thanks again Daniel for the clarification.
>
> However I cannot seem to find the repo for the drm-misc and documentation on 
> how to get it from the main kernel tree.
>
> Could you can give me some pointers on where to get the git tree of the 
> drm-misc for small drivers. Sorry as I am not very familiar with the DRM 
> architecture

The doc I linked also contains the git url:

https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html

git://anongit.freedesktop.org/drm-misc

It is also listed in MAINTAINERS for each driver and subsystem
maintained in drm-misc.

Cheers, Daniel

>
>>-Original Message-
>>From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of 
>>Daniel
>>Vetter
>>Sent: Sunday, April 9, 2017 12:31 AM
>>To: Ong, Hean Loong 
>>Cc: Vetter, Daniel ; airl...@linux.ie; dri-
>>de...@lists.freedesktop.org
>>Subject: Re: DRM Display driver for Intel FPGA Video and Image Processing 
>>Suite
>>
>>On Sat, Apr 8, 2017 at 7:41 AM, Ong, Hean Loong 
>>wrote:
>>> Hi Daniel
>>>
>>> Thanks for the time and patience for reviewing my changes. I would ensure 
>>> that
>>subsequent patches will not have the same mail problems.
>>>
>>> I have some question on the validation methods. Since my drivers are
>>processing the images with an FPGA would running the tests with
>>https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-and-validation
>>be relevant?
>>
>>igt testcases automatically skip when they don't apply for a given 
>>platform/driver.
>>They might need some bugfixes if your driver is a completely new case, but it
>>should work.
>>
>>> The display images are streamed to the monitor via a Display Port connector
>>thus I don' t think it is virtual. The FPGA is programmed to run with a 
>>proprietary
>>Display Port IP. The driver just feeds it with display data.
>>
>>Well, it looked like a virtual driver (since the real DP handling is 
>>somewhere else
>>like you explain). And since it works like a virtual driver we could extract 
>>a helper
>>library to reduce duplicated code.
>>Virtual driver here means "just feeds display data to something else that 
>>handles
>>the real output handling duties". That applies to virtualized gpus, but also 
>>to your
>>case here.
>>
>>Btw a small ascii-art block diagram for your driver hw architecture to 
>>explain stuff
>>like this would be awesome (but it either into a code comment or into the 
>>commit
>>message).
>>
>>> I would take your advice in implementing it in the small drivers, but since 
>>> its new
>>are there any special cases that I would have to look out for in implementing 
>>this
>>driver in the drm-misc ?
>>
>>Small drivers is only about how to maintain it once it's merged, not about the
>>code itself. We assume/hope that people who submit drivers stay around for
>>helping maintaining it going forward (but if that doesn't happen, also no big 
>>deal).
>>-Daniel
>>
>>>
-Original Message-
From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf
Of Daniel Vetter
Sent: Saturday, April 8, 2017 12:32 AM
To: Ong, Hean Loong 
Cc: Vetter, Daniel ; airl...@linux.ie; dri-
de...@lists.freedesktop.org
Subject: Re: DRM Display driver for Intel FPGA Video and Image
Processing Suite

On Thu, Apr 6, 2017 at 8:29 AM, Ong, Hean Loong

wrote:
> Hi All,
>
> Any comments for the patch below?

Seems the same version that I already reviewed. My comment about not
sending inline was more for the next version, especially once it's
about applying the patch, attached patches are a bit of a pain (since they 
break
>>the tooling here).
-Daniel
>
> Thanks
>
> Hean Loong
>
> On Tue, 2017-04-04 at 04:01 +, Ong, Hean Loong wrote:
>> Hi All,
>>
>> Apologies for the attachment earlier. Below are the inline changes
>> for the patch
>>
>> From 0de293e3646a1780ed603cf8e1f2a19d9aebbe83 Mon Sep 17 00:00:00
>> 2001
>> From: Ong, Hean Loong 
>> Date: Thu, 30 Mar 2017 18:02:22 +0800
>> Subject: [PATCHv0] Intel FPGA Video and Image Processing Suite
>> Frame Buffer II driver
>>
>> Signed-off-by: Ong, Hean Loong 
>> ---
>>  drivers/gpu/drm/Kconfig   |2 +
>>  drivers/gpu/drm/Makefile  |1 +
>>  drivers/gpu/drm/ivip/Kconfig  |   22 
>>  drivers/gpu/drm/ivip/Makefile |9 ++
>>  drivers/gpu/drm/ivip/intel_vip_conn.c |  145
>> ++ drivers/gpu/drm/ivip/intel_vip_core.c |  215
>> +
>>  drivers/gpu/drm/ivip/intel_vip_crtc.c |  161
>> 
>>  drivers/gpu/drm/ivip/intel_vip_drv.h  |   55 +
>>  drivers/gpu/drm/ivip/intel_vip_of.c   |  146 ++
>>  9 files changed, 756 insertions(+), 0 deletions(-)  create mode
>> 100644 dri

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 204 warnings (v4.11-rc5-1803-gd86f5fa557fd)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 204 warnings 
(v4.11-rc5-1803-gd86f5fa557fd)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1803-gd86f5fa557fd/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1803-gd86f5fa557fd
Git Commit: d86f5fa557fdf089bdb5b51f625a7f5967f11015
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  drivers/tty/vt/keyboard.c:14

Re: [PATCH libdrm v2 1/2] etnaviv: sync uapi header

[Philipp Zabel]

On Sat, 2017-04-08 at 20:55 +0100, Emil Velikov wrote:
> On 7 April 2017 at 13:06, Philipp Zabel  wrote:
> > Import the etnaviv header changes from kernel commits 9ad59fea162c
> > ("drm/etnaviv: submit support for in-fences") and 78ec187f64fa
> > ("drm/etnaviv: submit support for out-fences") for fence fd support.
> >
> > The drm_etnaviv_gem_submit structure was extended to include a flags
> > field, new flags for in-fence and out-fence fds and an input/output
> > fence fd field.
> >
> > This is one-way backwards compatible because old userspace code passing
> > a short structure not including the flags field to new kernels will
> > cause the remaining fields to be zero-filled. New userspace code must
> > make sure to only pass the short structure to old kernels, though.
> >
> > Not generated using make headers_install, since the drm/etnaviv_drm.h
> > uapi header is not installed yet by the kernel.
> IIRC all the other drivers should already install the header, so we
> want to fix this, right?
> If we're too late for this kernel cycle, we will land the patch as-is.

Yes, I'll send a kernel patch for the next cycle. For now I'll just
resend the patch as-is but with the new symbol added to symbol-check.

regards
Philipp

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

Re: [PATCH 1/2] drm: Add DRM_CAP_PRIME_SCANOUT.

[Michel Dänzer]

On 06/04/17 04:47 PM, Christopher James Halse Rogers wrote:
> On Wed, 5 Apr 2017 at 20:14 Lucas Stach  > wrote:
> 
> Am Mittwoch, den 05.04.2017, 11:59 +0200 schrieb Daniel Vetter:
> > On Wed, Apr 05, 2017 at 10:15:44AM +0200, Lucas Stach wrote:
> > > Am Mittwoch, den 05.04.2017, 00:20 + schrieb Christopher
> James Halse
> > > Rogers:
> > > >
> > > >
> > > > On Tue, Apr 4, 2017 at 9:53 PM Daniel Vetter  > wrote:
> > > >
> > > > On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach
> > > >  > wrote:
> > > > >> If I could guarantee that I'd only ever run on
> > > > 4.13-or-later kernels
> > > > >> (I think that's when the previous patches will
> land?), then
> > > > this would
> > > > >> indeed be mostly unnecessary. It would save me a
> bunch of
> > > > addfb calls
> > > > >> that would predictably fail, but they're cheap.
> > > > >
> > > > > I don't think we ever had caps for "things are
> working now,
> > > > as they are
> > > > > supposed to". i915 wasn't properly synchronizing on
> foreign
> > > > fences for a
> > > > > long time, yet we didn't gain a cap for "cross
> device sync
> > > > works now".
> > > > >
> > > > > If your distro use-case relies on those things
> working it's
> > > > probably
> > > > > best to just backport the relevant fixes.
> > > >
> > > > The even better solution for this is to push the backports
> > > > through
> > > > upstream -stable kernels. This stuff here is simple enough
> > > > that we can
> > > > do it. Same could have been done for the fairly minimal
> > > > fencing fixes
> > > > for i915 (at least some of them, the ones in the
> page-flip).
> > > >
> > > > Otherwise we'll end up with tons IM_NOT_BUGGY and
> > > > IM_SLIGHTLY_LESS_BUGGY and
> > > > IM_NOT_BUGGY_EXCEPT_THIS_BOTCHED_BACKPORT
> > > > flags where no one at all knows what they mean, usage
> between
> > > > different drivers and different userspace is entirely
> > > > inconsistent and
> > > > they just all add to the confusion. They're just bugs,
> lets
> > > > treat them
> > > > like that.
> > > >
> > > >
> > > > It's not *quite* DRM_CAP_PRIME_SCANOUT_NOT_BUGGY - while the
> relevant
> > > > hardware allegedly supports it, nouveau/radeon/amdgpu don't do
> scanout
> > > > of GTT, so the lack of this cap indicates that there's no point in
> > > > trying to call addfb2.
> > > >
> > > >
> > > > But calling addfb2 and it failing is not expensive, so this is
> rather
> > > > niche.
> > > >
> > > >
> > > > In practice I can just restrict attempting to scanout of imported
> > > > buffers to i915, as that's the only driver that it'll work on.
> By the
> > > > time nouveau/radeon/amdgpu get patches to scanout of GTT the fixes
> > > > should be old enough that I don't need to care about unfixed
> kernels.
> > > >
> > > So given that most discreet hardware won't ever be able to
> scanout from
> > > GTT (latency and iso requirements will be hard to meet), can't
> we just
> > > fix the case of the broken prime sharing when migrating to VRAM?
> > >
> > > I'm thinking about attaching an exclusive fence to the dma-buf
> when the
> > > migration to VRAM happens, then when the GPU is done with the
> buffer we
> > > can either write back any changes to GTT, or just drop the fence
> in case
> > > the GPU didn't modify the buffer.
> >
> > We could, but someone needs to type the code for it. There's also the
> > problem that you need to migrate back, and then doing all that behind
> > userspaces back might not be the best idea.
> 
> Drivers with separate VRAM and GTT are already doing a lot of migration
> behind the userspaces back. The only issue with dma-buf migration to
> VRAM is that you probably don't want to migrate the pages, but duplicate
> them in VRAM, doubling memory consumption with possible OOM. But then
> you could alloc the memory on addfb where you are able to return proper
> errors.
> 
> 
> Hm. So, on a first inspection, this looks like something I could
> actually cook up.
> 
> Looking at amdgpu it seems like the thing to do would be to associate a
> shadow-bo in VRAM for the imported dma-buf in the addfb call, then
> pin-and-copy-to the shadow bo in the places where the bo is currently
> pinned.
> 
> Is this approach likely to be acceptable?

It

Re: [PATCH 1/2] drm: Add DRM_CAP_PRIME_SCANOUT.

[Michel Dänzer]

On 05/04/17 08:21 PM, Christian König wrote:
> Am 05.04.2017 um 13:13 schrieb Christopher James Halse Rogers:
>> On Wed, Apr 5, 2017 at 8:14 PM Lucas Stach > > wrote:
>>
>> Am Mittwoch, den 05.04.2017, 11:59 +0200 schrieb Daniel Vetter:
>> > On Wed, Apr 05, 2017 at 10:15:44AM +0200, Lucas Stach wrote:
>> > > Am Mittwoch, den 05.04.2017, 00:20 + schrieb Christopher
>> James Halse
>> > > Rogers:
>> > > >
>> > > >
>> > > > On Tue, Apr 4, 2017 at 9:53 PM Daniel Vetter
>> mailto:dan...@ffwll.ch>> wrote:
>> > > >
>> > > > On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach
>> > > > > > wrote:
>> > > > >> If I could guarantee that I'd only ever run on
>> > > > 4.13-or-later kernels
>> > > > >> (I think that's when the previous patches will
>> land?), then
>> > > > this would
>> > > > >> indeed be mostly unnecessary. It would save me a
>> bunch of
>> > > > addfb calls
>> > > > >> that would predictably fail, but they're cheap.
>> > > > >
>> > > > > I don't think we ever had caps for "things are
>> working now,
>> > > > as they are
>> > > > > supposed to". i915 wasn't properly synchronizing
>> on foreign
>> > > > fences for a
>> > > > > long time, yet we didn't gain a cap for "cross
>> device sync
>> > > > works now".
>> > > > >
>> > > > > If your distro use-case relies on those things
>> working it's
>> > > > probably
>> > > > > best to just backport the relevant fixes.
>> > > >
>> > > > The even better solution for this is to push the
>> backports
>> > > > through
>> > > > upstream -stable kernels. This stuff here is simple
>> enough
>> > > > that we can
>> > > > do it. Same could have been done for the fairly minimal
>> > > > fencing fixes
>> > > > for i915 (at least some of them, the ones in the
>> page-flip).
>> > > >
>> > > > Otherwise we'll end up with tons IM_NOT_BUGGY and
>> > > > IM_SLIGHTLY_LESS_BUGGY and
>> > > > IM_NOT_BUGGY_EXCEPT_THIS_BOTCHED_BACKPORT
>> > > > flags where no one at all knows what they mean,
>> usage between
>> > > > different drivers and different userspace is entirely
>> > > > inconsistent and
>> > > > they just all add to the confusion. They're just
>> bugs, lets
>> > > > treat them
>> > > > like that.
>> > > >
>> > > >
>> > > > It's not *quite* DRM_CAP_PRIME_SCANOUT_NOT_BUGGY - while the
>> relevant
>> > > > hardware allegedly supports it, nouveau/radeon/amdgpu don't
>> do scanout
>> > > > of GTT, so the lack of this cap indicates that there's no
>> point in
>> > > > trying to call addfb2.
>> > > >
>> > > >
>> > > > But calling addfb2 and it failing is not expensive, so this
>> is rather
>> > > > niche.
>> > > >
>> > > >
>> > > > In practice I can just restrict attempting to scanout of
>> imported
>> > > > buffers to i915, as that's the only driver that it'll work
>> on. By the
>> > > > time nouveau/radeon/amdgpu get patches to scanout of GTT the
>> fixes
>> > > > should be old enough that I don't need to care about unfixed
>> kernels.
>> > > >
>> > > So given that most discreet hardware won't ever be able to
>> scanout from
>> > > GTT (latency and iso requirements will be hard to meet), can't
>> we just
>> > > fix the case of the broken prime sharing when migrating to VRAM?
>>
>>
>> At least some nouveau and AMD devs seem to think that their hardware
>> is capable of doing it. Shrug.
> 
> Wow, wait a second. Recent AMD GPU can scanout from system memory,
> that's true.

Even discrete GPUs, or only APUs?


> But you need to met quite a bunch of special allocation requirements to
> do this.
> 
> When we are talking about sharing between AMD GPUs, (e.g. both exporter
> and importer are AMD hardware) than that might work.
> 
> But I think it's unrealistic that an imported BO (created by an external
> driver stack) will ever meet those requirements.

Indeed. Also, none of the GPUs supported by the radeon driver support this.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: panels: Add MAINTAINERS entry for LVS panel driver

[Laurent Pinchart]

Hi Thierry,

On Monday 10 Apr 2017 09:17:59 Thierry Reding wrote:
> On Sun, Apr 09, 2017 at 01:31:40PM +0100, Emil Velikov wrote:
> > Hi Thierry,
> > 
> > I don't mean to stir up anything, just voicing "my 2c" as they say.
> > 
> > On 7 April 2017 at 18:33, Thierry Reding  wrote:
> > > Ever since the simple-panel binding was introduced, which is now about
> > > 3 1/2 years ago,
> > 
> > Do you have a link to these discussions? Your blog article does not
> > have any links and I only found the "Runtime Interpreted Power
> > Sequences" thread.
> > That in itself does not cover the pros/cons of storing HW information*
> > within DT.
> 
> There's some discussion here:
> 
>   
> https://lists.freedesktop.org/archives/dri-devel/2013-November/049509.html
> 
> which continues here:
> 
>   
> https://lists.freedesktop.org/archives/dri-devel/2013-December/050082.html
> 
> There are a couple of earlier threads, though, that discuss similar
> issues. This one seems to be the earliest I can find that is publicly
> archived:
> 
>   http://www.spinics.net/lists/devicetree/msg08497.html
> 
> Going over all these threads again wasn't a very pleasant experience. I
> realize how much time I already spent discussing these, and I don't have
> any desire to repeat that discussion.
> 
> We've had these differences ever since the very beginning. So we're now
> again going in circles.
> 
> The main concern back at the time was that having to specify timings in
> the driver would result in a complete mess because we have zillions of
> panels that we need to support. That's turned out to be a complete non-
> issue. We've got something on the order of 50 or 60 drivers supported in
> the simple-panel driver, and for everything that's more complicated we
> have a handful of separate drivers, all fairly simple as well.
> 
> So while I understand why people want to put all this information into
> DT, we've repeatedly discussed the disadvantages that this would have.
> And while we were never able to get everyone to agree, the current
> solution has had enough agreement that we merged it. And it turned out
> to be good enough. There's nothing in panel-lvds that I can see that
> fundamentally changes this.
> 
> > Personally, the idea of having hardware information* in DT does not
> > sound all that bad. The simple panel driver(s) can use those
> > properties and any panels that require anything more complex will
> > still need their own driver.
> 
> Again, the point is that you're going to have to modify the driver in
> any case, because you need to support the new compatible string. Without
> that compatible string you have zero information about the panel, and
> matching on a generic one isn't going to give you a working panel.

It will *if* the panel doesn't need any device-specific handling. In all other 
cases I agree with you, panel-specific code will be needed in the kernel (to 
handle power sequences for instance).

> So if you're already going to have to support a panel in a driver, why not
> go all the way and fully describe its capabilities and properties? We do it
> for all other devices. Panels are not at all special.

That we agree on, panels are not special. They're not the only devices that 
store in DT information that could be hardcoded in the driver based on the 
compatible string. We have many devices whose compatible string contains the 
SoC version. Driver could then hardcode interrupts or clocks without any need 
to specific them in DT. We don't do that as it would be more complex to 
handle.

Regarding timings, I've long hesitated (albeit I confess I was more on the 
side of specifying them in DT) until Rob Herring convinced me with the generic 
rule that adding information in DT that are generally exposed by devices 
themselves makes sense. Displays traditionally expose video mode information 
through EDID, which is effectively device firmware. When a panel is integrated 
in a system, and the system designer decides to save money by removing the 
EDID I2C EEPROM, moving that piece of device firmware data to system firmware 
makes sense to me.

I certainly won't try to revive the power sequence discussions, I don't 
believe it belongs to DT.

> > For better or for worse, there's already a handful of drivers and
> > bindings that rely on/provide these. Using that information
> > consistently across the board, would be of a benefit, IMHO.
> 
> Would you mind pointing out which ones these are? I'm aware of only a
> couple that seemed to have sneeked in because people were trying to
> side-step adding drm/panel support for their boards, so I don't think
> that qualifies as a reason to rethink how drm/panel works.

-- 
Regards,

Laurent Pinchart

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

[PATCH libdrm v3 2/2] etnaviv: add fence fd support

[Philipp Zabel]

Add etna_cmd_stream_flush2 with in-fence fd and out-fence fd support for
explicit fencing.

v3: added etna_cmd_stream_flush2 to etnaviv/etnaviv-symbol-check

v2: renamed etna_cmd_stream_flush_explicit to etna_cmd_stream_flush2

Signed-off-by: Philipp Zabel 
Reviewed-by: Eric Engestrom 
Reviewed-by: Christian Gmeiner 
---
 etnaviv/etnaviv-symbol-check |  1 +
 etnaviv/etnaviv_cmd_stream.c | 33 +
 etnaviv/etnaviv_drmif.h  |  2 ++
 3 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/etnaviv/etnaviv-symbol-check b/etnaviv/etnaviv-symbol-check
index 22afd168..0e2030e4 100755
--- a/etnaviv/etnaviv-symbol-check
+++ b/etnaviv/etnaviv-symbol-check
@@ -39,6 +39,7 @@ etna_cmd_stream_new
 etna_cmd_stream_del
 etna_cmd_stream_timestamp
 etna_cmd_stream_flush
+etna_cmd_stream_flush2
 etna_cmd_stream_finish
 etna_cmd_stream_reloc
 EOF
diff --git a/etnaviv/etnaviv_cmd_stream.c b/etnaviv/etnaviv_cmd_stream.c
index 9ce3f363..3c7b0ed6 100644
--- a/etnaviv/etnaviv_cmd_stream.c
+++ b/etnaviv/etnaviv_cmd_stream.c
@@ -177,7 +177,8 @@ static uint32_t bo2idx(struct etna_cmd_stream *stream, 
struct etna_bo *bo,
return idx;
 }
 
-static void flush(struct etna_cmd_stream *stream)
+static void flush(struct etna_cmd_stream *stream, int in_fence_fd,
+ int *out_fence_fd)
 {
struct etna_cmd_stream_priv *priv = etna_cmd_stream_priv(stream);
int ret, id = priv->pipe->id;
@@ -194,8 +195,22 @@ static void flush(struct etna_cmd_stream *stream)
.stream_size = stream->offset * 4, /* in bytes */
};
 
+   if (in_fence_fd != -1) {
+   req.flags |= ETNA_SUBMIT_FENCE_FD_IN | ETNA_SUBMIT_NO_IMPLICIT;
+   req.fence_fd = in_fence_fd;
+   }
+
+   if (out_fence_fd)
+   req.flags |= ETNA_SUBMIT_FENCE_FD_OUT;
+
+   /*
+* Pass the complete submit structure only if flags are set. Otherwise,
+* only pass the fields up to, but not including the flags field for
+* backwards compatiblity with older kernels.
+*/
ret = drmCommandWriteRead(gpu->dev->fd, DRM_ETNAVIV_GEM_SUBMIT,
-   &req, sizeof(req));
+   &req, req.flags ? sizeof(req) :
+   offsetof(struct drm_etnaviv_gem_submit, flags));
 
if (ret)
ERROR_MSG("submit failed: %d (%s)", ret, strerror(errno));
@@ -208,11 +223,21 @@ static void flush(struct etna_cmd_stream *stream)
bo->current_stream = NULL;
etna_bo_del(bo);
}
+
+   if (out_fence_fd)
+   *out_fence_fd = req.fence_fd;
 }
 
 void etna_cmd_stream_flush(struct etna_cmd_stream *stream)
 {
-   flush(stream);
+   flush(stream, -1, NULL);
+   reset_buffer(stream);
+}
+
+void etna_cmd_stream_flush2(struct etna_cmd_stream *stream, int in_fence_fd,
+   int *out_fence_fd)
+{
+   flush(stream, in_fence_fd, out_fence_fd);
reset_buffer(stream);
 }
 
@@ -220,7 +245,7 @@ void etna_cmd_stream_finish(struct etna_cmd_stream *stream)
 {
struct etna_cmd_stream_priv *priv = etna_cmd_stream_priv(stream);
 
-   flush(stream);
+   flush(stream, -1, NULL);
etna_pipe_wait(priv->pipe, priv->last_timestamp, 5000);
reset_buffer(stream);
 }
diff --git a/etnaviv/etnaviv_drmif.h b/etnaviv/etnaviv_drmif.h
index 8119baad..87704acd 100644
--- a/etnaviv/etnaviv_drmif.h
+++ b/etnaviv/etnaviv_drmif.h
@@ -142,6 +142,8 @@ struct etna_cmd_stream *etna_cmd_stream_new(struct 
etna_pipe *pipe, uint32_t siz
 void etna_cmd_stream_del(struct etna_cmd_stream *stream);
 uint32_t etna_cmd_stream_timestamp(struct etna_cmd_stream *stream);
 void etna_cmd_stream_flush(struct etna_cmd_stream *stream);
+void etna_cmd_stream_flush2(struct etna_cmd_stream *stream, int in_fence_fd,
+   int *out_fence_fd);
 void etna_cmd_stream_finish(struct etna_cmd_stream *stream);
 
 static inline uint32_t etna_cmd_stream_avail(struct etna_cmd_stream *stream)
-- 
2.11.0

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

[PATCH libdrm v3 1/2] etnaviv: sync uapi header

[Philipp Zabel]

Import the etnaviv header changes from kernel commits 9ad59fea162c
("drm/etnaviv: submit support for in-fences") and 78ec187f64fa
("drm/etnaviv: submit support for out-fences") for fence fd support.

The drm_etnaviv_gem_submit structure was extended to include a flags
field, new flags for in-fence and out-fence fds and an input/output
fence fd field.

This is one-way backwards compatible because old userspace code passing
a short structure not including the flags field to new kernels will
cause the remaining fields to be zero-filled. New userspace code must
make sure to only pass the short structure to old kernels, though.

Not generated using make headers_install, since the drm/etnaviv_drm.h
uapi header is not installed yet by the kernel.
Copied from the airlied/drm-next commit 78ec187f64fa.

v2: improved commit message

Signed-off-by: Philipp Zabel 
Reviewed-by: Christian Gmeiner 
---
 etnaviv/etnaviv_drm.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/etnaviv/etnaviv_drm.h b/etnaviv/etnaviv_drm.h
index 2584c1cc..76f6f78a 100644
--- a/etnaviv/etnaviv_drm.h
+++ b/etnaviv/etnaviv_drm.h
@@ -154,6 +154,12 @@ struct drm_etnaviv_gem_submit_bo {
  * one or more cmdstream buffers.  This allows for conditional execution
  * (context-restore), and IB buffers needed for per tile/bin draw cmds.
  */
+#define ETNA_SUBMIT_NO_IMPLICIT 0x0001
+#define ETNA_SUBMIT_FENCE_FD_IN 0x0002
+#define ETNA_SUBMIT_FENCE_FD_OUT0x0004
+#define ETNA_SUBMIT_FLAGS  (ETNA_SUBMIT_NO_IMPLICIT | \
+ETNA_SUBMIT_FENCE_FD_IN | \
+ETNA_SUBMIT_FENCE_FD_OUT)
 #define ETNA_PIPE_3D  0x00
 #define ETNA_PIPE_2D  0x01
 #define ETNA_PIPE_VG  0x02
@@ -167,6 +173,8 @@ struct drm_etnaviv_gem_submit {
__u64 bos;/* in, ptr to array of submit_bo's */
__u64 relocs; /* in, ptr to array of submit_reloc's */
__u64 stream; /* in, ptr to cmdstream */
+   __u32 flags;  /* in, mask of ETNA_SUBMIT_x */
+   __s32 fence_fd;   /* in/out, fence fd (see ETNA_SUBMIT_FENCE_FD_x) 
*/
 };
 
 /* The normal way to synchronize with the GPU is just to CPU_PREP on
-- 
2.11.0

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

Re: [PATCH 1/2] drm: Add DRM_CAP_PRIME_SCANOUT.

[Christian König]

Am 10.04.2017 um 10:52 schrieb Michel Dänzer:

On 05/04/17 08:21 PM, Christian König wrote:

Am 05.04.2017 um 13:13 schrieb Christopher James Halse Rogers:

On Wed, Apr 5, 2017 at 8:14 PM Lucas Stach mailto:l.st...@pengutronix.de>> wrote:

 Am Mittwoch, den 05.04.2017, 11:59 +0200 schrieb Daniel Vetter:
 > On Wed, Apr 05, 2017 at 10:15:44AM +0200, Lucas Stach wrote:
 > > Am Mittwoch, den 05.04.2017, 00:20 + schrieb Christopher
 James Halse
 > > Rogers:
 > > >
 > > >
 > > > On Tue, Apr 4, 2017 at 9:53 PM Daniel Vetter
 mailto:dan...@ffwll.ch>> wrote:
 > > >
 > > > On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach
 > > > mailto:l.st...@pengutronix.de>> wrote:
 > > > >> If I could guarantee that I'd only ever run on
 > > > 4.13-or-later kernels
 > > > >> (I think that's when the previous patches will
 land?), then
 > > > this would
 > > > >> indeed be mostly unnecessary. It would save me a
 bunch of
 > > > addfb calls
 > > > >> that would predictably fail, but they're cheap.
 > > > >
 > > > > I don't think we ever had caps for "things are
 working now,
 > > > as they are
 > > > > supposed to". i915 wasn't properly synchronizing
 on foreign
 > > > fences for a
 > > > > long time, yet we didn't gain a cap for "cross
 device sync
 > > > works now".
 > > > >
 > > > > If your distro use-case relies on those things
 working it's
 > > > probably
 > > > > best to just backport the relevant fixes.
 > > >
 > > > The even better solution for this is to push the
 backports
 > > > through
 > > > upstream -stable kernels. This stuff here is simple
 enough
 > > > that we can
 > > > do it. Same could have been done for the fairly minimal
 > > > fencing fixes
 > > > for i915 (at least some of them, the ones in the
 page-flip).
 > > >
 > > > Otherwise we'll end up with tons IM_NOT_BUGGY and
 > > > IM_SLIGHTLY_LESS_BUGGY and
 > > > IM_NOT_BUGGY_EXCEPT_THIS_BOTCHED_BACKPORT
 > > > flags where no one at all knows what they mean,
 usage between
 > > > different drivers and different userspace is entirely
 > > > inconsistent and
 > > > they just all add to the confusion. They're just
 bugs, lets
 > > > treat them
 > > > like that.
 > > >
 > > >
 > > > It's not *quite* DRM_CAP_PRIME_SCANOUT_NOT_BUGGY - while the
 relevant
 > > > hardware allegedly supports it, nouveau/radeon/amdgpu don't
 do scanout
 > > > of GTT, so the lack of this cap indicates that there's no
 point in
 > > > trying to call addfb2.
 > > >
 > > >
 > > > But calling addfb2 and it failing is not expensive, so this
 is rather
 > > > niche.
 > > >
 > > >
 > > > In practice I can just restrict attempting to scanout of
 imported
 > > > buffers to i915, as that's the only driver that it'll work
 on. By the
 > > > time nouveau/radeon/amdgpu get patches to scanout of GTT the
 fixes
 > > > should be old enough that I don't need to care about unfixed
 kernels.
 > > >
 > > So given that most discreet hardware won't ever be able to
 scanout from
 > > GTT (latency and iso requirements will be hard to meet), can't
 we just
 > > fix the case of the broken prime sharing when migrating to VRAM?


At least some nouveau and AMD devs seem to think that their hardware
is capable of doing it. Shrug.

Wow, wait a second. Recent AMD GPU can scanout from system memory,
that's true.

Even discrete GPUs, or only APUs?


Good question. The crux is that you need to match certain bandwith and 
latency limitations or otherwise you get a flickering picture.


If I understood the documentation correctly that should even work with 
dGPUs in theory, but nobody is testing/validating this.


Long story short I wouldn't try it without feedback from the hardware/DC 
guys. They are the designated experts for this.


Regards,
Christian.





But you need to met quite a bunch of special allocation requirements to
do this.

When we are talking about sharing between AMD GPUs, (e.g. both exporter
and importer are AMD hardware) than that might work.

But I think it's unrealistic that an imported BO (created by an external
driver stack) will ever meet those requirements.

Indeed. Also, none of the GPUs supported by the radeon driver support this.




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

[Bug 100593] corruption in total war warhammer when using mesa 17.1 - git

[bugzilla-daemon]

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

--- Comment #6 from tarp...@gmx.de ---
(In reply to Gregor Münch from comment #5)
> Some people reported this should actually got fixed by
> 0fb5a505fac7be0a1831b565019f0f04369e56bd, but looks like it isnt for all. 
> https://bugs.freedesktop.org/show_bug.cgi?id=100531
> 
> Will test myself in some days...

The "blue shadows" as shown in this screenshot
https://bugs.freedesktop.org/show_bug.cgi?id=100531#c2 have been fixed for me
with the latest update in the padoka ppa.

What remains are the "fancy coloured textures" on my R9 290 (Hawaii, CGN 1.1)
which were also reported on R9 270 (Curacao/Pitcairn, CGN 1.0) in unigine
(valley/heaven) https://bugs.freedesktop.org/show_bug.cgi?id=100593#c4

-- 
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: [RFC 1/7] drm/atomic: initial support for asynchronous plane update

[Gustavo Padovan]

Hi Emil,

Thank you for your review!

2017-04-10 Emil Velikov :

> Hi Gustavo,
> 
> Mostly some documentation suggestions below. Hope that I've not lost
> the plot and they seem ok :-)
> 
> On 10 April 2017 at 01:24, Gustavo Padovan  wrote:
> 
> > +static bool drm_atomic_async_check(struct drm_atomic_state *state)
> > +{
> 
> /* FIXME: we support single plane updates for now */
> > +   if (!plane || n_planes != 1)
> > +   return false;
> > +
> 
> > +   if (!funcs->atomic_async_update)
> > +   return false;
> 
> 
> > +void drm_atomic_helper_async_commit(struct drm_device *dev,
> > +   struct drm_atomic_state *state)
> > +{
> > +   struct drm_plane *plane;
> > +   struct drm_plane_state *plane_state;
> > +   const struct drm_plane_helper_funcs *funcs;
> > +   int i;
> > +
> > +   for_each_new_plane_in_state(state, plane, plane_state, i) {
> > +   funcs = plane->helper_private;
> > +
> > +   plane->state->src_x = plane_state->src_x;
> > +   plane->state->src_y = plane_state->src_y;
> > +   plane->state->crtc_x = plane_state->crtc_x;
> > +   plane->state->crtc_y = plane_state->crtc_y;
> > +
> > +   if (funcs && funcs->atomic_async_update)
> > +   funcs->atomic_async_update(plane, plane_state);
> 
> This looks a bit strange. We don't want to change any state if the
> hook is missing right?
> Actually the if will always be true, since we've already validated
> that in drm_atomic_async_check().
> 
> Should we unconditionally call funcs->atomic_async_update()?

That would be much better. I'll do that.

> 
> 
> > @@ -172,6 +174,8 @@ struct drm_atomic_state {
> > struct drm_device *dev;
> > bool allow_modeset : 1;
> > bool legacy_cursor_update : 1;
> > +   bool legacy_set_config : 1;
> Seems unused in this patch. Introduce at a later stage?

Hmm, rebase garbage. :(  Sorry about that.

> 
> 
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -1048,6 +1048,53 @@ struct drm_plane_helper_funcs {
> >  */
> > void (*atomic_disable)(struct drm_plane *plane,
> >struct drm_plane_state *old_state);
> > +
> > +   /**
> > +* @atomic_async_check:
> > +*
> > +* Drivers should use this function check if the plane state
> s/use this function check/set this function pointer/
> 
> > +* can be updated in a async fashion.
> > +*
> > +* This hook is called by drm_atomic_async_check() in the process
> > +* to figure out if an given update can be committed asynchronously,
> s/in the process to figure out if an/to establish if a/ s/,/./
> 
> > +* that is, if it can jump ahead the state currently queued for
> > +* update.
> > +*
> > +* Check drm_atomic_async_check() to see what is already there
> > +* to discover potential async updates.
> Remove these two sentences? They don't seem to bring much.
> 
> > +*
> > +* RETURNS:
> > +*
> > +* Return 0 on success and -EINVAL if the update can't be async.
> s/if the update can't be async/on error/

I don't think that is an error, it just can't be async so the regular 
atomic sync commit will be performed. For async page flip this would be
a show stopper error, but we are not there yet.

> 
> > +* Error return doesn't mean that the update can't be applied,
> > +* it just mean that it can't be an async one.
> > +*
> Any error returned indicates that the update can not be applied in
> asynchronous manner.
> Side-note: suggest who/how to retry synchronously ?

Retry synchronously is the default fallback. Actually it is the
opposite, async is a special shortcut of sync.

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

Re: [PATCH 2/5] i915: flush gem obj freeing workqueues to add accuracy to the i915 shrinker

[Chris Wilson]

On Fri, Apr 07, 2017 at 06:48:58PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 07, 2017 at 04:30:11PM +0100, Chris Wilson wrote:
> > Not getting hangs is a good sign, but lockdep doesn't like it:
> > 
> > [  460.684901] WARNING: CPU: 1 PID: 172 at kernel/workqueue.c:2418 
> > check_flush_dependency+0x92/0x130
> > [  460.684924] workqueue: PF_MEMALLOC task 172(kworker/1:1H) is flushing 
> > !WQ_MEM_RECLAIM events:__i915_gem_free_work [i915]
> > 
> > If I allocated the workqueue with WQ_MEM_RELCAIM, it complains bitterly
> > as well.
> 
> So in PF_MEMALLOC context we can't flush a workqueue with
> !WQ_MEM_RECLAIM.
> 
>   system_wq = alloc_workqueue("events", 0, 0);
> 
> My point is synchronize_rcu_expedited will still push its work in
> the same system_wq workqueue...
> 
>   /* Marshall arguments & schedule the expedited grace period. */
>   rew.rew_func = func;
>   rew.rew_rsp = rsp;
>   rew.rew_s = s;
>   INIT_WORK_ONSTACK(&rew.rew_work, wait_rcu_exp_gp);
>   schedule_work(&rew.rew_work);
> 
> It's also using schedule_work, so either the above is a false
> positive, or we've still a problem with synchronize_rcu_expedited,
> just a reproducible issue anymore after we stop running it under the
> struct_mutex.

We still do have a problem with using synchronize_rcu_expedited() from
the shrinker as we maybe under someone else's mutex is that involved in
its own RCU dance.

> Even synchronize_sched will wait on the system_wq if
> synchronize_rcu_expedited has been issued in parallel by some other
> code, it's just there's no check for it because it's not invoking
> flush_work to wait.

Right.
 
> The deadlock happens if we flush_work() while holding any lock that
> may be taken by any of the workqueues that could be queued there. i915
> makes sure to flush_work only if the struct_mutex was released (not
> my initial version) but we're not checking if any of the other
> system_wq workqueues could possibly taking a lock that may have been
> hold during the allocation that invoked reclaim, I suppose that is the
> problem left, but I don't see how flush_work is special about it,
> synchronize_rcu_expedited would still have the same issue no? (despite
> no lockdep warning)
> 
> I suspect this means synchronize_rcu_expedited() is not usable in
> reclaim context and lockdep should warn if PF_MEMALLOC is set when
> synchronize_rcu_expedited/synchronize_sched/synchronize_rcu are
> called.

Yes.

> Probably to fix this we should create a private workqueue for both RCU
> and i915 and stop sharing the system_wq with the rest of the system
> (and of course set WQ_MEM_RECLAIM in both workqueues). This makes sure
> when we call synchronize_rcu_expedited; flush_work from the shrinker,
> we won't risk waiting on other random work that may be taking locks
> that are hold by the code that invoked reclaim during an allocation.

We simply do not need to do our own synchronize_rcu* -- it's only used
to flush our slab frees on the off chance that (a) we have any and (b)
we do manage to free a whole slab. It is not the bulk of the memory that
we return to the system from the shrinker.

In the other thread, I stated that we should simply remove it. The
kswapd reclaim path should try to reclaim RCU slabs (by doing a
synhronize_sched or equivalent).

> The macro bug of waiting on system_wq 100% of the time while always
> holding the struct_mutex is gone, but we need to perfect this further
> and stop using the system_wq for RCU and i915 shrinker work.

Agreed. My preference is to simply not do it and leave the dangling RCU
to the core reclaim paths.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Andrzej Hajda]

On 07.04.2017 18:39, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1-107).
>
> This patch adds a bool input variable, which indicates if the connected
> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> HDMI 2.0 VIC to a HDMI 1.4 sink.
>
> This patch touches all drm drivers, who are callers of this function
> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
> no change in current behavior, is_hdmi2 is kept as false.
>
> In case of I915 driver, this patch checks the connector->display_info
> to check if the connected display is HDMI 2.0.
>
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Andrzej Hajda 
> Cc: Alex Deucher 
> Cc: Daniel Vetter 
>
> PS: This patch touches a few lines in few files, which were
> already above 80 char, so checkpatch gives 80 char warning again.
> - gpu/drm/omapdrm/omap_encoder.c
> - gpu/drm/i915/intel_sdvo.c
>
> Signed-off-by: Shashank Sharma 

Finally I have chances to look at the specs and I am not sure if this
solution fully reflects the specs and is scalable. According to specs
VIC set to 0 in AVIF means "Video Format not documented in CTA-861", ie
it is described by vendor specific data block and vendor specific
infoframe, maybe something else(???). I suppose ideally during EDID read
there should be recorded info for every mode if it was defined by vendor
extension, or not. This info could be later used by drivers to configure
AVIF and VSIF accordingly.

Anyway as a short-term initial solution it could work.
So:
Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej

> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
>  drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
>  drivers/gpu/drm/bridge/sii902x.c  |  2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
>  drivers/gpu/drm/drm_edid.c| 12 +++-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
>  drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
>  drivers/gpu/drm/i915/intel_hdmi.c |  5 -
>  drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
>  drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
>  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
>  drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
>  drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
>  drivers/gpu/drm/tegra/hdmi.c  |  2 +-
>  drivers/gpu/drm/tegra/sor.c   |  2 +-
>  drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
>  drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
>  include/drm/drm_edid.h|  3 ++-
>  21 files changed, 38 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index daf003d..5dc3e95 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -1877,7 +1877,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
> *encoder,
>   dce_v10_0_audio_write_sad_regs(encoder);
>   dce_v10_0_audio_write_latency_fields(encoder, mode);
>  
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
>   if (err < 0) {
>   DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
>   return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 3a72967..b70f077 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -1861,7 +1861,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
> *encoder,
>   dce_v11_0_audio_write_sad_regs(encoder);
>   dce_v11_0_audio_write_latency_fields(encoder, mode);
>  
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
>   if (err < 0) {
>   DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
>   return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index 6943f26..bcf9c75 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -1760,7 +1760,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
> *encoder,
>   dce_v8_0_audio_write_sad_regs(encoder);
>   dce_v8_0_audio_write_latency_fields(encoder, mode);
>  
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
>   if (err < 0) {
>   DRM_ERROR("failed to setup AVI inf

Re: [PATCH] drm: panels: Add MAINTAINERS entry for LVS panel driver

[Lucas Stach]

Am Montag, den 10.04.2017, 09:17 +0200 schrieb Thierry Reding:
> On Sun, Apr 09, 2017 at 01:31:40PM +0100, Emil Velikov wrote:
> > Hi Thierry,
> > 
> > I don't mean to stir up anything, just voicing "my 2c" as they say.

I normally try to keep away from this "political" discussions,
especially with regard to the panel stuff, but as this seems to pop up
again and again, I feel the need to speak up.

> > On 7 April 2017 at 18:33, Thierry Reding  wrote:
> > 
> > > Ever since the simple-panel binding was introduced, which is now about
> > > 3 1/2 years ago,
> > 
> > Do you have a link to these discussions? Your blog article does not
> > have any links and I only found the "Runtime Interpreted Power
> > Sequences" thread.
> > That in itself does not cover the pros/cons of storing HW information*
> > within DT.
> 
> There's some discussion here:
> 
>   
> https://lists.freedesktop.org/archives/dri-devel/2013-November/049509.html
> 
> which continues here:
> 
>   
> https://lists.freedesktop.org/archives/dri-devel/2013-December/050082.html
> 
> There are a couple of earlier threads, though, that discuss similar
> issues. This one seems to be the earliest I can find that is publicly
> archived:
> 
>   http://www.spinics.net/lists/devicetree/msg08497.html
> 
> Going over all these threads again wasn't a very pleasant experience. I
> realize how much time I already spent discussing these, and I don't have
> any desire to repeat that discussion.
> 
> We've had these differences ever since the very beginning. So we're now
> again going in circles.
> 
> The main concern back at the time was that having to specify timings in
> the driver would result in a complete mess because we have zillions of
> panels that we need to support. That's turned out to be a complete non-
> issue. We've got something on the order of 50 or 60 drivers supported in
> the simple-panel driver, and for everything that's more complicated we
> have a handful of separate drivers, all fairly simple as well.
> 
> So while I understand why people want to put all this information into
> DT, we've repeatedly discussed the disadvantages that this would have.
> And while we were never able to get everyone to agree, the current
> solution has had enough agreement that we merged it. And it turned out
> to be good enough. There's nothing in panel-lvds that I can see that
> fundamentally changes this.

I was personally opposed to the idea of specifying panels only by
compatible and carrying around a "modedb" in the form of the
simple-panel driver. Since then I've come to appreciate the flexibility
that having a real driver for a panel provides.

A panel is _much_ more than a simple mode. For LVDS panels it's in many
cases a complete range of timings that will work with the panel, it's
the enable sequencing with regulators and GPIOs, it's the size of the
panel, so we get proper DPI information, it's a bus format describing
all the oddities that vendors choose to implement when designing the
physical interface. It provides proper sequencing of backlight
enable/disable.

I very much support Thierrys view, that all this should be encoded by
the compatible. This allows us to add required properties to the panel
if needed. It certainly saved us a lot of backward compat issues in
imx-drm, that we could just add all the required information to the
panel, so everything is consistent within one kernel version.

> > Personally, the idea of having hardware information* in DT does not
> > sound all that bad. The simple panel driver(s) can use those
> > properties and any panels that require anything more complex will
> > still need their own driver.

Although some people seems to feel different on that matter, but DT is
supposed to be ABI. Newer kernels _must_ work on older DTs. Which means
it needs to encode _all_ information on the panel.

Personally I don't trust people, who are just enabling their one board
to go through and validate that all the panel information is correct. As
soon as a picture shows up they are going to ship the DT.

With having to go through a panel driver, there is at least some basic
review of the panel properties.

Also speaking from experience with a board with different display
configurations, where only the bootloader knows the specific attached
panel, it's very convenient to have the bootloader only patch in the
correct compatible, instead of all the panel properties. If any of those
properties turns out to be wrong, I can fix it with a simple kernel
update, instead of having to update the bootloader.

> Again, the point is that you're going to have to modify the driver in
> any case, because you need to support the new compatible string. Without
> that compatible string you have zero information about the panel, and
> matching on a generic one isn't going to give you a working panel. So if
> you're already going to have to support a panel in a driver, why not go
> all the way and fully describe its capabilities and properties? 

[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

[bugzilla-daemon]

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

--- Comment #12 from Julien Isorce  ---
Thx for the answers and suggestions. In order to make sure I am still tracking
the same hard lockup, will any failure to load the gpu microcode will lead to a
total freeze of the machine ?

Currently in the setup where I can get some logs it can fail in 2 ways:

For both it starts with: "ring 0 stalled" is detected.

1: kworker triggers the gpu soft reset.

[drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for more than 5secs
aborting.
[drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing C483
(len 254, WS 0, PS 4) @ 0xC4AD
[drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing BC59
(len 74, WS 0, PS 8) @ 0xBC8E
si_mc_program::radeon_mc_wait_for_idle, the one after WREG32(vram.start) and
before 
evergreen_mc_resume. Can it freeze on a call to RREG32(SRBM_STATUS) & 0x1F00 ?

2: the gl app triggers the gpu soft reset.

The first failure is then evergreen_mc_stop::radeon_mc_wait_for_idle which
reached the timeout and then same errors as 1:
But the freeze happens a bit later in the radeon_gpu_reset sequence, in
atombios_crtc_dpms in one of its atombios_X(crtc, ATOM_Y) calls.

So my question above, will any single problem during the gpu soft reset lead to
a machine freeze ? If yes then I am probably tracking now a different freeze
that the one I reported initially.

Also in kernel's drm_drv.c::drm_err I tried to add a call to sys_sync();
(#include ) to make sure all errors are written on disk so
that I can read them after a reboot (Instead of having null characters ^@). But
I got an undefined reference. How could I add dependcy on fs/sync.c ? I have
not search long but at first glance tty driver calls it and there is nothing
special in the Makefile.
(As an alternative I am running a while true; sleep 0.5; sync; done but it does
not work all the time)

Thx!

-- 
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 v4 2/2] crypto: hw_random - Add new Exynos RNG driver

[Bartlomiej Zolnierkiewicz]

Hi,

On Saturday, April 08, 2017 03:32:45 PM Krzysztof Kozlowski wrote:
> Replace existing hw_ranndom/exynos-rng driver with a new, reworked one.
> This is a driver for pseudo random number generator block which on
> Exynos4 chipsets must be seeded with some value.  On newer Exynos5420
> chipsets it might seed itself from true random number generator block
> but this is not implemented yet.
> 
> New driver is a complete rework to use the crypto ALGAPI instead of
> hw_random API.  Rationale for the change:
> 1. hw_random interface is for true RNG devices.
> 2. The old driver was seeding itself with jiffies which is not a
>reliable source for randomness.
> 3. Device generates five random 32-bit numbers in each pass but old
>driver was returning only one 32-bit number thus its performance was
>reduced.
> 
> Compatibility with DeviceTree bindings is preserved.
> 
> New driver does not use runtime power management but manually enables
> and disables the clock when needed.  This is preferred approach because
> using runtime PM just to toggle clock is huge overhead.
> 
> Another difference is reseeding itself with generated random data
> periodically and during resuming from system suspend (previously driver
> was re-seeding itself again with jiffies).
> 
> Signed-off-by: Krzysztof Kozlowski 
> Reviewed-by: Stephan Müller 
> Reviewed-by: PrasannaKumar Muralidharan 

Reviewed-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

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

[RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Gerd Hoffmann]

Ok, this is really a kickstart for a discussion.  While working on
graphics support for virtual machines on ppc64 (which exists in both
little and big endian variants) I've figured the comments in the header
file don't match reality.  They are not considered little endian (as
suggested by the comments) but in practice are used as native endian.

So, go update the comments.

This patch switches all 32bpp / 8 bpc formats over to native endian.
Those used/supported by ppc64 virtual machines (virtio-gpu/bochs-drm
drivers).

Given that DRM_FORMAT_BIG_ENDIAN isn't used anywhere in the codebase
I suspect this problem applies to more formats.  When looking at
drm_mode_legacy_fb_format it seems *all* RGB formats are actually
native endian not little endian.

Dunno where we stand in terms of YCbCr.

Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Gerd Hoffmann 
---
 include/uapi/drm/drm_fourcc.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 995c8f9..a7fc81d 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -85,15 +85,15 @@ extern "C" {
 #define DRM_FORMAT_BGR888  fourcc_code('B', 'G', '2', '4') /* [23:0] B:G:R 
little endian */
 
 /* 32 bpp RGB */
-#define DRM_FORMAT_XRGBfourcc_code('X', 'R', '2', '4') /* [31:0] 
x:R:G:B 8:8:8:8 little endian */
-#define DRM_FORMAT_XBGRfourcc_code('X', 'B', '2', '4') /* [31:0] 
x:B:G:R 8:8:8:8 little endian */
-#define DRM_FORMAT_RGBXfourcc_code('R', 'X', '2', '4') /* [31:0] 
R:G:B:x 8:8:8:8 little endian */
-#define DRM_FORMAT_BGRXfourcc_code('B', 'X', '2', '4') /* [31:0] 
B:G:R:x 8:8:8:8 little endian */
+#define DRM_FORMAT_XRGBfourcc_code('X', 'R', '2', '4') /* [31:0] 
x:R:G:B 8:8:8:8 native endian */
+#define DRM_FORMAT_XBGRfourcc_code('X', 'B', '2', '4') /* [31:0] 
x:B:G:R 8:8:8:8 native endian */
+#define DRM_FORMAT_RGBXfourcc_code('R', 'X', '2', '4') /* [31:0] 
R:G:B:x 8:8:8:8 native endian */
+#define DRM_FORMAT_BGRXfourcc_code('B', 'X', '2', '4') /* [31:0] 
B:G:R:x 8:8:8:8 native endian */
 
-#define DRM_FORMAT_ARGBfourcc_code('A', 'R', '2', '4') /* [31:0] 
A:R:G:B 8:8:8:8 little endian */
-#define DRM_FORMAT_ABGRfourcc_code('A', 'B', '2', '4') /* [31:0] 
A:B:G:R 8:8:8:8 little endian */
-#define DRM_FORMAT_RGBAfourcc_code('R', 'A', '2', '4') /* [31:0] 
R:G:B:A 8:8:8:8 little endian */
-#define DRM_FORMAT_BGRAfourcc_code('B', 'A', '2', '4') /* [31:0] 
B:G:R:A 8:8:8:8 little endian */
+#define DRM_FORMAT_ARGBfourcc_code('A', 'R', '2', '4') /* [31:0] 
A:R:G:B 8:8:8:8 native endian */
+#define DRM_FORMAT_ABGRfourcc_code('A', 'B', '2', '4') /* [31:0] 
A:B:G:R 8:8:8:8 native endian */
+#define DRM_FORMAT_RGBAfourcc_code('R', 'A', '2', '4') /* [31:0] 
R:G:B:A 8:8:8:8 native endian */
+#define DRM_FORMAT_BGRAfourcc_code('B', 'A', '2', '4') /* [31:0] 
B:G:R:A 8:8:8:8 native endian */
 
 #define DRM_FORMAT_XRGB2101010 fourcc_code('X', 'R', '3', '0') /* [31:0] 
x:R:G:B 2:10:10:10 little endian */
 #define DRM_FORMAT_XBGR2101010 fourcc_code('X', 'B', '3', '0') /* [31:0] 
x:B:G:R 2:10:10:10 little endian */
-- 
2.9.3

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

Re: [PATCH] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes, v4.

[Boris Brezillon]

Hi Maarteen,

Sorry for the late review, I was on vacation last week.

On Thu,  6 Apr 2017 20:55:20 +0200
Maarten Lankhorst  wrote:

> mode_valid() called from drm_helper_probe_single_connector_modes()
> may need to look at connector->state because what a valid mode is may
> depend on connector properties being set. For example some HDMI modes
> might be rejected when a connector property forces the connector
> into DVI mode.
> 
> Some implementations of detect() already lock all state,
> so we have to pass an acquire_ctx to them to prevent a deadlock.
> 
> This means changing the function signature of detect() slightly,
> and passing the acquire_ctx for locking multiple crtc's.
> For the callbacks, it will always be non-zero. To allow callers
> not to worry about this, drm_helper_probe_detect_ctx is added
> which might handle -EDEADLK for you.
> 
> Changes since v1:
> - Always set ctx parameter.
> Changes since v2:
> - Always take connection_mutex when probing.
> Changes since v3:
> - Remove the ctx from intel_dp_long_pulse, and add
>   WARN_ON(!connection_mutex) (danvet)
> - Update docs to clarify the locking situation. (danvet)

Maybe this is something DRM-specific, but usually we put the changelog
after the '---' to avoid having it in the final commit.

Same goes for the ", v4" suffix in the commit title, it should be
'[PATCH vX] '.

> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Boris Brezillon 
> Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_probe_helper.c   | 100 
> ---
>  drivers/gpu/drm/i915/intel_crt.c |  25 
>  drivers/gpu/drm/i915/intel_display.c |  25 
>  drivers/gpu/drm/i915/intel_dp.c  |  21 +++
>  drivers/gpu/drm/i915/intel_drv.h |   8 +--
>  drivers/gpu/drm/i915/intel_hotplug.c |   3 +-
>  drivers/gpu/drm/i915/intel_tv.c  |  21 +++
>  include/drm/drm_connector.h  |   6 ++
>  include/drm/drm_crtc_helper.h|   3 +
>  include/drm/drm_modeset_helper_vtables.h |  36 +++
>  10 files changed, 187 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index efb5e5e8ce62..1b0c14ab3fff 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -169,12 +169,73 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
>  EXPORT_SYMBOL(drm_kms_helper_poll_enable);
>  
>  static enum drm_connector_status
> -drm_connector_detect(struct drm_connector *connector, bool force)
> +drm_helper_probe_detect_ctx(struct drm_connector *connector, bool force)

The function name is misleading IMHO. AFAIU, this helper is
instantiating a new context because the caller did not provide one, so
how about renaming it drm_helper_probe_detect_no_ctx()?

>  {
> - return connector->funcs->detect ?
> - connector->funcs->detect(connector, force) :
> - connector_status_connected;
> + const struct drm_connector_helper_funcs *funcs = 
> connector->helper_private;
> + struct drm_modeset_acquire_ctx ctx;
> + int ret;
> +
> + drm_modeset_acquire_init(&ctx, 0);
> +
> +retry:
> + ret = drm_modeset_lock(&connector->dev->mode_config.connection_mutex, 
> &ctx);
> + if (!ret) {
> + if (funcs->detect_ctx)
> + ret = funcs->detect_ctx(connector, &ctx, force);
> + else if (connector->funcs->detect)
> + ret = connector->funcs->detect(connector, force);
> + else
> + ret = connector_status_connected;
> + }
> +
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff(&ctx);
> + goto retry;
> + }
> +
> + if (WARN_ON(ret < 0))
> + ret = connector_status_unknown;
> +
> + drm_modeset_drop_locks(&ctx);
> + drm_modeset_acquire_fini(&ctx);
> +
> + return ret;
> +}

[...]

>   /**
> +  * @detect_ctx:
> +  *
> +  * Check to see if anything is attached to the connector. The parameter
> +  * force is set to false whilst polling, true when checking the
> +  * connector due to a user request. force can be used by the driver to
> +  * avoid expensive, destructive operations during automated probing.
> +  *
> +  * This callback is optional, if not implemented the connector will be
> +  * considered as always being attached.
> +  *
> +  * This is the atomic version of &drm_connector_funcs.detect.
> +  *
> +  * To avoid races against concurrent connector state updates, the
> +  * helper libraries always call this with ctx set to a valid context,
> +  * and &drm_mode_config.connection_mutex will always be locked with
> +  * the ctx parameter set to this ctx. This allows taking additional
> +  * locks as required.
> +  *
> +  * RETURNS:
> +  *
> +  * &drm_connector_status indicating the connector's status,
> +  * or the error code r

[PATCH 2/2] drm/tegra: Add driver documentation

[Thierry Reding]

From: Thierry Reding 

Adds some driver documentation for Tegra. It provides a short overview
of the hardware and software architectures.

Signed-off-by: Thierry Reding 
---
 Documentation/gpu/index.rst |   1 +
 Documentation/gpu/tegra.rst | 178 
 2 files changed, 179 insertions(+)
 create mode 100644 Documentation/gpu/tegra.rst

diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index c572f092739e..feae37fa7ca3 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -12,6 +12,7 @@ Linux GPU Driver Developer's Guide
drm-uapi
i915
meson
+   tegra
tinydrm
vc4
vga-switcheroo
diff --git a/Documentation/gpu/tegra.rst b/Documentation/gpu/tegra.rst
new file mode 100644
index ..d2ed8938ca43
--- /dev/null
+++ b/Documentation/gpu/tegra.rst
@@ -0,0 +1,178 @@
+===
+ drm/tegra NVIDIA Tegra GPU and display driver
+===
+
+NVIDIA Tegra SoCs support a set of display, graphics and video functions via
+the host1x controller. host1x supplies command streams, gathered from a push
+buffer provided directly by the CPU, to its clients via channels. Software,
+or blocks amongst themselves, can use syncpoints for synchronization.
+
+Up until, but not including, Tegra124 (aka Tegra K1) the drm/tegra driver
+supports the built-in GPU, comprised of the gr2d and gr3d engines. Starting
+with Tegra124 the GPU is based on the NVIDIA desktop GPU architecture and
+supported by the drm/nouveau driver.
+
+The drm/tegra driver supports NVIDIA Tegra SoC generations since Tegra20. It
+has three parts:
+
+  - A host1x driver that provides infrastructure and access to the host1x
+services.
+
+  - A KMS driver that supports the display controllers as well as a number of
+outputs, such as RGB, HDMI, DSI, and DisplayPort.
+
+  - A set of custom userspace IOCTLs that can be used to submit jobs to the
+GPU and video engines via host1x.
+
+Driver Infrastructure
+=
+
+The various host1x clients need to be bound together into a logical device in
+order to expose their functionality to users. The infrastructure that supports
+this is implemented in the host1x driver. When a driver is registered with the
+infrastructure it provides a list of compatible strings specifying the devices
+that it needs. The infrastructure creates a logical device and scan the device
+tree for matching device nodes, adding the required clients to a list. Drivers
+for individual clients register with the infrastructure as well and are added
+to the logical host1x device.
+
+Once all clients are available, the infrastructure will initialize the logical
+device using a driver-provided function which will set up the bits specific to
+the subsystem and in turn initialize each of its clients.
+
+Similarly, when one of the clients is unregistered, the infrastructure will
+destroy the logical device by calling back into the driver, which ensures that
+the subsystem specific bits are torn down and the clients destroyed in turn.
+
+Host1x Infrastructure Reference
+---
+
+.. kernel-doc:: include/linux/host1x.h
+
+.. kernel-doc:: drivers/gpu/host1x/bus.c
+   :export:
+
+Host1x Syncpoint Reference
+--
+
+.. kernel-doc:: drivers/gpu/host1x/syncpt.c
+   :export:
+
+KMS driver
+==
+
+The display hardware has remained mostly backwards compatible over the various
+Tegra SoC generations, up until Tegra186 which introduces several changes that
+make it difficult to support with a parameterized driver.
+
+Display Controllers
+---
+
+Tegra SoCs have two display controllers, each of which can be associated with
+zero or more outputs. Outputs can also share a single display controller, but
+only if they run with compatible display timings. Two display controllers can
+also share a single framebuffer, allowing cloned configurations even if modes
+on two outputs don't match. A display controller is modelled as a CRTC in KMS
+terms.
+
+On Tegra186, the number of display controllers has been increased to three. A
+display controller can no longer drive all of the outputs. While two of these
+controllers can drive both DSI outputs and both SOR outputs, the third cannot
+drive any DSI.
+
+Windows
+~~~
+
+A display controller controls a set of windows that can be used to composite
+multiple buffers onto the screen. While it is possible to assign arbitrary Z
+ordering to individual windows (by programming the corresponding blending
+registers), this is currently not supported by the driver. Instead, it will
+assume a fixed Z ordering of the windows (window A is the root window, that
+is, the lowest, while windows B and C are overlaid on top of window A). The
+overlay windows support multiple pixel formats and can automatically convert
+from YUV to RGB at scanout time. This makes them useful for 

Re: [PATCH v3] drm/exynos: mixer: document YCbCr magic numbers

[Tobias Jakobi]

Inki Dae wrote:
> 2017-03-29 20:56 GMT+09:00 Tobias Jakobi :
>> Hello Daniel,
>>
>> same question here. Patch doesn't introduce any functional changes (just
>> adds code documentation), so can you merge it through drm-misc?
>>
> 
> Sorry for late. Confirmed just now. I will check it on next Monday.
You have added the wrong patch (v2 instead of v3).

- Tobias


> Thanks,
> Inki Dae
> 
>> With best wishes,
>> Tobias
>>
>>
>> Tobias Jakobi wrote:
>>> The output stage of the mixer uses YCbCr for the internal
>>> computations, which is the reason that some registers take
>>> YCbCr related data as input. In particular this applies
>>> to MXR_BG_COLOR{0,1,2} and MXR_CM_COEFF_{Y,CB,CR}.
>>>
>>> Document the formatting of the data which we write to
>>> these registers.
>>>
>>> While at it, unify wording of comments in the register header.
>>>
>>> Reviewed-by: Andrzej Hajda 
>>> Signed-off-by: Tobias Jakobi 
>>> ---
>>> Changes in v2:
>>> - use floating point values as input for the macros, as
>>>   suggested by Andrzej
>>> - the floating point values have been tuned to exactly match
>>>   the values that are currently used
>>>
>>> Changes in v3:
>>> - use only three digit values (pointed out by Andrzej)
>>>
>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 33 
>>> +
>>>  drivers/gpu/drm/exynos/regs-mixer.h   |  7 +--
>>>  2 files changed, 30 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> index 41d0c36..9648dd5 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> @@ -45,6 +45,22 @@
>>>  #define MIXER_WIN_NR 3
>>>  #define VP_DEFAULT_WIN   2
>>>
>>> +/*
>>> + * Mixer color space conversion coefficient triplet.
>>> + * Used for CSC from RGB to YCbCr.
>>> + * Each coefficient is a 10-bit fixed point number with
>>> + * sign and no integer part, i.e.
>>> + * [0:8] = fractional part (representing a value y = x / 2^9)
>>> + * [9] = sign
>>> + * Negative values are encoded with two's complement.
>>> + */
>>> +#define MXR_CSC_C(x) ((int)((x) * 512.0) & 0x3ff)
>>> +#define MXR_CSC_CT(a0, a1, a2) \
>>> +  ((MXR_CSC_C(a0) << 20) | (MXR_CSC_C(a1) << 10) | (MXR_CSC_C(a2) << 0))
>>> +
>>> +/* YCbCr value, used for mixer background color configuration. */
>>> +#define MXR_YCBCR_VAL(y, cb, cr) (((y) << 16) | ((cb) << 8) | ((cr) << 0))
>>> +
>>>  /* The pixelformats that are natively supported by the mixer. */
>>>  #define MXR_FORMAT_RGB5654
>>>  #define MXR_FORMAT_ARGB1555  5
>>> @@ -391,13 +407,14 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
>>> *ctx, unsigned int height)
>>>   case 1080:
>>>   default:
>>>   val = MXR_CFG_RGB709_16_235;
>>> + /* Configure the BT.709 CSC matrix for full range RGB. */
>>>   mixer_reg_write(res, MXR_CM_COEFF_Y,
>>> - (1 << 30) | (94 << 20) | (314 << 10) |
>>> - (32 << 0));
>>> + MXR_CSC_CT( 0.184,  0.614,  0.063) |
>>> + MXR_CM_COEFF_RGB_FULL);
>>>   mixer_reg_write(res, MXR_CM_COEFF_CB,
>>> - (972 << 20) | (851 << 10) | (225 << 0));
>>> + MXR_CSC_CT(-0.102, -0.338,  0.440));
>>>   mixer_reg_write(res, MXR_CM_COEFF_CR,
>>> - (225 << 20) | (820 << 10) | (1004 << 0));
>>> + MXR_CSC_CT( 0.440, -0.399, -0.040));
>>>   break;
>>>   }
>>>
>>> @@ -715,10 +732,10 @@ static void mixer_win_reset(struct mixer_context *ctx)
>>>   /* reset default layer priority */
>>>   mixer_reg_write(res, MXR_LAYER_CFG, 0);
>>>
>>> - /* setting background color */
>>> - mixer_reg_write(res, MXR_BG_COLOR0, 0x008080);
>>> - mixer_reg_write(res, MXR_BG_COLOR1, 0x008080);
>>> - mixer_reg_write(res, MXR_BG_COLOR2, 0x008080);
>>> + /* set all background colors to RGB (0,0,0) */
>>> + mixer_reg_write(res, MXR_BG_COLOR0, MXR_YCBCR_VAL(0, 128, 128));
>>> + mixer_reg_write(res, MXR_BG_COLOR1, MXR_YCBCR_VAL(0, 128, 128));
>>> + mixer_reg_write(res, MXR_BG_COLOR2, MXR_YCBCR_VAL(0, 128, 128));
>>>
>>>   if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) {
>>>   /* configuration of Video Processor Registers */
>>> diff --git a/drivers/gpu/drm/exynos/regs-mixer.h 
>>> b/drivers/gpu/drm/exynos/regs-mixer.h
>>> index 7f22df5..c311f57 100644
>>> --- a/drivers/gpu/drm/exynos/regs-mixer.h
>>> +++ b/drivers/gpu/drm/exynos/regs-mixer.h
>>> @@ -140,11 +140,11 @@
>>>  #define MXR_INT_EN_VSYNC (1 << 11)
>>>  #define MXR_INT_EN_ALL   (0x0f << 8)
>>>
>>> -/* bit for MXR_INT_STATUS */
>>> +/* bits for MXR_INT_STATUS */
>>>  #define MXR_INT_CLEAR_VSYNC  (1 << 11)
>>>  #define MXR_INT_STATUS_VSYNC (1 << 0)
>>>
>>> -/* bit for MXR_LAYER_CFG */
>>> +/* bits for MXR_LAYER_CFG */
>>>

[PATCH 1/2] gpu: host1x: Flesh out kerneldoc

[Thierry Reding]

From: Thierry Reding 

Improve kerneldoc for the public parts of the host1x infrastructure in
preparation for adding driver-specific part to the GPU documentation.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/bus.c| 75 +
 drivers/gpu/host1x/syncpt.c | 81 +++--
 include/linux/host1x.h  | 25 ++
 3 files changed, 170 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 0c7ed03c235b..5e7ff8bec53d 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -40,6 +40,9 @@ struct host1x_subdev {
 
 /**
  * host1x_subdev_add() - add a new subdevice with an associated device node
+ * @device: host1x device to add the subdevice to
+ * @driver: host1x driver
+ * @np: device node
  */
 static int host1x_subdev_add(struct host1x_device *device,
 struct host1x_driver *driver,
@@ -80,6 +83,7 @@ static int host1x_subdev_add(struct host1x_device *device,
 
 /**
  * host1x_subdev_del() - remove subdevice
+ * @subdev: subdevice to remove
  */
 static void host1x_subdev_del(struct host1x_subdev *subdev)
 {
@@ -90,6 +94,8 @@ static void host1x_subdev_del(struct host1x_subdev *subdev)
 
 /**
  * host1x_device_parse_dt() - scan device tree and add matching subdevices
+ * @device: host1x logical device
+ * @driver: host1x driver
  */
 static int host1x_device_parse_dt(struct host1x_device *device,
  struct host1x_driver *driver)
@@ -190,6 +196,16 @@ static void host1x_subdev_unregister(struct host1x_device 
*device,
mutex_unlock(&device->subdevs_lock);
 }
 
+/**
+ * host1x_device_init() - initialize a host1x logical device
+ * @device: host1x logical device
+ *
+ * The driver for the host1x logical device can call this during execution of
+ * its &host1x_driver.probe implementation to initialize each of its clients.
+ * The client drivers access the subsystem specific driver data using the
+ * &host1x_client.parent field and driver data associated with it (usually by
+ * calling dev_get_drvdata()).
+ */
 int host1x_device_init(struct host1x_device *device)
 {
struct host1x_client *client;
@@ -216,6 +232,15 @@ int host1x_device_init(struct host1x_device *device)
 }
 EXPORT_SYMBOL(host1x_device_init);
 
+/**
+ * host1x_device_exit() - uninitialize host1x logical device
+ * @device: host1x logical device
+ *
+ * When the driver for a host1x logical device is unloaded, it can call this
+ * function to tear down each of its clients. Typically this is done after a
+ * subsystem-specific data structure is removed and the functionality can no
+ * longer be used.
+ */
 int host1x_device_exit(struct host1x_device *device)
 {
struct host1x_client *client;
@@ -470,6 +495,14 @@ static void host1x_detach_driver(struct host1x *host1x,
mutex_unlock(&host1x->devices_lock);
 }
 
+/**
+ * host1x_register() - register a host1x controller
+ * @host1x: host1x controller
+ *
+ * The host1x controller driver uses this to register a host1x controller with
+ * the infrastructure. Note that all Tegra SoC generations have only ever come
+ * with a single host1x instance, so this function is somewhat academic.
+ */
 int host1x_register(struct host1x *host1x)
 {
struct host1x_driver *driver;
@@ -488,6 +521,13 @@ int host1x_register(struct host1x *host1x)
return 0;
 }
 
+/**
+ * host1x_unregister() - unregister a host1x controller
+ * @host1x: host1x controller
+ *
+ * The host1x controller driver uses this to remove a host1x controller from
+ * the infrastructure.
+ */
 int host1x_unregister(struct host1x *host1x)
 {
struct host1x_driver *driver;
@@ -537,6 +577,16 @@ static void host1x_device_shutdown(struct device *dev)
driver->shutdown(device);
 }
 
+/**
+ * host1x_driver_register_full() - register a host1x driver
+ * @driver: host1x driver
+ * @owner: owner module
+ *
+ * Drivers for host1x logical devices call this function to register a driver
+ * with the infrastructure. Note that since these drive logical devices, the
+ * registration of the driver actually triggers tho logical device creation.
+ * A logical device will be created for each host1x instance.
+ */
 int host1x_driver_register_full(struct host1x_driver *driver,
struct module *owner)
 {
@@ -565,6 +615,13 @@ int host1x_driver_register_full(struct host1x_driver 
*driver,
 }
 EXPORT_SYMBOL(host1x_driver_register_full);
 
+/**
+ * host1x_driver_unregister() - unregister a host1x driver
+ * @driver: host1x driver
+ *
+ * Unbinds the driver from each of the host1x logical devices that it is
+ * bound to, effectively removing the subsystem devices that they represent.
+ */
 void host1x_driver_unregister(struct host1x_driver *driver)
 {
driver_unregister(&driver->driver);
@@ -575,6 +632,17 @@ void host1x_driver_unregister(struct host1x_driver *driver)
 }
 EXPOR

Re: [PATCH] drm/exynos: clean up description of exynos_drm_crtc

[Tobias Jakobi]

Inki Dae wrote:
> 2017-04-07 20:40 GMT+09:00 Tobias Jakobi :
>> Hello Inki,
>>
>>
>> Inki Dae wrote:
>>> Hello Tobias,
>>>
>>>
>>> 2017년 04월 07일 02:10에 Tobias Jakobi 이(가) 쓴 글:
 Hello Inki,


 Inki Dae wrote:
> This patch removes unnecessary descriptions on
> exynos_drm_crtc structure and adds one description
> which specifies what pipe_clk member does.
>
> pipe_clk support had been added by below patch without any description,
>  drm/exynos: add support for pipeline clock to the framework
 I would put the commit id here. That makes it easier to look up the
 commit your refer to.


> Signed-off-by: Inki Dae 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 527bf1d..b0462cc 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -152,12 +152,10 @@ struct exynos_drm_clk {
>   *
>   * @base: crtc object.
>   * @type: one of EXYNOS_DISPLAY_TYPE_LCD and HDMI.
> - * @enabled: if the crtc is enabled or not
> - * @event: vblank event that is currently queued for flip
> - * @wait_update: wait all pending planes updates to finish
> - * @pending_update: number of pending plane updates in this crtc
>   * @ops: pointer to callbacks for exynos drm specific functionality
>   * @ctx: A pointer to the crtc's implementation specific context
> + * @pipe_clk: A pipe clock structure which includes a callback function
> + for enabling DP clock of FIMD and HDMI PHY clock.
 This is wrong/inconsistent with the rest of the documentation. pipe_clk
 is not a struct, but a pointer.

 I would suggest to follow. Just document that we have a pointer to >>> escription> here (compare docu for 'ops' and 'ctx').
 And then put the later bits ("...callback function for enabling DP
 clock...") directly to the definition of 'struct exynos_drm_clk' (which
 is currently lacking any kind of docu).
>>>
>>> Thanks for pointing it out. My mistake. :)
>>>
>>> How about this simply?
>>> "A pointer to exynos_drm_clk structure for enabling and disabling DP clock 
>>> of FIMD and HDMI PHY clocks"
>> Not what I meant. You're describing 'struct exynos_drm_clk', and that
>> does not belong here. If you describe 'struct exynos_drm_clk', then this
>> should go in front of the struct's definition.
>>
>> How abouting something like this in front of the struct's definition::
>>> /*
>>>  * Exynos DRM pipeline clock structure.
>>>  *
>>>  * @enable: callback to enable/disable the clock.
>>>  *
>>>  * Used for proper clock synchronization of components belonging
>>>  * to the same pipeline. Used e.g. for enabling the DP clock of
>>>  * the FIMD or the HDMI PHY clock.
>>>  */
>>> struct exynos_drm_clk {
>>> 
>>
>> For 'pipe_clk' I would just go with this:
>>> @pipe_clk: A pointet to the crtc's pipeline clock.
> 
> More simple and looks better.
In this form (commit a07d468cb2efd347a9e279e4f68661f0f370d10f in
exynos-drm-next), the description is incomplete. Please read my mails again.

- Tobias


> 
> Thanks,
> Inki Dae
> 
>>
>> I hope this helps.
>>
>> - Tobias
>>
>>
>>> Thanks,
>>> Inki Dae
>>>


 - Tobias

>   */
>  struct exynos_drm_crtc {
> struct drm_crtc base;
>




>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

Re: [PATCH 0/2] drm: dw-hdmi: various improvements

[Neil Armstrong]

On 04/10/2017 12:08 PM, Russell King - ARM Linux wrote:
> On Mon, Apr 10, 2017 at 10:49:18AM +0530, Archit Taneja wrote:
>> Hi,
>>
>> On 04/07/2017 07:49 PM, Romain Perier wrote:
>>> This set of patches split the stream handling functions in two parts. It
>>> introduces new callbacks that are specific to each variant, one for I2S
>>> and one for AHB.
>>>
>>> Then, as requested by the datasheet for the I2S variant, it adds support
>>> for gating the audio sampler clock when the audio stream is enabled and
>>> disabled.
>>>
>>> This patches series is the continuity of the following discussion:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/493550.html
>>
>> Since these aren't fixes, could you make sure to redo the patches over:
>>
>> git://anongit.freedesktop.org/drm-misc drm-misc-next
>>
>> The dw-hdmi driver is now under drivers/gpu/drm/bridge/synopsis/
> 
> This is annoying as it makes submission of CEC support for dw-hdmi
> rather difficult due to the now horrid cross-tree dependencies:
> 
> * if I submit it to the DRM tree, the DRM tree will build break because
>   you don't have the necessary CEC changes which have recently been
>   merged into the media tree.
> 
> * if I submit it to the media tree, the new files will be placed into
>   drivers/gpu/drm/bridge and when stuff gets merged into linux-next
>   and/or Linus' tree, things will need quite a large fixup (someone
>   will have to rename the files and fix the Kconfig/Makefiles.)
> 
> So, I'll hold it back for another cycle to avoid the mess that would
> result from trying to get it merged during this cycle.
> 

Hi Russell,

Cross tree with media has already been done on this cycle with the
dw-hdmi formats changes.

Nevertheless, please push your updated dw-hdmi cec patchset for tests
and review based on the latest drm-misc-next and hverkuil's HPD notifier
release.

I would like to run it on some Amlogic boards.

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

Re: [PATCH] drm: dw-hdmi: Implement the mode_fixup drm helper

[Archit Taneja]

On 04/08/2017 12:03 AM, Daniel Vetter wrote:

On Fri, Apr 07, 2017 at 02:17:43PM +0200, Romain Perier wrote:

This helper is supposed to validate or reject the modeline before it
applied by the mode setting. Currently this function has been dropped,
it was previously set to a dummy function that always returned true. For
both cases, this means that userspace can ask for a bad modeline that
will be always accepted.

On some platforms, like Rockchip, the drm dw_hdmi-rockchip variant driver
already implements the atomic_check drm helper, so mode_fixup cannot be
handled and implemented there (as drm_atomic_helper relies on either
atomic_check or mode_fixup).

This commit implements this helper. It only checks that this mode is
correct from the connector point of view

Signed-off-by: Romain Perier 


Yup this is how it's supposed to be done, check bridge limits in the
bridge's mode_fixup hook.

Acked-by: Daniel Vetter 


queued to drm-misc-next-fixes (so that it makes it into 4.12).

Thanks,
Archit


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

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 22211ff..3bd0807 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1740,6 +1740,21 @@ static int dw_hdmi_bridge_attach(struct drm_bridge 
*bridge)
return 0;
 }

+
+static bool dw_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *orig_mode,
+ struct drm_display_mode *mode)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+   struct drm_connector *connector = &hdmi->connector;
+   enum drm_mode_status status;
+
+   status = dw_hdmi_connector_mode_valid(connector, mode);
+   if (status != MODE_OK)
+   return false;
+   return true;
+}
+
 static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
struct drm_display_mode *orig_mode,
struct drm_display_mode *mode)
@@ -1781,6 +1796,7 @@ static const struct drm_bridge_funcs dw_hdmi_bridge_funcs 
= {
.enable = dw_hdmi_bridge_enable,
.disable = dw_hdmi_bridge_disable,
.mode_set = dw_hdmi_bridge_mode_set,
+   .mode_fixup = dw_hdmi_bridge_mode_fixup,
 };

 static irqreturn_t dw_hdmi_i2c_irq(struct dw_hdmi *hdmi)
--
2.9.3

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




--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/tilcdc: do the complete reset sequence if the LCDC is enabled

[Jyri Sarha]

On 03/28/17 11:11, Emiliano Ingrassia wrote:
> If the LCD controller was already enabled (e.g. by the bootloader),
> do the complete software reset sequence to avoid time out while loading
> the palette and a consequent time out waiting for vblank.
> 
> Signed-off-by: Emiliano Ingrassia 

Thanks for the patch, and sorry that I did not respond to you earlier.

The issue is obviously real, but I do not like duplicating the already
existing code for CRTC disable irq enable. Another issue is making the
check every time the CRTC is turned on.

I'll send a patch of my own to try to fix the issue shortly. Could you
spare time to test it if it fixes the issue on your platform?

Best regards,
Jyri

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 3621ff42979f..589156b2f76c 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -208,10 +208,33 @@ static void reset(struct drm_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->dev;
>   struct tilcdc_drm_private *priv = dev->dev_private;
> + struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> + int ret;
>  
>   if (priv->rev != 2)
>   return;
>  
> + /*
> +  * If the LCDC was already enabled (e.g. by the bootloader)
> +  * do the complete software reset sequence.
> +  */
> + if (tilcdc_read(dev, LCDC_RASTER_CTRL_REG) & LCDC_RASTER_ENABLE) {
> +
> + /* Enable DMA Frame Done Interrupt */
> + tilcdc_write(dev, LCDC_INT_ENABLE_SET_REG, LCDC_FRAME_DONE);
> + tilcdc_clear_irqstatus(dev, 0x);
> +
> + tilcdc_crtc->frame_done = false;
> + tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
> +
> + ret = wait_event_timeout(tilcdc_crtc->frame_done_wq,
> +  tilcdc_crtc->frame_done,
> +  msecs_to_jiffies(500));
> + if (ret == 0)
> + dev_err(dev->dev, "%s: timeout waiting for framedone 
> while resetting LCDC\n",
> + __func__);
> + }
> +
>   tilcdc_set(dev, LCDC_CLK_RESET_REG, LCDC_CLK_MAIN_RESET);
>   usleep_range(250, 1000);
>   tilcdc_clear(dev, LCDC_CLK_RESET_REG, LCDC_CLK_MAIN_RESET);
> 

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

[PATCH] drm/tilcdc: If CRTC is enabled at init phase, disable it

[Jyri Sarha]

If the LCDC is already enabled (e.g. by the bootloader) at the
initialization phase, disable it before returning from the probe.

Signed-off-by: Jyri Sarha 
Reported-by: Emiliano Ingrassia 
---
This patch should fix the same issus as this patch does:
https://lists.freedesktop.org/archives/dri-devel/2017-March/137091.html

I do not like the above patch duplicating the already existing code
for CRTC disable. Another issue is making the check every time the
CRTC is turned on.

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 21 +
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  3 +++
 drivers/gpu/drm/tilcdc/tilcdc_drv.h  |  1 +
 3 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index afd2a7b..540378a 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -566,6 +566,26 @@ void tilcdc_crtc_shutdown(struct drm_crtc *crtc)
tilcdc_crtc_off(crtc, true);
 }
 
+void tilcdc_crtc_disable_init(struct drm_crtc *crtc)
+{
+   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+   struct drm_device *dev = crtc->dev;
+
+   /*
+* If the LCDC was already enabled (e.g. by the bootloader)
+* disable the CRTC before finishing the probe.
+*/
+   pm_runtime_get_sync(dev->dev);
+   if (tilcdc_read(dev, LCDC_RASTER_CTRL_REG) & LCDC_RASTER_ENABLE) {
+   tilcdc_crtc->enabled = true;
+   tilcdc_crtc_enable_irqs(dev);
+   /* To match pm_runtime_put_sync() in tilcdc_crtc_off() */
+   pm_runtime_get_sync(dev->dev);
+   tilcdc_crtc_off(crtc, false);
+   }
+   pm_runtime_put_sync(dev->dev);
+}
+
 static bool tilcdc_crtc_is_on(struct drm_crtc *crtc)
 {
return crtc->state && crtc->state->enable && crtc->state->active;
@@ -1054,6 +1074,7 @@ int tilcdc_crtc_create(struct drm_device *dev)
}
 
priv->crtc = crtc;
+
return 0;
 
 fail:
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index d7ae5be..7dabe55 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -415,6 +415,9 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
device *dev)
goto init_failed;
 
priv->is_registered = true;
+
+   tilcdc_crtc_disable_init(priv->crtc);
+
return 0;
 
 init_failed:
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 8caa11b..adde1e4 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -179,6 +179,7 @@ void tilcdc_crtc_set_simulate_vesa_sync(struct drm_crtc 
*crtc,
 int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_pending_vblank_event *event);
+void tilcdc_crtc_disable_init(struct drm_crtc *crtc);
 
 int tilcdc_plane_init(struct drm_device *dev, struct drm_plane *plane);
 
-- 
1.9.1

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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Pekka Paalanen]

On Sun, 09 Apr 2017 10:27:31 -0700
Keith Packard  wrote:

> Pekka Paalanen  writes:
> 
> > we need some kind of a database to recognize HMDs in any case, right?
> > It would be best if the database was shared, so that everyone could
> > recognize all HMDs, at least as far as one can do that based on EDID.  
> 
> Yeah, I think you've got some good ideas here. Here are some questions
> which this raises:
> 
>  * What should we do with an HMD which is in the database but for which
>no application is installed on the host?

IMHO, if nothing is providing a picture intended for the HMD, the HMD
should be off. There is no use in showing an arbitrary image that does
not look right, is there?

For the rest of the questions I can't really say anything, except that
even if the database was just a bunch of files, you still need code to
access it, and probably something to ensure the entries are
well-formed, so that everyone will agree on how to parse them. One
should probably decide whether the database will only answer the
question "is it a HMD?" or can it provide other information as well.


Thanks,
pq


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

Re: [PATCH] drm: panels: Add MAINTAINERS entry for LVS panel driver

[Emil Velikov]

On 10 April 2017 at 10:58, Lucas Stach  wrote:
> Am Montag, den 10.04.2017, 09:17 +0200 schrieb Thierry Reding:
>> On Sun, Apr 09, 2017 at 01:31:40PM +0100, Emil Velikov wrote:
>> > Hi Thierry,
>> >
>> > I don't mean to stir up anything, just voicing "my 2c" as they say.
>
> I normally try to keep away from this "political" discussions,
> especially with regard to the panel stuff, but as this seems to pop up
> again and again, I feel the need to speak up.
>
Right, my intent did not plan as expected.

>> > On 7 April 2017 at 18:33, Thierry Reding  wrote:
>> >
>> > > Ever since the simple-panel binding was introduced, which is now about
>> > > 3 1/2 years ago,
>> >
>> > Do you have a link to these discussions? Your blog article does not
>> > have any links and I only found the "Runtime Interpreted Power
>> > Sequences" thread.
>> > That in itself does not cover the pros/cons of storing HW information*
>> > within DT.
>>
>> There's some discussion here:
>>
>>   
>> https://lists.freedesktop.org/archives/dri-devel/2013-November/049509.html
>>
>> which continues here:
>>
>>   
>> https://lists.freedesktop.org/archives/dri-devel/2013-December/050082.html
>>
>> There are a couple of earlier threads, though, that discuss similar
>> issues. This one seems to be the earliest I can find that is publicly
>> archived:
>>
>>   http://www.spinics.net/lists/devicetree/msg08497.html
>>
>> Going over all these threads again wasn't a very pleasant experience. I
>> realize how much time I already spent discussing these, and I don't have
>> any desire to repeat that discussion.
>>
>> We've had these differences ever since the very beginning. So we're now
>> again going in circles.
>>
>> The main concern back at the time was that having to specify timings in
>> the driver would result in a complete mess because we have zillions of
>> panels that we need to support. That's turned out to be a complete non-
>> issue. We've got something on the order of 50 or 60 drivers supported in
>> the simple-panel driver, and for everything that's more complicated we
>> have a handful of separate drivers, all fairly simple as well.
>>
>> So while I understand why people want to put all this information into
>> DT, we've repeatedly discussed the disadvantages that this would have.
>> And while we were never able to get everyone to agree, the current
>> solution has had enough agreement that we merged it. And it turned out
>> to be good enough. There's nothing in panel-lvds that I can see that
>> fundamentally changes this.
>
> I was personally opposed to the idea of specifying panels only by
> compatible and carrying around a "modedb" in the form of the
> simple-panel driver. Since then I've come to appreciate the flexibility
> that having a real driver for a panel provides.
>
> A panel is _much_ more than a simple mode. For LVDS panels it's in many
> cases a complete range of timings that will work with the panel, it's
> the enable sequencing with regulators and GPIOs, it's the size of the
> panel, so we get proper DPI information, it's a bus format describing
> all the oddities that vendors choose to implement when designing the
> physical interface. It provides proper sequencing of backlight
> enable/disable.
>
> I very much support Thierrys view, that all this should be encoded by
> the compatible. This allows us to add required properties to the panel
> if needed. It certainly saved us a lot of backward compat issues in
> imx-drm, that we could just add all the required information to the
> panel, so everything is consistent within one kernel version.
>
>> > Personally, the idea of having hardware information* in DT does not
>> > sound all that bad. The simple panel driver(s) can use those
>> > properties and any panels that require anything more complex will
>> > still need their own driver.
>
> Although some people seems to feel different on that matter, but DT is
> supposed to be ABI. Newer kernels _must_ work on older DTs. Which means
> it needs to encode _all_ information on the panel.
>
> Personally I don't trust people, who are just enabling their one board
> to go through and validate that all the panel information is correct. As
> soon as a picture shows up they are going to ship the DT.
>
> With having to go through a panel driver, there is at least some basic
> review of the panel properties.
>
> Also speaking from experience with a board with different display
> configurations, where only the bootloader knows the specific attached
> panel, it's very convenient to have the bootloader only patch in the
> correct compatible, instead of all the panel properties. If any of those
> properties turns out to be wrong, I can fix it with a simple kernel
> update, instead of having to update the bootloader.
>
>> Again, the point is that you're going to have to modify the driver in
>> any case, because you need to support the new compatible string. Without
>> that compatible string you have zero information about the panel, and

drm-tip/drm-tip boot: 116 boots: 4 failed, 109 passed with 3 offline (v4.11-rc5-1803-gd86f5fa557fd)

[kernelci . org bot]

drm-tip/drm-tip boot: 116 boots: 4 failed, 109 passed with 3 offline 
(v4.11-rc5-1803-gd86f5fa557fd)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1803-gd86f5fa557fd/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1803-gd86f5fa557fd/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1803-gd86f5fa557fd
Git Commit: d86f5fa557fdf089bdb5b51f625a7f5967f11015
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 18 unique boards, 10 SoC families, 27 builds out of 207

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

arm:

multi_v7_defconfig+CONFIG_SMP=n
exynos5250-snow: 1 failed lab

Offline Platforms:

x86:

allmodconfig:
minnowboard-max: 1 offline lab

allmodconfig+CONFIG_OF=n:
minnowboard-max: 1 offline lab

arm:

bcm2835_defconfig:
bcm2836-rpi-2-b: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Fix get_property logic fumble

[Daniel Vetter]

Yet again I've proven that I can't negate conditions :(

Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
Cc: Maarten Lankhorst 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Reported-by: Tvrtko Ursulin 
Cc: Tvrtko Ursulin 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_property.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 3feef0659940..3e88fa24eab3 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -476,7 +476,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
list_for_each_entry(prop_enum, &property->enum_list, head) {
enum_count++;
-   if (out_resp->count_enum_blobs <= enum_count)
+   if (out_resp->count_enum_blobs < enum_count)
continue;
 
if (copy_to_user(&enum_ptr[copied].value,
-- 
2.11.0

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

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 204 warnings (v4.11-rc5-1806-g02f6d3e01f3e)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 204 warnings 
(v4.11-rc5-1806-g02f6d3e01f3e)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1806-g02f6d3e01f3e/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1806-g02f6d3e01f3e
Git Commit: 02f6d3e01f3e1b6b91efeaceabd24e36e0540b49
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  drivers/tty/vt/keyboard.c:14

Re: [RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid

[Tomi Valkeinen]

On 08/04/17 13:11, Hans Verkuil wrote:

> So, this is a bit of a blast from the past since the omap4 CEC development
> has been on hold for almost a year. But I am about to resume my work on this
> now that the CEC framework was merged.
> 
> The latest code is here, if you are interested:
> 
> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=panda-cec
> 
> It's pretty much unchanged from the version I posted a year ago, just rebased.
> 
> But before I continue with this I have one question for you. First some
> background:
> 
> There is a special corner case (and I wasn't aware of that a year ago!) where
> it is allowed to send a CEC message when there is *no HPD*.
> 
> The reason is that some displays turn off the hotplug detect pin when they go
> into standby or when another input is active. The only way to communicate with
> such displays is via CEC.
> 
> The problem is that without a HPD there is no EDID and basically no way for an
> HDMI transmitter to detect that something is connected at all, unless you are
> using CEC.
> 
> What this means is that if we want to implement this on the omap4 the CEC 
> support
> has to be on all the time.
> 
> We have seen modern displays that behave like this, so this is a real issue. 
> And
> this corner case is specifically allowed by the CEC specification: the Poll,
> Image/Text View On and the Active Source messages can be sent to a TV even 
> when
> there is no HPD in order to turn on the display if it was in standby and to 
> make
> us the active input.
> 
> The CEC framework in the kernel supports this starting with 4.12 (this code is
> in the panda-cec branch above).
> 
> If this *can't* be supported by the omap4, then I will likely have to add a 
> CEC
> capability to signal to the application that this specific corner case is not
> supported.
> 
> I just did some tests with omap4 and I my impression is that this can't be
> supported: when the HPD goes away it seems like most/all of the HDMI blocks 
> are
> all powered off and any attempt to even access the CEC registers will fail.
> 
> Changing this looks to be non-trivial if not impossible.
> 
> Can you confirm that that isn't possible? If you think this can be done, then
> I'd appreciate if you can give me a few pointers.

HPD doesn't control the HW, it's all in the SW. So while I don't know
much at all about CEC and haven't looked at this particular use case, I
believe it's doable. HPD going off will make the DRM connector to be in
"disconnected" state, which on omapdrm will cause everything about HDMI
to be turned off.

Does it work on some other DRM driver? I'm wondering if there's
something in the DRM framework side that also has to be changed, in
addition to omapdrm changes.

It could require larger SW redesigns, though... Which makes me think
that the work shouldn't be done until we have changed the omapdrm's
driver model to DRM's common bridge driver model, and then all this
could possibly be done in a more generic manner.

Well, then again, I think the hdmi driver's internal power state
handling could be improved even before that. Currently it's not very
versatile. We should have ways to partially enable the IP for just the
required parts.

 Tomi



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

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Daniel Vetter]

On Mon, Apr 10, 2017 at 12:12:01PM +0200, Gerd Hoffmann wrote:
> Ok, this is really a kickstart for a discussion.  While working on
> graphics support for virtual machines on ppc64 (which exists in both
> little and big endian variants) I've figured the comments in the header
> file don't match reality.  They are not considered little endian (as
> suggested by the comments) but in practice are used as native endian.
> 
> So, go update the comments.
> 
> This patch switches all 32bpp / 8 bpc formats over to native endian.
> Those used/supported by ppc64 virtual machines (virtio-gpu/bochs-drm
> drivers).
> 
> Given that DRM_FORMAT_BIG_ENDIAN isn't used anywhere in the codebase
> I suspect this problem applies to more formats.  When looking at
> drm_mode_legacy_fb_format it seems *all* RGB formats are actually
> native endian not little endian.
> 
> Dunno where we stand in terms of YCbCr.
> 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Gerd Hoffmann 

I think we should go all-in on this and essentially remove the _BIG_ENDIAN
stuff. But in the end this is to be decided be the people who care about
big endian, afaik that's only you (for the pile of virt drivers we have)
and amdgpu/radeon.
-Daniel

> ---
>  include/uapi/drm/drm_fourcc.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 995c8f9..a7fc81d 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -85,15 +85,15 @@ extern "C" {
>  #define DRM_FORMAT_BGR888fourcc_code('B', 'G', '2', '4') /* [23:0] B:G:R 
> little endian */
>  
>  /* 32 bpp RGB */
> -#define DRM_FORMAT_XRGB  fourcc_code('X', 'R', '2', '4') /* [31:0] 
> x:R:G:B 8:8:8:8 little endian */
> -#define DRM_FORMAT_XBGR  fourcc_code('X', 'B', '2', '4') /* [31:0] 
> x:B:G:R 8:8:8:8 little endian */
> -#define DRM_FORMAT_RGBX  fourcc_code('R', 'X', '2', '4') /* [31:0] 
> R:G:B:x 8:8:8:8 little endian */
> -#define DRM_FORMAT_BGRX  fourcc_code('B', 'X', '2', '4') /* [31:0] 
> B:G:R:x 8:8:8:8 little endian */
> +#define DRM_FORMAT_XRGB  fourcc_code('X', 'R', '2', '4') /* [31:0] 
> x:R:G:B 8:8:8:8 native endian */
> +#define DRM_FORMAT_XBGR  fourcc_code('X', 'B', '2', '4') /* [31:0] 
> x:B:G:R 8:8:8:8 native endian */
> +#define DRM_FORMAT_RGBX  fourcc_code('R', 'X', '2', '4') /* [31:0] 
> R:G:B:x 8:8:8:8 native endian */
> +#define DRM_FORMAT_BGRX  fourcc_code('B', 'X', '2', '4') /* [31:0] 
> B:G:R:x 8:8:8:8 native endian */
>  
> -#define DRM_FORMAT_ARGB  fourcc_code('A', 'R', '2', '4') /* [31:0] 
> A:R:G:B 8:8:8:8 little endian */
> -#define DRM_FORMAT_ABGR  fourcc_code('A', 'B', '2', '4') /* [31:0] 
> A:B:G:R 8:8:8:8 little endian */
> -#define DRM_FORMAT_RGBA  fourcc_code('R', 'A', '2', '4') /* [31:0] 
> R:G:B:A 8:8:8:8 little endian */
> -#define DRM_FORMAT_BGRA  fourcc_code('B', 'A', '2', '4') /* [31:0] 
> B:G:R:A 8:8:8:8 little endian */
> +#define DRM_FORMAT_ARGB  fourcc_code('A', 'R', '2', '4') /* [31:0] 
> A:R:G:B 8:8:8:8 native endian */
> +#define DRM_FORMAT_ABGR  fourcc_code('A', 'B', '2', '4') /* [31:0] 
> A:B:G:R 8:8:8:8 native endian */
> +#define DRM_FORMAT_RGBA  fourcc_code('R', 'A', '2', '4') /* [31:0] 
> R:G:B:A 8:8:8:8 native endian */
> +#define DRM_FORMAT_BGRA  fourcc_code('B', 'A', '2', '4') /* [31:0] 
> B:G:R:A 8:8:8:8 native endian */
>  
>  #define DRM_FORMAT_XRGB2101010   fourcc_code('X', 'R', '3', '0') /* 
> [31:0] x:R:G:B 2:10:10:10 little endian */
>  #define DRM_FORMAT_XBGR2101010   fourcc_code('X', 'B', '3', '0') /* 
> [31:0] x:B:G:R 2:10:10:10 little endian */
> -- 
> 2.9.3
> 
> ___
> 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 2/2] drm/tegra: Add driver documentation

[Daniel Vetter]

On Mon, Apr 10, 2017 at 12:27:02PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Adds some driver documentation for Tegra. It provides a short overview
> of the hardware and software architectures.
> 
> Signed-off-by: Thierry Reding 

Yay for docs! On both patches:

Acked-by: Daniel Vetter 
> ---
>  Documentation/gpu/index.rst |   1 +
>  Documentation/gpu/tegra.rst | 178 
> 
>  2 files changed, 179 insertions(+)
>  create mode 100644 Documentation/gpu/tegra.rst
> 
> diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> index c572f092739e..feae37fa7ca3 100644
> --- a/Documentation/gpu/index.rst
> +++ b/Documentation/gpu/index.rst
> @@ -12,6 +12,7 @@ Linux GPU Driver Developer's Guide
> drm-uapi
> i915
> meson
> +   tegra
> tinydrm
> vc4
> vga-switcheroo
> diff --git a/Documentation/gpu/tegra.rst b/Documentation/gpu/tegra.rst
> new file mode 100644
> index ..d2ed8938ca43
> --- /dev/null
> +++ b/Documentation/gpu/tegra.rst
> @@ -0,0 +1,178 @@
> +===
> + drm/tegra NVIDIA Tegra GPU and display driver
> +===
> +
> +NVIDIA Tegra SoCs support a set of display, graphics and video functions via
> +the host1x controller. host1x supplies command streams, gathered from a push
> +buffer provided directly by the CPU, to its clients via channels. Software,
> +or blocks amongst themselves, can use syncpoints for synchronization.
> +
> +Up until, but not including, Tegra124 (aka Tegra K1) the drm/tegra driver
> +supports the built-in GPU, comprised of the gr2d and gr3d engines. Starting
> +with Tegra124 the GPU is based on the NVIDIA desktop GPU architecture and
> +supported by the drm/nouveau driver.
> +
> +The drm/tegra driver supports NVIDIA Tegra SoC generations since Tegra20. It
> +has three parts:
> +
> +  - A host1x driver that provides infrastructure and access to the host1x
> +services.
> +
> +  - A KMS driver that supports the display controllers as well as a number of
> +outputs, such as RGB, HDMI, DSI, and DisplayPort.
> +
> +  - A set of custom userspace IOCTLs that can be used to submit jobs to the
> +GPU and video engines via host1x.
> +
> +Driver Infrastructure
> +=
> +
> +The various host1x clients need to be bound together into a logical device in
> +order to expose their functionality to users. The infrastructure that 
> supports
> +this is implemented in the host1x driver. When a driver is registered with 
> the
> +infrastructure it provides a list of compatible strings specifying the 
> devices
> +that it needs. The infrastructure creates a logical device and scan the 
> device
> +tree for matching device nodes, adding the required clients to a list. 
> Drivers
> +for individual clients register with the infrastructure as well and are added
> +to the logical host1x device.
> +
> +Once all clients are available, the infrastructure will initialize the 
> logical
> +device using a driver-provided function which will set up the bits specific 
> to
> +the subsystem and in turn initialize each of its clients.
> +
> +Similarly, when one of the clients is unregistered, the infrastructure will
> +destroy the logical device by calling back into the driver, which ensures 
> that
> +the subsystem specific bits are torn down and the clients destroyed in turn.
> +
> +Host1x Infrastructure Reference
> +---
> +
> +.. kernel-doc:: include/linux/host1x.h
> +
> +.. kernel-doc:: drivers/gpu/host1x/bus.c
> +   :export:
> +
> +Host1x Syncpoint Reference
> +--
> +
> +.. kernel-doc:: drivers/gpu/host1x/syncpt.c
> +   :export:
> +
> +KMS driver
> +==
> +
> +The display hardware has remained mostly backwards compatible over the 
> various
> +Tegra SoC generations, up until Tegra186 which introduces several changes 
> that
> +make it difficult to support with a parameterized driver.
> +
> +Display Controllers
> +---
> +
> +Tegra SoCs have two display controllers, each of which can be associated with
> +zero or more outputs. Outputs can also share a single display controller, but
> +only if they run with compatible display timings. Two display controllers can
> +also share a single framebuffer, allowing cloned configurations even if modes
> +on two outputs don't match. A display controller is modelled as a CRTC in KMS
> +terms.
> +
> +On Tegra186, the number of display controllers has been increased to three. A
> +display controller can no longer drive all of the outputs. While two of these
> +controllers can drive both DSI outputs and both SOR outputs, the third cannot
> +drive any DSI.
> +
> +Windows
> +~~~
> +
> +A display controller controls a set of windows that can be used to composite
> +multiple buffers onto the screen. While it is possible to assign arbitrary Z
> +ordering to individual windows (by programming the co

Re: [PATCH 0/2] drm: dw-hdmi: various improvements

[Daniel Vetter]

On Mon, Apr 10, 2017 at 12:35:43PM +0200, Neil Armstrong wrote:
> On 04/10/2017 12:08 PM, Russell King - ARM Linux wrote:
> > On Mon, Apr 10, 2017 at 10:49:18AM +0530, Archit Taneja wrote:
> >> Hi,
> >>
> >> On 04/07/2017 07:49 PM, Romain Perier wrote:
> >>> This set of patches split the stream handling functions in two parts. It
> >>> introduces new callbacks that are specific to each variant, one for I2S
> >>> and one for AHB.
> >>>
> >>> Then, as requested by the datasheet for the I2S variant, it adds support
> >>> for gating the audio sampler clock when the audio stream is enabled and
> >>> disabled.
> >>>
> >>> This patches series is the continuity of the following discussion:
> >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/493550.html
> >>
> >> Since these aren't fixes, could you make sure to redo the patches over:
> >>
> >> git://anongit.freedesktop.org/drm-misc drm-misc-next
> >>
> >> The dw-hdmi driver is now under drivers/gpu/drm/bridge/synopsis/
> > 
> > This is annoying as it makes submission of CEC support for dw-hdmi
> > rather difficult due to the now horrid cross-tree dependencies:
> > 
> > * if I submit it to the DRM tree, the DRM tree will build break because
> >   you don't have the necessary CEC changes which have recently been
> >   merged into the media tree.
> > 
> > * if I submit it to the media tree, the new files will be placed into
> >   drivers/gpu/drm/bridge and when stuff gets merged into linux-next
> >   and/or Linus' tree, things will need quite a large fixup (someone
> >   will have to rename the files and fix the Kconfig/Makefiles.)
> > 
> > So, I'll hold it back for another cycle to avoid the mess that would
> > result from trying to get it merged during this cycle.
> > 
> 
> Hi Russell,
> 
> Cross tree with media has already been done on this cycle with the
> dw-hdmi formats changes.
> 
> Nevertheless, please push your updated dw-hdmi cec patchset for tests
> and review based on the latest drm-misc-next and hverkuil's HPD notifier
> release.
> 
> I would like to run it on some Amlogic boards.

Yeah, cross subsystem topic branches aren't rocket science, we have the
entire process documented and scripted on the drm side. Hairy depencies
really aren't a reason to not submit patches, we've got this :-)

But 4.12 is done anyway on the drm side, so will get delayed to 4.13 no
matter what. Still would be good to get the patches reviewed as early as
possible.
-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

[Bug 195295] USB device insertion turns on discrete Radeon GPU

[bugzilla-daemon]

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

--- Comment #2 from Eugene Shalygin (eugene.shaly...@gmail.com) ---
I will try.

-- 
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: [Intel-gfx] [PATCH] drm: Fix get_property logic fumble

[Chris Wilson]

On Mon, Apr 10, 2017 at 01:54:45PM +0200, Daniel Vetter wrote:
> Yet again I've proven that I can't negate conditions :(
> 
> Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")

You also get to write the igt/kms_getproperty, starting with a 
memset(prop_values, 0xc5, foo);
drmIoctl(GETPROPERTY);
igt_assert(!memchr(prop_values, 0xc5, bar));
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Fix get_property logic fumble

[Maarten Lankhorst]

Op 10-04-17 om 13:54 schreef Daniel Vetter:
> Yet again I've proven that I can't negate conditions :(
>
> Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Reported-by: Tvrtko Ursulin 
> Cc: Tvrtko Ursulin 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_property.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index 3feef0659940..3e88fa24eab3 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -476,7 +476,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
>   drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
>   list_for_each_entry(prop_enum, &property->enum_list, head) {
>   enum_count++;
> - if (out_resp->count_enum_blobs <= enum_count)
> + if (out_resp->count_enum_blobs < enum_count)
>   continue;
>  
>   if (copy_to_user(&enum_ptr[copied].value,

Neither can I, glanced over it while looking why the bisect pointed at this 
commit.

Reviewed-by: Maarten Lankhorst 

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

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Pekka Paalanen]

On Mon, 10 Apr 2017 12:12:01 +0200
Gerd Hoffmann  wrote:

> Ok, this is really a kickstart for a discussion.  While working on
> graphics support for virtual machines on ppc64 (which exists in both
> little and big endian variants) I've figured the comments in the header
> file don't match reality.  They are not considered little endian (as
> suggested by the comments) but in practice are used as native endian.
> 
> So, go update the comments.
> 
> This patch switches all 32bpp / 8 bpc formats over to native endian.
> Those used/supported by ppc64 virtual machines (virtio-gpu/bochs-drm
> drivers).
> 
> Given that DRM_FORMAT_BIG_ENDIAN isn't used anywhere in the codebase
> I suspect this problem applies to more formats.  When looking at
> drm_mode_legacy_fb_format it seems *all* RGB formats are actually
> native endian not little endian.
> 
> Dunno where we stand in terms of YCbCr.
> 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/uapi/drm/drm_fourcc.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

Hi,

which software have you used as representative of "reality"?

I worry is that there is potential to have endianess bugs in every
layer of the graphics stack: driver, Mesa, display servers,
compositors, toolkits, and applications. What's worse, two wrongs might
sometimes make a right - incorrectly swapping twice gives you what you
expected in the first place.

We just had a detailed review to get a new pixel format
definitions list in Weston right for LE vs. BE and Pixman vs. DRM vs.
OpenGL. We took the DRM definition literally to be always described in
LE regardless of machine endianess:
https://cgit.freedesktop.org/wayland/weston/commit/?id=903721a6215f474787b5daf02761fbcb1d3a0bb5

We also have this fun problem in Wayland:
https://lists.freedesktop.org/archives/wayland-devel/2017-March/033492.html

To solve that problem, we would like to know if anything existing would
break for each possible solution, but no developers using BE have really
turned up.

We have known for a long time that at least Weston is likely broken on
BE wrt. pixel formats.

We also have a bug for Mesa EGL/Wayland:
https://bugs.freedesktop.org/show_bug.cgi?id=99638

> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 995c8f9..a7fc81d 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -85,15 +85,15 @@ extern "C" {
>  #define DRM_FORMAT_BGR888fourcc_code('B', 'G', '2', '4') /* [23:0] B:G:R 
> little endian */
>  
>  /* 32 bpp RGB */
> -#define DRM_FORMAT_XRGB  fourcc_code('X', 'R', '2', '4') /* [31:0] 
> x:R:G:B 8:8:8:8 little endian */
> -#define DRM_FORMAT_XBGR  fourcc_code('X', 'B', '2', '4') /* [31:0] 
> x:B:G:R 8:8:8:8 little endian */
> -#define DRM_FORMAT_RGBX  fourcc_code('R', 'X', '2', '4') /* [31:0] 
> R:G:B:x 8:8:8:8 little endian */
> -#define DRM_FORMAT_BGRX  fourcc_code('B', 'X', '2', '4') /* [31:0] 
> B:G:R:x 8:8:8:8 little endian */
> +#define DRM_FORMAT_XRGB  fourcc_code('X', 'R', '2', '4') /* [31:0] 
> x:R:G:B 8:8:8:8 native endian */
> +#define DRM_FORMAT_XBGR  fourcc_code('X', 'B', '2', '4') /* [31:0] 
> x:B:G:R 8:8:8:8 native endian */
> +#define DRM_FORMAT_RGBX  fourcc_code('R', 'X', '2', '4') /* [31:0] 
> R:G:B:x 8:8:8:8 native endian */
> +#define DRM_FORMAT_BGRX  fourcc_code('B', 'X', '2', '4') /* [31:0] 
> B:G:R:x 8:8:8:8 native endian */
>  
> -#define DRM_FORMAT_ARGB  fourcc_code('A', 'R', '2', '4') /* [31:0] 
> A:R:G:B 8:8:8:8 little endian */
> -#define DRM_FORMAT_ABGR  fourcc_code('A', 'B', '2', '4') /* [31:0] 
> A:B:G:R 8:8:8:8 little endian */
> -#define DRM_FORMAT_RGBA  fourcc_code('R', 'A', '2', '4') /* [31:0] 
> R:G:B:A 8:8:8:8 little endian */
> -#define DRM_FORMAT_BGRA  fourcc_code('B', 'A', '2', '4') /* [31:0] 
> B:G:R:A 8:8:8:8 little endian */
> +#define DRM_FORMAT_ARGB  fourcc_code('A', 'R', '2', '4') /* [31:0] 
> A:R:G:B 8:8:8:8 native endian */
> +#define DRM_FORMAT_ABGR  fourcc_code('A', 'B', '2', '4') /* [31:0] 
> A:B:G:R 8:8:8:8 native endian */
> +#define DRM_FORMAT_RGBA  fourcc_code('R', 'A', '2', '4') /* [31:0] 
> R:G:B:A 8:8:8:8 native endian */
> +#define DRM_FORMAT_BGRA  fourcc_code('B', 'A', '2', '4') /* [31:0] 
> B:G:R:A 8:8:8:8 native endian */
>  
>  #define DRM_FORMAT_XRGB2101010   fourcc_code('X', 'R', '3', '0') /* 
> [31:0] x:R:G:B 2:10:10:10 little endian */
>  #define DRM_FORMAT_XBGR2101010   fourcc_code('X', 'B', '3', '0') /* 
> [31:0] x:B:G:R 2:10:10:10 little endian */

These format definitions are directly referenced by Wayland protocol
extension for dmabufs and Mesa (wl_drm), and they have been copied into
the Wayland core protocol for wl_shm. Changing their definition would
be... awkward.


Thanks,
pq


pgpqmpt0qpcLB.pgp
Description: OpenPGP digital signature
___
dri-devel mailing

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings (v4.11-rc5-1807-g777f8b443ed1)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings 
(v4.11-rc5-1807-g777f8b443ed1)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1807-g777f8b443ed1/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1807-g777f8b443ed1
Git Commit: 777f8b443ed1aa6c045ed923ba7e5d65f8ea6e1c
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failure Detected:

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig+CONFIG_OF=n: FAIL

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1339

Re: [PATCH 1/2] drm: Add DRM_CAP_PRIME_SCANOUT.

[Alex Deucher]

On Mon, Apr 10, 2017 at 5:03 AM, Christian König
 wrote:
> Am 10.04.2017 um 10:52 schrieb Michel Dänzer:
>>
>> On 05/04/17 08:21 PM, Christian König wrote:
>>>
>>> Am 05.04.2017 um 13:13 schrieb Christopher James Halse Rogers:

 On Wed, Apr 5, 2017 at 8:14 PM Lucas Stach >>> > wrote:

  Am Mittwoch, den 05.04.2017, 11:59 +0200 schrieb Daniel Vetter:
  > On Wed, Apr 05, 2017 at 10:15:44AM +0200, Lucas Stach wrote:
  > > Am Mittwoch, den 05.04.2017, 00:20 + schrieb Christopher
  James Halse
  > > Rogers:
  > > >
  > > >
  > > > On Tue, Apr 4, 2017 at 9:53 PM Daniel Vetter
  mailto:dan...@ffwll.ch>> wrote:
  > > >
  > > > On Tue, Apr 4, 2017 at 12:43 PM, Lucas Stach
  > > > >>>  > wrote:
  > > > >> If I could guarantee that I'd only ever run on
  > > > 4.13-or-later kernels
  > > > >> (I think that's when the previous patches will
  land?), then
  > > > this would
  > > > >> indeed be mostly unnecessary. It would save me a
  bunch of
  > > > addfb calls
  > > > >> that would predictably fail, but they're cheap.
  > > > >
  > > > > I don't think we ever had caps for "things are
  working now,
  > > > as they are
  > > > > supposed to". i915 wasn't properly synchronizing
  on foreign
  > > > fences for a
  > > > > long time, yet we didn't gain a cap for "cross
  device sync
  > > > works now".
  > > > >
  > > > > If your distro use-case relies on those things
  working it's
  > > > probably
  > > > > best to just backport the relevant fixes.
  > > >
  > > > The even better solution for this is to push the
  backports
  > > > through
  > > > upstream -stable kernels. This stuff here is simple
  enough
  > > > that we can
  > > > do it. Same could have been done for the fairly
 minimal
  > > > fencing fixes
  > > > for i915 (at least some of them, the ones in the
  page-flip).
  > > >
  > > > Otherwise we'll end up with tons IM_NOT_BUGGY and
  > > > IM_SLIGHTLY_LESS_BUGGY and
  > > > IM_NOT_BUGGY_EXCEPT_THIS_BOTCHED_BACKPORT
  > > > flags where no one at all knows what they mean,
  usage between
  > > > different drivers and different userspace is entirely
  > > > inconsistent and
  > > > they just all add to the confusion. They're just
  bugs, lets
  > > > treat them
  > > > like that.
  > > >
  > > >
  > > > It's not *quite* DRM_CAP_PRIME_SCANOUT_NOT_BUGGY - while the
  relevant
  > > > hardware allegedly supports it, nouveau/radeon/amdgpu don't
  do scanout
  > > > of GTT, so the lack of this cap indicates that there's no
  point in
  > > > trying to call addfb2.
  > > >
  > > >
  > > > But calling addfb2 and it failing is not expensive, so this
  is rather
  > > > niche.
  > > >
  > > >
  > > > In practice I can just restrict attempting to scanout of
  imported
  > > > buffers to i915, as that's the only driver that it'll work
  on. By the
  > > > time nouveau/radeon/amdgpu get patches to scanout of GTT the
  fixes
  > > > should be old enough that I don't need to care about unfixed
  kernels.
  > > >
  > > So given that most discreet hardware won't ever be able to
  scanout from
  > > GTT (latency and iso requirements will be hard to meet), can't
  we just
  > > fix the case of the broken prime sharing when migrating to
 VRAM?


 At least some nouveau and AMD devs seem to think that their hardware
 is capable of doing it. Shrug.
>>>
>>> Wow, wait a second. Recent AMD GPU can scanout from system memory,
>>> that's true.
>>
>> Even discrete GPUs, or only APUs?
>
>
> Good question. The crux is that you need to match certain bandwith and
> latency limitations or otherwise you get a flickering picture.
>
> If I understood the documentation correctly that should even work with dGPUs
> in theory, but nobody is testing/validating this.
>
> Long story short I wouldn't try it without feedback from the hardware/DC
> guys. They are the designated experts for this.

It's only been validated on APUs.

Alex


>
> Regards,
> Christian.
>
>

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Gerd Hoffmann]

  Hi,

> which software have you used as representative of "reality"?

ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
driver.  Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and
only format supported by bochs-drm), and we have to interpret that in
bigendian byte order on the host side to get a correct display.

Didn't try wayland.  Can do, but will take a while.  Don't have a
wayland-capable guest install at hand, and installing one takes a while
because I don't have a physical pseries and emulation is slww.

> To solve that problem, we would like to know if anything existing would
> break for each possible solution, but no developers using BE have really
> turned up.

That is part of the problem.
And even ppc is moving to little endian these days ...

cheers,
  Gerd

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

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Mon, Apr 10, 2017 at 10:17 AM, Gerd Hoffmann  wrote:
>   Hi,
>
>> which software have you used as representative of "reality"?
>
> ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
> driver.  Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and
> only format supported by bochs-drm), and we have to interpret that in
> bigendian byte order on the host side to get a correct display.
>
> Didn't try wayland.  Can do, but will take a while.  Don't have a
> wayland-capable guest install at hand, and installing one takes a while
> because I don't have a physical pseries and emulation is slww.
>
>> To solve that problem, we would like to know if anything existing would
>> break for each possible solution, but no developers using BE have really
>> turned up.
>
> That is part of the problem.
> And even ppc is moving to little endian these days ...

The poor saps who are still using PPC G4's and G5's with NVIDIA and
ATI boards constantly get their working setups broken by people trying
to "fix" BE. I think it's important to keep them in mind, and test
those setups, whenever one tries to make a large sweeping change.

Cheers,

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

[PATCH] MAINTAINERS: add drm/sti driver into drm-misc

[Vincent Abriou]

drm/sti driver is now part of drm-misc as a small driver.

Signed-off-by: Vincent Abriou 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4ea82b2..66b424a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4417,7 +4417,7 @@ DRM DRIVERS FOR STI
 M: Benjamin Gaignard 
 M: Vincent Abriou 
 L: dri-devel@lists.freedesktop.org
-T: git http://git.linaro.org/people/benjamin.gaignard/kernel.git
+T: git git://anongit.freedesktop.org/drm/drm-misc
 S: Maintained
 F: drivers/gpu/drm/sti
 F: Documentation/devicetree/bindings/display/st,stih4xx.txt
-- 
2.7.4

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

[Bug 100618] Dead Island crash after starting a new game

[bugzilla-daemon]

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

--- Comment #5 from at...@t-online.de ---
Created attachment 130779
  --> https://bugs.freedesktop.org/attachment.cgi?id=130779&action=edit
gdb backtrace after crash

I'm not familiar with gdb, so I'm not sure if I did what you were asking for. I
started the game with "DEBUGGER=gdb steam steam://rungameid/91310", continued
till the game crashes, typed backtrace and copied the output.

-- 
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: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Pekka Paalanen]

On Mon, 10 Apr 2017 16:17:27 +0200
Gerd Hoffmann  wrote:

>   Hi,
> 
> > which software have you used as representative of "reality"?  
> 
> ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
> driver.  Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and
> only format supported by bochs-drm), and we have to interpret that in
> bigendian byte order on the host side to get a correct display.

I wonder if that is just an oversight from trying to match OpenGL
formats to DRM formats. It's full of gotcha's.

Did you try with GLAMOR? Do you see a difference with and without
GLAMOR? Hmm, but you have no GPU support, so GLAMOR would be through a
Mesa software renderer? I think I heard someone say something about
Mesa software on BE...

But even if this actually is a valid example of software we must keep
working as is, well, ouch. But if I cannot show that your fix breaks
anything, then I suppose you win. Your proposal would certainly solve
the dilemma we have with wl_shm formats in Wayland.

I also wonder if a real BE machine could have different results than
the virtual machine.


Thanks,
pq

> Didn't try wayland.  Can do, but will take a while.  Don't have a
> wayland-capable guest install at hand, and installing one takes a while
> because I don't have a physical pseries and emulation is slww.
> 
> > To solve that problem, we would like to know if anything existing would
> > break for each possible solution, but no developers using BE have really
> > turned up.  
> 
> That is part of the problem.
> And even ppc is moving to little endian these days ...
> 
> cheers,
>   Gerd
> 



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

Re: [PATCHv3 17/22] staging: android: ion: Collapse internal header files

[Laura Abbott]

On 04/08/2017 11:12 AM, Emil Velikov wrote:
> Hi Laura,
> 
> Couple of trivial nitpicks below.
> 
> On 3 April 2017 at 19:57, Laura Abbott  wrote:
> 
>> --- a/drivers/staging/android/ion/ion.h
>> +++ b/drivers/staging/android/ion/ion.h
>> @@ -1,5 +1,5 @@
>>  /*
>> - * drivers/staging/android/ion/ion.h
>> + * drivers/staging/android/ion/ion_priv.h
> Does not match the actual filename.
> 
>>   *
>>   * Copyright (C) 2011 Google, Inc.
>>   *
>> @@ -14,24 +14,26 @@
>>   *
>>   */
>>
>> -#ifndef _LINUX_ION_H
>> -#define _LINUX_ION_H
>> +#ifndef _ION_PRIV_H
>> +#define _ION_PRIV_H
>>
> Ditto.
> 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>>  #include 
>> +#include 
>>
>>  #include "../uapi/ion.h"
>>
> You don't want to use "../" in includes. Perhaps address with another
> patch, if you haven't already ?
> 

There isn't a better option until this driver moves out of staging.
Once it moves out it can be fixed up.

Thanks,
Laura

> Regards,
> Emil
> 

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

drm-tip/drm-tip boot: 114 boots: 4 failed, 108 passed with 2 offline (v4.11-rc5-1806-g02f6d3e01f3e)

[kernelci . org bot]

drm-tip/drm-tip boot: 114 boots: 4 failed, 108 passed with 2 offline 
(v4.11-rc5-1806-g02f6d3e01f3e)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1806-g02f6d3e01f3e/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1806-g02f6d3e01f3e/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1806-g02f6d3e01f3e
Git Commit: 02f6d3e01f3e1b6b91efeaceabd24e36e0540b49
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 17 unique boards, 10 SoC families, 27 builds out of 207

Boot Regressions Detected:

arm:

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
exynos5422-odroidxu3:
lab-collabora: new failure (last pass: v4.11-rc5-1803-gd86f5fa557fd)

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

arm:

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
exynos5422-odroidxu3: 1 failed lab

Offline Platforms:

x86:

allmodconfig:
minnowboard-max: 1 offline lab

allmodconfig+CONFIG_OF=n:
minnowboard-max: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100618] Dead Island crash after starting a new game

[bugzilla-daemon]

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

at...@t-online.de changed:

   What|Removed |Added

 Attachment #130779|0   |1
is obsolete||

--- Comment #6 from at...@t-online.de ---
Created attachment 130781
  --> https://bugs.freedesktop.org/attachment.cgi?id=130781&action=edit
gdb backtrace from dead island after crash

The first file seems to be only gdb backtrace of steam. So I tried to use "gdb
--pid=" and this looks like I got gdb running with the game. Hope this
helps.

-- 
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: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen  wrote:
> On Mon, 10 Apr 2017 16:17:27 +0200
> Gerd Hoffmann  wrote:
>
>>   Hi,
>>
>> > which software have you used as representative of "reality"?
>>
>> ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
>> driver.  Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and
>> only format supported by bochs-drm), and we have to interpret that in
>> bigendian byte order on the host side to get a correct display.
>
> I wonder if that is just an oversight from trying to match OpenGL
> formats to DRM formats. It's full of gotcha's.
>
> Did you try with GLAMOR? Do you see a difference with and without
> GLAMOR? Hmm, but you have no GPU support, so GLAMOR would be through a
> Mesa software renderer? I think I heard someone say something about
> Mesa software on BE...
>
> But even if this actually is a valid example of software we must keep
> working as is, well, ouch. But if I cannot show that your fix breaks
> anything, then I suppose you win. Your proposal would certainly solve
> the dilemma we have with wl_shm formats in Wayland.
>
> I also wonder if a real BE machine could have different results than
> the virtual machine.

I have a PPC G5 with an AGP GeForce FX 5200 that I can test things on,
if necessary. (I got it specifically for this purpose, as the people
who use this type of hw daily tend to perform updates rarely... in no
small part due to the fact that updates tend to break the HW.)

Just let know what you need tested, I should be able to turn it around
within a couple of days.

Cheers,

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

Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging

[Laura Abbott]

On 04/08/2017 03:38 AM, Greg Kroah-Hartman wrote:
> On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote:
>> Hi,
>>
>> This is v3 of the series to do some serious Ion cleanup in preparation for
>> moving out of staging. I didn't hear much on v2 so I'm going to assume
>> people are okay with the series as is. I know there were still some open
>> questions about moving away from /dev/ion but in the interest of small
>> steps I'd like to go ahead and merge this series assuming there are no more
>> major objections. More work can happen on top of this.
> 
> I've applied patches 3-11 as those were independant of the CMA changes.
> I'd like to take the rest, including the CMA changes, but I need an ack
> from someone dealing with the -mm tree before I can do that.
> 
> Or, if they just keep ignoring it, I guess I can take them :)
> 
> thanks,
> 
> greg k-h
> 

Thanks. I'll send out some nag e-mails asking for Acks. If I don't get
any, I'll resend the rest of the series after the 4.12 merge window.

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

Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging

[Greg Kroah-Hartman]

On Mon, Apr 10, 2017 at 09:20:27AM -0700, Laura Abbott wrote:
> On 04/08/2017 03:38 AM, Greg Kroah-Hartman wrote:
> > On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote:
> >> Hi,
> >>
> >> This is v3 of the series to do some serious Ion cleanup in preparation for
> >> moving out of staging. I didn't hear much on v2 so I'm going to assume
> >> people are okay with the series as is. I know there were still some open
> >> questions about moving away from /dev/ion but in the interest of small
> >> steps I'd like to go ahead and merge this series assuming there are no more
> >> major objections. More work can happen on top of this.
> > 
> > I've applied patches 3-11 as those were independant of the CMA changes.
> > I'd like to take the rest, including the CMA changes, but I need an ack
> > from someone dealing with the -mm tree before I can do that.
> > 
> > Or, if they just keep ignoring it, I guess I can take them :)
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Thanks. I'll send out some nag e-mails asking for Acks. If I don't get
> any, I'll resend the rest of the series after the 4.12 merge window.

Why so long?  This series has been sent a bunch, if no one responds in a
week, I'll be glad to take them all in my tree :)

thanks,

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

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Alex Deucher]

On Mon, Apr 10, 2017 at 10:45 AM, Ilia Mirkin  wrote:
> On Mon, Apr 10, 2017 at 10:17 AM, Gerd Hoffmann  wrote:
>>   Hi,
>>
>>> which software have you used as representative of "reality"?
>>
>> ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
>> driver.  Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and
>> only format supported by bochs-drm), and we have to interpret that in
>> bigendian byte order on the host side to get a correct display.
>>
>> Didn't try wayland.  Can do, but will take a while.  Don't have a
>> wayland-capable guest install at hand, and installing one takes a while
>> because I don't have a physical pseries and emulation is slww.
>>
>>> To solve that problem, we would like to know if anything existing would
>>> break for each possible solution, but no developers using BE have really
>>> turned up.
>>
>> That is part of the problem.
>> And even ppc is moving to little endian these days ...
>
> The poor saps who are still using PPC G4's and G5's with NVIDIA and
> ATI boards constantly get their working setups broken by people trying
> to "fix" BE. I think it's important to keep them in mind, and test
> those setups, whenever one tries to make a large sweeping change.

I think part of the problem is that the higher levels of the stack
have different expectations than the kernel does.  Mesa breaks every
time someone fixes something endian related.  Most userspace stuff
assumes host endianness.  Someone that has the hw and cares about BE
should really audit the stack top to bottom and make sure all the
expectations are met for each level.  I doubt anyone will.

Alex

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

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Alex Deucher]

On Mon, Apr 10, 2017 at 8:02 AM, Daniel Vetter  wrote:
> On Mon, Apr 10, 2017 at 12:12:01PM +0200, Gerd Hoffmann wrote:
>> Ok, this is really a kickstart for a discussion.  While working on
>> graphics support for virtual machines on ppc64 (which exists in both
>> little and big endian variants) I've figured the comments in the header
>> file don't match reality.  They are not considered little endian (as
>> suggested by the comments) but in practice are used as native endian.
>>
>> So, go update the comments.
>>
>> This patch switches all 32bpp / 8 bpc formats over to native endian.
>> Those used/supported by ppc64 virtual machines (virtio-gpu/bochs-drm
>> drivers).
>>
>> Given that DRM_FORMAT_BIG_ENDIAN isn't used anywhere in the codebase
>> I suspect this problem applies to more formats.  When looking at
>> drm_mode_legacy_fb_format it seems *all* RGB formats are actually
>> native endian not little endian.
>>
>> Dunno where we stand in terms of YCbCr.
>>
>> Cc: Ville Syrjälä 
>> Cc: Daniel Vetter 
>> Cc: amd-...@lists.freedesktop.org
>> Signed-off-by: Gerd Hoffmann 
>
> I think we should go all-in on this and essentially remove the _BIG_ENDIAN
> stuff. But in the end this is to be decided be the people who care about
> big endian, afaik that's only you (for the pile of virt drivers we have)
> and amdgpu/radeon.

For radeon/amdgpu, we try to be good endian citizens when writing the
code, but as far as testing and support, it's all LE.  For a lot of hw
blocks, the surface format is the least of your worries.

Alex

> -Daniel
>
>> ---
>>  include/uapi/drm/drm_fourcc.h | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>> index 995c8f9..a7fc81d 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -85,15 +85,15 @@ extern "C" {
>>  #define DRM_FORMAT_BGR888fourcc_code('B', 'G', '2', '4') /* [23:0] 
>> B:G:R little endian */
>>
>>  /* 32 bpp RGB */
>> -#define DRM_FORMAT_XRGB  fourcc_code('X', 'R', '2', '4') /* [31:0] 
>> x:R:G:B 8:8:8:8 little endian */
>> -#define DRM_FORMAT_XBGR  fourcc_code('X', 'B', '2', '4') /* [31:0] 
>> x:B:G:R 8:8:8:8 little endian */
>> -#define DRM_FORMAT_RGBX  fourcc_code('R', 'X', '2', '4') /* [31:0] 
>> R:G:B:x 8:8:8:8 little endian */
>> -#define DRM_FORMAT_BGRX  fourcc_code('B', 'X', '2', '4') /* [31:0] 
>> B:G:R:x 8:8:8:8 little endian */
>> +#define DRM_FORMAT_XRGB  fourcc_code('X', 'R', '2', '4') /* [31:0] 
>> x:R:G:B 8:8:8:8 native endian */
>> +#define DRM_FORMAT_XBGR  fourcc_code('X', 'B', '2', '4') /* [31:0] 
>> x:B:G:R 8:8:8:8 native endian */
>> +#define DRM_FORMAT_RGBX  fourcc_code('R', 'X', '2', '4') /* [31:0] 
>> R:G:B:x 8:8:8:8 native endian */
>> +#define DRM_FORMAT_BGRX  fourcc_code('B', 'X', '2', '4') /* [31:0] 
>> B:G:R:x 8:8:8:8 native endian */
>>
>> -#define DRM_FORMAT_ARGB  fourcc_code('A', 'R', '2', '4') /* [31:0] 
>> A:R:G:B 8:8:8:8 little endian */
>> -#define DRM_FORMAT_ABGR  fourcc_code('A', 'B', '2', '4') /* [31:0] 
>> A:B:G:R 8:8:8:8 little endian */
>> -#define DRM_FORMAT_RGBA  fourcc_code('R', 'A', '2', '4') /* [31:0] 
>> R:G:B:A 8:8:8:8 little endian */
>> -#define DRM_FORMAT_BGRA  fourcc_code('B', 'A', '2', '4') /* [31:0] 
>> B:G:R:A 8:8:8:8 little endian */
>> +#define DRM_FORMAT_ARGB  fourcc_code('A', 'R', '2', '4') /* [31:0] 
>> A:R:G:B 8:8:8:8 native endian */
>> +#define DRM_FORMAT_ABGR  fourcc_code('A', 'B', '2', '4') /* [31:0] 
>> A:B:G:R 8:8:8:8 native endian */
>> +#define DRM_FORMAT_RGBA  fourcc_code('R', 'A', '2', '4') /* [31:0] 
>> R:G:B:A 8:8:8:8 native endian */
>> +#define DRM_FORMAT_BGRA  fourcc_code('B', 'A', '2', '4') /* [31:0] 
>> B:G:R:A 8:8:8:8 native endian */
>>
>>  #define DRM_FORMAT_XRGB2101010   fourcc_code('X', 'R', '3', '0') /* 
>> [31:0] x:R:G:B 2:10:10:10 little endian */
>>  #define DRM_FORMAT_XBGR2101010   fourcc_code('X', 'B', '3', '0') /* 
>> [31:0] x:B:G:R 2:10:10:10 little endian */
>> --
>> 2.9.3
>>
>> ___
>> 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
> ___
> 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

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 204 warnings (v4.11-rc5-1808-ge461ecfd413f)

[kernelci . org bot]

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 204 warnings 
(v4.11-rc5-1808-ge461ecfd413f)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1808-ge461ecfd413f/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1808-ge461ecfd413f
Git Commit: e461ecfd413fb930d00f44f3de0019e528b4731f
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  drivers/tty/vt/keyboard.c:14

[Bug 100646] System hang on Mullins hardware with Linux 4.11-rc6

[bugzilla-daemon]

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

Bug ID: 100646
   Summary: System hang on Mullins hardware with Linux 4.11-rc6
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: gamwiz...@gmail.com

Created attachment 130783
  --> https://bugs.freedesktop.org/attachment.cgi?id=130783&action=edit
dmesg including xorg log

Using the 4.11-rc6 kernel on Mullins based laptop crashes xorg and hangs the
system. Changing to a vt doesn't work but rebooting works with sysrq. I tried
rc5, but the same happens there. Amdgpu works on my system with 4.10.

Attached is the dmesg log including the xorg log and crash. There is also a
kernel oops message present in the log.


xorg 1.19.3
mesa git

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

drm-tip/drm-tip boot: 137 boots: 5 failed, 131 passed with 1 offline (v4.11-rc5-1807-g777f8b443ed1)

[kernelci . org bot]

drm-tip/drm-tip boot: 137 boots: 5 failed, 131 passed with 1 offline 
(v4.11-rc5-1807-g777f8b443ed1)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1807-g777f8b443ed1/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1807-g777f8b443ed1/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1807-g777f8b443ed1
Git Commit: 777f8b443ed1aa6c045ed923ba7e5d65f8ea6e1c
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 18 unique boards, 10 SoC families, 26 builds out of 207

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

x86:

allnoconfig
minnowboard-max: 1 failed lab

tinyconfig
minnowboard-max: 1 failed lab

allmodconfig+CONFIG_OF=n
minnowboard-max: 1 failed lab

arm:

multi_v7_defconfig+CONFIG_SMP=n
exynos5250-snow: 1 failed lab

Offline Platforms:

x86:

allmodconfig:
minnowboard-max: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Fix get_property logic fumble

[Sean Paul]

On Mon, Apr 10, 2017 at 01:54:45PM +0200, Daniel Vetter wrote:
> Yet again I've proven that I can't negate conditions :(
> 
> Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 

Reviewed-by: Sean Paul 

> Reported-by: Tvrtko Ursulin 
> Cc: Tvrtko Ursulin 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_property.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index 3feef0659940..3e88fa24eab3 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -476,7 +476,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
>   drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
>   list_for_each_entry(prop_enum, &property->enum_list, head) {
>   enum_count++;
> - if (out_resp->count_enum_blobs <= enum_count)
> + if (out_resp->count_enum_blobs < enum_count)
>   continue;
>  
>   if (copy_to_user(&enum_ptr[copied].value,
> -- 
> 2.11.0

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging

[Laura Abbott]

On 04/10/2017 09:25 AM, Greg Kroah-Hartman wrote:
> On Mon, Apr 10, 2017 at 09:20:27AM -0700, Laura Abbott wrote:
>> On 04/08/2017 03:38 AM, Greg Kroah-Hartman wrote:
>>> On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote:
 Hi,

 This is v3 of the series to do some serious Ion cleanup in preparation for
 moving out of staging. I didn't hear much on v2 so I'm going to assume
 people are okay with the series as is. I know there were still some open
 questions about moving away from /dev/ion but in the interest of small
 steps I'd like to go ahead and merge this series assuming there are no more
 major objections. More work can happen on top of this.
>>>
>>> I've applied patches 3-11 as those were independant of the CMA changes.
>>> I'd like to take the rest, including the CMA changes, but I need an ack
>>> from someone dealing with the -mm tree before I can do that.
>>>
>>> Or, if they just keep ignoring it, I guess I can take them :)
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>
>> Thanks. I'll send out some nag e-mails asking for Acks. If I don't get
>> any, I'll resend the rest of the series after the 4.12 merge window.
> 
> Why so long?  This series has been sent a bunch, if no one responds in a
> week, I'll be glad to take them all in my tree :)
> 
> thanks,
> 
> greg k-h
> 

Ideally I'd like some confirmation that at least someone other than
myself thinks it's a good idea but I know mm review bandwidth has
been a topic of discussion so maybe silence is the best I can get.
If you pick it up and nobody objects, I guess I won't object either :)

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

[Bug 195231] Continuous messages of "*ERROR* UVD not responding, trying to reset the VCPU!!!" and frozen screen

[bugzilla-daemon]

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

--- Comment #12 from rbr...@gmail.com ---
Dear Alex, Christian and others,

On Mon, Apr 10, 2017 at 3:50 AM,   wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=195231
> --- Comment #11 from Christian König (deathsim...@vodafone.de) ---
> Well bisecting which patch caused the break would be a good idea.

First of all, I hope you don't mind that I'm including my mom here, so
that she can follow how her computer is doing, or, rather, what I am
doing with her computer.

> To start that I suggest you try to compile kernel 4.4 by yourself first.
>
> That should also yield a temporary solution until we can narrow down the root
> cause.

I tried using Ubuntu's unpatched/precompiled kernels 4.2, 4.4, 4.8,
4.10 and 4.11-rc5 and, apparently, they now always show this message
*and* it frequently freezes to the point that no magic Sysrq keys
work, sometimes the caps lock kernel blinks and so on.

Booting with radeon.modeset=0 allows the computer to boot to the
desktop environment, but makes the CPU so hot when she plays her
flashplayer-based games that the kernel shows many messages of thermal
limit being reached and CPU speed being throttled.

Booting with radeon.runpm=0 still gets me all the error messages
listed in the subject (and present in the logs that I sent to
bugzilla), but the temperature *seems* to be slightly lower (not
enough testing was done with this configuration).

I don't know how to see/check what GPU is being used at a given time:
if the Intel GPU or if the AMD GPU...

So, given that the problem now seems to be present with all those
kernel versions that I tested, is it worthwhile to compile my own
kernels?

As before, I will try to do whatever I'm directed to.


Thanks a lot,

Rogério.

-- 
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: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Mario Kleiner]

On 04/04/2017 06:48 PM, Keith Packard wrote:

Daniel Vetter  writes:


Yeah I think that's a pretty neat idea to reduce the lease complexity even
more. If the VR compositor is unhappy and wants a different mode, it can
simply nuke the lease and as for a new one. Forgot to say that :-)


Not sure it changes the lease complexity, but it reduces the potential
interference with the X server after the lease is created.

Hrm. Thinking about the impact on X a bit more, this seems hard - you
can't just display the root window in the HMD, so you need a frame
buffer to use. The VR compositor can construct this knowing the planned
X mode, but, we then have to wire it through the whole X mode set
infrastructure, which is not exactly set up to do that.

I'll go look at the code in more detail, but I suspect the easiest
plan will be to have the VR compositor set its own mode. That may fail
if X is consuming too many display resources, but that doesn't seem
significantly different from having the lease fail.

This doesn't change the kernel API at all, so we can figure out the X
bits separately from the kernel bits.



Hi,

as input from a highly interested future user of such api's:

An additional use case beyond VR compositors, at least highly valuable 
for my kind of apps (= neuroscience / vision science / medical research 
toolkits) would be to get fullscreen exclusive control over regular 
outputs / displays. My use cases run about 98% of the time in fullscreen 
exclusive mode and want as little interference from the windowing system 
/ desktop environment as possible, with as much low level control as 
possible. It still needs windowed mode for same cases and needs a 
windowing system up and running.


Atm. under X i have to hope that fullscreen unredirection works to get 
me page flipping for single display monoscopic stimulation and 
dual-display stereoscopic stuff. And then there's the popular "Regular 
desktop GUI for interaction" + separate displays for "fullscreen + page 
flipping for controlled presentation" case.


Atm. i have to use custom xorg.confs + dual/multi-x-screen + 
ZaphodHeads, a static configuration with all the logout/login dance / no 
display hotplug for configuration change. Workable under X (minus the 
occasional ZaphodHeads corner case bugs), but somewhat clunky.


So if this would give me a plug & play dynamic replacement for 
ZaphodHeads and xorg.conf fiddling that would be _very_ valuable.


The RRCreateLease requests looks as if i could get that for regular 
non-HMD video outputs as well?


And the RRCreateOutputGrab would be mostly to avoid flicker when 
plugging HMD's or other special purpose devices, but wouldn't be 
strictly needed for a regular X-client to get a lease on a set of outputs?


As far as controllable properties on a lease go, i'd find it very useful 
if i could have control over framebuffer formats, e.g., being able to 
select 10 bit scanout formats would be very useful, but is afaik 
something that X currently doesn't expose with most drivers, especially 
not for regular desktop mode.


Set/Get Gamma tables, dithering properties, other output properties, 
modesetting would be also important. On X i can do that via RandR, but 
in the Wayland world, much of this stuff is afaik often restricted to 
privileged clients or proprietary per-compositor protocols. That's a big 
upcoming problem for me in the Wayland world, and lease support could be 
a very good solution for me.


If the underlying DRM leases allow me to control this stuff, and Wayland 
would gain similar extensions to lease outputs for fullscreen exclusive 
control, i could have one drm/kms backend that can be mostly agnostic of 
X vs. Wayland / different Wayland compositor flavors.


Basically my vote to expose as much flexility in modesetting / 
properties for the exposed leases as possible on the kernel and X side.


thanks,
-mario




___
xorg-de...@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel


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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Keith Packard]

Mario Kleiner  writes:

> as input from a highly interested future user of such api's:

Thanks much for taking a look at this.

> My use cases run about 98% of the time in fullscreen 
> exclusive mode and want as little interference from the windowing system 
> / desktop environment as possible, with as much low level control as 
> possible. It still needs windowed mode for same cases and needs a 
> windowing system up and running.

The new APIs can give you exclusive access to the display resources,
bypassing the window system entirely.

> Atm. under X i have to hope that fullscreen unredirection works to get 
> me page flipping for single display monoscopic stimulation and 
> dual-display stereoscopic stuff. And then there's the popular "Regular 
> desktop GUI for interaction" + separate displays for "fullscreen + page 
> flipping for controlled presentation" case.

You're still depending on the window system server for timely page flips
though; the main reason we're doing the leasing work is to get that
variable out of the equation, eliminating any window system scheduling
jitter from the regular screen updates on the HMD.

> The RRCreateLease requests looks as if i could get that for regular 
> non-HMD video outputs as well?

Yes, there's almost no way we could restrict it even if we wanted
to. I'm doing testing with two standard monitors, but any hardware at
all will work.

> And the RRCreateOutputGrab would be mostly to avoid flicker when 
> plugging HMD's or other special purpose devices, but wouldn't be 
> strictly needed for a regular X-client to get a lease on a set of
> outputs?

Yes, just to avoid having the desktop extend itself onto the HMD, even
briefly. The two components of the RandR changes are logically separate,
but should be useful in combination when using HMD displays.

> As far as controllable properties on a lease go, i'd find it very useful 
> if i could have control over framebuffer formats, e.g., being able to 
> select 10 bit scanout formats would be very useful, but is afaik 
> something that X currently doesn't expose with most drivers, especially 
> not for regular desktop mode.

You have the full KMS api at your disposal; do whatever you like :-)

> If the underlying DRM leases allow me to control this stuff, and Wayland 
> would gain similar extensions to lease outputs for fullscreen exclusive 
> control, i could have one drm/kms backend that can be mostly agnostic of 
> X vs. Wayland / different Wayland compositor flavors.

Right, that's another benefit here -- allowing HMD applications to be largely
window system independent, except for acquiring the initial lease.

> Basically my vote to expose as much flexility in modesetting / 
> properties for the exposed leases as possible on the kernel and X
> side.

I'll have a second cut of the kernel API changes ready in another day or
so; that will eliminate the ability to change an existing lease, so
you'll have to acquire all of the resources you need all at
once. Otherwise, it will look quite similar at the user API level.

The RandR protocol changes will also need another spin; it sounds like
we want to configure the set of 'special' monitors and have those never
reported as connected via the current API. I don't think that will
affect your use case at all, and the other part of the protocol for
creating a lease won't change.

-- 
-keith


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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Alex Deucher]

On Tue, Apr 4, 2017 at 3:02 AM, Daniel Vetter  wrote:
> On Mon, Apr 03, 2017 at 03:50:33PM -0700, Keith Packard wrote:
>> Daniel Vetter  writes:
>>
>> > Also if this confuses VR, then another reason why we want to make leases
>> > invariant and only allow pure revoke, not changing the list.
>>
>> I'm not sure why you want this to be asymmetrical, nor why you would
>> expect lessees to be any more competent at dealing with hotplug than the
>> lessor.
>>
>> One use case already proposed for this API was to allow for multi-seat,
>> where the lessee would be an existing window system, which we already
>> accept as being incompetent at dealing with resource hotplug. I imagine
>> that in this case, a newly plugged monitor would be detected by the
>> multi-seat manager (logind?) and added to one of the existing leases,
>> along with a suitable CRTC resource. For this to work, the lessee will
>> need to already know about those resources and only have their
>> connectivity status hidden.
>
> The multi-seat thing sounds like vapourware, I think we should care about
> the vr use-case for now, and only that one. And for that restricting stuff
> is perfectly fine. Of course we can design the entire thing in a way that
> doesn't draw us into a corner in the future right away, but that's mostly
> on the implementation side. For VR itself I'd go as far as saying that
> probably our "create lease" ioctl should have only the semantics we need
> to pass one crtc+primary plane for pageflipping in a VR compositor,
> expressed in a flag. All the details about additional corner cases are
> just so unclear to me (and there's not even a clear use case that will
> materialize) that I don't think having the uapi is worth it. Too close to
> the "I'll regret this immediately" bucket :-)
>

I don't know about vaprware.  There were a number of attempts to
provide static allocation if display resources over the years to solve
things like custom zaphod configs and users wanting to use multiple
heads for separate users (which currently ends up in various zephyr
hacks IRC).  Lots of patches were proposed, none landed.  I think
there is a definite use case there.  Why do we need to make X aware of
the lease stuff?  What about having some pre-X configuration that
decides how to split up the display resources.  It could be user
defined static or dynamic based on what is attached.  You can just
start X on the device nodes with whatever resources they are assigned.
In the multi-user case, you can statically assign resources to each
node; in the VR case, you can detect the HMD and automatically assign
it's resources to a separate node or override if necessary.

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

[Bug 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)

[bugzilla-daemon]

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

--- Comment #24 from Julien Isorce  ---
Does the test
wget
http://www.phoronix-test-suite.com/benchmark-files/GpuTest_Linux_x64_0.7.0.zip
DISPLAY=:0 ./GpuTest /test=fur /fullscreen

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

Re: [PATCH v6 0/2] drm: rockchip: Fix rockchip drm unbind crash error

[Sean Paul]

On Mon, Apr 10, 2017 at 06:00:43PM +0800, Jeffy Chen wrote:

Hi Jeffy,
Thanks for sending this up again.

> 
> Verified on rk3399 chromebook kevin, no more crashes during unbind/bind drm.

I'm assuming this is on the chromeos-4.4 kernel? If so, you should probably
mention that when you're posting upstream.

Sean


> 
> Changes in v6:
> Address Daniel Vetter 's comments.
> 
> Changes in v5:
> Fix wrong git account.
> 
> Changes in v2:
> Fix some commit messages.
> 
> Jeffy Chen (2):
>   drm: Unplug drm device when unregistering it
>   drm: Prevent release fb after cleanup mode config
> 
>  drivers/gpu/drm/drm_drv.c | 6 +++---
>  drivers/gpu/drm/drm_framebuffer.c | 5 +
>  drivers/gpu/drm/udl/udl_drv.c | 2 +-
>  include/drm/drmP.h| 6 ++
>  4 files changed, 15 insertions(+), 4 deletions(-)
> 
> -- 
> 2.1.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: panels: Add MAINTAINERS entry for LVS panel driver

[Dave Airlie]

On 10 April 2017 at 19:03, Laurent Pinchart
 wrote:
> Hi Thierry,
>
> On Monday 10 Apr 2017 09:17:59 Thierry Reding wrote:
>> On Sun, Apr 09, 2017 at 01:31:40PM +0100, Emil Velikov wrote:
>> > Hi Thierry,
>> >
>> > I don't mean to stir up anything, just voicing "my 2c" as they say.
>> >
>> > On 7 April 2017 at 18:33, Thierry Reding  wrote:
>> > > Ever since the simple-panel binding was introduced, which is now about
>> > > 3 1/2 years ago,
>> >
>> > Do you have a link to these discussions? Your blog article does not
>> > have any links and I only found the "Runtime Interpreted Power
>> > Sequences" thread.
>> > That in itself does not cover the pros/cons of storing HW information*
>> > within DT.
>>
>> There's some discussion here:
>>
>>   
>> https://lists.freedesktop.org/archives/dri-devel/2013-November/049509.html
>>
>> which continues here:
>>
>>   
>> https://lists.freedesktop.org/archives/dri-devel/2013-December/050082.html
>>
>> There are a couple of earlier threads, though, that discuss similar
>> issues. This one seems to be the earliest I can find that is publicly
>> archived:
>>
>>   http://www.spinics.net/lists/devicetree/msg08497.html
>>
>> Going over all these threads again wasn't a very pleasant experience. I
>> realize how much time I already spent discussing these, and I don't have
>> any desire to repeat that discussion.
>>
>> We've had these differences ever since the very beginning. So we're now
>> again going in circles.
>>
>> The main concern back at the time was that having to specify timings in
>> the driver would result in a complete mess because we have zillions of
>> panels that we need to support. That's turned out to be a complete non-
>> issue. We've got something on the order of 50 or 60 drivers supported in
>> the simple-panel driver, and for everything that's more complicated we
>> have a handful of separate drivers, all fairly simple as well.
>>
>> So while I understand why people want to put all this information into
>> DT, we've repeatedly discussed the disadvantages that this would have.
>> And while we were never able to get everyone to agree, the current
>> solution has had enough agreement that we merged it. And it turned out
>> to be good enough. There's nothing in panel-lvds that I can see that
>> fundamentally changes this.
>>
>> > Personally, the idea of having hardware information* in DT does not
>> > sound all that bad. The simple panel driver(s) can use those
>> > properties and any panels that require anything more complex will
>> > still need their own driver.
>>
>> Again, the point is that you're going to have to modify the driver in
>> any case, because you need to support the new compatible string. Without
>> that compatible string you have zero information about the panel, and
>> matching on a generic one isn't going to give you a working panel.
>
> It will *if* the panel doesn't need any device-specific handling. In all other
> cases I agree with you, panel-specific code will be needed in the kernel (to
> handle power sequences for instance).
>
>> So if you're already going to have to support a panel in a driver, why not
>> go all the way and fully describe its capabilities and properties? We do it
>> for all other devices. Panels are not at all special.
>
> That we agree on, panels are not special. They're not the only devices that
> store in DT information that could be hardcoded in the driver based on the
> compatible string. We have many devices whose compatible string contains the
> SoC version. Driver could then hardcode interrupts or clocks without any need
> to specific them in DT. We don't do that as it would be more complex to
> handle.
>
> Regarding timings, I've long hesitated (albeit I confess I was more on the
> side of specifying them in DT) until Rob Herring convinced me with the generic
> rule that adding information in DT that are generally exposed by devices
> themselves makes sense. Displays traditionally expose video mode information
> through EDID, which is effectively device firmware. When a panel is integrated
> in a system, and the system designer decides to save money by removing the
> EDID I2C EEPROM, moving that piece of device firmware data to system firmware
> makes sense to me.
>
> I certainly won't try to revive the power sequence discussions, I don't
> believe it belongs to DT.
>
>> > For better or for worse, there's already a handful of drivers and
>> > bindings that rely on/provide these. Using that information
>> > consistently across the board, would be of a benefit, IMHO.
>>
>> Would you mind pointing out which ones these are? I'm aware of only a
>> couple that seemed to have sneeked in because people were trying to
>> side-step adding drm/panel support for their boards, so I don't think
>> that qualifies as a reason to rethink how drm/panel works.

Okay I'm afraid I agree with Thierry here.

I don't want mode timings or EDID in DT files, I'm pretty sure I was one of the
people who helped decide that jus

Re: Vulkan WSI+VK_KHR_display for KMS/DRM?

[Chad Versace]

On Tue 04 Apr 2017, Keith Packard wrote:
> Jason Ekstrand  writes:
> 
> > Interesting question.  To my knowledge, no one has actually implemented the
> > Vulkan WSI direct-to-display extensions.  (I tried to prevent them from
> > getting released with 1.0 but failed.)  I believe the correct answer is to
> > use the external memory dma-buf stuff that chad and I have been using and
> > talk directly to KMS.
> 
> Sounds good, and minimizes the amount of code I have to write too :-)

I found an implementation. Nvidia's 2017-04-06 Linux driver release
notes claim newly added support for VK_EXT_direct_mode_diplay, which is
layered atop VK_KHR_display.

http://www.nvidia.com/download/driverResults.aspx/117741/en-us
https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html#VK_EXT_direct_mode_display

> > I see no good reason to have a large abstraction in
> > the middle.
> 
> Other than 'it's a standard', neither do I.

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

Re: [PATCH v6 1/2] drm: Unplug drm device when unregistering it

[Sean Paul]

On Mon, Apr 10, 2017 at 06:00:44PM +0800, Jeffy Chen wrote:
> After unbinding drm, the user space may still owns the drm dev fd,
> and may still be able to call drm ioctl.
> 
> We're using an unplugged state to prevent something like that, so
> let's reuse it here.
> 
> Signed-off-by: Jeffy Chen 
> ---
> 
> Changes in v6:
> Address Daniel Vetter 's comments.
> 
> Changes in v5:
> Fix wrong git account.
> 
> Changes in v2:
> Fix some commit messages.
> 
>  drivers/gpu/drm/drm_drv.c | 6 +++---
>  drivers/gpu/drm/udl/udl_drv.c | 2 +-
>  include/drm/drmP.h| 6 ++
>  3 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index b5c6bb4..f38de26 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -357,9 +357,6 @@ EXPORT_SYMBOL(drm_put_dev);
>  
>  void drm_unplug_dev(struct drm_device *dev)
>  {
> - /* for a USB device */
> - drm_dev_unregister(dev);
> -
>   mutex_lock(&drm_global_mutex);
>  
>   drm_device_set_unplugged(dev);
> @@ -787,6 +784,8 @@ int drm_dev_register(struct drm_device *dev, unsigned 
> long flags)
>   if (drm_core_check_feature(dev, DRIVER_MODESET))
>   drm_modeset_register_all(dev);
>  
> + drm_device_set_plugged(dev);
> +
>   ret = 0;
>  
>   DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
> @@ -826,6 +825,7 @@ void drm_dev_unregister(struct drm_device *dev)
>   drm_lastclose(dev);
>  
>   dev->registered = false;
> + drm_unplug_dev(dev);
>  
>   if (drm_core_check_feature(dev, DRIVER_MODESET))
>   drm_modeset_unregister_all(dev);
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index cd8b017..5dbd916 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -108,7 +108,7 @@ static void udl_usb_disconnect(struct usb_interface 
> *interface)
>   drm_kms_helper_poll_disable(dev);
>   udl_fbdev_unplug(dev);
>   udl_drop_usb(dev);
> - drm_unplug_dev(dev);
> + drm_dev_unregister(dev);
>  }
>  
>  /*
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 3bfafcd..c930a77 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -488,6 +488,12 @@ static __inline__ int drm_core_check_feature(struct 
> drm_device *dev,
>   return ((dev->driver->driver_features & feature) ? 1 : 0);
>  }
>  
> +static inline void drm_device_set_plugged(struct drm_device *dev)
> +{
> + smp_wmb();
> + atomic_set(&dev->unplugged, 0);
> +}
> +
>  static inline void drm_device_set_unplugged(struct drm_device *dev)

Instead of introducing a new function, just rename this to
drm_device_set_plug_state(struct drm_device *dev, bool plugged)

and call it from both plug and unplug

With that nit, this is

Reviewed-by: Sean Paul 

>  {
>   smp_wmb();
> -- 
> 2.1.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Keith Packard]

Alex Deucher  writes:

> I think there is a definite use case there.

I agree. What we're missing right now is someone interested in driving
an implementation of that use case to help define the right
interfaces. Lacking that, we're not likely to come up with a good
solution on our own. I think that's what Daniel is concerned about --
specifying something in the absence of an implementation using it.

I took a stab at this and added the ability to change leases on the fly,
and to create 'sub-leases' from an existing lease. He's pushing back on
those features, and I think his reasons are sound.

> Why do we need to make X aware of the lease stuff? What about having
> some pre-X configuration that decides how to split up the display
> resources.

For multi-user, this makes a lot of sense; you'd want the system to
allocate resources between users to allow them to operate fairly
independently.

For single-user with a hot-plugged HMD, I'd suggest that having X
involved makes a lot of sense -- you may have to interact with the user
to reduce resource consumption so that the HMD can be driven
successfully, and that will involve poking at the X configuration.

> It could be user defined static or dynamic based on what is attached.
> You can just start X on the device nodes with whatever resources they
> are assigned.  In the multi-user case, you can statically assign
> resources to each node; in the VR case, you can detect the HMD and
> automatically assign it's resources to a separate node or override if
> necessary.

I don't think we've precluded this for a multi-user environment, and I
think it's a good plan in the abstract.

I will, however, suggest that asking for VR applications to wait for the
desktop environment to be re-architected so that display resources can
be centrally allocated by a new 'display resource manager' seems like a
rather steep requirement.

What I do want to ensure is that these two use cases can both be
supported by the kernel interfaces we define, and that we can work in
user space on either design going forward.

If you'd like to start exploring the design of such a central service,
that'd be awesome.

-- 
-keith


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

Re: [RFC 1/7] drm/atomic: initial support for asynchronous plane update

[Eric Anholt]

Gustavo Padovan  writes:

> From: Gustavo Padovan 
>
> In some cases, like cursor updates, it is interesting to update the
> plane in an asynchronous fashion to avoid big delays.
>
> The current queued update could be still waiting for a fence to signal and
> thus block and subsequent update until its scan out. In cases like this if
> we update the cursor synchronously it will cause significant delays on
> some platforms that would be noticed by the final user.
>
> This patch creates a fast path to jump ahead the current queued state and
> do single planes updates without going through all atomic step in
> drm_atomic_helper_commit().
>
> For now only single plane updates are supported and only if there is no
> update to that plane in the queued state.
>
> We plan to support async PageFlips through this interface as well in the
> near future.

This looks really nice -- the vc4 code for cursors was really gross to
write, and I got it wrong a couple of times.  Couple of comments inline.

> ---
>  drivers/gpu/drm/drm_atomic.c | 75 
> 
>  drivers/gpu/drm/drm_atomic_helper.c  | 41 +
>  include/drm/drm_atomic.h |  4 ++
>  include/drm/drm_atomic_helper.h  |  2 +
>  include/drm/drm_modeset_helper_vtables.h | 47 
>  5 files changed, 169 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index f32506a..cae0122 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -631,6 +631,79 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
>   return 0;
>  }
>  
> +static bool drm_atomic_async_check(struct drm_atomic_state *state)
> +{
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc_commit *commit;
> + struct drm_plane *__plane, *plane = NULL;
> + struct drm_plane_state *__plane_state, *plane_state = NULL;
> + const struct drm_plane_helper_funcs *funcs;
> + int i, n_planes = 0;
> +
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + if (drm_atomic_crtc_needs_modeset(crtc_state))
> + return false;
> + }
> +
> + for_each_new_plane_in_state(state, __plane, __plane_state, i) {
> + n_planes++;
> + plane = __plane;
> + plane_state = __plane_state;
> + }
> +
> + if (!plane || n_planes != 1)
> + return false;
> +
> + if (!plane->state->crtc)
> + return false;
> +
> + if (plane_state->fence)
> + return false;
> +
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + if (plane->crtc != crtc)
> + continue;
> +
> + spin_lock(&crtc->commit_lock);
> + commit = list_first_entry_or_null(&crtc->commit_list,
> +   struct drm_crtc_commit,
> +   commit_entry);
> + if (!commit) {
> + spin_unlock(&crtc->commit_lock);
> + continue;
> + }
> + spin_unlock(&crtc->commit_lock);
> +
> + for_each_plane_in_state(crtc_state->state, __plane,
> + __plane_state, i) {
> + if (__plane == plane) {
> + return false;
> + }
> + }
> + }
> +
> + /* Not configuring new scaling in the async path. */

s/Not/No/

> + if (plane->state->crtc_w != plane_state->crtc_w ||
> + plane->state->crtc_h != plane_state->crtc_h ||
> + plane->state->src_w != plane_state->src_w ||
> + plane->state->src_h != plane_state->src_h) {
> + return false;
> + }
> +
> + funcs = plane->helper_private;
> +
> + if (!funcs->atomic_async_update)
> + return false;
> +
> + if (funcs->atomic_async_check) {
> + if (funcs->atomic_async_check(plane, plane_state) < 0)
> + return false;
> + }
> +
> + return true;
> +}
> +
>  static void drm_atomic_crtc_print_state(struct drm_printer *p,
>   const struct drm_crtc_state *state)
>  {
> @@ -1591,6 +1664,8 @@ int drm_atomic_check_only(struct drm_atomic_state 
> *state)
>   }
>   }
>  
> + state->async_update = drm_atomic_async_check(state);
> +
>   return ret;
>  }

The promotion of any modeset that passes the async_check test to async
seems weird -- shouldn't we only be doing that if userspace requested
async?  Right now it seems like we're just getting lucky because only
cursor planes have it set, and the cursor update ioctls imply async.

>  EXPORT_SYMBOL(drm_atomic_check_only);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 8be9719..a79e06c 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gp

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Mario Kleiner]

On 04/10/2017 08:11 PM, Keith Packard wrote:

Mario Kleiner  writes:


as input from a highly interested future user of such api's:


Thanks much for taking a look at this.


My use cases run about 98% of the time in fullscreen
exclusive mode and want as little interference from the windowing system
/ desktop environment as possible, with as much low level control as
possible. It still needs windowed mode for same cases and needs a
windowing system up and running.


The new APIs can give you exclusive access to the display resources,
bypassing the window system entirely.


Atm. under X i have to hope that fullscreen unredirection works to get
me page flipping for single display monoscopic stimulation and
dual-display stereoscopic stuff. And then there's the popular "Regular
desktop GUI for interaction" + separate displays for "fullscreen + page
flipping for controlled presentation" case.


You're still depending on the window system server for timely page flips
though; the main reason we're doing the leasing work is to get that
variable out of the equation, eliminating any window system scheduling
jitter from the regular screen updates on the HMD.



Yes, and that will be an advantage for me as well, especially for some 
more exotic situations. That said, in my experience good old X is 
holding up rather well for page-flipped windows if one gets unredirected 
fullscreen with no DE interference. I have users which runs a 
1920x1080@240 Hz display at 240 fps stable update rates without skipping 
frames and proper frame accurate timing on AMD gfx with the open-source 
graphics stack on a standard Ubuntu 16.04 + Server 1.18 :)
In fact, it still beats current standard Wayland compositors by a large 
margin, mostly due to how display update scheduling is done in the 
current incarnations and because Wayland doesn't have a full DRI/Present 
or OML_sync_control equivalent yet.



The RRCreateLease requests looks as if i could get that for regular
non-HMD video outputs as well?


Yes, there's almost no way we could restrict it even if we wanted
to. I'm doing testing with two standard monitors, but any hardware at
all will work.


And the RRCreateOutputGrab would be mostly to avoid flicker when
plugging HMD's or other special purpose devices, but wouldn't be
strictly needed for a regular X-client to get a lease on a set of
outputs?


Yes, just to avoid having the desktop extend itself onto the HMD, even
briefly. The two components of the RandR changes are logically separate,
but should be useful in combination when using HMD displays.


As far as controllable properties on a lease go, i'd find it very useful
if i could have control over framebuffer formats, e.g., being able to
select 10 bit scanout formats would be very useful, but is afaik
something that X currently doesn't expose with most drivers, especially
not for regular desktop mode.


You have the full KMS api at your disposal; do whatever you like :-)


If the underlying DRM leases allow me to control this stuff, and Wayland
would gain similar extensions to lease outputs for fullscreen exclusive
control, i could have one drm/kms backend that can be mostly agnostic of
X vs. Wayland / different Wayland compositor flavors.


Right, that's another benefit here -- allowing HMD applications to be largely
window system independent, except for acquiring the initial lease.



Great! Haven't looked at your patches yet, only at this thread and your 
blog, but this sounds all very promising.



Basically my vote to expose as much flexility in modesetting /
properties for the exposed leases as possible on the kernel and X
side.


I'll have a second cut of the kernel API changes ready in another day or
so; that will eliminate the ability to change an existing lease, so
you'll have to acquire all of the resources you need all at
once. Otherwise, it will look quite similar at the user API level.

The RandR protocol changes will also need another spin; it sounds like
we want to configure the set of 'special' monitors and have those never
reported as connected via the current API. I don't think that will
affect your use case at all, and the other part of the protocol for
creating a lease won't change.



Yes, sounds like i could deal with that.
-mario
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 7/7] drm/vc4: update cursors asynchronously through atomic

[Eric Anholt]

Gustavo Padovan  writes:

> From: Gustavo Padovan 
>
> Add support to async updates of cursors by using the new atomic
> interface for that. Basically what this commit does is do what
> vc4_update_plane() did but through atomic.
>
> Cc: Eric Anholt 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/vc4/vc4_plane.c | 94 
> -
>  1 file changed, 27 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index d34cd53..e33c75b 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -735,70 +735,27 @@ void vc4_plane_async_set_fb(struct drm_plane *plane, 
> struct drm_framebuffer *fb)
>   vc4_state->dlist[vc4_state->ptr0_offset] = addr;
>  }
>  
> -static const struct drm_plane_helper_funcs vc4_plane_helper_funcs = {
> - .atomic_check = vc4_plane_atomic_check,
> - .atomic_update = vc4_plane_atomic_update,
> -};
> -
> -static void vc4_plane_destroy(struct drm_plane *plane)
> -{
> - drm_plane_helper_disable(plane);
> - drm_plane_cleanup(plane);
> -}
> -
> -/* Implements immediate (non-vblank-synced) updates of the cursor
> - * position, or falls back to the atomic helper otherwise.
> - */
> -static int
> -vc4_update_plane(struct drm_plane *plane,
> -  struct drm_crtc *crtc,
> -  struct drm_framebuffer *fb,
> -  int crtc_x, int crtc_y,
> -  unsigned int crtc_w, unsigned int crtc_h,
> -  uint32_t src_x, uint32_t src_y,
> -  uint32_t src_w, uint32_t src_h,
> -  struct drm_modeset_acquire_ctx *ctx)
> +static int vc4_plane_atomic_async_check(struct drm_plane *plane,
> + struct drm_plane_state *state)
>  {
> - struct drm_plane_state *plane_state;
> - struct vc4_plane_state *vc4_state;
> -
> - if (plane != crtc->cursor)
> - goto out;
> -
> - plane_state = plane->state;
> - vc4_state = to_vc4_plane_state(plane_state);
> -
> - if (!plane_state)
> - goto out;
> + if (plane != state->crtc->cursor)
> + return -EINVAL;
>  
> - /* No configuring new scaling in the fast path. */
> - if (crtc_w != plane_state->crtc_w ||
> - crtc_h != plane_state->crtc_h ||
> - src_w != plane_state->src_w ||
> - src_h != plane_state->src_h) {
> - goto out;
> - }
> + if (!plane->state)
> + return -EINVAL;
>  
> - if (fb != plane_state->fb) {
> - drm_atomic_set_fb_for_plane(plane->state, fb);
> - vc4_plane_async_set_fb(plane, fb);
> - }
> + return 0;
> +}
>  
> - /* Set the cursor's position on the screen.  This is the
> -  * expected change from the drm_mode_cursor_universal()
> -  * helper.
> -  */
> - plane_state->crtc_x = crtc_x;
> - plane_state->crtc_y = crtc_y;
> +static void vc4_plane_atomic_async_update(struct drm_plane *plane,
> +   struct drm_plane_state *new_state)
> +{
> + struct vc4_plane_state *vc4_state = to_vc4_plane_state(plane->state);
>  
> - /* Allow changing the start position within the cursor BO, if
> -  * that matters.
> -  */
> - plane_state->src_x = src_x;
> - plane_state->src_y = src_y;
> + if (plane->state->fb != new_state->fb)
> + vc4_plane_async_set_fb(plane, new_state->fb);
>  
> - /* Update the display list based on the new crtc_x/y. */
> - vc4_plane_atomic_check(plane, plane_state);
> + plane->state->fb = new_state->fb;

The vc4_plane_atomic_check() is what sets up the dlist[]'s position
fields that are used right after this, so this call needs to stay in
place, and x/y need to be updated already (since we're looking at
plane->state, not new_state).

Also, I think we'll need to make sure that you're not trying to
enable/disable the plane in the fast path, since we're not updating the
CTL0_VALID field.

>   /* Note that we can't just call vc4_plane_write_dlist()
>* because that would smash the context data that the HVS is
> @@ -810,20 +767,23 @@ vc4_update_plane(struct drm_plane *plane,
>  &vc4_state->hw_dlist[vc4_state->pos2_offset]);
>   writel(vc4_state->dlist[vc4_state->ptr0_offset],
>  &vc4_state->hw_dlist[vc4_state->ptr0_offset]);
> +}


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

drm-tip/drm-tip boot: 135 boots: 4 failed, 129 passed with 2 offline (v4.11-rc5-1808-ge461ecfd413f)

[kernelci . org bot]

drm-tip/drm-tip boot: 135 boots: 4 failed, 129 passed with 2 offline 
(v4.11-rc5-1808-ge461ecfd413f)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1808-ge461ecfd413f/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1808-ge461ecfd413f/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1808-ge461ecfd413f
Git Commit: e461ecfd413fb930d00f44f3de0019e528b4731f
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 18 unique boards, 10 SoC families, 26 builds out of 207

Boot Regressions Detected:

arm:

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
exynos5422-odroidxu3:
lab-collabora: new failure (last pass: v4.11-rc5-1807-g777f8b443ed1)

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

x86:

tinyconfig
minnowboard-max: 1 failed lab

arm:

multi_v7_defconfig+CONFIG_SMP=n
exynos5250-snow: 1 failed lab

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
exynos5422-odroidxu3: 1 failed lab

Offline Platforms:

x86:

allmodconfig:
minnowboard-max: 1 offline lab

allmodconfig+CONFIG_OF=n:
minnowboard-max: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 2/2] drm: Prevent release fb after cleanup mode config

[Sean Paul]

On Mon, Apr 10, 2017 at 06:00:45PM +0800, Jeffy Chen wrote:
> After unbinding drm, the user space may still owns the drm dev fd,
> and may trigger fb release after cleanup mode config.
> 
> Add a sanity check to prevent that.
> 
> Signed-off-by: Jeffy Chen 
> ---
> 
> Changes in v6: None
> Changes in v5: None
> Changes in v2: None
> 
>  drivers/gpu/drm/drm_framebuffer.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index e8f9c13..03c1632 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -583,6 +583,11 @@ void drm_fb_release(struct drm_file *priv)
>  {
>   struct drm_framebuffer *fb, *tfb;
>   struct drm_mode_rmfb_work arg;
> + struct drm_minor *minor = priv->minor;
> + struct drm_device *dev = minor->dev;
> +
> + if (WARN_ON(!dev->mode_config.num_fb && !list_empty(&priv->fbs)))

Have you actually seen this happen? num_fb should be tightly couple to
priv->fbs, so it seems like this could only result from a driver bug (or I'm not
reading the code correctly).

Sean

> + return;
>  
>   INIT_LIST_HEAD(&arg.fbs);
>  
> -- 
> 2.1.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Keith Packard]

Mario Kleiner  writes:

> Great! Haven't looked at your patches yet, only at this thread and your 
> blog, but this sounds all very promising.

I'll write up another blog post when I finish with the first round of
review. That should describe the kernel API at least. I think the X API
will be pretty simple though -- tell me which output and  crtc and I'll
hand you a lease for those.

-- 
-keith


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

[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

[bugzilla-daemon]

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

--- Comment #13 from Julien Isorce  ---
Created attachment 130787
  --> https://bugs.freedesktop.org/attachment.cgi?id=130787&action=edit
dmesg_HD7770_kernel_amd-staging-4.9_ring_stalled

-- 
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 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

[bugzilla-daemon]

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

--- Comment #14 from Julien Isorce  ---
Created attachment 130788
  --> https://bugs.freedesktop.org/attachment.cgi?id=130788&action=edit
ddebug_dumps_HD7770_kernel_amd-staging-4.9_ring_stalled

-- 
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 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

[bugzilla-daemon]

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

--- Comment #15 from Julien Isorce  ---
Created attachment 130789
  --> https://bugs.freedesktop.org/attachment.cgi?id=130789&action=edit
dmesg_HD7770_kernel_agd5f-drm-next-4.12_ring_stalled

-- 
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 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

[bugzilla-daemon]

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

--- Comment #16 from Julien Isorce  ---
Created attachment 130790
  --> https://bugs.freedesktop.org/attachment.cgi?id=130790&action=edit
ddebug_dumps_HD7770_kernel_agd5f-drm-next-4.12_ring_stalled

-- 
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 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

[bugzilla-daemon]

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

--- Comment #17 from Julien Isorce  ---
These last 4 attachements logs are for comment #12. And generated with
GALLIUM_DDEBUG="pipelined 1" R600_DEBUG=check_vm . Again it is potentially
a different freeze than the one reported initially, simplify because I still
have no logs for the former which is with a W600.

-- 
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 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

[bugzilla-daemon]

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

--- Comment #18 from Julien Isorce  ---
-simplify +simply

-- 
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 v3] drm/exynos: mixer: document YCbCr magic numbers

[Inki Dae]

2017년 04월 10일 19:27에 Tobias Jakobi 이(가) 쓴 글:
> Inki Dae wrote:
>> 2017-03-29 20:56 GMT+09:00 Tobias Jakobi :
>>> Hello Daniel,
>>>
>>> same question here. Patch doesn't introduce any functional changes (just
>>> adds code documentation), so can you merge it through drm-misc?
>>>
>>
>> Sorry for late. Confirmed just now. I will check it on next Monday.
> You have added the wrong patch (v2 instead of v3).

Tobias,

you had posted this patch with other one like below,
[PATCH v2 1/2] drm/exynos: mixer: simplify mixer_cfg_rgb_fmt()
[PATCH v2 2/2] drm/exynos: mixer: document YCbCr magic numbers

And than you have posted it without any comment again, v3,
[PATCH v3] drm/exynos: mixer: document YCbCr magic numbers

Please use --cover-letter option to make patch series and keep the patch set to 
be consistent with previous version.

I can merge the new one - really trivial - but I think it'd be better you to 
resend this patch series for other people.

This patch set has been removed from my tree. Please resend (not v4) this patch 
set like below,
[PATCH v3 0/2] drm/exynos: clean up mixer driver??
[PATCH v3 1/2] drm/exynos: mixer: simplify mixer_cfg_rgb_fmt()
[PATCH v3 2/2] drm/exynos: mixer: document YCbCr magic numbers

Thanks,
Inki Dae

> 
> - Tobias
> 
> 
>> Thanks,
>> Inki Dae
>>
>>> With best wishes,
>>> Tobias
>>>
>>>
>>> Tobias Jakobi wrote:
 The output stage of the mixer uses YCbCr for the internal
 computations, which is the reason that some registers take
 YCbCr related data as input. In particular this applies
 to MXR_BG_COLOR{0,1,2} and MXR_CM_COEFF_{Y,CB,CR}.

 Document the formatting of the data which we write to
 these registers.

 While at it, unify wording of comments in the register header.

 Reviewed-by: Andrzej Hajda 
 Signed-off-by: Tobias Jakobi 
 ---
 Changes in v2:
 - use floating point values as input for the macros, as
   suggested by Andrzej
 - the floating point values have been tuned to exactly match
   the values that are currently used

 Changes in v3:
 - use only three digit values (pointed out by Andrzej)

  drivers/gpu/drm/exynos/exynos_mixer.c | 33 
 +
  drivers/gpu/drm/exynos/regs-mixer.h   |  7 +--
  2 files changed, 30 insertions(+), 10 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
 b/drivers/gpu/drm/exynos/exynos_mixer.c
 index 41d0c36..9648dd5 100644
 --- a/drivers/gpu/drm/exynos/exynos_mixer.c
 +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
 @@ -45,6 +45,22 @@
  #define MIXER_WIN_NR 3
  #define VP_DEFAULT_WIN   2

 +/*
 + * Mixer color space conversion coefficient triplet.
 + * Used for CSC from RGB to YCbCr.
 + * Each coefficient is a 10-bit fixed point number with
 + * sign and no integer part, i.e.
 + * [0:8] = fractional part (representing a value y = x / 2^9)
 + * [9] = sign
 + * Negative values are encoded with two's complement.
 + */
 +#define MXR_CSC_C(x) ((int)((x) * 512.0) & 0x3ff)
 +#define MXR_CSC_CT(a0, a1, a2) \
 +  ((MXR_CSC_C(a0) << 20) | (MXR_CSC_C(a1) << 10) | (MXR_CSC_C(a2) << 0))
 +
 +/* YCbCr value, used for mixer background color configuration. */
 +#define MXR_YCBCR_VAL(y, cb, cr) (((y) << 16) | ((cb) << 8) | ((cr) << 0))
 +
  /* The pixelformats that are natively supported by the mixer. */
  #define MXR_FORMAT_RGB5654
  #define MXR_FORMAT_ARGB1555  5
 @@ -391,13 +407,14 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
 *ctx, unsigned int height)
   case 1080:
   default:
   val = MXR_CFG_RGB709_16_235;
 + /* Configure the BT.709 CSC matrix for full range RGB. */
   mixer_reg_write(res, MXR_CM_COEFF_Y,
 - (1 << 30) | (94 << 20) | (314 << 10) |
 - (32 << 0));
 + MXR_CSC_CT( 0.184,  0.614,  0.063) |
 + MXR_CM_COEFF_RGB_FULL);
   mixer_reg_write(res, MXR_CM_COEFF_CB,
 - (972 << 20) | (851 << 10) | (225 << 0));
 + MXR_CSC_CT(-0.102, -0.338,  0.440));
   mixer_reg_write(res, MXR_CM_COEFF_CR,
 - (225 << 20) | (820 << 10) | (1004 << 0));
 + MXR_CSC_CT( 0.440, -0.399, -0.040));
   break;
   }

 @@ -715,10 +732,10 @@ static void mixer_win_reset(struct mixer_context 
 *ctx)
   /* reset default layer priority */
   mixer_reg_write(res, MXR_LAYER_CFG, 0);

 - /* setting background color */
 - mixer_reg_write(res, MXR_BG_COLOR0, 0x008080);
 - mixer_reg_write(res, MXR_BG_COLOR1, 0x008080);
 - mixer_reg_write(res, MXR_BG_COLOR2, 0x008080);
 + /* set a

Re: [PATCH] drm/exynos: clean up description of exynos_drm_crtc

[Inki Dae]

2017년 04월 10일 19:29에 Tobias Jakobi 이(가) 쓴 글:
> Inki Dae wrote:
>> 2017-04-07 20:40 GMT+09:00 Tobias Jakobi :
>>> Hello Inki,
>>>
>>>
>>> Inki Dae wrote:
 Hello Tobias,


 2017년 04월 07일 02:10에 Tobias Jakobi 이(가) 쓴 글:
> Hello Inki,
>
>
> Inki Dae wrote:
>> This patch removes unnecessary descriptions on
>> exynos_drm_crtc structure and adds one description
>> which specifies what pipe_clk member does.
>>
>> pipe_clk support had been added by below patch without any description,
>>  drm/exynos: add support for pipeline clock to the framework
> I would put the commit id here. That makes it easier to look up the
> commit your refer to.
>
>
>> Signed-off-by: Inki Dae 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 527bf1d..b0462cc 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -152,12 +152,10 @@ struct exynos_drm_clk {
>>   *
>>   * @base: crtc object.
>>   * @type: one of EXYNOS_DISPLAY_TYPE_LCD and HDMI.
>> - * @enabled: if the crtc is enabled or not
>> - * @event: vblank event that is currently queued for flip
>> - * @wait_update: wait all pending planes updates to finish
>> - * @pending_update: number of pending plane updates in this crtc
>>   * @ops: pointer to callbacks for exynos drm specific functionality
>>   * @ctx: A pointer to the crtc's implementation specific context
>> + * @pipe_clk: A pipe clock structure which includes a callback function
>> + for enabling DP clock of FIMD and HDMI PHY clock.
> This is wrong/inconsistent with the rest of the documentation. pipe_clk
> is not a struct, but a pointer.
>
> I would suggest to follow. Just document that we have a pointer to  escription> here (compare docu for 'ops' and 'ctx').
> And then put the later bits ("...callback function for enabling DP
> clock...") directly to the definition of 'struct exynos_drm_clk' (which
> is currently lacking any kind of docu).

 Thanks for pointing it out. My mistake. :)

 How about this simply?
 "A pointer to exynos_drm_clk structure for enabling and disabling DP clock 
 of FIMD and HDMI PHY clocks"
>>> Not what I meant. You're describing 'struct exynos_drm_clk', and that
>>> does not belong here. If you describe 'struct exynos_drm_clk', then this
>>> should go in front of the struct's definition.
>>>
>>> How abouting something like this in front of the struct's definition::
 /*
  * Exynos DRM pipeline clock structure.
  *
  * @enable: callback to enable/disable the clock.
  *
  * Used for proper clock synchronization of components belonging
  * to the same pipeline. Used e.g. for enabling the DP clock of
  * the FIMD or the HDMI PHY clock.
  */
 struct exynos_drm_clk {
 
>>>
>>> For 'pipe_clk' I would just go with this:
 @pipe_clk: A pointet to the crtc's pipeline clock.
>>
>> More simple and looks better.
> In this form (commit a07d468cb2efd347a9e279e4f68661f0f370d10f in
> exynos-drm-next), the description is incomplete. Please read my mails again.

Many patches in mainline used same form. Please git log | grep "commit-id" -n10.
Sorry but no update and no comment anymore but will use the generic form later.

Thanks,
Inki Dae

> 
> - Tobias
> 
> 
>>
>> Thanks,
>> Inki Dae
>>
>>>
>>> I hope this helps.
>>>
>>> - Tobias
>>>
>>>
 Thanks,
 Inki Dae

>
>
> - Tobias
>
>>   */
>>  struct exynos_drm_crtc {
>> struct drm_crtc base;
>>
>
>
>
>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe 
>>> linux-samsung-soc" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Bug 195231] Continuous messages of "*ERROR* UVD not responding, trying to reset the VCPU!!!" and frozen screen

[Rogério Brito]

Dear Alex, Christian and others,

On Mon, Apr 10, 2017 at 3:50 AM,   wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=195231
> --- Comment #11 from Christian König (deathsim...@vodafone.de) ---
> Well bisecting which patch caused the break would be a good idea.

First of all, I hope you don't mind that I'm including my mom here, so
that she can follow how her computer is doing, or, rather, what I am
doing with her computer.

> To start that I suggest you try to compile kernel 4.4 by yourself first.
>
> That should also yield a temporary solution until we can narrow down the root
> cause.

I tried using Ubuntu's unpatched/precompiled kernels 4.2, 4.4, 4.8,
4.10 and 4.11-rc5 and, apparently, they now always show this message
*and* it frequently freezes to the point that no magic Sysrq keys
work, sometimes the caps lock kernel blinks and so on.

Booting with radeon.modeset=0 allows the computer to boot to the
desktop environment, but makes the CPU so hot when she plays her
flashplayer-based games that the kernel shows many messages of thermal
limit being reached and CPU speed being throttled.

Booting with radeon.runpm=0 still gets me all the error messages
listed in the subject (and present in the logs that I sent to
bugzilla), but the temperature *seems* to be slightly lower (not
enough testing was done with this configuration).

I don't know how to see/check what GPU is being used at a given time:
if the Intel GPU or if the AMD GPU...

So, given that the problem now seems to be present with all those
kernel versions that I tested, is it worthwhile to compile my own
kernels?

As before, I will try to do whatever I'm directed to.


Thanks a lot,

Rogério.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 0/2] drm: rockchip: Fix rockchip drm unbind crash error

[Jeffy Chen]

Verified on rk3399 chromebook kevin, no more crashes during unbind/bind drm.

Changes in v6:
Address Daniel Vetter 's comments.

Changes in v5:
Fix wrong git account.

Changes in v2:
Fix some commit messages.

Jeffy Chen (2):
  drm: Unplug drm device when unregistering it
  drm: Prevent release fb after cleanup mode config

 drivers/gpu/drm/drm_drv.c | 6 +++---
 drivers/gpu/drm/drm_framebuffer.c | 5 +
 drivers/gpu/drm/udl/udl_drv.c | 2 +-
 include/drm/drmP.h| 6 ++
 4 files changed, 15 insertions(+), 4 deletions(-)

-- 
2.1.4


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

[PATCH v6 1/2] drm: Unplug drm device when unregistering it

[Jeffy Chen]

After unbinding drm, the user space may still owns the drm dev fd,
and may still be able to call drm ioctl.

We're using an unplugged state to prevent something like that, so
let's reuse it here.

Signed-off-by: Jeffy Chen 
---

Changes in v6:
Address Daniel Vetter 's comments.

Changes in v5:
Fix wrong git account.

Changes in v2:
Fix some commit messages.

 drivers/gpu/drm/drm_drv.c | 6 +++---
 drivers/gpu/drm/udl/udl_drv.c | 2 +-
 include/drm/drmP.h| 6 ++
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index b5c6bb4..f38de26 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -357,9 +357,6 @@ EXPORT_SYMBOL(drm_put_dev);
 
 void drm_unplug_dev(struct drm_device *dev)
 {
-   /* for a USB device */
-   drm_dev_unregister(dev);
-
mutex_lock(&drm_global_mutex);
 
drm_device_set_unplugged(dev);
@@ -787,6 +784,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long 
flags)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_register_all(dev);
 
+   drm_device_set_plugged(dev);
+
ret = 0;
 
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
@@ -826,6 +825,7 @@ void drm_dev_unregister(struct drm_device *dev)
drm_lastclose(dev);
 
dev->registered = false;
+   drm_unplug_dev(dev);
 
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_unregister_all(dev);
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index cd8b017..5dbd916 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -108,7 +108,7 @@ static void udl_usb_disconnect(struct usb_interface 
*interface)
drm_kms_helper_poll_disable(dev);
udl_fbdev_unplug(dev);
udl_drop_usb(dev);
-   drm_unplug_dev(dev);
+   drm_dev_unregister(dev);
 }
 
 /*
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3bfafcd..c930a77 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -488,6 +488,12 @@ static __inline__ int drm_core_check_feature(struct 
drm_device *dev,
return ((dev->driver->driver_features & feature) ? 1 : 0);
 }
 
+static inline void drm_device_set_plugged(struct drm_device *dev)
+{
+   smp_wmb();
+   atomic_set(&dev->unplugged, 0);
+}
+
 static inline void drm_device_set_unplugged(struct drm_device *dev)
 {
smp_wmb();
-- 
2.1.4


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

Re: [PATCH 0/4] Fix DP busy wait and defer disabling overlay plane

[Dan MacDonald]

Hi Philipp

Is there any more info regarding my display probs that you need from me?

Are you working on or do you plan to create another revision of this patch?

I am presuming I'm the only person on this list who owns the Element14
version of the SABRE Lite?

Thanks

On Wed, Apr 5, 2017 at 3:18 PM, Dan MacDonald  wrote:
> Hi Phillipp
>
> My SL was attached to a 27" UHD Acer S277HK Monitor.
>
> I can disable those for the next patch but I get the impression thats
> not the only issue here as I've gone from being able to get a picture
> (but not the right res) in 4.10 to not getting any HDMI signal at all
> with this patch.
>
> Those flip errors have to be another bad sign, right?
>
> Thanks
>
> On Wed, Apr 5, 2017 at 2:51 PM, Philipp Zabel  wrote:
>> On Tue, 2017-04-04 at 19:25 +0100, Dan MacDonald wrote:
>>> It took just under 11 hours to build the Arch 4.11 armv7h kernel on my
>>> SL. The good news is that the patch both applied and built OK this
>>> time, and the kernel package installed fine. What didn't seem right is
>>> that boot pauses for a minute or so on these lines:
>>>
>>> [ 4.458572] panel-simple panel-lcd: panel-lcd supply power not found,
>>> using dummy regulator
>>> [ 4.467736] panel-simple panel-lvds0: panel-lvds0 supply power not
>>> found, using dummy regulator
>>
>> I have no idea where that delay comes from, but do you have the Okaya
>> RS800480T-7x0GP parallel panel or the Hannstar HSD100PXN1 LVDS panel
>> that are described in imx6qdl-sabrelite.dtsi connected to the SABRE Lite
>> board? If not, could you try disabling them or the one that you don't
>> have:
>>
>> --8<--
>> diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
>> b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
>> index 84131794e97b6..c291c2821345f 100644
>> --- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
>> +++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
>> @@ -159,7 +159,7 @@
>> brightness-levels = <0 4 8 16 32 64 128 255>;
>> default-brightness-level = <7>;
>> power-supply = <®_3p3v>;
>> -   status = "okay";
>> +   status = "disabled";
>> };
>>
>> backlight_lvds: backlight-lvds {
>> @@ -168,7 +168,7 @@
>> brightness-levels = <0 4 8 16 32 64 128 255>;
>> default-brightness-level = <7>;
>> power-supply = <®_3p3v>;
>> -   status = "okay";
>> +   status = "disabled";
>> };
>>
>> lcd_display: display@di0 {
>> @@ -178,7 +178,7 @@
>> interface-pix-fmt = "bgr666";
>> pinctrl-names = "default";
>> pinctrl-0 = <&pinctrl_j15>;
>> -   status = "okay";
>> +   status = "disabled";
>>
>> port@0 {
>> reg = <0>;
>> @@ -200,6 +200,7 @@
>> panel-lcd {
>> compatible = "okaya,rs800480t-7x0gp";
>> backlight = <&backlight_lcd>;
>> +   status = "disabled";
>>
>> port {
>> lcd_panel_in: endpoint {
>> @@ -211,6 +212,7 @@
>> panel-lvds0 {
>> compatible = "hannstar,hsd100pxn1";
>> backlight = <&backlight_lvds>;
>> +   status = "disabled";
>>
>> port {
>> panel_in: endpoint {
>> -->8--
>>
>> regards
>> Philipp
>>
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load

[Martin Kepplinger]

Am 07.04.2017 01:23 schrieb Andrea Arcangeli:

I'm also getting kernel hangs every couple of days. For me it's still
not fixed here in 4.11-rc5. It's hard to reproduce, the best
reproducer is to build lineageos 14.1 on host while running LTP in a
guest to stress the guest VM.

Initially I thought it was related to the fact I upgraded the xf86
intel driver just a few weeks ago (I deferred any upgrade of the
userland intel driver since last July because of a regression that
never got fixed and broke xterm for me). After I found a workaround
for the userland regression (appended at the end for reference) I
started getting kernel hangs but they are separate issues as far as I
can tell.

It's not well tested so beware... (it survived a couple of builds and
some VM reclaim but that's it).

The first patch 1/5 is the potential fix for the i915 kernel hang. The
rest are incremental improvements.

And I've no great solution for when the shrinker was invoked with the
struct_mutex held and and recurse on the lock. I don't think we can
possibly wait in such case (other than flush work that the second
patch does) but then practically it shouldn't be a big deal, the big
RAM eater is unlikely to be i915 when the system is low on memory.



FWIW without having insight here, -rc6 seems to be good.
No disturbing gpu hangs under load so far.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: DRM Display driver for Intel FPGA Video and Image Processing Suite

[Ong, Hean Loong]

Thanks again Daniel for the clarification.

However I cannot seem to find the repo for the drm-misc and documentation on 
how to get it from the main kernel tree.

Could you can give me some pointers on where to get the git tree of the 
drm-misc for small drivers. Sorry as I am not very familiar with the DRM 
architecture

>-Original Message-
>From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of 
>Daniel
>Vetter
>Sent: Sunday, April 9, 2017 12:31 AM
>To: Ong, Hean Loong 
>Cc: Vetter, Daniel ; airl...@linux.ie; dri-
>de...@lists.freedesktop.org
>Subject: Re: DRM Display driver for Intel FPGA Video and Image Processing Suite
>
>On Sat, Apr 8, 2017 at 7:41 AM, Ong, Hean Loong 
>wrote:
>> Hi Daniel
>>
>> Thanks for the time and patience for reviewing my changes. I would ensure 
>> that
>subsequent patches will not have the same mail problems.
>>
>> I have some question on the validation methods. Since my drivers are
>processing the images with an FPGA would running the tests with
>https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-and-validation
>be relevant?
>
>igt testcases automatically skip when they don't apply for a given 
>platform/driver.
>They might need some bugfixes if your driver is a completely new case, but it
>should work.
>
>> The display images are streamed to the monitor via a Display Port connector
>thus I don' t think it is virtual. The FPGA is programmed to run with a 
>proprietary
>Display Port IP. The driver just feeds it with display data.
>
>Well, it looked like a virtual driver (since the real DP handling is somewhere 
>else
>like you explain). And since it works like a virtual driver we could extract a 
>helper
>library to reduce duplicated code.
>Virtual driver here means "just feeds display data to something else that 
>handles
>the real output handling duties". That applies to virtualized gpus, but also 
>to your
>case here.
>
>Btw a small ascii-art block diagram for your driver hw architecture to explain 
>stuff
>like this would be awesome (but it either into a code comment or into the 
>commit
>message).
>
>> I would take your advice in implementing it in the small drivers, but since 
>> its new
>are there any special cases that I would have to look out for in implementing 
>this
>driver in the drm-misc ?
>
>Small drivers is only about how to maintain it once it's merged, not about the
>code itself. We assume/hope that people who submit drivers stay around for
>helping maintaining it going forward (but if that doesn't happen, also no big 
>deal).
>-Daniel
>
>>
>>>-Original Message-
>>>From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf
>>>Of Daniel Vetter
>>>Sent: Saturday, April 8, 2017 12:32 AM
>>>To: Ong, Hean Loong 
>>>Cc: Vetter, Daniel ; airl...@linux.ie; dri-
>>>de...@lists.freedesktop.org
>>>Subject: Re: DRM Display driver for Intel FPGA Video and Image
>>>Processing Suite
>>>
>>>On Thu, Apr 6, 2017 at 8:29 AM, Ong, Hean Loong
>>>
>>>wrote:
 Hi All,

 Any comments for the patch below?
>>>
>>>Seems the same version that I already reviewed. My comment about not
>>>sending inline was more for the next version, especially once it's
>>>about applying the patch, attached patches are a bit of a pain (since they 
>>>break
>the tooling here).
>>>-Daniel

 Thanks

 Hean Loong

 On Tue, 2017-04-04 at 04:01 +, Ong, Hean Loong wrote:
> Hi All,
>
> Apologies for the attachment earlier. Below are the inline changes
> for the patch
>
> From 0de293e3646a1780ed603cf8e1f2a19d9aebbe83 Mon Sep 17 00:00:00
> 2001
> From: Ong, Hean Loong 
> Date: Thu, 30 Mar 2017 18:02:22 +0800
> Subject: [PATCHv0] Intel FPGA Video and Image Processing Suite
> Frame Buffer II driver
>
> Signed-off-by: Ong, Hean Loong 
> ---
>  drivers/gpu/drm/Kconfig   |2 +
>  drivers/gpu/drm/Makefile  |1 +
>  drivers/gpu/drm/ivip/Kconfig  |   22 
>  drivers/gpu/drm/ivip/Makefile |9 ++
>  drivers/gpu/drm/ivip/intel_vip_conn.c |  145
> ++ drivers/gpu/drm/ivip/intel_vip_core.c |  215
> +
>  drivers/gpu/drm/ivip/intel_vip_crtc.c |  161
> 
>  drivers/gpu/drm/ivip/intel_vip_drv.h  |   55 +
>  drivers/gpu/drm/ivip/intel_vip_of.c   |  146 ++
>  9 files changed, 756 insertions(+), 0 deletions(-)  create mode
> 100644 drivers/gpu/drm/ivip/Kconfig  create mode 100644
> drivers/gpu/drm/ivip/Makefile  create mode 100644
> drivers/gpu/drm/ivip/intel_vip_conn.c
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_crtc.c
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
>
> diff --git a/drivers/gpu/drm/Kconfig b/driv

Re: [PATCH 0/2] drm: dw-hdmi: various improvements

[Russell King - ARM Linux]

On Mon, Apr 10, 2017 at 12:35:43PM +0200, Neil Armstrong wrote:
> Hi Russell,
> 
> Cross tree with media has already been done on this cycle with the
> dw-hdmi formats changes.
> 
> Nevertheless, please push your updated dw-hdmi cec patchset for tests
> and review based on the latest drm-misc-next and hverkuil's HPD notifier
> release.

You can get my current version at:

 git://git.armlinux.org.uk/~rmk/linux-arm.git cec-v18

As it's taken me over a week to validate both dw-hdmi and tda998x against
the latest version of Hans patches (despite me wanting to get it out to
Hans), I don't have the bandwidth to rebase it onto some other tree and
re-test at the moment.  As we're at -rc6 today, I doubt that'll happen
before the merge window, sorry.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] drm: dw-hdmi: various improvements

[Russell King - ARM Linux]

On Mon, Apr 10, 2017 at 10:49:18AM +0530, Archit Taneja wrote:
> Hi,
> 
> On 04/07/2017 07:49 PM, Romain Perier wrote:
> >This set of patches split the stream handling functions in two parts. It
> >introduces new callbacks that are specific to each variant, one for I2S
> >and one for AHB.
> >
> >Then, as requested by the datasheet for the I2S variant, it adds support
> >for gating the audio sampler clock when the audio stream is enabled and
> >disabled.
> >
> >This patches series is the continuity of the following discussion:
> >http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/493550.html
> 
> Since these aren't fixes, could you make sure to redo the patches over:
> 
> git://anongit.freedesktop.org/drm-misc drm-misc-next
> 
> The dw-hdmi driver is now under drivers/gpu/drm/bridge/synopsis/

This is annoying as it makes submission of CEC support for dw-hdmi
rather difficult due to the now horrid cross-tree dependencies:

* if I submit it to the DRM tree, the DRM tree will build break because
  you don't have the necessary CEC changes which have recently been
  merged into the media tree.

* if I submit it to the media tree, the new files will be placed into
  drivers/gpu/drm/bridge and when stuff gets merged into linux-next
  and/or Linus' tree, things will need quite a large fixup (someone
  will have to rename the files and fix the Kconfig/Makefiles.)

So, I'll hold it back for another cycle to avoid the mess that would
result from trying to get it merged during this cycle.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 2/2] drm: Prevent release fb after cleanup mode config

[Jeffy Chen]

After unbinding drm, the user space may still owns the drm dev fd,
and may trigger fb release after cleanup mode config.

Add a sanity check to prevent that.

Signed-off-by: Jeffy Chen 
---

Changes in v6: None
Changes in v5: None
Changes in v2: None

 drivers/gpu/drm/drm_framebuffer.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index e8f9c13..03c1632 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -583,6 +583,11 @@ void drm_fb_release(struct drm_file *priv)
 {
struct drm_framebuffer *fb, *tfb;
struct drm_mode_rmfb_work arg;
+   struct drm_minor *minor = priv->minor;
+   struct drm_device *dev = minor->dev;
+
+   if (WARN_ON(!dev->mode_config.num_fb && !list_empty(&priv->fbs)))
+   return;
 
INIT_LIST_HEAD(&arg.fbs);
 
-- 
2.1.4


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

Re: Vulkan WSI+VK_KHR_display for KMS/DRM?

[Jason Ekstrand]

On April 10, 2017 12:29:12 PM Chad Versace  wrote:


On Tue 04 Apr 2017, Keith Packard wrote:

Jason Ekstrand  writes:

> Interesting question.  To my knowledge, no one has actually implemented the
> Vulkan WSI direct-to-display extensions.  (I tried to prevent them from
> getting released with 1.0 but failed.)  I believe the correct answer is to
> use the external memory dma-buf stuff that chad and I have been using and
> talk directly to KMS.

Sounds good, and minimizes the amount of code I have to write too :-)


I found an implementation. Nvidia's 2017-04-06 Linux driver release
notes claim newly added support for VK_EXT_direct_mode_diplay, which is
layered atop VK_KHR_display.


If it's useful to do so, we can always pull Keith's work into Mesa or even 
put it in a layer.  Let's start with an implementation and figure out the 
Vulkan bits later.  Of there's something interesting in NVIDIA's 
extensions, we can let that guide the design of course.



http://www.nvidia.com/download/driverResults.aspx/117741/en-us
https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html#VK_EXT_direct_mode_display


> I see no good reason to have a large abstraction in
> the middle.

Other than 'it's a standard', neither do I.


Yup.



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