[pull] radeon and amdgpu drm-fixes-4.11

[Alex Deucher]

Hi Dave,

A few small fixes for 4.11

The following changes since commit 27b713c2e08ef27d500a79166098d42b24977500:

  Merge branch 'drm-fixes-4.11' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2017-03-16 11:28:44 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.11

for you to fetch changes up to cf8c73afb3abf0f8905efbaddd4ce11a0deec9da:

  drm/amd/amdgpu: add POLARIS12 PCI ID (2017-03-17 14:44:34 -0400)


Alex Deucher (2):
  drm/radeon: reinstate oland workaround for sclk
  drm/amdgpu: reinstate oland workaround for sclk

Evan Quan (1):
  drm/amd/amdgpu: add POLARIS12 PCI ID

Huang Rui (1):
  drm/amdgpu: fix the clearing wb size

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  4 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  1 +
 drivers/gpu/drm/amd/amdgpu/si_dpm.c| 10 +++---
 drivers/gpu/drm/radeon/si_dpm.c| 10 +++---
 4 files changed, 17 insertions(+), 8 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

[bugzilla-daemon]

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

Jan Vesely  changed:

   What|Removed |Added

 Depends on||99856


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99856
[Bug 99856] OpenCL Hello world returns "unsupported call to function
get_local_size"
-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: Refactor vblank sequence number comparison

[Michel Dänzer]

On 22/03/17 07:06 PM, Chris Wilson wrote:
> Move the repeated (a - b) <= (1 << 23) to its own function.
> 
> v2: Catch the '1<<23' inside drm_handle_vblank() as well
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Michel Dänzer 


-- 
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: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:
> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
>> > I guess I'm a little late to the party here, but I haven't had time to
>> > really let all of this sink in and actually look at meson.  It doesn't
>> > seem so bad with a quick look and I think I could probably sort it out
>> > when the time came, but there would still be a bit of a learning
>> > curve.  While that may not be a big deal at the micro level, I have
>> > concerns at the macro level.
>> >
>> > First, I'm concerned it may discourage casual developers and
>> > packagers.  autotools isn't great, but most people are familiar enough
>> > with it that they can get by.  Most people have enough knowledge of
>> > autotools that they can pretty easily diagnose a configuration based
>> > failure. There are a lot of resources for autotools.  I'm not sure
>> > that would be the case for meson.  Do we as a community feel we have
>> > enough meson experience to get people over the hump?  Anything that
>> > makes it harder for someone to try a new build or do a bisect is a big
>> > problem in my opinion.
>>
>> One of the things that's prompted this on our side (I've talked this over 
>> with
>> other people at Intel before starting), was that clearly we *don't* know
>> autotools well enough to get it right. Emil almost always finds cases were 
>> we've
>> done things *almost*, but not quite right.
>>
>> For my part, it took me about 3 or 4 days of reading through the docs and
>> writing the libdrm port to get it right, and a lot of that is just the
>> boilerplate of having ~8 drivers that all need basically the same logic.
>>
>> > Next, my bigger concern is for distro and casual packagers and people
>> > that maintain large build systems with lots of existing custom
>> > configurations.  Changing from autotools would basically require many
>> > of these existing tools and systems to be rewritten and then deal with
>> > the debugging and fall out from that.  The potential decreased build
>> > time is a nice bonus, but frankly a lot of people/companies have years
>> > of investment in existing tools.
>>
>> Sure, but we're also not the only ones investigating meson. Gnome is using it
>> already, libepoxy is using it, gstreamer is using it. There are patches for
>> weston (written by Daniel Stone) and libinput (written by Peter Hutterer), 
>> there
>> are some other projects in the graphics sphere that people are working on. So
>> even if we as a community decide that meson isn't for us, it's not going 
>> away.
>
> It is worth pointing out that it is currently required by no component
> of an x.org stack.  In the case of libepoxy it was added by a new maintainer
> on a new release and even then autoconf remains.
>
> And as far as I can tell nothing in the entire OpenBSD ports tree
> currently requires meson to build including gnome and gstreamer.
>

but I guess that is conflating two completely different topics..
addition of meson and removal of autotools.  It is probably better
that we treat the topics separately.  I don't see any way that the two
can happen at the same time.

The autotools build probably needs to remain for at least a couple
releases, and I certainly wouldn't mind if some of the other desktop
projects took the leap of dropping autotools first (at least then
various different "distro" consumers will have already dealt with how
to build meson packages)

None of that blocks addition of a meson build system (or what various
developers use day to day)

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
> > I guess I'm a little late to the party here, but I haven't had time to
> > really let all of this sink in and actually look at meson.  It doesn't
> > seem so bad with a quick look and I think I could probably sort it out
> > when the time came, but there would still be a bit of a learning
> > curve.  While that may not be a big deal at the micro level, I have
> > concerns at the macro level.
> >
> > First, I'm concerned it may discourage casual developers and
> > packagers.  autotools isn't great, but most people are familiar enough
> > with it that they can get by.  Most people have enough knowledge of
> > autotools that they can pretty easily diagnose a configuration based
> > failure. There are a lot of resources for autotools.  I'm not sure
> > that would be the case for meson.  Do we as a community feel we have
> > enough meson experience to get people over the hump?  Anything that
> > makes it harder for someone to try a new build or do a bisect is a big
> > problem in my opinion.
> 
> One of the things that's prompted this on our side (I've talked this over with
> other people at Intel before starting), was that clearly we *don't* know
> autotools well enough to get it right. Emil almost always finds cases were 
> we've
> done things *almost*, but not quite right.
> 
> For my part, it took me about 3 or 4 days of reading through the docs and
> writing the libdrm port to get it right, and a lot of that is just the
> boilerplate of having ~8 drivers that all need basically the same logic. 
> 
> > Next, my bigger concern is for distro and casual packagers and people
> > that maintain large build systems with lots of existing custom
> > configurations.  Changing from autotools would basically require many
> > of these existing tools and systems to be rewritten and then deal with
> > the debugging and fall out from that.  The potential decreased build
> > time is a nice bonus, but frankly a lot of people/companies have years
> > of investment in existing tools.
> 
> Sure, but we're also not the only ones investigating meson. Gnome is using it
> already, libepoxy is using it, gstreamer is using it. There are patches for
> weston (written by Daniel Stone) and libinput (written by Peter Hutterer), 
> there
> are some other projects in the graphics sphere that people are working on. So
> even if we as a community decide that meson isn't for us, it's not going away.

It is worth pointing out that it is currently required by no component
of an x.org stack.  In the case of libepoxy it was added by a new maintainer
on a new release and even then autoconf remains.

And as far as I can tell nothing in the entire OpenBSD ports tree
currently requires meson to build including gnome and gstreamer.

> 
> Quoting Rob Clark (2017-03-22 10:07:54)
> > I guess an interesting question (from someone who doesn't know meson
> > yet) would be whether meson could slurp in the Makefile.sources type
> > stuff that we have, which are shared so far between
> > android/scons/autotools (and for the most part, kept developers from
> > having to care *too* much about the different build systems)
> 
> Jason and I have talked about that too. I'd suggested that we could write a
> module for meson to read makefile.sources (since we're surely not the only
> project that would benefit from such a module), except that android is moving 
> to
> blueprint[1] instead of android.mk files. As far as I can tell blueprint 
> doesn't
> support using makefile.sources, so it seems somewhat moot in a world of
> blueprint for android, meson for *.
> 
> I don't think that meson should try to generate blueprint files, since 
> blueprint
> is itself a metabuild system that generates ninja files, and is self
> boot-strapping Go code. I don't know if the community is going to want 
> blueprint
> to live in repo either, since one actually writes Go code for the build 
> system.
> (I'm not objecting prematurely, I'm just pointing out that the design is
> significantly different the Android.mk, and the community will probably want 
> to
> re-evaluate)
> 
> If android doesn't mandate a migration to blueprint, or blueprint does handle
> makefile.sources (I don't think it does), I'd be happy to propose a module for
> meson that could read makefile.sources, and write said module, and get said
> module upstream.
> 
> [1] https://godoc.org/github.com/google/blueprint
> > 
> > If so, that makes it easier to coexist with existing build systems.  I
> > don't think it would be a good idea to remove the autotools build
> > anytime soon.. that should be the last one removed, after meson has
> > replaced scons (and hopefully android?)
> 
> I would imagine that if we did merge meson, we would make at the very least 
> one
> release with meson and autotools (scons is VMWare's thing, they can migrate at
> their leisure), if not two, to 

[Bug 96897] clpeak OpenCL benchmark hangs during compilation on Clover RadeonSI

[bugzilla-daemon]

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

--- Comment #7 from Andy Furniss  ---
(In reply to Andy Furniss from comment #6)
> Same for me on tonga + git llvm/libclc/mesa/clpeak
> 
> Platform: Clover
>   Device: AMD TONGA (DRM 3.13.0 / 4.11.0-rc1-g00c1259, LLVM 5.0.0)
> Driver version  : 17.1.0-devel (Linux x64)
> Compute units   : 28
> Clock frequency : 973 MHz
> clpeak: /mnt/sdb1/Gits/llvm/tools/clang/lib/Sema/Sema.cpp:316:
> clang::Sema::~Sema(): Assertion `DelayedTypos.empty() && "Uncorrected
> typos!"' failed.
> Aborted

This starts with clpeak commit -

16e1b207a4d4e81a0c48c77c950437dca1364cb6 is the first bad commit
commit 16e1b207a4d4e81a0c48c77c950437dca1364cb6
Author: espes 
Date:   Mon Jul 18 17:06:15 2016 -0700

Add support for halfs

Before this it completes OK, but there is some delay ~40 seconds, before
results start appearing.

-- 
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 02/19] drm: Add acquire ctx parameter to ->update_plane

[Russell King - ARM Linux]

On Wed, Mar 22, 2017 at 10:50:41PM +0100, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
> b/drivers/gpu/drm/armada/armada_overlay.c
> index 34cb73d0db77..b54fd8cbd3a6 100644
> --- a/drivers/gpu/drm/armada/armada_overlay.c
> +++ b/drivers/gpu/drm/armada/armada_overlay.c
> @@ -94,7 +94,8 @@ static int
>  armada_ovl_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
>   struct drm_framebuffer *fb,
>   int crtc_x, int crtc_y, unsigned crtc_w, unsigned crtc_h,
> - uint32_t src_x, uint32_t src_y, uint32_t src_w, uint32_t src_h)
> + uint32_t src_x, uint32_t src_y, uint32_t src_w, uint32_t src_h,
> + struct drm_modeset_acquire_ctx *ctx)

I'm rather unhappy that we're ending up with a function taking soo many
arguments.

Most of these have to be stacked on ARM, and I'm guessing most
architectures end up doing something similar.  Is there a reason why we
don't pass pointers to drm_rect's or maybe even consider passing the
drm_plane_state structure in?

I've found that, when cleaning up these code paths in armada, that
storing all the parameters into a drm_plane_state and then validating
it with drm_plane_helper_check_state() is by way the simplest solution,
and of course, it's forward-compatible with atomic modeset.

-- 
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 v5 4/8] drm: Add driver-private objects to atomic state

[Dhinakaran Pandiyan]

From: "Pandiyan, Dhinakaran" 

It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and clearing
it's state. So, lets add void * objects and helper functions that operate
on void * types to keep these objects and states private to the core.
Drivers can then implement specific functions to swap and clear states.
The other advantage having just void * for these objects in
drm_atomic_state is that objects of different types can be managed in the
same state array.

v4: Avoid redundant NULL checks when private_objs array is empty (Maarten)
v3: Macro alignment (Chris)
v2: Added docs and new iterator to filter private objects (Daniel)

Acked-by: Harry Wentland 
Suggested-by: Daniel Vetter 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_atomic.c| 69 +++
 drivers/gpu/drm/drm_atomic_helper.c |  5 ++
 include/drm/drm_atomic.h| 93 +
 3 files changed, 167 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 9b892af..e590148 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct drm_atomic_state 
*state)
kfree(state->connectors);
kfree(state->crtcs);
kfree(state->planes);
+   kfree(state->private_objs);
 }
 EXPORT_SYMBOL(drm_atomic_state_default_release);
 
@@ -184,6 +185,21 @@ void drm_atomic_state_default_clear(struct 
drm_atomic_state *state)
state->planes[i].ptr = NULL;
state->planes[i].state = NULL;
}
+
+   for (i = 0; i < state->num_private_objs; i++) {
+   void *private_obj = state->private_objs[i].obj;
+   void *obj_state = state->private_objs[i].obj_state;
+
+   if (!private_obj)
+   continue;
+
+   state->private_objs[i].funcs->destroy_state(obj_state);
+   state->private_objs[i].obj = NULL;
+   state->private_objs[i].obj_state = NULL;
+   state->private_objs[i].funcs = NULL;
+   }
+   state->num_private_objs = 0;
+
 }
 EXPORT_SYMBOL(drm_atomic_state_default_clear);
 
@@ -978,6 +994,59 @@ static void drm_atomic_plane_print_state(struct 
drm_printer *p,
 }
 
 /**
+ * drm_atomic_get_private_obj_state - get private object state
+ * @state: global atomic state
+ * @obj: private object to get the state for
+ * @funcs: pointer to the struct of function pointers that identify the object
+ * type
+ *
+ * This function returns the private object state for the given private object,
+ * allocating the state if needed. It does not grab any locks as the caller is
+ * expected to care of any required locking.
+ *
+ * RETURNS:
+ *
+ * Either the allocated state or the error code encoded into a pointer.
+ */
+void *
+drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
+ const struct drm_private_state_funcs *funcs)
+{
+   int index, num_objs, i;
+   size_t size;
+   struct __drm_private_objs_state *arr;
+
+   for (i = 0; i < state->num_private_objs; i++)
+   if (obj == state->private_objs[i].obj &&
+   state->private_objs[i].obj_state)
+   return state->private_objs[i].obj_state;
+
+   num_objs = state->num_private_objs + 1;
+   size = sizeof(*state->private_objs) * num_objs;
+   arr = krealloc(state->private_objs, size, GFP_KERNEL);
+   if (!arr)
+   return ERR_PTR(-ENOMEM);
+
+   state->private_objs = arr;
+   index = state->num_private_objs;
+   memset(>private_objs[index], 0, sizeof(*state->private_objs));
+
+   state->private_objs[index].obj_state = funcs->duplicate_state(state, 
obj);
+   if (!state->private_objs[index].obj_state)
+   return ERR_PTR(-ENOMEM);
+
+   state->private_objs[index].obj = obj;
+   state->private_objs[index].funcs = funcs;
+   state->num_private_objs = num_objs;
+
+   DRM_DEBUG_ATOMIC("Added new private object state %p to %p\n",
+state->private_objs[index].obj_state, state);
+
+   return state->private_objs[index].obj_state;
+}
+EXPORT_SYMBOL(drm_atomic_get_private_obj_state);
+
+/**
  * drm_atomic_get_connector_state - get connector state
  * @state: global atomic state object
  * @connector: connector to get state object for
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 4e26b73..1403334 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2001,6 +2001,8 @@ void 

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

[Dan MacDonald]

Hi Philipp

I moved house again on Sunday - that is the second time in two months.
I won't bore you with the details but it means I've not had much time
to myself recently and why I've not been able to test this patch.

As I was saying previously, the only way I can reliably test this is
to do it 'the Arch way' by creating a new kernel package with your
patch rolled in. Doing it that way means I can't directly use your git
repo in the PKGBUILD but instead we need to create a patch that can be
applied against
https://www.kernel.org/pub/linux/kernel/v4.x/testing/linux-4.11-rc3.tar.xz
which is what is downloaded and patched by the armv7-rc PKGBUILD as
feched from:

git clone https://github.com/archlinuxarm/PKGBUILDs.git

See the PKGBUILD under core/linux-armv7-rc. There is a short guide on
how Arch/ABS expects its patches to be formatted here:

https://wiki.archlinux.org/index.php/Patching_in_ABS

I'm surprised I'm the only Arch user on this list - I thought someone
else would already have a dev kernel PKGBUILD for me but apparently
not?

If you really don't have time to create a patch against the latest rc
tarball I can give it a go but I can see me making a royal mess of it!
:)

Thanks

On Mon, Mar 13, 2017 at 11:11 AM, Philipp Zabel  wrote:
> Hi Dan,
>
> On Fri, 2017-03-10 at 11:11 +, Dan MacDonald wrote:
>> Should your patches work fine under 4.11-rc1 Phillipp or do I need to
>> test againt the very latest git? I realise that would be preferred.
>
> The patches from the v4.10-ipu-dp-plane-fix-2 tag should work under
> v4.11-rc1, they are applied on top of v4.11-rc1 in the imx-drm/next
> branch.
>
> regards
> Philipp
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 96897] clpeak OpenCL benchmark hangs during compilation on Clover RadeonSI

[bugzilla-daemon]

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

--- Comment #6 from Andy Furniss  ---
Same for me on tonga + git llvm/libclc/mesa/clpeak

Platform: Clover
  Device: AMD TONGA (DRM 3.13.0 / 4.11.0-rc1-g00c1259, LLVM 5.0.0)
Driver version  : 17.1.0-devel (Linux x64)
Compute units   : 28
Clock frequency : 973 MHz
clpeak: /mnt/sdb1/Gits/llvm/tools/clang/lib/Sema/Sema.cpp:316:
clang::Sema::~Sema(): Assertion `DelayedTypos.empty() && "Uncorrected typos!"'
failed.
Aborted

-- 
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 100067] [OpenCL] const int in argument list crashes build

[bugzilla-daemon]

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

--- Comment #5 from Mig  ---
minimal.cpp compiled with

gcc -c minimal.cpp -g   -o minimal.o

[miguel@antergos-mig extra]$ gdb
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) file ./minimal
Reading symbols from ./minimal...done.
(gdb) b 20
Breakpoint 1 at 0x400cee: file minimal.cpp, line 20.
(gdb) run
Starting program:
/home/miguel/Dokumente/OpenCLExamples/myGEMM-master/extra/minimal 
>>> Initializing OpenCL...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffef7f8700 (LWP 3517)]
[New Thread 0x7fffeedf2700 (LWP 3518)]
[New Thread 0x7fffee5f1700 (LWP 3519)]
[New Thread 0x7fffeddf0700 (LWP 3520)]
[New Thread 0x7fffed5ef700 (LWP 3521)]
% Device: AMD TONGA (DRM 3.9.0 / 4.10.4-1-ARCH, LLVM 3.9.1), 2046.3 MiB memory,
max allocation 1432.4 MiB, driver  17.0.1

Thread 1 "minimal" received signal SIGSEGV, Segmentation fault.
0x72b9eb18 in llvm::SIInstrInfo::getInstSizeInBytes(llvm::MachineInstr
const&) const ()
   from /usr/lib/libLLVM-3.9.so
(gdb)


Also when I compile minimal.cl with 
clang -x cl -target amdgcn-- -mcpu=tonga -Dcl_clang_storage_class_specifiers=1
-Xclang -mlink-bitcode-file -Xclang /usr/local/lib/clc/tonga-amdgcn--.bc
-I/usr/local/include/clc -include /usr/local/include/clc/clc.h minimal.cl
'+fp64-fp16-denormals' is not a recognized feature for this target (ignoring
feature)
'+fp64-fp16-denormals' is not a recognized feature for this target (ignoring
feature)
minimal.cl:2:15: error: unsupported call to function get_global_id.3
__kernel void myGEMM1(const int M, 
  ^
minimal.cl:2:15: error: unsupported call to function get_global_id.3
clang-3.9:
/home/miguel/Downloads/llvm-3.9.1.src/lib/Target/AMDGPU/SIInstrInfo.cpp:2428:
void llvm::SIInstrInfo::legalizeOperands(llvm::MachineInstr&) const: Assertion
`MBB.getParent()->getSubtarget().getGeneration() <
SISubtarget::VOLCANIC_ISLANDS && "FIXME: Need to emit flat atomics here"'
failed.
#0 0x7efe68ec1662 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/home/miguel/Downloads/llvm-3.9.1.src/lib/Support/Unix/Signals.inc:402:0

...

I get errors.

-- 
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: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Eric Anholt (2017-03-22 15:15:46)
> Rob Clark  writes:
> 
> > On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker  wrote:
> >> Here's a not so complete list: 
> >> https://github.com/mesonbuild/meson/wiki/Users
> >>
> >> Notably gnome is moving to meson (and some parts already use it), weston 
> >> and
> >> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
> >> can't say for sure it's going to be around forever, but its been in 
> >> development
> >> since late 2012 and still lands several patches a day, they were 
> >> responsive to
> >> me when I sent a patch (that I still need to respin), and they seem to be
> >> picking up momentum from downstreams.
> >
> >
> > btw, possibly newbie question, but from what I can tell so far in
> > meson docs, there are separate 'meson build && cd build && ninja'
> > steps.. one nice thing about autotools is 'git pull && make' (and it
> > somehow magically figures out whether to re-automake/autoconf).  Not
> > sure if there is a way to do something like that in meson.
> 
> Consider meson build to be ./autogen.sh.  After that point you can git
> pull && make.

Additionally, ninja has the same -C flag as make. So that can be 'meson build &&
ninja -C build' and 'git pull && ninja -C build'


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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Eric Anholt]

Alex Deucher  writes:

> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker  wrote:
>> Why bother, and why would we want this?  
>> │~
>>
>> First it's written in python, which means the potential developer base
>> is massive. And it provides a recursive view for humans, but a
>> non-recursive view for the system. This is the best of both worlds,
>> humans can organize the build system in a way that makes sense, and the
>> machine gets a non-recursive build system. It also uses ninja rather
>> than make, and ninja is faster than make inherently. Meson is also a
>> simpler syntax than autotools or cmake it's not Turing Complete by
>> design nor does it expose python, again, by design. This allows meson
>> itself to be reimplemented in a another language if python becomes a
>> dead-end or a bottle-neck. It also makes it much easier to understand
>> what the build system is doing.
>>
>> What's different about using meson?
>>
>> Well, apart from a faster builds and less magic in the build system? The
>> configure flags are different, it uses -D= more like cmake
>> than the --enable or --with flags of autotools, although oddly it uses
>> --prefix and friends when calling meson, but not with mesonconf, there's
>> a bug opened on this. Meson also doesn't support in-tree builds at all;
>> all builds are done out of tree. It also doesn't provide a "make dist"
>> target, fortunately there's this awesome tool called git, and it
>> provides a "git archive" command that does much the same thing. Did I
>> mention it's fast?
>>
>> Here are the performance numbers I see on a 2 core 4 thread SKL, without
>> initial configuration, and building out of tree (using zsh):
>>
>> For meson the command line is:
>> time (meson build -Dmanpages=true && ninja -C build)
>>
>> For autotools the command line is:
>> time (mdkir build && cd build && ../autotools && make -j5 -l4)
>>
>> meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
>> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
>> meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
>> autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total
>>
>> That's ~4x faster for a cold build and ~10x faster for a hot build.
>>
>> For a make clean && make style build with a hot cache:
>> meson: 4.64s user 0.33s system 334% cpu 1.486 total
>> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>>
>> Why bother with libdrm?
>>
>> It's a simple build system, that could be completely (or mostly
>> completely) be ported in a very short time, and could serve as a tech
>> demo for the advantages of using meson to garner feedback for embarking
>> on a larger project, like mesa (which is what I'm planning to work on
>> next).
>>
>> tl;dr
>>
>> I wrote this as practice for porting Mesa, and figured I might as well
>> send it out since I wrote it.
>>
>> It is very likely that neither of these large patches will show up on the
>> mailing list, but this is available at my github:
>> https://github.com/dcbaker/libdrm wip/meson
>
>
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson.  It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.

Meson is so much nicer for the casual contributor than autoconf.  I've
been hacking at converting the X Server for two days, and I'm now far
more capable at meson than have ever been at autotools, and I've been
doing autotools for 15 years (I don't know how many autotools build
systems I've written over that time, but it's in the tens at least).

I think meson is a win for new users already.  I think we get into even
bigger wins when we consider the use of wrap when there's no distro copy
of a library -- just imagine never having to write instructions like the
"X Server" or "Mesa" parts of this page again:
https://github.com/anholt/mesa/wiki/VC4-complete-Raspbian-upgrade


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

[PATCH v3 0/5] DRM OF graph clean-up

[Rob Herring]

I've been unhappy with the OF graph API for some time and decided to
do something about it. The problem is drivers have to do too much of the
graph parsing and walking themselves. This has led to the same pattern
duplicated over and over. This series adapts DRM drivers to use a new OF
graph helper and added DRM helper.

The DT dependency went into 4.11, so this series can be applied to the DRM
tree without any cross tree dependencies.

I've done some build testing only, so testing appreciated. A git branch is
here[1].

Rob

[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git 
of-graph-helpers


Rob Herring (5):
  drm: make of_drm_find_panel also depend on CONFIG_DRM_PANEL
  drm: of: introduce drm_of_find_panel_or_bridge
  drm: convert drivers to use of_graph_get_remote_node
  drm: convert drivers to use drm_of_find_panel_or_bridge
  drm: omap: use common OF graph helpers

 drivers/gpu/drm/arm/hdlcd_drv.c  |  22 +
 drivers/gpu/drm/arm/malidp_drv.c |  28 +--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c |  73 +---
 drivers/gpu/drm/bridge/adv7511/adv7533.c |  12 +--
 drivers/gpu/drm/bridge/dumb-vga-dac.c|  15 +---
 drivers/gpu/drm/bridge/nxp-ptn3460.c |  16 +---
 drivers/gpu/drm/bridge/parade-ps8622.c   |  16 +---
 drivers/gpu/drm/bridge/tc358767.c|  27 +-
 drivers/gpu/drm/bridge/ti-tfp410.c   |  15 ++--
 drivers/gpu/drm/drm_of.c |  52 
 drivers/gpu/drm/exynos/exynos_dp.c   |  35 +++-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  |  16 +---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |  13 +--
 drivers/gpu/drm/exynos/exynos_drm_mic.c  |  25 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c|  39 ++---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c |  27 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c  |  30 +--
 drivers/gpu/drm/imx/imx-ldb.c|  27 ++
 drivers/gpu/drm/imx/parallel-display.c   |  36 +---
 drivers/gpu/drm/mediatek/mtk_dpi.c   |  12 +--
 drivers/gpu/drm/mediatek/mtk_dsi.c   |  23 ++---
 drivers/gpu/drm/mediatek/mtk_hdmi.c  |  26 +-
 drivers/gpu/drm/meson/meson_venc_cvbs.c  |  19 +
 drivers/gpu/drm/msm/dsi/dsi_host.c   |   2 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c  |  28 +--
 drivers/gpu/drm/mxsfb/mxsfb_out.c|  40 ++---
 drivers/gpu/drm/omapdrm/dss/dpi.c|   2 +-
 drivers/gpu/drm/omapdrm/dss/dsi.c|   3 +-
 drivers/gpu/drm/omapdrm/dss/dss-of.c | 102 +--
 drivers/gpu/drm/omapdrm/dss/dss.c|  61 +++---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c  |   3 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c  |   3 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h|  11 ---
 drivers/gpu/drm/omapdrm/dss/sdi.c|   2 +-
 drivers/gpu/drm/omapdrm/dss/venc.c   |   3 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  |  26 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c  |  18 ++--
 drivers/gpu/drm/sun4i/sun4i_rgb.c|  11 +--
 drivers/gpu/drm/sun4i/sun4i_tcon.c   |  90 ++--
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |  12 +--
 drivers/gpu/drm/tilcdc/tilcdc_external.c |  68 ++-
 drivers/gpu/drm/vc4/vc4_dpi.c|  15 +---
 include/drm/drm_of.h |  13 +++
 include/drm/drm_panel.h  |   2 +-
 44 files changed, 238 insertions(+), 881 deletions(-)

--
2.10.1

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

Re: [PATCH v4 2/6] media: uapi: Add RGB and YUV bus formats for Synopsys HDMI TX Controller

[Jose Abreu]

Hi Neil,


On 21-03-2017 15:12, Neil Armstrong wrote:
> In order to describe the RGB and YUV bus formats used to feed the
> Synopsys DesignWare HDMI TX Controller, add missing formats to the
> list of Bus Formats.
>
> Documentation for these formats is added in a separate patch.
>
> Reviewed-by: Archit Taneja 
> Signed-off-by: Neil Armstrong 

Reviewed-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

> ---
>  include/uapi/linux/media-bus-format.h | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/media-bus-format.h 
> b/include/uapi/linux/media-bus-format.h
> index 2168759..6c8f31c 100644
> --- a/include/uapi/linux/media-bus-format.h
> +++ b/include/uapi/linux/media-bus-format.h
> @@ -33,7 +33,7 @@
>  
>  #define MEDIA_BUS_FMT_FIXED  0x0001
>  
> -/* RGB - next is 0x1018 */
> +/* RGB - next is 0x101b */
>  #define MEDIA_BUS_FMT_RGB444_1X120x1016
>  #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE0x1001
>  #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE0x1002
> @@ -57,8 +57,11 @@
>  #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012
>  #define MEDIA_BUS_FMT_ARGB_1X32  0x100d
>  #define MEDIA_BUS_FMT_RGB888_1X32_PADHI  0x100f
> +#define MEDIA_BUS_FMT_RGB101010_1X30 0x1018
> +#define MEDIA_BUS_FMT_RGB121212_1X36 0x1019
> +#define MEDIA_BUS_FMT_RGB161616_1X48 0x101a
>  
> -/* YUV (including grey) - next is0x2026 */
> +/* YUV (including grey) - next is0x202c */
>  #define MEDIA_BUS_FMT_Y8_1X8 0x2001
>  #define MEDIA_BUS_FMT_UV8_1X80x2015
>  #define MEDIA_BUS_FMT_UYVY8_1_5X80x2002
> @@ -90,12 +93,18 @@
>  #define MEDIA_BUS_FMT_YVYU10_1X200x200e
>  #define MEDIA_BUS_FMT_VUY8_1X24  0x2024
>  #define MEDIA_BUS_FMT_YUV8_1X24  0x2025
> +#define MEDIA_BUS_FMT_UYYVYY8_1X24   0x2026
>  #define MEDIA_BUS_FMT_UYVY12_1X240x2020
>  #define MEDIA_BUS_FMT_VYUY12_1X240x2021
>  #define MEDIA_BUS_FMT_YUYV12_1X240x2022
>  #define MEDIA_BUS_FMT_YVYU12_1X240x2023
>  #define MEDIA_BUS_FMT_YUV10_1X30 0x2016
> +#define MEDIA_BUS_FMT_UYYVYY10_1X30  0x2027
>  #define MEDIA_BUS_FMT_AYUV8_1X32 0x2017
> +#define MEDIA_BUS_FMT_UYYVYY12_1X36  0x2028
> +#define MEDIA_BUS_FMT_YUV12_1X36 0x2029
> +#define MEDIA_BUS_FMT_YUV16_1X48 0x202a
> +#define MEDIA_BUS_FMT_UYYVYY16_1X48  0x202b
>  
>  /* Bayer - next is   0x3021 */
>  #define MEDIA_BUS_FMT_SBGGR8_1X8 0x3001

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 17/03/17 02:28, Brian Paul wrote:

On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand > wrote:

On March 16, 2017 5:41:24 PM Emil Velikov > wrote:

On 17 March 2017 at 00:21, Dylan Baker > wrote:

Hi Emil,

Quoting Emil Velikov (2017-03-16 16:35:33)

While I can see you're impressed by Meson, I would
kindly urge you to
not use it here. As you look closely you can see that
one could
trivially improve the times, yet the biggest thing is
that most of the
code in libdrm must go ;-)


Perhaps I wasn't clear enough, I don't really expect this to
land ever. I sent
it out more because I'd written it and it works and is a
useful demonstration of
meson+ninja performance. Obviously 20 seconds -> 5 seconds
isn't a huge deal :);
but in a larger project, consider that a 4x speedup would be
4 minutes to 1
minute, and that is a huge difference in time.

You are still failing to see past your usecase. As said before - if
there's any need to improve things say so.
Note that you simply cannot apply the 1000x speedup in any
situation.


Yes, you can't just linearly apply any scaling factor.  However,
when you build mesa on a machine with a decent number of threads (I
think our build machine for the CI system has 32 threads),
autotools+make is slow as mud.  Also, there's very little you can do
to speed up configure since it's a pile of shell and perl that
inherently runs single-threaded and is fairly complex due to mesa's
complicated dependencies.

As the port is not 1:1 wrt the autoconf one, the
performance numbers
above are comparing apples to oranges.


I fail to see what I'm missing from meson that would have an
effect on the
times I reported. There are some files that are installed by
autoconf that I
didn't bother to install with meson (because I don't expect
this to land). Since
I didn't time installs, I don't see how it isn't an apples
to apples comparison.

You already (explicitly) mentioned some differences. Admittedly
not a
deal breaker.

I understand that libdrm is a pessimal case for
recursive-make since most
sub folders contain < 5 C files, However, even if you were
to flatten the make
files meson+ninja would still be faster when you consider
that meson
configures and builds faster than autotools configures.

That's correct. If is so concerned - they should slim down the
configure.ac  ;-)


There are real limits as to what you can do there.

If you/others are unhappy with the build times of libdrm
- poke me on
IRC. I will give you some easy tips on how to improve those.

You have some good python knowledge - I would kindly
urge you to
improve/rewrite the slow and/or hacky python scripts we
have in mesa.
This is a topic that was mentioned multiple times, and a
part where
everyone will be glad to see some progress.

Thanks
Emil


The real goal here is to do mesa (in case I didn't make that
clear either), and
the advantage for mesa is not just performance, it's that
meson supports visual
studio on windows; which means that we could hopefully not
just get faster
builds, but also replace both autotools and scons with a
single build system.

Yes that was more than clear. Yet it won't fly, I'm afraid.

The VMWare people like their SCons,


??



How much?  I would really rather the VMWare people speak on behalf
of VMWare.  Meson is the single best shot we've ever had for
replacing both with one build system.  I'm sure the VMware people
would like to have a build system that gets maintained by the
community as a whole.


Sure, I'd like to see one build system instead of two.  Meson supports
Windows so that's good.  But the big issue is our automated build
system.  Replacing SCons with Meson could be a big deal in that
context.  It would at least involve pulling Meson into our toolchain and
rewriting a bunch of Python code to grok Meson.  I'd have to go off and
investigate that to even see if it's a possibility.  Maybe next week.



I 

Re: [PATCH v3 1/5] drm: make of_drm_find_panel also depend on CONFIG_DRM_PANEL

[Eric Anholt]

Rob Herring  writes:

> For drm_of_find_panel_or_bridge() added in the next commit, an empty
> version of of_drm_find_panel is needed for !CONFIG_DRM_PANEL.
>
> Signed-off-by: Rob Herring 

Makes sense.

Reviewed-by: Eric Anholt 


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

[PATCH v3 2/5] drm: of: introduce drm_of_find_panel_or_bridge

[Rob Herring]

Many drivers have a common pattern of searching the OF graph for either an
attached panel or bridge and then finding the DRM struct for the panel
or bridge. Also, most drivers need to handle deferred probing when the
DRM device is not yet instantiated. Create a common function,
drm_of_find_panel_or_bridge, to find the connected node and the
associated DRM panel or bridge device.

Signed-off-by: Rob Herring 
Acked-by: Philipp Zabel 
---
v3:
- rebase to v4.11-rc2
- fix comment that DT node is encoder ouput ports

 drivers/gpu/drm/drm_of.c | 52 
 include/drm/drm_of.h | 13 
 2 files changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index b5f2f0fece99..2120f33bdf4a 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -3,8 +3,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 

 static void drm_release_of(struct device *dev, void *data)
@@ -208,3 +210,53 @@ int drm_of_encoder_active_endpoint(struct device_node 
*node,
return -EINVAL;
 }
 EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
+
+/*
+ * drm_of_find_panel_or_bridge - return connected panel or bridge device
+ * @np: device tree node containing encoder output ports
+ * @panel: pointer to hold returned drm_panel
+ * @bridge: pointer to hold returned drm_bridge
+ *
+ * Given a DT node's port and endpoint number, find the connected node and
+ * return either the associated struct drm_panel or drm_bridge device. Either
+ * @panel or @bridge must not be NULL.
+ *
+ * Returns zero if successful, or one of the standard error codes if it fails.
+ */
+int drm_of_find_panel_or_bridge(const struct device_node *np,
+   int port, int endpoint,
+   struct drm_panel **panel,
+   struct drm_bridge **bridge)
+{
+   int ret = -EPROBE_DEFER;
+   struct device_node *remote;
+
+   if (!panel && !bridge)
+   return -EINVAL;
+
+   remote = of_graph_get_remote_node(np, port, endpoint);
+   if (!remote)
+   return -ENODEV;
+
+   if (panel) {
+   *panel = of_drm_find_panel(remote);
+   if (*panel)
+   ret = 0;
+   }
+
+   /* No panel found yet, check for a bridge next. */
+   if (bridge) {
+   if (ret) {
+   *bridge = of_drm_find_bridge(remote);
+   if (*bridge)
+   ret = 0;
+   } else {
+   *bridge = NULL;
+   }
+
+   }
+
+   of_node_put(remote);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 26a64805cc15..f86507f0599b 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -8,6 +8,8 @@ struct component_match;
 struct device;
 struct drm_device;
 struct drm_encoder;
+struct drm_panel;
+struct drm_bridge;
 struct device_node;

 #ifdef CONFIG_OF
@@ -23,6 +25,10 @@ extern int drm_of_component_probe(struct device *dev,
 extern int drm_of_encoder_active_endpoint(struct device_node *node,
  struct drm_encoder *encoder,
  struct of_endpoint *endpoint);
+extern int drm_of_find_panel_or_bridge(const struct device_node *np,
+  int port, int endpoint,
+  struct drm_panel **panel,
+  struct drm_bridge **bridge);
 #else
 static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
  struct device_node *port)
@@ -52,6 +58,13 @@ static inline int drm_of_encoder_active_endpoint(struct 
device_node *node,
 {
return -EINVAL;
 }
+static inline int drm_of_find_panel_or_bridge(const struct device_node *np,
+ int port, int endpoint,
+ struct drm_panel **panel,
+ struct drm_bridge **bridge)
+{
+   return -EINVAL;
+}
 #endif

 static inline int drm_of_encoder_active_endpoint_id(struct device_node *node,
--
2.10.1

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

[RFC 0/5] HDMI 2.0+ video modes handling in DRM core

[Jose Abreu]

Hi all,

This is a RFC series that aims to collect comments regarding the handling
of HDMI 2.0+ video modes and features in the DRM core.

Some of the HDMI 2.0 features are already implemented and only affect kernel
drivers (SDCD for example). There are some features, though, which can,
and will, affect userspace.

It is clear that userspace can't be broken, so, based on previous discussions
I started implementing a "HDMI 2.0+ knob" which can be set by userspace to
enable HDMI 2.0+ features.

For now this only limits the exposing of the video modes defined in CEA-861-F,
but it can be extended adding, for example, YCbCr 4:2:0.

Please do not see this as a formal patch as this wasn't even compiled tested 
but,
please, feel free to comment :)

NOTE: The adding of the new video modes timings was originally done by
Shashank Sharma  so, credit to him. I modified it a
little bit (added the HDMI 2.0+ flag) and I don't know if I should add his
signed-off-by as it was modified.

Best regards,
Jose Miguel Abreu

Cc: Carlos Palminha 
Cc: dri-devel@lists.freedesktop.org

Jose Abreu (5):
  drm: Add HDMI 2.0+ features exposing knob
  drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag
  drm: edid: Add HDMI 2.0 CEA video modes
  drm: connector: Add hdmi2_allowed flag
  drm: Do not expose HDMI 2.0+ modes to userspace/drivers unless asked
to

 drivers/gpu/drm/drm_connector.c|   2 +
 drivers/gpu/drm/drm_edid.c | 258 +
 drivers/gpu/drm/drm_ioctl.c|   5 +
 drivers/gpu/drm/drm_probe_helper.c |   9 +-
 include/drm/drm_connector.h|   2 +
 include/drm/drm_file.h |   8 ++
 include/drm/drm_modes.h|  14 ++
 include/uapi/drm/drm.h |   7 +
 include/uapi/drm/drm_mode.h|   9 ++
 9 files changed, 313 insertions(+), 1 deletion(-)

-- 
1.9.1


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

[RFC 4/5] drm: connector: Add hdmi2_allowed flag

[Jose Abreu]

Add a new HDMI 2.0+ flag which will signal core that the
connector can handle HDMI 2.0+ video modes.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: dri-devel@lists.freedesktop.org
---
 include/drm/drm_connector.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index f8b766d..f3db9bd 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -637,6 +637,7 @@ struct drm_cmdline_mode {
  * @interlace_allowed: can this connector handle interlaced modes?
  * @doublescan_allowed: can this connector handle doublescan?
  * @stereo_allowed: can this connector handle stereo modes?
+ * @hdmi2_allowed: can this connector handle HDMI 2.0+ modes?
  * @funcs: connector control functions
  * @edid_blob_ptr: DRM property containing EDID if present
  * @properties: property tracking for this connector
@@ -701,6 +702,7 @@ struct drm_connector {
bool interlace_allowed;
bool doublescan_allowed;
bool stereo_allowed;
+   bool hdmi2_allowed;
/**
 * @registered: Is this connector exposed (registered) with userspace?
 * Protected by @mutex.
-- 
1.9.1


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

Re: [RFC 0/5] HDMI 2.0+ video modes handling in DRM core

[Jose Abreu]

++ Daniel

++ Ville

++ Shashank


On 22-03-2017 17:35, Jose Abreu wrote:
> Hi all,
>
> This is a RFC series that aims to collect comments regarding the handling
> of HDMI 2.0+ video modes and features in the DRM core.
>
> Some of the HDMI 2.0 features are already implemented and only affect kernel
> drivers (SDCD for example). There are some features, though, which can,
> and will, affect userspace.
>
> It is clear that userspace can't be broken, so, based on previous discussions
> I started implementing a "HDMI 2.0+ knob" which can be set by userspace to
> enable HDMI 2.0+ features.
>
> For now this only limits the exposing of the video modes defined in CEA-861-F,
> but it can be extended adding, for example, YCbCr 4:2:0.
>
> Please do not see this as a formal patch as this wasn't even compiled tested 
> but,
> please, feel free to comment :)
>
> NOTE: The adding of the new video modes timings was originally done by
> Shashank Sharma  so, credit to him. I modified it a
> little bit (added the HDMI 2.0+ flag) and I don't know if I should add his
> signed-off-by as it was modified.
>
> Best regards,
> Jose Miguel Abreu
>
> Cc: Carlos Palminha 
> Cc: dri-devel@lists.freedesktop.org
>
> Jose Abreu (5):
>   drm: Add HDMI 2.0+ features exposing knob
>   drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag
>   drm: edid: Add HDMI 2.0 CEA video modes
>   drm: connector: Add hdmi2_allowed flag
>   drm: Do not expose HDMI 2.0+ modes to userspace/drivers unless asked
> to
>
>  drivers/gpu/drm/drm_connector.c|   2 +
>  drivers/gpu/drm/drm_edid.c | 258 
> +
>  drivers/gpu/drm/drm_ioctl.c|   5 +
>  drivers/gpu/drm/drm_probe_helper.c |   9 +-
>  include/drm/drm_connector.h|   2 +
>  include/drm/drm_file.h |   8 ++
>  include/drm/drm_modes.h|  14 ++
>  include/uapi/drm/drm.h |   7 +
>  include/uapi/drm/drm_mode.h|   9 ++
>  9 files changed, 313 insertions(+), 1 deletion(-)
>

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

Re: [Intel-gfx] [PATCH v4 8/8] drm/dp: Track MST link bandwidth

[Pandiyan, Dhinakaran]

On Wed, 2017-03-22 at 13:30 +0100, Maarten Lankhorst wrote:
> Op 16-03-17 om 08:10 schreef Dhinakaran Pandiyan:
> > From: "Pandiyan, Dhinakaran" 
> >
> > Use the added helpers to track MST link bandwidth for atomic modesets.
> > Link bw is acquired in the ->atomic_check() phase when CRTCs are being
> > enabled with drm_atomic_find_vcpi_slots() instead of drm_find_vcpi_slots().
> > Similarly, link bw is released during ->atomic_check() with the connector
> > helper callback ->atomic_release() when CRTCs are disabled.
> >
> > v2:
> > Squashed atomic_release() implementation and caller (Daniel)
> > Fixed logic for connector-crtc switching case (Daniel)
> > Fixed logic for suspend-resume case.
> >
> > Cc: Daniel Vetter 
> > Cc: Archit Taneja 
> > Cc: Maarten Lankhorst 
> > Cc: Chris Wilson 
> > Cc: Harry Wentland 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 38 
> > ++---
> >  1 file changed, 31 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index c1f62eb..a8f40fa 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -39,9 +39,9 @@ static bool intel_dp_mst_compute_config(struct 
> > intel_encoder *encoder,
> > struct intel_dp *intel_dp = _dig_port->dp;
> > struct intel_connector *connector =
> > to_intel_connector(conn_state->connector);
> > -   struct drm_atomic_state *state;
> > +   struct drm_atomic_state *state = pipe_config->base.state;
> > int bpp;
> > -   int lane_count, slots;
> > +   int lane_count, slots = 0;
> > const struct drm_display_mode *adjusted_mode = 
> > _config->base.adjusted_mode;
> > int mst_pbn;
> >  
> > @@ -57,30 +57,53 @@ static bool intel_dp_mst_compute_config(struct 
> > intel_encoder *encoder,
> >  * seem to suggest we should do otherwise.
> >  */
> > lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> > -
> > pipe_config->lane_count = lane_count;
> >  
> > pipe_config->pipe_bpp = bpp;
> > pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
> >  
> > -   state = pipe_config->base.state;
> > -
> > if (drm_dp_mst_port_has_audio(_dp->mst_mgr, connector->port))
> > pipe_config->has_audio = true;
> > -   mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
> >  
> > +   mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
> > pipe_config->pbn = mst_pbn;
> > -   slots = drm_dp_find_vcpi_slots(_dp->mst_mgr, mst_pbn);
> >  
> > intel_link_compute_m_n(bpp, lane_count,
> >adjusted_mode->crtc_clock,
> >pipe_config->port_clock,
> >_config->dp_m_n);
> >  
> > +   if (pipe_config->base.active) {
> > +   slots = drm_dp_atomic_find_vcpi_slots(state, _dp->mst_mgr,
> > + connector->port, mst_pbn);
> > +   if (slots < 0) {
> > +   DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots);
> > +   return false;
> > +   }
> > +   }
> > pipe_config->dp_m_n.tu = slots;
> >  
> > return true;
> > +}
> > +
> > +static void intel_dp_mst_atomic_release(struct drm_connector *connector,
> > +   struct drm_connector_state *conn_state)
> > +{
> > +   struct intel_dp_mst_encoder *intel_mst;
> > +   struct drm_dp_mst_topology_mgr *mgr;
> > +   struct drm_encoder *encoder;
> > +   struct intel_connector *intel_connector = to_intel_connector(connector);
> > +   struct drm_atomic_state *state = conn_state->state;
> > +   int slots;
> > +
> > +   encoder = connector->state->best_encoder;
> > +   intel_mst = enc_to_mst(encoder);
> > +   mgr = _mst->primary->dp.mst_mgr;
> >  
> > +   slots = drm_dp_atomic_release_vcpi_slots(state, mgr,
> > +intel_connector->port);
> > +   if (slots < 0)
> > +   DRM_DEBUG_KMS("failed releasing vcpi slots:%d\n", slots);
> >  }
> >  
> >  static void intel_mst_disable_dp(struct intel_encoder *encoder,
> > @@ -387,6 +410,7 @@ static const struct drm_connector_helper_funcs 
> > intel_dp_mst_connector_helper_fun
> > .mode_valid = intel_dp_mst_mode_valid,
> > .atomic_best_encoder = intel_mst_atomic_best_encoder,
> > .best_encoder = intel_mst_best_encoder,
> > +   .atomic_release = intel_dp_mst_atomic_release,
> >  };
> >  
> >  static void intel_dp_mst_encoder_destroy(struct drm_encoder *encoder)
> 
> Is there any issue into attempting to release vcpi slots when they're already 
> released? If not, for patches 1-3 5-8
> 
> Reviewed-by: Maarten Lankhorst 
> 

Thanks 

[RFC 1/5] drm: Add HDMI 2.0+ features exposing knob

[Jose Abreu]

We can't expect userspace to have full support for all HDMI 2.0+
features. Instead of expecting/waiting for userspace to support
the new features add a knob, much like the stereo knob, so that
DRM core will only expose the features when asked too.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/drm_ioctl.c | 5 +
 include/drm/drm_file.h  | 8 
 include/uapi/drm/drm.h  | 7 +++
 3 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index a7c61c2..2430e2e 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -318,6 +318,11 @@ static int drm_getcap(struct drm_device *dev, void *data, 
struct drm_file *file_
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
+   case DRM_CLIENT_CAP_HDMI2:
+   if (req->value > 1)
+   return -EINVAL;
+   file_priv->hdmi2_allowed = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 5dd27ae..7b97d85 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -192,6 +192,14 @@ struct drm_file {
unsigned is_master:1;
 
/**
+* @hdmi2_allowed:
+*
+* True if client understands HDMI 2.0+ features like, for example,
+* extended aspect ratios
+*/
+   unsigned hdmi2_allowed:1;
+
+   /**
 * @master:
 *
 * Master this node is currently associated with. Only relevant if
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index b2c5284..9e25138 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -678,6 +678,13 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_ATOMIC  3
 
+/**
+ * DRM_CLIENT_CAP_HDMI2
+ *
+ * If set to 1, the DRM core will expose HDMI 2.0+ features to userspace
+ */
+#define DRM_CLIENT_CAP_HDMI2   4
+
 /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
-- 
1.9.1


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

Re: [Intel-gfx] [PATCH v4 4/8] drm: Add driver-private objects to atomic state

[Pandiyan, Dhinakaran]

On Wed, 2017-03-22 at 11:00 +0100, Maarten Lankhorst wrote:
> Op 16-03-17 om 08:10 schreef Dhinakaran Pandiyan:
> > From: "Pandiyan, Dhinakaran" 
> >
> > It is necessary to track states for objects other than connector, crtc
> > and plane for atomic modesets. But adding objects like DP MST link
> > bandwidth to drm_atomic_state would mean that a non-core object will be
> > modified by the core helper functions for swapping and clearing
> > it's state. So, lets add void * objects and helper functions that operate
> > on void * types to keep these objects and states private to the core.
> > Drivers can then implement specific functions to swap and clear states.
> > The other advantage having just void * for these objects in
> > drm_atomic_state is that objects of different types can be managed in the
> > same state array.
> >
> > v2: Added docs and new iterator to filter private objects (Daniel)
> > v3: Macro alignment (Chris)
> >
> > Cc: Daniel Vetter 
> > Cc: Archit Taneja 
> > Cc: Maarten Lankhorst 
> > Cc: Chris Wilson 
> > Cc: Harry Wentland 
> > Acked-by: Harry Wentland 
> > Suggested-by: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> 
> Mostly looks good, but too many null checks. I think it's best to get rid of 
> them all
> by freeing state->driver_private in default_clear() or setting 
> num_private_objs to 0.
> It would remove the need for all null checks I think..
> 
> ~Maarten
> 

Did you mean the NULL checks in this loop inside
drm_atomic_get_private_obj_state()

+   for (i = 0; i < state->num_private_objs; i++)
+   if (obj == state->private_objs[i].obj &&
+   state->private_objs[i].obj_state)
+   return state->private_objs[i].obj_state;

and the fact that I am not setting num_private_objs = 0 in
drm_atomic_state_default_clear() ?

-DK
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH v3 3/5] drm: convert drivers to use of_graph_get_remote_node

[Rob Herring]

Convert drivers to use the new of_graph_get_remote_node() helper
instead of parsing the endpoint node and then getting the remote device
node. Now drivers can just specify the device node and which
port/endpoint and get back the connected remote device node. The details
of the graph binding are nicely abstracted into the core OF graph code.

This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.

Signed-off-by: Rob Herring 
Acked-by: Neil Armstrong 
Tested-by: Liviu Dudau 
Tested-by: Eric Anholt 
Tested-by: Jyri Sarha 
Tested by: Archit Taneja 
---
v3:
- rebase to v4.11-rc2

 drivers/gpu/drm/arm/hdlcd_drv.c | 22 ++--
 drivers/gpu/drm/arm/malidp_drv.c| 28 ++
 drivers/gpu/drm/bridge/adv7511/adv7533.c| 12 +
 drivers/gpu/drm/bridge/dumb-vga-dac.c   | 15 ++
 drivers/gpu/drm/bridge/ti-tfp410.c  | 15 ++
 drivers/gpu/drm/exynos/exynos_drm_dpi.c | 16 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 ++---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 25 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 30 +--
 drivers/gpu/drm/mediatek/mtk_dpi.c  | 12 ++---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 26 ++
 drivers/gpu/drm/meson/meson_venc_cvbs.c | 19 ++-
 drivers/gpu/drm/msm/dsi/dsi_host.c  |  2 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 28 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 18 +++
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c| 12 +
 drivers/gpu/drm/tilcdc/tilcdc_external.c| 68 +++--
 drivers/gpu/drm/vc4/vc4_dpi.c   | 15 ++
 18 files changed, 54 insertions(+), 322 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index 4ce4f970920b..924df354c0ab 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -423,29 +423,13 @@ static int compare_dev(struct device *dev, void *data)

 static int hdlcd_probe(struct platform_device *pdev)
 {
-   struct device_node *port, *ep;
+   struct device_node *port;
struct component_match *match = NULL;

-   if (!pdev->dev.of_node)
-   return -ENODEV;
-
/* there is only one output port inside each device, find it */
-   ep = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
-   if (!ep)
-   return -ENODEV;
-
-   if (!of_device_is_available(ep)) {
-   of_node_put(ep);
+   port = of_graph_get_remote_node(pdev->dev.of_node, 0, 0);
+   if (!port)
return -ENODEV;
-   }
-
-   /* add the remote encoder port as component */
-   port = of_graph_get_remote_port_parent(ep);
-   of_node_put(ep);
-   if (!port || !of_device_is_available(port)) {
-   of_node_put(port);
-   return -EAGAIN;
-   }

drm_of_component_match_add(>dev, , compare_dev, port);
of_node_put(port);
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 8b0672d4aee9..3470b8c80777 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -315,7 +315,6 @@ static int malidp_bind(struct device *dev)
 {
struct resource *res;
struct drm_device *drm;
-   struct device_node *ep;
struct malidp_drm *malidp;
struct malidp_hw_device *hwdev;
struct platform_device *pdev = to_platform_device(dev);
@@ -430,12 +429,7 @@ static int malidp_bind(struct device *dev)
goto init_fail;

/* Set the CRTC's port so that the encoder component can find it */
-   ep = of_graph_get_next_endpoint(dev->of_node, NULL);
-   if (!ep) {
-   ret = -EINVAL;
-   goto port_fail;
-   }
-   malidp->crtc.port = of_get_next_parent(ep);
+   malidp->crtc.port = of_graph_get_port_by_id(dev->of_node, 0);

ret = component_bind_all(dev, drm);
if (ret) {
@@ -490,7 +484,6 @@ static int malidp_bind(struct device *dev)
 bind_fail:
of_node_put(malidp->crtc.port);
malidp->crtc.port = NULL;
-port_fail:
malidp_fini(drm);
 init_fail:
drm->dev_private = NULL;
@@ -548,29 +541,16 @@ static int malidp_compare_dev(struct device *dev, void 
*data)

 static int malidp_platform_probe(struct platform_device *pdev)
 {
-   struct device_node *port, *ep;
+   struct device_node *port;
struct component_match *match = NULL;

if (!pdev->dev.of_node)
return -ENODEV;

/* there is only one output port inside each device, find it */
-   ep = 

[RFC 2/5] drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag

[Jose Abreu]

Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new
flag which will signal userspace that this is a HDMI 2.0+ mode. It
is expected that these new flags will not be exported to userspace
unless client asks to.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: dri-devel@lists.freedesktop.org
---
 include/uapi/drm/drm_mode.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 8c67fc0..62e679c 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -89,6 +89,8 @@
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354
 
 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -98,6 +100,13 @@
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
+
+/* HDMI 2.0+ mode flag: will only be set if client supports it */
+#define DRM_MODE_FLAG_HDMI2(1<<23)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
1.9.1


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

Re: [PATCH v7] drm/rockchip: Refactor the component match logic.

[jeffy]

Hi Sean,

On 03/22/2017 03:55 AM, Sean Paul wrote:

On Tue, Mar 21, 2017 at 02:42:11PM +0800, Jeffy Chen wrote:

Currently we are adding all components from the dts, if one of their
drivers been disabled, we would not be able to bring up others.

Refactor component match logic, follow exynos drm.

Signed-off-by: Jeffy Chen 
Reviewed-by: Andrzej Hajda 
Acked-by: Mark Yao 
Tested-by: Heiko Stuebner 

---

Changes in v7:
Add Heiko Stuebner 's Tested-by.

Changes in v6:
Add Mark Yao 's Acked-by.

Changes in v5:
Fix compile error reported by Heiko Stuebner .

Changes in v4:
Use platform_driver helpers to register/unregister drivers.
Fix null pointer error reported by Heiko Stuebner .

Changes in v3:
Address Andrzej Hajda 's comments.

Changes in v2:
Address Sean Paul 's comments.

  drivers/gpu/drm/rockchip/Kconfig|  10 +-
  drivers/gpu/drm/rockchip/Makefile   |  16 +--
  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |   9 +-
  drivers/gpu/drm/rockchip/cdn-dp-core.c  |   8 +-
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  |   8 +-
  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  10 +-
  drivers/gpu/drm/rockchip/inno_hdmi.c|  10 +-
  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 138 +++-
  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   6 ++
  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   8 +-
  10 files changed, 115 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0e4eb84..50c41c0 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -13,7 +13,7 @@ config DRM_ROCKCHIP
  IP found on the SoC.

  config ROCKCHIP_ANALOGIX_DP
-   tristate "Rockchip specific extensions for Analogix DP driver"
+   bool "Rockchip specific extensions for Analogix DP driver"
depends on DRM_ROCKCHIP
select DRM_ANALOGIX_DP
help
@@ -22,7 +22,7 @@ config ROCKCHIP_ANALOGIX_DP
  on RK3288 based SoC, you should selet this option.

  config ROCKCHIP_CDN_DP
-tristate "Rockchip cdn DP"
+bool "Rockchip cdn DP"
  depends on DRM_ROCKCHIP
depends on EXTCON
select SND_SOC_HDMI_CODEC if SND_SOC
@@ -33,7 +33,7 @@ config ROCKCHIP_CDN_DP
  option.

  config ROCKCHIP_DW_HDMI
-tristate "Rockchip specific extensions for Synopsys DW HDMI"
+bool "Rockchip specific extensions for Synopsys DW HDMI"
  depends on DRM_ROCKCHIP
  select DRM_DW_HDMI
  help
@@ -43,7 +43,7 @@ config ROCKCHIP_DW_HDMI
  option.

  config ROCKCHIP_DW_MIPI_DSI
-   tristate "Rockchip specific extensions for Synopsys DW MIPI DSI"
+   bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
depends on DRM_ROCKCHIP
select DRM_MIPI_DSI
help
@@ -53,7 +53,7 @@ config ROCKCHIP_DW_MIPI_DSI
 option.

  config ROCKCHIP_INNO_HDMI
-   tristate "Rockchip specific extensions for Innosilicon HDMI"
+   bool "Rockchip specific extensions for Innosilicon HDMI"
depends on DRM_ROCKCHIP
help
  This selects support for Rockchip SoC specific extensions
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index c931e2a..fa8dc9d 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -3,14 +3,14 @@
  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.

  rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
-   rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
+   rockchip_drm_gem.o rockchip_drm_psr.o \
+   rockchip_drm_vop.o rockchip_vop_reg.o
  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o

-obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
-obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp.o
-cdn-dp-objs := cdn-dp-core.o cdn-dp-reg.o
-obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
-obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
-obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o

-obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
+obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8548e82..91ebe5c 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c

[PATCH v8] drm/rockchip: Refactor the component match logic.

[Jeffy Chen]

Currently we are adding all components from the dts, if one of their
drivers been disabled, we would not be able to bring up others.

Refactor component match logic, follow exynos drm.

Signed-off-by: Jeffy Chen 
Reviewed-by: Andrzej Hajda 
Acked-by: Mark Yao 
Tested-by: Heiko Stuebner 

---

Changes in v8:
Address Sean Paul 's comments.

Changes in v7:
Add Heiko Stuebner 's Tested-by.

Changes in v6:
Add Mark Yao 's Acked-by.

Changes in v5:
Fix compile error reported by Heiko Stuebner .

Changes in v4:
Use platform_driver helpers to register/unregister drivers.
Fix null pointer error reported by Heiko Stuebner .

Changes in v3:
Address Andrzej Hajda 's comments.

Changes in v2:
Address Sean Paul 's comments.

 drivers/gpu/drm/rockchip/Kconfig|  10 +-
 drivers/gpu/drm/rockchip/Makefile   |  16 +--
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |   9 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.c  |   8 +-
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c  |   8 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  10 +-
 drivers/gpu/drm/rockchip/inno_hdmi.c|  10 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 141 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   6 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   8 +-
 10 files changed, 118 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0e4eb84..50c41c0 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -13,7 +13,7 @@ config DRM_ROCKCHIP
  IP found on the SoC.
 
 config ROCKCHIP_ANALOGIX_DP
-   tristate "Rockchip specific extensions for Analogix DP driver"
+   bool "Rockchip specific extensions for Analogix DP driver"
depends on DRM_ROCKCHIP
select DRM_ANALOGIX_DP
help
@@ -22,7 +22,7 @@ config ROCKCHIP_ANALOGIX_DP
  on RK3288 based SoC, you should selet this option.
 
 config ROCKCHIP_CDN_DP
-tristate "Rockchip cdn DP"
+bool "Rockchip cdn DP"
 depends on DRM_ROCKCHIP
depends on EXTCON
select SND_SOC_HDMI_CODEC if SND_SOC
@@ -33,7 +33,7 @@ config ROCKCHIP_CDN_DP
  option.
 
 config ROCKCHIP_DW_HDMI
-tristate "Rockchip specific extensions for Synopsys DW HDMI"
+bool "Rockchip specific extensions for Synopsys DW HDMI"
 depends on DRM_ROCKCHIP
 select DRM_DW_HDMI
 help
@@ -43,7 +43,7 @@ config ROCKCHIP_DW_HDMI
  option.
 
 config ROCKCHIP_DW_MIPI_DSI
-   tristate "Rockchip specific extensions for Synopsys DW MIPI DSI"
+   bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
depends on DRM_ROCKCHIP
select DRM_MIPI_DSI
help
@@ -53,7 +53,7 @@ config ROCKCHIP_DW_MIPI_DSI
 option.
 
 config ROCKCHIP_INNO_HDMI
-   tristate "Rockchip specific extensions for Innosilicon HDMI"
+   bool "Rockchip specific extensions for Innosilicon HDMI"
depends on DRM_ROCKCHIP
help
  This selects support for Rockchip SoC specific extensions
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index c931e2a..fa8dc9d 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -3,14 +3,14 @@
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
 rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
-   rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
+   rockchip_drm_gem.o rockchip_drm_psr.o \
+   rockchip_drm_vop.o rockchip_vop_reg.o
 rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
 
-obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
-obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp.o
-cdn-dp-objs := cdn-dp-core.o cdn-dp-reg.o
-obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
-obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
-obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
 
-obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
+obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8548e82..91ebe5c 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -507,7 +507,7 @@ static const struct of_device_id 

Re: [PATCH v4 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

[Jose Abreu]

Hi Neil,


On 21-03-2017 15:12, Neil Armstrong wrote:
> Some display pipelines can only provide non-RBG input pixels to the HDMI TX
> Controller, this patch takes the pixel format from the plat_data if provided.
>
> Signed-off-by: Neil Armstrong 

Looks fine, I'm assuming you test this on your platform which has
non RGB in input and the CSC worked correctly, right?

Reviewed-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 326 
> +-
>  include/drm/bridge/dw_hdmi.h  |  63 ++
>  2 files changed, 294 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index f82750a..fcb0a27 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -30,18 +30,15 @@
>  #include 
>  #include 
>  
> +#include 
> +#include 
> +
>  #include "dw-hdmi.h"
>  #include "dw-hdmi-audio.h"
>  
>  #define DDC_SEGMENT_ADDR 0x30
>  #define HDMI_EDID_LEN512
>  
> -#define RGB  0
> -#define YCBCR444 1
> -#define YCBCR422_16BITS  2
> -#define YCBCR422_8BITS   3
> -#define XVYCC444 4
> -
>  enum hdmi_datamap {
>   RGB444_8B = 0x01,
>   RGB444_10B = 0x03,
> @@ -95,10 +92,10 @@ struct hdmi_vmode {
>  };
>  
>  struct hdmi_data_info {
> - unsigned int enc_in_format;
> - unsigned int enc_out_format;
> - unsigned int enc_color_depth;
> - unsigned int colorimetry;
> + unsigned int enc_in_bus_format;
> + unsigned int enc_out_bus_format;
> + unsigned int enc_in_encoding;
> + unsigned int enc_out_encoding;
>   unsigned int pix_repet_factor;
>   unsigned int hdcp_enable;
>   struct hdmi_vmode video_mode;
> @@ -567,6 +564,92 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
>  }
>  EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
>  
> +static bool hdmi_bus_fmt_is_rgb(unsigned int bus_format)
> +{
> + switch (bus_format) {
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + case MEDIA_BUS_FMT_RGB101010_1X30:
> + case MEDIA_BUS_FMT_RGB121212_1X36:
> + case MEDIA_BUS_FMT_RGB161616_1X48:
> + return true;
> +
> + default:
> + return false;
> + }
> +}
> +
> +static bool hdmi_bus_fmt_is_yuv444(unsigned int bus_format)
> +{
> + switch (bus_format) {
> + case MEDIA_BUS_FMT_YUV8_1X24:
> + case MEDIA_BUS_FMT_YUV10_1X30:
> + case MEDIA_BUS_FMT_YUV12_1X36:
> + case MEDIA_BUS_FMT_YUV16_1X48:
> + return true;
> +
> + default:
> + return false;
> + }
> +}
> +
> +static bool hdmi_bus_fmt_is_yuv422(unsigned int bus_format)
> +{
> + switch (bus_format) {
> + case MEDIA_BUS_FMT_UYVY8_1X16:
> + case MEDIA_BUS_FMT_UYVY10_1X20:
> + case MEDIA_BUS_FMT_UYVY12_1X24:
> + return true;
> +
> + default:
> + return false;
> + }
> +}
> +
> +static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
> +{
> + switch (bus_format) {
> + case MEDIA_BUS_FMT_UYYVYY8_1X24:
> + case MEDIA_BUS_FMT_UYYVYY10_1X30:
> + case MEDIA_BUS_FMT_UYYVYY12_1X36:
> + case MEDIA_BUS_FMT_UYYVYY16_1X48:
> + return true;
> +
> + default:
> + return false;
> + }
> +}
> +
> +static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
> +{
> + switch (bus_format) {
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + case MEDIA_BUS_FMT_YUV8_1X24:
> + case MEDIA_BUS_FMT_UYVY8_1X16:
> + case MEDIA_BUS_FMT_UYYVYY8_1X24:
> + return 8;
> +
> + case MEDIA_BUS_FMT_RGB101010_1X30:
> + case MEDIA_BUS_FMT_YUV10_1X30:
> + case MEDIA_BUS_FMT_UYVY10_1X20:
> + case MEDIA_BUS_FMT_UYYVYY10_1X30:
> + return 10;
> +
> + case MEDIA_BUS_FMT_RGB121212_1X36:
> + case MEDIA_BUS_FMT_YUV12_1X36:
> + case MEDIA_BUS_FMT_UYVY12_1X24:
> + case MEDIA_BUS_FMT_UYYVYY12_1X36:
> + return 12;
> +
> + case MEDIA_BUS_FMT_RGB161616_1X48:
> + case MEDIA_BUS_FMT_YUV16_1X48:
> + case MEDIA_BUS_FMT_UYYVYY16_1X48:
> + return 16;
> +
> + default:
> + return 0;
> + }
> +}
> +
>  /*
>   * this submodule is responsible for the video data synchronization.
>   * for example, for RGB 4:4:4 input, the data map is defined as
> @@ -579,37 +662,49 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
>   int color_format = 0;
>   u8 val;
>  
> - if (hdmi->hdmi_data.enc_in_format == RGB) {
> - if (hdmi->hdmi_data.enc_color_depth == 8)
> - color_format = 0x01;
> - else if (hdmi->hdmi_data.enc_color_depth == 10)
> - color_format = 0x03;
> - else if (hdmi->hdmi_data.enc_color_depth == 12)
> - color_format = 0x05;
> - else if 

[RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

[Jose Abreu]

This patch completes CEA table of video modes so that VIC 1-107
are now available. Use the HDMI 2.0+ flag to signal these are
modes for HDMI 2.0 onwards.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/drm_edid.c | 258 +
 1 file changed, 258 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fad3d44..90080368 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1001,6 +1001,264 @@ struct minimode {
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080@30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080@50Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 76 - 1920x1080@60Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+  DRM_MODE_FLAG_HDMI2),
+ .vrefresh = 60, .picture_aspect_ratio 

Re: [PATCH v3 2/5] drm: of: introduce drm_of_find_panel_or_bridge

[Philipp Zabel]

On Wed, 2017-03-22 at 08:26 -0500, Rob Herring wrote:
> Many drivers have a common pattern of searching the OF graph for either an
> attached panel or bridge and then finding the DRM struct for the panel
> or bridge. Also, most drivers need to handle deferred probing when the
> DRM device is not yet instantiated. Create a common function,
> drm_of_find_panel_or_bridge, to find the connected node and the
> associated DRM panel or bridge device.
> 
> Signed-off-by: Rob Herring 
> Acked-by: Philipp Zabel 

Tested-by: Philipp Zabel 
(imx-ldb on i.MX6)

regards
Philipp

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

[PATCH v3 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

[Rob Herring]

Similar to the previous commit, convert drivers open coding OF graph
parsing to use drm_of_find_panel_or_bridge instead.

This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.

Signed-off-by: Rob Herring 
Reviewed-by: Archit Taneja 
---
v3:
- rebase to v4.11-rc2
- rework atmel to support 1 to N connections

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 73 ++-
 drivers/gpu/drm/bridge/nxp-ptn3460.c | 16 ++---
 drivers/gpu/drm/bridge/parade-ps8622.c   | 16 ++---
 drivers/gpu/drm/bridge/tc358767.c| 27 +--
 drivers/gpu/drm/exynos/exynos_dp.c   | 35 -
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 39 +++---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 ++-
 drivers/gpu/drm/imx/imx-ldb.c| 27 ++-
 drivers/gpu/drm/imx/parallel-display.c   | 36 ++
 drivers/gpu/drm/mediatek/mtk_dsi.c   | 23 ++
 drivers/gpu/drm/mxsfb/mxsfb_out.c| 40 ++-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  | 26 ++-
 drivers/gpu/drm/sun4i/sun4i_rgb.c| 11 +--
 drivers/gpu/drm/sun4i/sun4i_tcon.c   | 90 ++--
 14 files changed, 92 insertions(+), 394 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index e7799b6ee829..f987b4572d4a 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -22,7 +22,7 @@
 #include 

 #include 
-#include 
+#include 

 #include "atmel_hlcdc_dc.h"

@@ -152,29 +152,11 @@ static const struct drm_connector_funcs 
atmel_hlcdc_panel_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

-static int atmel_hlcdc_check_endpoint(struct drm_device *dev,
- const struct of_endpoint *ep)
-{
-   struct device_node *np;
-   void *obj;
-
-   np = of_graph_get_remote_port_parent(ep->local_node);
-
-   obj = of_drm_find_panel(np);
-   if (!obj)
-   obj = of_drm_find_bridge(np);
-
-   of_node_put(np);
-
-   return obj ? 0 : -EPROBE_DEFER;
-}
-
 static int atmel_hlcdc_attach_endpoint(struct drm_device *dev,
-  const struct of_endpoint *ep)
+  const struct device_node *np)
 {
struct atmel_hlcdc_dc *dc = dev->dev_private;
struct atmel_hlcdc_rgb_output *output;
-   struct device_node *np;
struct drm_panel *panel;
struct drm_bridge *bridge;
int ret;
@@ -195,13 +177,11 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,

output->encoder.possible_crtcs = 0x1;

-   np = of_graph_get_remote_port_parent(ep->local_node);
-
-   ret = -EPROBE_DEFER;
+   ret = drm_of_find_panel_or_bridge(np, 0, 0, , );
+   if (ret)
+   return ret;

-   panel = of_drm_find_panel(np);
if (panel) {
-   of_node_put(np);
output->connector.dpms = DRM_MODE_DPMS_OFF;
output->connector.polled = DRM_CONNECTOR_POLL_CONNECT;
drm_connector_helper_add(>connector,
@@ -226,9 +206,6 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,
return 0;
}

-   bridge = of_drm_find_bridge(np);
-   of_node_put(np);
-
if (bridge) {
ret = drm_bridge_attach(>encoder, bridge, NULL);
if (!ret)
@@ -243,31 +220,23 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,

 int atmel_hlcdc_create_outputs(struct drm_device *dev)
 {
-   struct device_node *ep_np = NULL;
-   struct of_endpoint ep;
-   int ret;
-
-   for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
-   ret = of_graph_parse_endpoint(ep_np, );
-   if (!ret)
-   ret = atmel_hlcdc_check_endpoint(dev, );
-
-   if (ret) {
-   of_node_put(ep_np);
-   return ret;
-   }
-   }
-
-   for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
-   ret = of_graph_parse_endpoint(ep_np, );
-   if (!ret)
-   ret = atmel_hlcdc_attach_endpoint(dev, );
-
-   if (ret) {
-   of_node_put(ep_np);
+   struct device_node *remote;
+   int ret, endpoint = 0;
+
+   while (true) {
+   /* Loop thru possible multiple connections to the output */
+   remote = of_graph_get_remote_node(dev->dev->of_node, 0,
+ endpoint++);
+   if (!remote)
+

Re: [PATCH v4 1/6] drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function

[Jose Abreu]

Hi Neil,


On 21-03-2017 15:12, Neil Armstrong wrote:
> From: Laurent Pinchart 
>
> In preparation for adding PHY operations to handle RX SENSE and HPD,
> group all the PHY interrupt setup code in a single location and extract
> it to a separate function.
>
> Signed-off-by: Laurent Pinchart 
> Signed-off-by: Neil Armstrong 

Reviewed-by: Jose Abreu 

Maybe if you submit a next version we could get rid of
"dw_hdmi_fb_registered" totally and move the remaining setup code
to a new "dw_hdmi_setup_i2c" function.

Best regards,
Jose Miguel Abreu

> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 50 
> ++-
>  1 file changed, 23 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index af93f7a..f82750a 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1559,7 +1559,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
> drm_display_mode *mode)
>  }
>  
>  /* Wait until we are registered to enable interrupts */
> -static int dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
> +static void dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
>  {
>   hdmi_writeb(hdmi, HDMI_PHY_I2CM_INT_ADDR_DONE_POL,
>   HDMI_PHY_I2CM_INT_ADDR);
> @@ -1567,15 +1567,6 @@ static int dw_hdmi_fb_registered(struct dw_hdmi *hdmi)
>   hdmi_writeb(hdmi, HDMI_PHY_I2CM_CTLINT_ADDR_NAC_POL |
>   HDMI_PHY_I2CM_CTLINT_ADDR_ARBITRATION_POL,
>   HDMI_PHY_I2CM_CTLINT_ADDR);
> -
> - /* enable cable hot plug irq */
> - hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> -
> - /* Clear Hotplug interrupts */
> - hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
> - HDMI_IH_PHY_STAT0);
> -
> - return 0;
>  }
>  
>  static void initialize_hdmi_ih_mutes(struct dw_hdmi *hdmi)
> @@ -1693,6 +1684,26 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi 
> *hdmi)
>   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
>  }
>  
> +static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi)
> +{
> + /*
> +  * Configure the PHY RX SENSE and HPD interrupts polarities and clear
> +  * any pending interrupt.
> +  */
> + hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
> + hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
> + HDMI_IH_PHY_STAT0);
> +
> + /* Enable cable hot plug irq. */
> + hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> +
> + /* Clear and unmute interrupts. */
> + hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
> + HDMI_IH_PHY_STAT0);
> + hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
> + HDMI_IH_MUTE_PHY_STAT0);
> +}
> +
>  static enum drm_connector_status
>  dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
>  {
> @@ -2204,29 +2215,14 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
>   hdmi->ddc = NULL;
>   }
>  
> - /*
> -  * Configure registers related to HDMI interrupt
> -  * generation before registering IRQ.
> -  */
> - hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
> -
> - /* Clear Hotplug interrupts */
> - hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
> - HDMI_IH_PHY_STAT0);
> -
>   hdmi->bridge.driver_private = hdmi;
>   hdmi->bridge.funcs = _hdmi_bridge_funcs;
>  #ifdef CONFIG_OF
>   hdmi->bridge.of_node = pdev->dev.of_node;
>  #endif
>  
> - ret = dw_hdmi_fb_registered(hdmi);
> - if (ret)
> - goto err_iahb;
> -
> - /* Unmute interrupts */
> - hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
> - HDMI_IH_MUTE_PHY_STAT0);
> + dw_hdmi_fb_registered(hdmi);
> + dw_hdmi_phy_setup_hpd(hdmi);
>  
>   memset(, 0, sizeof(pdevinfo));
>   pdevinfo.parent = dev;

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

[PATCH v3 1/5] drm: make of_drm_find_panel also depend on CONFIG_DRM_PANEL

[Rob Herring]

For drm_of_find_panel_or_bridge() added in the next commit, an empty
version of of_drm_find_panel is needed for !CONFIG_DRM_PANEL.

Signed-off-by: Rob Herring 
---
v3:
- rebase to v4.11-rc2

 include/drm/drm_panel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 4b76cf2d5a7b..1b364b0100f4 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -192,7 +192,7 @@ void drm_panel_remove(struct drm_panel *panel);
 int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector);
 int drm_panel_detach(struct drm_panel *panel);

-#ifdef CONFIG_OF
+#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL)
 struct drm_panel *of_drm_find_panel(const struct device_node *np);
 #else
 static inline struct drm_panel *of_drm_find_panel(const struct device_node *np)
--
2.10.1

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

[PATCH v3 5/5] drm: omap: use common OF graph helpers

[Rob Herring]

The OMAP driver has its own OF graph helpers that are similar to the
common helpers. This commit replaces most of the calls with the common
helpers. There's still a couple of custom helpers left, but the driver
needs more extensive changes to get rid of them.

In dss_init_ports, we invert the loop, looping through the known ports
and matching them to DT nodes rather than looping thru DT nodes and
matching them to the ports.

Signed-off-by: Rob Herring 
---
v3:
- rebase to v4.11-rc2

 drivers/gpu/drm/omapdrm/dss/dpi.c |   2 +-
 drivers/gpu/drm/omapdrm/dss/dsi.c |   3 +-
 drivers/gpu/drm/omapdrm/dss/dss-of.c  | 102 +-
 drivers/gpu/drm/omapdrm/dss/dss.c |  61 +---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c   |   3 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c   |   3 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h |  11 
 drivers/gpu/drm/omapdrm/dss/sdi.c |   2 +-
 drivers/gpu/drm/omapdrm/dss/venc.c|   3 +-
 9 files changed, 26 insertions(+), 164 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index e75162d26ac0..e5bb494d4689 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -855,7 +855,7 @@ int dpi_init_port(struct platform_device *pdev, struct 
device_node *port)
if (!dpi)
return -ENOMEM;

-   ep = omapdss_of_get_next_endpoint(port, NULL);
+   ep = of_get_next_child(port, NULL);
if (!ep)
return 0;

diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index f74615d005a8..0aebd5d709ea 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -5091,7 +5092,7 @@ static int dsi_probe_of(struct platform_device *pdev)
struct device_node *ep;
struct omap_dsi_pin_config pin_cfg;

-   ep = omapdss_of_get_first_endpoint(node);
+   ep = of_graph_get_endpoint_by_regs(node, 0, 0);
if (!ep)
return 0;

diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
b/drivers/gpu/drm/omapdrm/dss/dss-of.c
index dfd4e9621e3b..eb520ab45ddd 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
@@ -16,77 +16,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "omapdss.h"
 #include "dss.h"

-struct device_node *
-omapdss_of_get_next_port(const struct device_node *parent,
-struct device_node *prev)
-{
-   struct device_node *port = NULL;
-
-   if (!parent)
-   return NULL;
-
-   if (!prev) {
-   struct device_node *ports;
-   /*
-* It's the first call, we have to find a port subnode
-* within this node or within an optional 'ports' node.
-*/
-   ports = of_get_child_by_name(parent, "ports");
-   if (ports)
-   parent = ports;
-
-   port = of_get_child_by_name(parent, "port");
-
-   /* release the 'ports' node */
-   of_node_put(ports);
-   } else {
-   struct device_node *ports;
-
-   ports = of_get_parent(prev);
-   if (!ports)
-   return NULL;
-
-   do {
-   port = of_get_next_child(ports, prev);
-   if (!port) {
-   of_node_put(ports);
-   return NULL;
-   }
-   prev = port;
-   } while (of_node_cmp(port->name, "port") != 0);
-
-   of_node_put(ports);
-   }
-
-   return port;
-}
-EXPORT_SYMBOL_GPL(omapdss_of_get_next_port);
-
-struct device_node *
-omapdss_of_get_next_endpoint(const struct device_node *parent,
-struct device_node *prev)
-{
-   struct device_node *ep = NULL;
-
-   if (!parent)
-   return NULL;
-
-   do {
-   ep = of_get_next_child(parent, prev);
-   if (!ep)
-   return NULL;
-   prev = ep;
-   } while (of_node_cmp(ep->name, "endpoint") != 0);
-
-   return ep;
-}
-EXPORT_SYMBOL_GPL(omapdss_of_get_next_endpoint);
-
 struct device_node *dss_of_port_get_parent_device(struct device_node *port)
 {
struct device_node *np;
@@ -123,37 +58,6 @@ u32 dss_of_port_get_port_number(struct device_node *port)
return reg;
 }

-static struct device_node *omapdss_of_get_remote_port(const struct device_node 
*node)
-{
-   struct device_node *np;
-
-   np = of_parse_phandle(node, "remote-endpoint", 0);
-   if (!np)
-   return NULL;
-
-   np = of_get_next_parent(np);
-
-   return np;
-}
-
-struct device_node *
-omapdss_of_get_first_endpoint(const struct device_node *parent)
-{
-   struct 

[BUG][REGRESSION] i915 gpu hangs under load

[Martin Kepplinger]

Hi

I know something similar is here: 
https://bugs.freedesktop.org/show_bug.cgi?id=100110 too.


But this is rc3 and my machine is totally *not usable*. Let me be 
annoying :) I hope I can help:


Since rc1 I get gpu hangs and resets under load: This is almost 
certainly a kernel issue. 4.10 is fine.
I keep a debian stable userspace. nouveau is running on this machine 
too.


Mar 22 09:17:01 martin-laptop kernel: [ 2409.538706] [drm] GPU HANG: 
ecode 7:0:0xf3ce, in gnome-shell [1869], reason: Hang on render 
ring, action: reset
Mar 22 09:17:01 martin-laptop kernel: [ 2409.538711] [drm] GPU hangs can 
indicate a bug anywhere in the entire gfx stack, including userspace.
Mar 22 09:17:01 martin-laptop kernel: [ 2409.538713] [drm] Please file a 
_new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
Mar 22 09:17:01 martin-laptop kernel: [ 2409.538714] [drm] drm/i915 
developers can then reassign to the right component if it's not a kernel 
issue.
Mar 22 09:17:01 martin-laptop kernel: [ 2409.538715] [drm] The gpu crash 
dump is required to analyze gpu hangs, so please always attach it.
Mar 22 09:17:01 martin-laptop kernel: [ 2409.538716] [drm] GPU crash 
dump saved to /sys/class/drm/card0/error
Mar 22 09:17:01 martin-laptop kernel: [ 2409.538768] drm/i915: Resetting 
chip after gpu hang
Mar 22 09:17:09 martin-laptop kernel: [ 2417.537886] drm/i915: Resetting 
chip after gpu hang
Mar 22 09:17:17 martin-laptop kernel: [ 2425.537152] drm/i915: Resetting 
chip after gpu hang
Mar 22 09:17:25 martin-laptop kernel: [ 2433.536407] drm/i915: Resetting 
chip after gpu hang
Mar 22 09:17:33 martin-laptop kernel: [ 2441.539674] drm/i915: Resetting 
chip after gpu hang



Furthermore, there are weird, small display distortions occuring. I 
don't get any log about them and
don't have a screenshot. Well. Nevermind. Please fix 4.11 and CC anyone 
I forgot.



thanks

 martin
GPU HANG: ecode 7:0:0xf3ce, in gnome-shell [1869], reason: Hang on render 
ring, action: reset
Kernel: 4.11.0-rc3-3-gbc61cd2
Time: 1490170621 s 524489 us
Boottime: 2409 s 756155 us
Uptime: 2395 s 323536 us
is_mobile: no
is_lp: no
is_alpha_support: no
has_64bit_reloc: no
has_aliasing_ppgtt: yes
has_csr: no
has_ddi: yes
has_decoupled_mmio: no
has_dp_mst: yes
has_fbc: yes
has_fpga_dbg: yes
has_full_ppgtt: yes
has_full_48bit_ppgtt: no
has_gmbus_irq: yes
has_gmch_display: no
has_guc: no
has_hotplug: yes
has_hw_contexts: yes
has_l3_dpf: yes
has_llc: yes
has_logical_ring_contexts: no
has_overlay: no
has_pipe_cxsr: no
has_pooled_eu: no
has_psr: yes
has_rc6: yes
has_rc6p: no
has_resource_streamer: yes
has_runtime_pm: yes
has_snoop: no
cursor_needs_physical: no
hws_needs_physical: no
overlay_needs_physical: no
supports_tv: no
Active process (on ring render): gnome-shell [1869], context bans 0
Reset count: 0
Suspend count: 0
Platform: HASWELL
PCI ID: 0x0416
PCI Revision: 0x06
PCI Subsystem: 10cf:17ac
IOMMU enabled?: 0
EIR: 0x
IER: 0xfc002529
GTIER: 0x00401821
PGTBL_ER: 0x
FORCEWAKE: 0x0001
DERRMR: 0x
CCID: 0x00ef410d
Missed interrupts: 0x
  fence[0] = 
  fence[1] = 
  fence[2] = 
  fence[3] = 
  fence[4] = 
  fence[5] = 
  fence[6] = 
  fence[7] = 
  fence[8] = 
  fence[9] = 
  fence[10] = 
  fence[11] = 
  fence[12] = 
  fence[13] = 
  fence[14] = 
  fence[15] = 
  fence[16] = 
  fence[17] = 
  fence[18] = 4b530770374a001
  fence[19] = 
  fence[20] = 
  fence[21] = 
  fence[22] = 
  fence[23] = 
  fence[24] = 
  fence[25] = 
  fence[26] = 
  fence[27] = 
  fence[28] = 
  fence[29] = 
  fence[30] = 
  fence[31] = 
ERROR: 0x0109
DONE_REG: 0x
ERR_INT: 0x
render command stream:
  START: 0x007ea000
  HEAD:  0x07a1f6dc [0x0001f648]
  TAIL:  0x0001f8f8 [0x0001f728, 0x0001f760]
  CTL:   0x0001f001
  MODE:  0x4000
  HWS:   0x7fff
  ACTHD: 0x 07a1f6dc
  IPEIR: 0x
  IPEHR: 0x0c00
  INSTDONE: 0xffce
  SC_INSTDONE: 0x
  SAMPLER_INSTDONE[0][0]: 0x
  ROW_INSTDONE[0][0]: 0x
  BBADDR: 0x_7fa48330
  BB_STATE: 0x
  INSTPS: 0x0500
  INSTPM: 0x6080
  FADDR: 0x 008096d8
  RC PSMI: 0x0010
  FAULT_REG: 0x00c5
  SYNC_0: 0x
  SYNC_1: 0x0001c2a1
  SYNC_2: 0x
  GFX_MODE: 0x2a00
  PP_DIR_BASE: 0x7fdf
  seqno: 0x0001c29a
  last_seqno: 0x0001c2a2
  waiting: yes
  ring->head: 0x00016e60
  ring->tail: 0x0001f8f8
  hangcheck stall: yes
  hangcheck action: dead
  hangcheck action timestamp: 4295493232, 204600 ms ago
blt command stream:
  START: 0x0080a000
  HEAD:  0x07e0e8d0 [0x]
  TAIL:  0xe8d0 [0x, 0x]
  CTL:   0x0001f001
  MODE:  0x0200
  HWS:   0x7fff1000
  ACTHD: 0x 07e0e8d0
  IPEIR: 0x
  IPEHR: 

Re: [PATCH v3 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

[Philipp Zabel]

On Wed, 2017-03-22 at 08:26 -0500, Rob Herring wrote:
> Similar to the previous commit, convert drivers open coding OF graph
> parsing to use drm_of_find_panel_or_bridge instead.
> 
> This changes some error messages to debug messages (in the graph core).
> Graph connections are often "no connects" depending on the particular
> board, so we want to avoid spurious messages. Plus the kernel is not a
> DT validator.
> 
> Signed-off-by: Rob Herring 
> Reviewed-by: Archit Taneja 

Tested-by: Philipp Zabel 
(imx-ldb on i.MX6)

regards
Philipp

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

[RFC 5/5] drm: Do not expose HDMI 2.0+ modes to userspace/drivers unless asked to

[Jose Abreu]

Perform sanity checks so that HDMI 2.0+ modes are not exported to
drivers or userspace unless asked to.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/drm_connector.c|  2 ++
 drivers/gpu/drm/drm_probe_helper.c |  9 -
 include/drm/drm_modes.h| 14 ++
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9f84761..430bb2b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1200,6 +1200,8 @@ static bool drm_mode_expose_to_userspace(const struct 
drm_display_mode *mode,
 */
if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
return false;
+   if (!file_priv->hdmi2_allowed && drm_mode_is_hdmi2(mode))
+   return false;
 
return true;
 }
diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 85005d5..ddacb5d 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -77,6 +77,10 @@
!(flags & DRM_MODE_FLAG_3D_MASK))
return MODE_NO_STEREO;
 
+   if ((mode->flags & DRM_MODE_FLAG_HDMI2) &&
+   !(flags & DRM_MODE_FLAG_HDMI2))
+   return MODE_NO_HDMI2;
+
return MODE_OK;
 }
 
@@ -221,7 +225,8 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
  *- drm_mode_validate_size() filters out modes larger than @maxX and @maxY
  *  (if specified)
  *- drm_mode_validate_flag() checks the modes against basic connector
- *  capabilities (interlace_allowed,doublescan_allowed,stereo_allowed)
+ *  capabilities (interlace_allowed,doublescan_allowed,stereo_allowed,
+ *  hdmi2_allowed)
  *- the optional _connector_helper_funcs.mode_valid helper can perform
  *  driver and/or hardware specific checks
  *
@@ -336,6 +341,8 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
mode_flags |= DRM_MODE_FLAG_DBLSCAN;
if (connector->stereo_allowed)
mode_flags |= DRM_MODE_FLAG_3D_MASK;
+   if (connector->hdmi2_allowed)
+   mode_flags |= DRM_MODE_FLAG_HDMI2;
 
list_for_each_entry(mode, >modes, head) {
if (mode->status == MODE_OK)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 6dd34280..83466ff 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -80,6 +80,7 @@
  * @MODE_ONE_SIZE: only one resolution is supported
  * @MODE_NO_REDUCED: monitor doesn't accept reduced blanking
  * @MODE_NO_STEREO: stereo modes not supported
+ * @MODE_NO_HDMI2: HDMI 2.0+ modes not supported
  * @MODE_STALE: mode has become stale
  * @MODE_BAD: unspecified reason
  * @MODE_ERROR: error condition
@@ -124,6 +125,7 @@ enum drm_mode_status {
MODE_ONE_SIZE,
MODE_NO_REDUCED,
MODE_NO_STEREO,
+   MODE_NO_HDMI2,
MODE_STALE = -3,
MODE_BAD = -2,
MODE_ERROR = -1
@@ -422,6 +424,18 @@ static inline bool drm_mode_is_stereo(const struct 
drm_display_mode *mode)
return mode->flags & DRM_MODE_FLAG_3D_MASK;
 }
 
+/**
+ * drm_mode_is_hdmi2 - check for HDMI 2.0+ mode flag
+ * @mode: drm_display_mode to check
+ *
+ * Returns:
+ * True if the mode is HDMI 2.0+ mode, false if not
+ */
+static inline bool drm_mode_is_hdmi2(const struct drm_display_mode *mode)
+{
+   return mode->flags & DRM_MODE_FLAG_HDMI2;
+}
+
 struct drm_connector;
 struct drm_cmdline_mode;
 
-- 
1.9.1


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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 16/03/17 22:36, Marek Olšák wrote:

Is there a way not to use ninja with meson, because ninja redirects
all stderr output from gcc to stdout, which breaks many development
environments that expect errors in stderr?

I'm basically saying that if ninja can't keep gcc errors in stderr, I
wouldn't like any project that I might be involved in to require ninja
for building.

Marek


Yes, that's an annoying behavior from ninja.

I use a simple shell script for IDEs that care about that (e.g., with 
QtCreator):


  $ cat `which ninja-stderr `
  #!/bin/sh
  ninja "$@" 1>&2

There's a rationale for ninja to behave like that -- ninja buffers the 
whole program output, but and they use a combined buffer for both stderr 
and stdout so lines appear in same order.  Still, it would be nice if 
they fixed this for everybody.


Jose

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

Re: [PATCH] drm/msm/hdmi: redefinitions of macros not required

[Vinay Simha B N]

hi,

Could you please give some feedback or review comments for this patch

On 3/14/17, Vinay Simha BN  wrote:
> 4 macros already defined in hdmi.h,
> which is not required to redefine in hdmi_audio.c
>
> Signed-off-by: Vinay Simha BN 
> ---
>  drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 7 ---
>  1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
> b/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
> index a54d3bb..8177e85 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
> @@ -18,13 +18,6 @@
>  #include 
>  #include "hdmi.h"
>
> -
> -/* Supported HDMI Audio channels */
> -#define MSM_HDMI_AUDIO_CHANNEL_2 0
> -#define MSM_HDMI_AUDIO_CHANNEL_4 1
> -#define MSM_HDMI_AUDIO_CHANNEL_6 2
> -#define MSM_HDMI_AUDIO_CHANNEL_8 3
> -
>  /* maps MSM_HDMI_AUDIO_CHANNEL_n consts used by audio driver to # of
> channels: */
>  static int nchannels[] = { 2, 4, 6, 8 };
>
> --
> 2.7.4
>
>


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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Eric Anholt]

Rob Clark  writes:

> On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker  wrote:
>> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
>>
>> Notably gnome is moving to meson (and some parts already use it), weston and
>> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
>> can't say for sure it's going to be around forever, but its been in 
>> development
>> since late 2012 and still lands several patches a day, they were responsive 
>> to
>> me when I sent a patch (that I still need to respin), and they seem to be
>> picking up momentum from downstreams.
>
>
> btw, possibly newbie question, but from what I can tell so far in
> meson docs, there are separate 'meson build && cd build && ninja'
> steps.. one nice thing about autotools is 'git pull && make' (and it
> somehow magically figures out whether to re-automake/autoconf).  Not
> sure if there is a way to do something like that in meson.

Consider meson build to be ./autogen.sh.  After that point you can git
pull && make.


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

[Bug 96897] clpeak OpenCL benchmark hangs during compilation on Clover RadeonSI

[bugzilla-daemon]

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

--- Comment #5 from Jan Ziak <0xe2.0x9a.0...@gmail.com> ---
With LLVM 4.0.0 I am getting the following results:

$ clinfo
  Platform ID:  0x7ff6aaf2ed60
  Name: AMD HAWAII (DRM 3.10.0 / 4.11.0-rc2+, LLVM
4.0.0)
  Vendor:   AMD
  Device OpenCL C version:  OpenCL C 1.1 
  Driver version:   17.1.0-devel
  Profile:  FULL_PROFILE
  Version:  OpenCL 1.1 Mesa 17.1.0-devel (git-ad13bd2)

$ ./clpeak
Platform: Clover
  Device: AMD HAWAII (DRM 3.10.0 / 4.11.0-rc2+, LLVM 4.0.0)
Driver version  : 17.1.0-devel (Linux x64)
Compute units   : 40
Clock frequency : 1000 MHz
clpeak:
/var/tmp/portage/sys-devel/clang-4.0.0/work/x/y/cfe-4.0.0.src/lib/Sema/Sema.cpp:317:
clang::Sema::~Sema(): Assertion `DelayedTypos.empty() && "Uncorrected typos!"'
failed.
Aborted (core dumped)

-- 
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: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker  wrote:
> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
>
> Notably gnome is moving to meson (and some parts already use it), weston and
> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
> can't say for sure it's going to be around forever, but its been in 
> development
> since late 2012 and still lands several patches a day, they were responsive to
> me when I sent a patch (that I still need to respin), and they seem to be
> picking up momentum from downstreams.


btw, possibly newbie question, but from what I can tell so far in
meson docs, there are separate 'meson build && cd build && ninja'
steps.. one nice thing about autotools is 'git pull && make' (and it
somehow magically figures out whether to re-automake/autoconf).  Not
sure if there is a way to do something like that in meson.

(I nearly always use separate build and debug builddirs w/ autotools,
so that part I don't mind.. you can git-pull from a subdir fo the git
tree)

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

[PATCH 17/19] drm: Add explicit acquire ctx handling around ->set_config

[Daniel Vetter]

Just the groundwork to have something to feed into ->set_config.
Again we need a temporary hack to still fill out the legacy
ctx in mode_config.acquire_ctx.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 05447492483f..bfaa0e769ea6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -444,7 +444,8 @@ int drm_mode_getcrtc(struct drm_device *dev,
return 0;
 }
 
-static int __drm_mode_set_config_internal(struct drm_mode_set *set)
+static int __drm_mode_set_config_internal(struct drm_mode_set *set,
+ struct drm_modeset_acquire_ctx *ctx)
 {
struct drm_crtc *crtc = set->crtc;
struct drm_framebuffer *fb;
@@ -494,7 +495,7 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
 {
WARN_ON(drm_drv_uses_atomic_modeset(set->crtc->dev));
 
-   return __drm_mode_set_config_internal(set);
+   return __drm_mode_set_config_internal(set, NULL);
 }
 EXPORT_SYMBOL(drm_mode_set_config_internal);
 
@@ -551,6 +552,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
struct drm_display_mode *mode = NULL;
struct drm_mode_set set;
uint32_t __user *set_connectors_ptr;
+   struct drm_modeset_acquire_ctx ctx;
int ret;
int i;
 
@@ -564,15 +566,19 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
if (crtc_req->x & 0x || crtc_req->y & 0x)
return -ERANGE;
 
-   drm_modeset_lock_all(dev);
crtc = drm_crtc_find(dev, crtc_req->crtc_id);
if (!crtc) {
DRM_DEBUG_KMS("Unknown CRTC ID %d\n", crtc_req->crtc_id);
-   ret = -ENOENT;
-   goto out;
+   return -ENOENT;
}
DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
 
+   drm_modeset_acquire_init(, 0);
+retry:
+   ret = drm_modeset_lock_all_ctx(crtc->dev, );
+   if (ret)
+   goto out;
+   dev->mode_config.acquire_ctx = 
if (crtc_req->mode_valid) {
/* If we have a mode we need a framebuffer. */
/* If we pass -1, set the mode with the currently bound fb */
@@ -693,7 +699,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.connectors = connector_set;
set.num_connectors = crtc_req->count_connectors;
set.fb = fb;
-   ret = __drm_mode_set_config_internal();
+   ret = __drm_mode_set_config_internal(, );
 
 out:
if (fb)
@@ -707,7 +713,13 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
}
kfree(connector_set);
drm_mode_destroy(dev, mode);
-   drm_modeset_unlock_all(dev);
+   if (ret == -EDEADLK) {
+   drm_modeset_backoff();
+   goto retry;
+   }
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+
return ret;
 }
 
-- 
2.11.0

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

[PATCH 12/19] drm/atomic-helper: remove backoff hack from page_flip

[Daniel Vetter]

Yay, we can now properly retry in case of deadlocks or whatever!

Also don't forget to remove the transitional crtc->acquire_ctx
assignment again.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 40 ++---
 drivers/gpu/drm/drm_plane.c |  1 -
 2 files changed, 2 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 0e65ce4497b3..c0ec763ec538 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2885,34 +2885,16 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
if (!state)
return -ENOMEM;
 
-   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+   state->acquire_ctx = ctx;
 
-retry:
ret = page_flip_common(state, crtc, fb, event, flags);
if (ret != 0)
goto fail;
 
ret = drm_atomic_nonblocking_commit(state);
-
 fail:
-   if (ret == -EDEADLK)
-   goto backoff;
-
drm_atomic_state_put(state);
return ret;
-
-backoff:
-   drm_atomic_state_clear(state);
-   drm_atomic_legacy_backoff(state);
-
-   /*
-* Someone might have exchanged the framebuffer while we dropped locks
-* in the backoff code. We need to fix up the fb refcount tracking the
-* core does for us.
-*/
-   plane->old_fb = plane->fb;
-
-   goto retry;
 }
 EXPORT_SYMBOL(drm_atomic_helper_page_flip);
 
@@ -2949,9 +2931,8 @@ int drm_atomic_helper_page_flip_target(
if (!state)
return -ENOMEM;
 
-   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+   state->acquire_ctx = ctx;
 
-retry:
ret = page_flip_common(state, crtc, fb, event, flags);
if (ret != 0)
goto fail;
@@ -2964,26 +2945,9 @@ int drm_atomic_helper_page_flip_target(
crtc_state->target_vblank = target;
 
ret = drm_atomic_nonblocking_commit(state);
-
 fail:
-   if (ret == -EDEADLK)
-   goto backoff;
-
drm_atomic_state_put(state);
return ret;
-
-backoff:
-   drm_atomic_state_clear(state);
-   drm_atomic_legacy_backoff(state);
-
-   /*
-* Someone might have exchanged the framebuffer while we dropped locks
-* in the backoff code. We need to fix up the fb refcount tracking the
-* core does for us.
-*/
-   plane->old_fb = plane->fb;
-
-   goto retry;
 }
 EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 373e980d698d..ec3e2e757800 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -875,7 +875,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
ret = drm_modeset_lock(>cursor->mutex, );
if (ret)
goto out;
-   crtc->acquire_ctx = 
 
if (crtc->primary->fb == NULL) {
/* The framebuffer is currently unbound, presumably
-- 
2.11.0

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

[PATCH 18/19] drm: Add acquire ctx parameter to ->set_config

[Daniel Vetter]

Surprisingly a lot of legacy drivers roll their own, for
runtime pm and because vmwgfx.

Also make nouveau's set_config static while at it.

Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
Cc: Ben Skeggs 
Cc: Patrik Jakobsson 
Cc: Alex Deucher 
Cc: Christian König 

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 3 ++-
 drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
 drivers/gpu/drm/drm_crtc.c  | 2 +-
 drivers/gpu/drm/drm_crtc_helper.c   | 4 +++-
 drivers/gpu/drm/drm_plane_helper.c  | 2 +-
 drivers/gpu/drm/gma500/gma_display.c| 7 ---
 drivers/gpu/drm/gma500/gma_display.h| 3 ++-
 drivers/gpu/drm/nouveau/dispnv04/crtc.c | 7 ---
 drivers/gpu/drm/nouveau/nouveau_display.h   | 1 -
 drivers/gpu/drm/radeon/radeon_display.c | 5 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 3 ++-
 include/drm/drm_atomic_helper.h | 3 ++-
 include/drm/drm_crtc.h  | 3 ++-
 include/drm/drm_crtc_helper.h   | 3 ++-
 17 files changed, 38 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 7b4fe91d3aec..ce15721cadda 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -333,7 +333,8 @@ int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
return 0;
 }
 
-int amdgpu_crtc_set_config(struct drm_mode_set *set)
+int amdgpu_crtc_set_config(struct drm_mode_set *set,
+  struct drm_modeset_acquire_ctx *ctx)
 {
struct drm_device *dev;
struct amdgpu_device *adev;
@@ -350,7 +351,7 @@ int amdgpu_crtc_set_config(struct drm_mode_set *set)
if (ret < 0)
return ret;
 
-   ret = drm_crtc_helper_set_config(set);
+   ret = drm_crtc_helper_set_config(set, ctx);
 
list_for_each_entry(crtc, >mode_config.crtc_list, head)
if (crtc->enabled)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index d19b803ba509..20d6522fd7b4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -593,7 +593,8 @@ int amdgpu_align_pitch(struct amdgpu_device *adev, int 
width, int bpp, bool tile
 /* amdgpu_display.c */
 void amdgpu_print_display_setup(struct drm_device *dev);
 int amdgpu_modeset_create_props(struct amdgpu_device *adev);
-int amdgpu_crtc_set_config(struct drm_mode_set *set);
+int amdgpu_crtc_set_config(struct drm_mode_set *set,
+  struct drm_modeset_acquire_ctx *ctx);
 int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
 struct drm_framebuffer *fb,
 struct drm_pending_vblank_event *event,
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 08d10abcece0..b502e2809ebd 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2266,6 +2266,7 @@ static int update_output_state(struct drm_atomic_state 
*state,
 /**
  * drm_atomic_helper_set_config - set a new config from userspace
  * @set: mode set configuration
+ * @ctx: lock acquisition context
  *
  * Provides a default crtc set_config handler using the atomic driver 
interface.
  *
@@ -2278,7 +2279,8 @@ static int update_output_state(struct drm_atomic_state 
*state,
  * Returns:
  * Returns 0 on success, negative errno numbers on failure.
  */
-int drm_atomic_helper_set_config(struct drm_mode_set *set)
+int drm_atomic_helper_set_config(struct drm_mode_set *set,
+struct drm_modeset_acquire_ctx *ctx)
 {
struct drm_atomic_state *state;
struct drm_crtc *crtc = set->crtc;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index bfaa0e769ea6..3fe1ec23c87e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -462,7 +462,7 @@ static int __drm_mode_set_config_internal(struct 
drm_mode_set *set,
 
fb = set->fb;
 
-   ret = crtc->funcs->set_config(set);
+   ret = crtc->funcs->set_config(set, ctx);
if (ret == 0) {
crtc->primary->crtc = crtc;
crtc->primary->fb = fb;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 8aa8c1084121..4afdf7902eda 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -476,6 +476,7 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
 /**
  * drm_crtc_helper_set_config - set a new config from userspace
  * @set: mode set 

[PATCH 13/19] drm: simplify the locking in the GETCRTC ioctl

[Daniel Vetter]

No need to grab both plane and crtc locks at the same time, we can do
them one after the other. If userspace races it'll get what it
deserves either way.

This removes another user of drm_modeset_lock_crtc. There's only one
left.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 660b4c8715de..df1ff0b8818b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -406,16 +406,18 @@ int drm_mode_getcrtc(struct drm_device *dev,
if (!crtc)
return -ENOENT;
 
-   drm_modeset_lock_crtc(crtc, crtc->primary);
crtc_resp->gamma_size = crtc->gamma_size;
 
+   drm_modeset_lock(>primary->mutex, NULL);
if (crtc->primary->state && crtc->primary->state->fb)
crtc_resp->fb_id = crtc->primary->state->fb->base.id;
else if (!crtc->primary->state && crtc->primary->fb)
crtc_resp->fb_id = crtc->primary->fb->base.id;
else
crtc_resp->fb_id = 0;
+   drm_modeset_unlock(>primary->mutex);
 
+   drm_modeset_lock(>mutex, NULL);
if (crtc->state) {
crtc_resp->x = crtc->primary->state->src_x >> 16;
crtc_resp->y = crtc->primary->state->src_y >> 16;
@@ -437,7 +439,7 @@ int drm_mode_getcrtc(struct drm_device *dev,
crtc_resp->mode_valid = 0;
}
}
-   drm_modeset_unlock_crtc(crtc);
+   drm_modeset_unlock(>mutex);
 
return 0;
 }
-- 
2.11.0

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

[PATCH 19/19] drm/atomic-helper: Remove the backoff hack from set_config

[Daniel Vetter]

Another one bites the dust.

Again let's not forget to remove the temporary hidden acquire_ctx
assignment, now that we pass this all around explicitly it can go
away again.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 21 ++---
 drivers/gpu/drm/drm_crtc.c  |  1 -
 2 files changed, 2 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index b502e2809ebd..2df4827305d4 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2291,32 +2291,15 @@ int drm_atomic_helper_set_config(struct drm_mode_set 
*set,
return -ENOMEM;
 
state->legacy_set_config = true;
-   state->acquire_ctx = crtc->dev->mode_config.acquire_ctx;
-retry:
+   state->acquire_ctx = ctx;
ret = __drm_atomic_helper_set_config(set, state);
if (ret != 0)
-   goto fail;
+   return ret;
 
ret = drm_atomic_commit(state);
-fail:
-   if (ret == -EDEADLK)
-   goto backoff;
 
drm_atomic_state_put(state);
return ret;
-
-backoff:
-   drm_atomic_state_clear(state);
-   drm_atomic_legacy_backoff(state);
-
-   /*
-* Someone might have exchanged the framebuffer while we dropped locks
-* in the backoff code. We need to fix up the fb refcount tracking the
-* core does for us.
-*/
-   crtc->primary->old_fb = crtc->primary->fb;
-
-   goto retry;
 }
 EXPORT_SYMBOL(drm_atomic_helper_set_config);
 
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3fe1ec23c87e..46e5b97a8c87 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -578,7 +578,6 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
ret = drm_modeset_lock_all_ctx(crtc->dev, );
if (ret)
goto out;
-   dev->mode_config.acquire_ctx = 
if (crtc_req->mode_valid) {
/* If we have a mode we need a framebuffer. */
/* If we pass -1, set the mode with the currently bound fb */
-- 
2.11.0

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

[PATCH 14/19] drm: Remove drm_modeset_(un)lock_crtc

[Daniel Vetter]

The last user, the cursor ioctl, can just open-code this too. We
simply have to move the acquire ctx dance from the universal function
up into the top-level ioctl handler.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc_internal.h |  3 --
 drivers/gpu/drm/drm_modeset_lock.c  | 67 -
 drivers/gpu/drm/drm_plane.c | 49 +--
 include/drm/drm_modeset_lock.h  |  1 -
 4 files changed, 24 insertions(+), 96 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index de1047530e07..8c04275cf226 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -61,9 +61,6 @@ int drm_mode_getresources(struct drm_device *dev,
  void *data, struct drm_file *file_priv);
 
 
-/* drm_modeset_lock.c */
-void drm_modeset_lock_crtc(struct drm_crtc *crtc,
-  struct drm_plane *plane);
 /* drm_dumb_buffers.c */
 /* IOCTLs */
 int drm_mode_create_dumb_ioctl(struct drm_device *dev,
diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index c94eff9d7544..c3ca6b859236 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -148,51 +148,6 @@ void drm_modeset_unlock_all(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_modeset_unlock_all);
 
-void drm_modeset_lock_crtc(struct drm_crtc *crtc,
-  struct drm_plane *plane)
-{
-   struct drm_modeset_acquire_ctx *ctx;
-   int ret;
-
-   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
-   if (WARN_ON(!ctx))
-   return;
-
-   drm_modeset_acquire_init(ctx, 0);
-
-retry:
-   ret = drm_modeset_lock(>mutex, ctx);
-   if (ret)
-   goto fail;
-
-   if (plane) {
-   ret = drm_modeset_lock(>mutex, ctx);
-   if (ret)
-   goto fail;
-
-   if (plane->crtc) {
-   ret = drm_modeset_lock(>crtc->mutex, ctx);
-   if (ret)
-   goto fail;
-   }
-   }
-
-   WARN_ON(crtc->acquire_ctx);
-
-   /* now we hold the locks, so now that it is safe, stash the
-* ctx for drm_modeset_unlock_crtc():
-*/
-   crtc->acquire_ctx = ctx;
-
-   return;
-
-fail:
-   if (ret == -EDEADLK) {
-   drm_modeset_backoff(ctx);
-   goto retry;
-   }
-}
-
 /**
  * drm_modeset_legacy_acquire_ctx - find acquire ctx for legacy ioctls
  * @crtc: drm crtc
@@ -215,28 +170,6 @@ drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc)
 EXPORT_SYMBOL(drm_modeset_legacy_acquire_ctx);
 
 /**
- * drm_modeset_unlock_crtc - drop crtc lock
- * @crtc: drm crtc
- *
- * This drops the crtc lock acquire with drm_modeset_lock_crtc() and all other
- * locks acquired through the hidden context.
- */
-void drm_modeset_unlock_crtc(struct drm_crtc *crtc)
-{
-   struct drm_modeset_acquire_ctx *ctx = crtc->acquire_ctx;
-
-   if (WARN_ON(!ctx))
-   return;
-
-   crtc->acquire_ctx = NULL;
-   drm_modeset_drop_locks(ctx);
-   drm_modeset_acquire_fini(ctx);
-
-   kfree(ctx);
-}
-EXPORT_SYMBOL(drm_modeset_unlock_crtc);
-
-/**
  * drm_warn_on_modeset_not_all_locked - check that all modeset locks are locked
  * @dev: device
  *
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index ec3e2e757800..ec62221d64a9 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -620,7 +620,8 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
 
 static int drm_mode_cursor_universal(struct drm_crtc *crtc,
 struct drm_mode_cursor2 *req,
-struct drm_file *file_priv)
+struct drm_file *file_priv,
+struct drm_modeset_acquire_ctx *ctx)
 {
struct drm_device *dev = crtc->dev;
struct drm_framebuffer *fb = NULL;
@@ -634,21 +635,11 @@ static int drm_mode_cursor_universal(struct drm_crtc 
*crtc,
int32_t crtc_x, crtc_y;
uint32_t crtc_w = 0, crtc_h = 0;
uint32_t src_w = 0, src_h = 0;
-   struct drm_modeset_acquire_ctx ctx;
int ret = 0;
 
BUG_ON(!crtc->cursor);
WARN_ON(crtc->cursor->crtc != crtc && crtc->cursor->crtc != NULL);
 
-   drm_modeset_acquire_init(, 0);
-retry:
-   ret = drm_modeset_lock(>mutex, );
-   if (ret)
-   goto fail;
-   ret = drm_modeset_lock(>cursor->mutex, );
-   if (ret)
-   goto fail;
-
/*
 * Obtain fb we'll be using (either new or existing) and take an extra
 * reference to it if fb != null.  setplane will take care of dropping
@@ -693,7 +684,7 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
 */
ret = 

[PATCH 10/19] drm: Roll out acquire context for the page_flip ioctl

[Daniel Vetter]

Again just prep work.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_plane.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 8535dc17db7e..62e833ffeffd 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -803,6 +803,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
struct drm_framebuffer *fb = NULL;
struct drm_pending_vblank_event *e = NULL;
u32 target_vblank = page_flip->sequence;
+   struct drm_modeset_acquire_ctx ctx;
int ret = -EINVAL;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
@@ -866,7 +867,16 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
return -EINVAL;
}
 
-   drm_modeset_lock_crtc(crtc, crtc->primary);
+   drm_modeset_acquire_init(, 0);
+retry:
+   ret = drm_modeset_lock(>mutex, );
+   if (ret)
+   goto out;
+   ret = drm_modeset_lock(>cursor->mutex, );
+   if (ret)
+   goto out;
+   crtc->acquire_ctx = 
+
if (crtc->primary->fb == NULL) {
/* The framebuffer is currently unbound, presumably
 * due to a hotplug event, that userspace has not
@@ -944,7 +954,14 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
if (crtc->primary->old_fb)
drm_framebuffer_put(crtc->primary->old_fb);
crtc->primary->old_fb = NULL;
-   drm_modeset_unlock_crtc(crtc);
+
+   if (ret == -EDEADLK) {
+   drm_modeset_backoff();
+   goto retry;
+   }
+
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
 
return ret;
 }
-- 
2.11.0

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

[PATCH 16/19] drm: Restrict drm_mode_set_config_internal to non-atomic drivers

[Daniel Vetter]

This is another case where we really can't reconstruct a acquire ctx
in any useful fashion because all the callers are legacy drivers. So
like drm_plane_force_disable simply restrict it to non-atomic drivers
so that it's clear we're ok with passing a NULL ctx.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 34 +-
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index df1ff0b8818b..05447492483f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -444,18 +444,7 @@ int drm_mode_getcrtc(struct drm_device *dev,
return 0;
 }
 
-/**
- * drm_mode_set_config_internal - helper to call 
_mode_config_funcs.set_config
- * @set: modeset config to set
- *
- * This is a little helper to wrap internal calls to the
- * _mode_config_funcs.set_config driver interface. The only thing it adds 
is
- * correct refcounting dance.
- *
- * Returns:
- * Zero on success, negative errno on failure.
- */
-int drm_mode_set_config_internal(struct drm_mode_set *set)
+static int __drm_mode_set_config_internal(struct drm_mode_set *set)
 {
struct drm_crtc *crtc = set->crtc;
struct drm_framebuffer *fb;
@@ -488,6 +477,25 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
 
return ret;
 }
+/**
+ * drm_mode_set_config_internal - helper to call 
_mode_config_funcs.set_config
+ * @set: modeset config to set
+ *
+ * This is a little helper to wrap internal calls to the
+ * _mode_config_funcs.set_config driver interface. The only thing it adds 
is
+ * correct refcounting dance.
+ *
+ * This should only be used by non-atomic legacy drivers.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_mode_set_config_internal(struct drm_mode_set *set)
+{
+   WARN_ON(drm_drv_uses_atomic_modeset(set->crtc->dev));
+
+   return __drm_mode_set_config_internal(set);
+}
 EXPORT_SYMBOL(drm_mode_set_config_internal);
 
 /**
@@ -685,7 +693,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.connectors = connector_set;
set.num_connectors = crtc_req->count_connectors;
set.fb = fb;
-   ret = drm_mode_set_config_internal();
+   ret = __drm_mode_set_config_internal();
 
 out:
if (fb)
-- 
2.11.0

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

[PATCH 15/19] drm: Remove drm_modeset_legacy_acquire_ctx and crtc->acquire_ctx

[Daniel Vetter]

With all the callers of drm_modeset_lock_crtc gone, and all the places
it was formerly used properly wiring the acquire ctx through, we can
remove this.

The only hidden context magic we still have is now the global one.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c  | 14 --
 drivers/gpu/drm/drm_atomic_helper.c   |  4 ++--
 drivers/gpu/drm/drm_modeset_lock.c| 21 -
 drivers/gpu/drm/i915/intel_display.c  |  4 ++--
 drivers/gpu/drm/i915/intel_pipe_crc.c |  2 +-
 include/drm/drm_crtc.h|  9 -
 include/drm/drm_modeset_lock.h|  2 --
 7 files changed, 5 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 9b892af7811a..345310213820 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1516,19 +1516,9 @@ EXPORT_SYMBOL(drm_atomic_add_affected_planes);
 void drm_atomic_legacy_backoff(struct drm_atomic_state *state)
 {
struct drm_device *dev = state->dev;
-   unsigned crtc_mask = 0;
-   struct drm_crtc *crtc;
int ret;
bool global = false;
 
-   drm_for_each_crtc(crtc, dev) {
-   if (crtc->acquire_ctx != state->acquire_ctx)
-   continue;
-
-   crtc_mask |= drm_crtc_mask(crtc);
-   crtc->acquire_ctx = NULL;
-   }
-
if (WARN_ON(dev->mode_config.acquire_ctx == state->acquire_ctx)) {
global = true;
 
@@ -1542,10 +1532,6 @@ void drm_atomic_legacy_backoff(struct drm_atomic_state 
*state)
if (ret)
goto retry;
 
-   drm_for_each_crtc(crtc, dev)
-   if (drm_crtc_mask(crtc) & crtc_mask)
-   crtc->acquire_ctx = state->acquire_ctx;
-
if (global)
dev->mode_config.acquire_ctx = state->acquire_ctx;
 }
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c0ec763ec538..08d10abcece0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2289,7 +2289,7 @@ int drm_atomic_helper_set_config(struct drm_mode_set *set)
return -ENOMEM;
 
state->legacy_set_config = true;
-   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+   state->acquire_ctx = crtc->dev->mode_config.acquire_ctx;
 retry:
ret = __drm_atomic_helper_set_config(set, state);
if (ret != 0)
@@ -2990,7 +2990,7 @@ int drm_atomic_helper_connector_dpms(struct drm_connector 
*connector,
if (!state)
return -ENOMEM;
 
-   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+   state->acquire_ctx = crtc->dev->mode_config.acquire_ctx;
 retry:
crtc_state = drm_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state)) {
diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index c3ca6b859236..64ef09a6cccb 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -149,27 +149,6 @@ void drm_modeset_unlock_all(struct drm_device *dev)
 EXPORT_SYMBOL(drm_modeset_unlock_all);
 
 /**
- * drm_modeset_legacy_acquire_ctx - find acquire ctx for legacy ioctls
- * @crtc: drm crtc
- *
- * Legacy ioctl operations like cursor updates or page flips only have per-crtc
- * locking, and store the acquire ctx in the corresponding crtc. All other
- * legacy operations take all locks and use a global acquire context. This
- * function grabs the right one.
- */
-struct drm_modeset_acquire_ctx *
-drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc)
-{
-   if (crtc->acquire_ctx)
-   return crtc->acquire_ctx;
-
-   WARN_ON(!crtc->dev->mode_config.acquire_ctx);
-
-   return crtc->dev->mode_config.acquire_ctx;
-}
-EXPORT_SYMBOL(drm_modeset_legacy_acquire_ctx);
-
-/**
  * drm_warn_on_modeset_not_all_locked - check that all modeset locks are locked
  * @dev: device
  *
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e27ea89efd67..84abff3f43d9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10715,7 +10715,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
state = drm_atomic_state_alloc(dev);
if (!state)
return -ENOMEM;
-   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+   state->acquire_ctx = dev->mode_config.acquire_ctx;
 
 retry:
plane_state = drm_atomic_get_plane_state(state, primary);
@@ -13075,7 +13075,7 @@ void intel_crtc_restore_mode(struct drm_crtc *crtc)
return;
}
 
-   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+   state->acquire_ctx = crtc->dev->mode_config.acquire_ctx;
 
 retry:
crtc_state = drm_atomic_get_crtc_state(state, crtc);
diff --git 

[PATCH 11/19] drm: Add acquire ctx parameter to ->page_flip(_target)

[Daniel Vetter]

Again just going through the motions, no functional changes in here.

Cc: Gerd Hoffmann 
Cc: Ben Skeggs 
Cc: Russell King 
Cc: Laurent Pinchart 
Cc: Eric Anholt 
Cc: Alex Deucher 
Cc: Christian König 
Signed-off-by: Daniel Vetter t
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 3 ++-
 drivers/gpu/drm/armada/armada_crtc.c| 3 ++-
 drivers/gpu/drm/bochs/bochs_kms.c   | 3 ++-
 drivers/gpu/drm/drm_atomic_helper.c | 8 ++--
 drivers/gpu/drm/drm_plane.c | 6 --
 drivers/gpu/drm/nouveau/nouveau_display.c   | 3 ++-
 drivers/gpu/drm/nouveau/nouveau_display.h   | 3 ++-
 drivers/gpu/drm/radeon/radeon_display.c | 3 ++-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c   | 3 ++-
 drivers/gpu/drm/udl/udl_modeset.c   | 3 ++-
 drivers/gpu/drm/vc4/vc4_crtc.c  | 5 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 3 ++-
 include/drm/drm_atomic_helper.h | 6 --
 include/drm/drm_crtc.h  | 6 --
 16 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 39fc388f222a..7b4fe91d3aec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -311,7 +311,8 @@ int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
 struct drm_framebuffer *fb,
 struct drm_pending_vblank_event *event,
 uint32_t page_flip_flags,
-uint32_t target)
+uint32_t target,
+struct drm_modeset_acquire_ctx *ctx)
 {
struct amdgpu_bo *new_abo;
struct amdgpu_flip_work *work;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index 6b8f766a6a35..d19b803ba509 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -597,7 +597,8 @@ int amdgpu_crtc_set_config(struct drm_mode_set *set);
 int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
 struct drm_framebuffer *fb,
 struct drm_pending_vblank_event *event,
-uint32_t page_flip_flags, uint32_t target);
+uint32_t page_flip_flags, uint32_t target,
+struct drm_modeset_acquire_ctx *ctx);
 void amdgpu_crtc_cleanup_flip_ctx(struct amdgpu_flip_work *work,
  struct amdgpu_bo *new_abo);
 int amdgpu_crtc_prepare_flip(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 1341e0b9368a..4fe19fde84f9 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1027,7 +1027,8 @@ static void armada_drm_crtc_destroy(struct drm_crtc *crtc)
  * and a mode_set.
  */
 static int armada_drm_crtc_page_flip(struct drm_crtc *crtc,
-   struct drm_framebuffer *fb, struct drm_pending_vblank_event *event, 
uint32_t page_flip_flags)
+   struct drm_framebuffer *fb, struct drm_pending_vblank_event *event, 
uint32_t page_flip_flags,
+   struct drm_modeset_acquire_ctx *ctx)
 {
struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
struct armada_frame_work *work;
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index d5e63eff357b..6a91e62da2f4 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -96,7 +96,8 @@ static void bochs_crtc_commit(struct drm_crtc *crtc)
 static int bochs_crtc_page_flip(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_pending_vblank_event *event,
-   uint32_t page_flip_flags)
+   uint32_t page_flip_flags,
+   struct drm_modeset_acquire_ctx *ctx)
 {
struct bochs_device *bochs =
container_of(crtc, struct bochs_device, crtc);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 845378c92ccb..0e65ce4497b3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2860,6 +2860,7 @@ static int page_flip_common(
  * @fb: DRM framebuffer
  * @event: optional DRM event to signal upon completion
  * @flags: flip flags for non-vblank sync'ed updates
+ * @ctx: lock acquisition context
  *
  * Provides a default _crtc_funcs.page_flip implementation
  

[PATCH 09/19] drm: Make drm_modeset_lock_crtc internal

[Daniel Vetter]

This is only for legacy paths that need to grab the crtc/plane lock
combo. If you want to lock a crtc, just use drm_modeset_lock().

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc_internal.h |  3 +++
 drivers/gpu/drm/drm_modeset_lock.c  | 14 --
 include/drm/drm_modeset_lock.h  |  2 --
 3 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 8c04275cf226..de1047530e07 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -61,6 +61,9 @@ int drm_mode_getresources(struct drm_device *dev,
  void *data, struct drm_file *file_priv);
 
 
+/* drm_modeset_lock.c */
+void drm_modeset_lock_crtc(struct drm_crtc *crtc,
+  struct drm_plane *plane);
 /* drm_dumb_buffers.c */
 /* IOCTLs */
 int drm_mode_create_dumb_ioctl(struct drm_device *dev,
diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index bf60f2645e55..c94eff9d7544 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -148,19 +148,6 @@ void drm_modeset_unlock_all(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_modeset_unlock_all);
 
-/**
- * drm_modeset_lock_crtc - lock crtc with hidden acquire ctx for a plane update
- * @crtc: DRM CRTC
- * @plane: DRM plane to be updated on @crtc
- *
- * This function locks the given crtc and plane (which should be either the
- * primary or cursor plane) using a hidden acquire context. This is necessary 
so
- * that drivers internally using the atomic interfaces can grab further locks
- * with the lock acquire context.
- *
- * Note that @plane can be NULL, e.g. when the cursor support hasn't yet been
- * converted to universal planes yet.
- */
 void drm_modeset_lock_crtc(struct drm_crtc *crtc,
   struct drm_plane *plane)
 {
@@ -205,7 +192,6 @@ void drm_modeset_lock_crtc(struct drm_crtc *crtc,
goto retry;
}
 }
-EXPORT_SYMBOL(drm_modeset_lock_crtc);
 
 /**
  * drm_modeset_legacy_acquire_ctx - find acquire ctx for legacy ioctls
diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h
index 96d39fbd12ca..88d35bfc9cd8 100644
--- a/include/drm/drm_modeset_lock.h
+++ b/include/drm/drm_modeset_lock.h
@@ -121,8 +121,6 @@ struct drm_plane;
 
 void drm_modeset_lock_all(struct drm_device *dev);
 void drm_modeset_unlock_all(struct drm_device *dev);
-void drm_modeset_lock_crtc(struct drm_crtc *crtc,
-  struct drm_plane *plane);
 void drm_modeset_unlock_crtc(struct drm_crtc *crtc);
 void drm_warn_on_modeset_not_all_locked(struct drm_device *dev);
 struct drm_modeset_acquire_ctx *
-- 
2.11.0

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

[PATCH 08/19] drm/tilcdc: Drop calls to modeset_lock_crtc

[Daniel Vetter]

Again this is an internal helper, not the official way to lock a crtc.

Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c92faa8f7560..afd2a7b2aff7 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -579,7 +579,7 @@ static void tilcdc_crtc_recover_work(struct work_struct 
*work)
 
dev_info(crtc->dev->dev, "%s: Reset CRTC", __func__);
 
-   drm_modeset_lock_crtc(crtc, NULL);
+   drm_modeset_lock(>mutex, NULL);
 
if (!tilcdc_crtc_is_on(crtc))
goto out;
@@ -587,7 +587,7 @@ static void tilcdc_crtc_recover_work(struct work_struct 
*work)
tilcdc_crtc_disable(crtc);
tilcdc_crtc_enable(crtc);
 out:
-   drm_modeset_unlock_crtc(crtc);
+   drm_modeset_unlock(>mutex);
 }
 
 static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
@@ -595,9 +595,9 @@ static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
struct tilcdc_drm_private *priv = crtc->dev->dev_private;
 
-   drm_modeset_lock_crtc(crtc, NULL);
+   drm_modeset_lock(>mutex, NULL);
tilcdc_crtc_disable(crtc);
-   drm_modeset_unlock_crtc(crtc);
+   drm_modeset_unlock(>mutex);
 
flush_workqueue(priv->wq);
 
@@ -856,7 +856,7 @@ void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
struct tilcdc_drm_private *priv = dev->dev_private;
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
 
-   drm_modeset_lock_crtc(crtc, NULL);
+   drm_modeset_lock(>mutex, NULL);
if (tilcdc_crtc->lcd_fck_rate != clk_get_rate(priv->clk)) {
if (tilcdc_crtc_is_on(crtc)) {
pm_runtime_get_sync(dev->dev);
@@ -868,7 +868,7 @@ void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
pm_runtime_put_sync(dev->dev);
}
}
-   drm_modeset_unlock_crtc(crtc);
+   drm_modeset_unlock(>mutex);
 }
 
 #define SYNC_LOST_COUNT_LIMIT 50
-- 
2.11.0

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

[PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

[Daniel Vetter]

It's been around forever, no one bothered to address the FIXME, so I
presume it's all fine.

Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 25 -
 1 file changed, 25 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index d492d57d5309..424b3fc57203 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -148,15 +148,6 @@ int vmw_du_crtc_cursor_set2(struct drm_crtc *crtc, struct 
drm_file *file_priv,
s32 hotspot_x, hotspot_y;
int ret;
 
-   /*
-* FIXME: Unclear whether there's any global state touched by the
-* cursor_set function, especially vmw_cursor_update_position looks
-* suspicious. For now take the easy route and reacquire all locks. We
-* can do this since the caller in the drm core doesn't check anything
-* which is protected by any looks.
-*/
-   drm_modeset_unlock_crtc(crtc);
-   drm_modeset_lock_all(dev_priv->dev);
hotspot_x = hot_x + du->hotspot_x;
hotspot_y = hot_y + du->hotspot_y;
 
@@ -224,9 +215,6 @@ int vmw_du_crtc_cursor_set2(struct drm_crtc *crtc, struct 
drm_file *file_priv,
}
 
 out:
-   drm_modeset_unlock_all(dev_priv->dev);
-   drm_modeset_lock_crtc(crtc, crtc->cursor);
-
return ret;
 }
 
@@ -239,25 +227,12 @@ int vmw_du_crtc_cursor_move(struct drm_crtc *crtc, int x, 
int y)
du->cursor_x = x + du->set_gui_x;
du->cursor_y = y + du->set_gui_y;
 
-   /*
-* FIXME: Unclear whether there's any global state touched by the
-* cursor_set function, especially vmw_cursor_update_position looks
-* suspicious. For now take the easy route and reacquire all locks. We
-* can do this since the caller in the drm core doesn't check anything
-* which is protected by any looks.
-*/
-   drm_modeset_unlock_crtc(crtc);
-   drm_modeset_lock_all(dev_priv->dev);
-
vmw_cursor_update_position(dev_priv, shown,
   du->cursor_x + du->hotspot_x +
   du->core_hotspot_x,
   du->cursor_y + du->hotspot_y +
   du->core_hotspot_y);
 
-   drm_modeset_unlock_all(dev_priv->dev);
-   drm_modeset_lock_crtc(crtc, crtc->cursor);
-
return 0;
 }
 
-- 
2.11.0

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

[PATCH 07/19] drm/tegra: Don't use modeset_lock_crtc

[Daniel Vetter]

Yes the help text is unhelpful, but atomic drivers should never use
this. Just grab the lock without context or anything.

Also an aside: Checking ->active like this doesn't protect against
nonblocking commits, this is rather bogus.

Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/tegra/dc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 0db5d5a8d3b9..95b373f739f2 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1382,7 +1382,7 @@ static int tegra_dc_show_regs(struct seq_file *s, void 
*data)
struct tegra_dc *dc = node->info_ent->data;
int err = 0;
 
-   drm_modeset_lock_crtc(>base, NULL);
+   drm_modeset_lock(>base.mutex, NULL);
 
if (!dc->base.state->active) {
err = -EBUSY;
@@ -1609,7 +1609,7 @@ static int tegra_dc_show_regs(struct seq_file *s, void 
*data)
 #undef DUMP_REG
 
 unlock:
-   drm_modeset_unlock_crtc(>base);
+   drm_modeset_unlock(>base.mutex);
return err;
 }
 
@@ -1620,7 +1620,7 @@ static int tegra_dc_show_crc(struct seq_file *s, void 
*data)
int err = 0;
u32 value;
 
-   drm_modeset_lock_crtc(>base, NULL);
+   drm_modeset_lock(>base.mutex, NULL);
 
if (!dc->base.state->active) {
err = -EBUSY;
@@ -1640,7 +1640,7 @@ static int tegra_dc_show_crc(struct seq_file *s, void 
*data)
tegra_dc_writel(dc, 0, DC_COM_CRC_CONTROL);
 
 unlock:
-   drm_modeset_unlock_crtc(>base);
+   drm_modeset_unlock(>base.mutex);
return err;
 }
 
-- 
2.11.0

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

[PATCH 05/19] drm/atomic-helper: remove backoff hack from disable/update_plane

[Daniel Vetter]

We can now properly retry at the top level, yay!

v2: Also remove the temporary acquire_ctx hack again, no longer
needed!

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 49 ++---
 drivers/gpu/drm/drm_plane.c |  2 --
 2 files changed, 2 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 1142075032a2..845378c92ccb 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2102,8 +2102,7 @@ int drm_atomic_helper_update_plane(struct drm_plane 
*plane,
if (!state)
return -ENOMEM;
 
-   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
-retry:
+   state->acquire_ctx = ctx;
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
ret = PTR_ERR(plane_state);
@@ -2128,24 +2127,8 @@ int drm_atomic_helper_update_plane(struct drm_plane 
*plane,
 
ret = drm_atomic_commit(state);
 fail:
-   if (ret == -EDEADLK)
-   goto backoff;
-
drm_atomic_state_put(state);
return ret;
-
-backoff:
-   drm_atomic_state_clear(state);
-   drm_atomic_legacy_backoff(state);
-
-   /*
-* Someone might have exchanged the framebuffer while we dropped locks
-* in the backoff code. We need to fix up the fb refcount tracking the
-* core does for us.
-*/
-   plane->old_fb = plane->fb;
-
-   goto retry;
 }
 EXPORT_SYMBOL(drm_atomic_helper_update_plane);
 
@@ -2166,23 +2149,11 @@ int drm_atomic_helper_disable_plane(struct drm_plane 
*plane,
struct drm_plane_state *plane_state;
int ret = 0;
 
-   /*
-* FIXME: Without plane->crtc set we can't get at the implicit legacy
-* acquire context. The real fix will be to wire the acquire ctx through
-* everywhere we need it, but meanwhile prevent chaos by just skipping
-* this noop. The critical case is the cursor ioctls which a) only grab
-* crtc/cursor-plane locks (so we need the crtc to get at the right
-* acquire context) and b) can try to disable the plane multiple times.
-*/
-   if (!plane->crtc)
-   return 0;
-
state = drm_atomic_state_alloc(plane->dev);
if (!state)
return -ENOMEM;
 
-   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(plane->crtc);
-retry:
+   state->acquire_ctx = ctx;
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
ret = PTR_ERR(plane_state);
@@ -2198,24 +2169,8 @@ int drm_atomic_helper_disable_plane(struct drm_plane 
*plane,
 
ret = drm_atomic_commit(state);
 fail:
-   if (ret == -EDEADLK)
-   goto backoff;
-
drm_atomic_state_put(state);
return ret;
-
-backoff:
-   drm_atomic_state_clear(state);
-   drm_atomic_legacy_backoff(state);
-
-   /*
-* Someone might have exchanged the framebuffer while we dropped locks
-* in the backoff code. We need to fix up the fb refcount tracking the
-* core does for us.
-*/
-   plane->old_fb = plane->fb;
-
-   goto retry;
 }
 EXPORT_SYMBOL(drm_atomic_helper_disable_plane);
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 526e74b548b2..8535dc17db7e 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -554,7 +554,6 @@ static int setplane_internal(struct drm_plane *plane,
ret = drm_modeset_lock_all_ctx(plane->dev, );
if (ret)
goto fail;
-   plane->dev->mode_config.acquire_ctx = 
ret = __setplane_internal(plane, crtc, fb,
  crtc_x, crtc_y, crtc_w, crtc_h,
  src_x, src_y, src_w, src_h, );
@@ -649,7 +648,6 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
ret = drm_modeset_lock(>cursor->mutex, );
if (ret)
goto fail;
-   crtc->acquire_ctx = 
 
/*
 * Obtain fb we'll be using (either new or existing) and take an extra
-- 
2.11.0

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

[PATCH 03/19] drm: drm_plane_force_disable is not for atomic drivers

[Daniel Vetter]

This way I can explain why it'll be fine to pass a NULL acquire ctx
here in the next patch.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_plane.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 8a4e75929810..67119332c441 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -277,6 +277,12 @@ EXPORT_SYMBOL(drm_plane_from_index);
  *
  * Used when the plane's current framebuffer is destroyed,
  * and when restoring fbdev mode.
+ *
+ * Note that this function is not suitable for atomic drivers, since it doesn't
+ * wire through the lock acquisition context properly and hence can't handle
+ * retries or driver private locks. You probably want to use
+ * drm_atomic_helper_disable_plane() or
+ * drm_atomic_helper_disable_planes_on_crtc() instead.
  */
 void drm_plane_force_disable(struct drm_plane *plane)
 {
@@ -285,6 +291,8 @@ void drm_plane_force_disable(struct drm_plane *plane)
if (!plane->fb)
return;
 
+   WARN_ON(drm_drv_uses_atomic_modeset(plane->dev));
+
plane->old_fb = plane->fb;
ret = plane->funcs->disable_plane(plane);
if (ret) {
-- 
2.11.0

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

[PATCH 04/19] drm: Add acquire ctx parameter to ->plane_disable

[Daniel Vetter]

Nouveau had a few direct calls to ->disable_plane, I replaced those
with drm_plane_force_disable. Same story for shmob.

Otherwise no code changes.

Cc: Ben Skeggs 
Cc: Russell King 
Cc: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/armada/armada_overlay.c|  3 ++-
 drivers/gpu/drm/drm_atomic_helper.c|  4 +++-
 drivers/gpu/drm/drm_plane.c|  4 ++--
 drivers/gpu/drm/drm_plane_helper.c |  5 +++--
 drivers/gpu/drm/nouveau/dispnv04/overlay.c | 12 +++-
 drivers/gpu/drm/shmobile/shmob_drm_plane.c |  5 +++--
 include/drm/drm_atomic_helper.h|  3 ++-
 include/drm/drm_plane.h|  3 ++-
 include/drm/drm_plane_helper.h |  3 ++-
 9 files changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index b54fd8cbd3a6..424e465ff407 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -258,7 +258,8 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
return 0;
 }
 
-static int armada_ovl_plane_disable(struct drm_plane *plane)
+static int armada_ovl_plane_disable(struct drm_plane *plane,
+   struct drm_modeset_acquire_ctx *ctx)
 {
struct armada_ovl_plane *dplane = drm_to_armada_ovl_plane(plane);
struct drm_framebuffer *fb;
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 8ef7c808670b..1142075032a2 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2152,13 +2152,15 @@ EXPORT_SYMBOL(drm_atomic_helper_update_plane);
 /**
  * drm_atomic_helper_disable_plane - Helper for primary plane disable using * 
atomic
  * @plane: plane to disable
+ * @ctx: lock acquire context
  *
  * Provides a default plane disable handler using the atomic driver interface.
  *
  * RETURNS:
  * Zero on success, error code on failure
  */
-int drm_atomic_helper_disable_plane(struct drm_plane *plane)
+int drm_atomic_helper_disable_plane(struct drm_plane *plane,
+   struct drm_modeset_acquire_ctx *ctx)
 {
struct drm_atomic_state *state;
struct drm_plane_state *plane_state;
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 67119332c441..526e74b548b2 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -294,7 +294,7 @@ void drm_plane_force_disable(struct drm_plane *plane)
WARN_ON(drm_drv_uses_atomic_modeset(plane->dev));
 
plane->old_fb = plane->fb;
-   ret = plane->funcs->disable_plane(plane);
+   ret = plane->funcs->disable_plane(plane, NULL);
if (ret) {
DRM_ERROR("failed to disable plane with busy fb\n");
plane->old_fb = NULL;
@@ -473,7 +473,7 @@ static int __setplane_internal(struct drm_plane *plane,
/* No fb means shut it down */
if (!fb) {
plane->old_fb = plane->fb;
-   ret = plane->funcs->disable_plane(plane);
+   ret = plane->funcs->disable_plane(plane, ctx);
if (!ret) {
plane->crtc = NULL;
plane->fb = NULL;
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 2339879f775d..775e94c30368 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -349,7 +349,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
 * provides their own disable function, this will just
 * wind up returning -EINVAL to userspace.
 */
-   return plane->funcs->disable_plane(plane);
+   return plane->funcs->disable_plane(plane, ctx);
 
/* Find current connectors for CRTC */
num_connectors = get_connectors_for_crtc(crtc, NULL, 0);
@@ -398,7 +398,8 @@ EXPORT_SYMBOL(drm_primary_helper_update);
  * RETURNS:
  * Unconditionally returns -EINVAL.
  */
-int drm_primary_helper_disable(struct drm_plane *plane)
+int drm_primary_helper_disable(struct drm_plane *plane,
+  struct drm_modeset_acquire_ctx *ctx)
 {
return -EINVAL;
 }
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c 
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index 2d90e7898ec8..e54944d23268 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -173,7 +173,8 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
 }
 
 static int
-nv10_disable_plane(struct drm_plane *plane)
+nv10_disable_plane(struct drm_plane *plane,
+  struct drm_modeset_acquire_ctx *ctx)
 {
struct nvif_object *dev = 
_drm(plane->dev)->client.device.object;
  

[PATCH 00/19] wire acquire ctx through legacy modeset paths

[Daniel Vetter]

Hi all,

This is something I kinda had on my todo list ever since atomic landed. The
legacy_backoff() hack really doesn't work if you need to acquire additional
locks, which does restrict drivers in how they handle and protect legacy paths,
and kinda forces us to be overzealous with taking locks for legacy paths, just
in case.

This patch set here fixes this, with 2 huge exceptions:
- get/set_property calls aren't fixed. The locking in there is a mess and needs
  some serious attention. My goal would be that for atomic we take no lock at
  all, and entirely rely upon the magic of drm_modeset_lock and atomic to just
  grab the minimal set required to update a property.

- fbdev emulation helpers. It abused the modeset_lock_all bkl as its own lock,
  which prevents us from pushing it down just around the (atomic) modeset calls,
  and hence from switching over to handling the acquire context in an explicit
  fashion. Thierry started to fix this with the addition of proper locking for
  fbdev emulation, but it needs a pile more work.

Survived light testing with full ww mutex debugging, I'll rely on CI to catch
the remaining mixups :-)

Cheers, Daniel

Daniel Vetter (19):
  drm: Wire up proper acquire ctx for plane functions
  drm: Add acquire ctx parameter to ->update_plane
  drm: drm_plane_force_disable is not for atomic drivers
  drm: Add acquire ctx parameter to ->plane_disable
  drm/atomic-helper: remove backoff hack from disable/update_plane
  drm/vmwgfx: Drop the cursor locking hack
  drm/tegra: Don't use modeset_lock_crtc
  drm/tilcdc: Drop calls to modeset_lock_crtc
  drm: Make drm_modeset_lock_crtc internal
  drm: Roll out acquire context for the page_flip ioctl
  drm: Add acquire ctx parameter to ->page_flip(_target)
  drm/atomic-helper: remove backoff hack from page_flip
  drm: simplify the locking in the GETCRTC ioctl
  drm: Remove drm_modeset_(un)lock_crtc
  drm: Remove drm_modeset_legacy_acquire_ctx and crtc->acquire_ctx
  drm: Restrict drm_mode_set_config_internal to non-atomic drivers
  drm: Add explicit acquire ctx handling around ->set_config
  drm: Add acquire ctx parameter to ->set_config
  drm/atomic-helper: Remove the backoff hack from set_config

 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h|   6 +-
 drivers/gpu/drm/armada/armada_crtc.c|   3 +-
 drivers/gpu/drm/armada/armada_overlay.c |   6 +-
 drivers/gpu/drm/bochs/bochs_kms.c   |   3 +-
 drivers/gpu/drm/drm_atomic.c|  14 ---
 drivers/gpu/drm/drm_atomic_helper.c | 132 +---
 drivers/gpu/drm/drm_crtc.c  |  61 -
 drivers/gpu/drm/drm_crtc_helper.c   |   4 +-
 drivers/gpu/drm/drm_modeset_lock.c  | 102 -
 drivers/gpu/drm/drm_plane.c |  87 ++
 drivers/gpu/drm/drm_plane_helper.c  |  11 ++-
 drivers/gpu/drm/gma500/gma_display.c|   7 +-
 drivers/gpu/drm/gma500/gma_display.h|   3 +-
 drivers/gpu/drm/i915/intel_display.c|   9 +-
 drivers/gpu/drm/i915/intel_pipe_crc.c   |   2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |   8 +-
 drivers/gpu/drm/nouveau/dispnv04/crtc.c |   7 +-
 drivers/gpu/drm/nouveau/dispnv04/overlay.c  |  18 ++--
 drivers/gpu/drm/nouveau/nouveau_display.c   |   3 +-
 drivers/gpu/drm/nouveau/nouveau_display.h   |   4 +-
 drivers/gpu/drm/radeon/radeon_display.c |   8 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c   |   3 +-
 drivers/gpu/drm/shmobile/shmob_drm_plane.c  |   8 +-
 drivers/gpu/drm/tegra/dc.c  |   8 +-
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c|  12 +--
 drivers/gpu/drm/udl/udl_modeset.c   |   3 +-
 drivers/gpu/drm/vc4/vc4_crtc.c  |   5 +-
 drivers/gpu/drm/vc4/vc4_plane.c |   6 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  25 --
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |   3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|   6 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|   6 +-
 include/drm/drm_atomic_helper.h |  15 ++--
 include/drm/drm_crtc.h  |  18 ++--
 include/drm/drm_crtc_helper.h   |   3 +-
 include/drm/drm_modeset_lock.h  |   5 --
 include/drm/drm_plane.h |   7 +-
 include/drm/drm_plane_helper.h  |   6 +-
 39 files changed, 265 insertions(+), 380 deletions(-)

-- 
2.11.0

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

[PATCH 01/19] drm: Wire up proper acquire ctx for plane functions

[Daniel Vetter]

This is just prep work to get an acquire ctx into every place where we
call ->update_plane or ->disable_plane.

v2: Keep the hidden acquire_ctx pointers valid while transitioning.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_plane.c | 52 -
 1 file changed, 42 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index a22e76837065..0d04888172a7 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -457,7 +457,8 @@ static int __setplane_internal(struct drm_plane *plane,
   uint32_t crtc_w, uint32_t crtc_h,
   /* src_{x,y,w,h} values are 16.16 fixed point */
   uint32_t src_x, uint32_t src_y,
-  uint32_t src_w, uint32_t src_h)
+  uint32_t src_w, uint32_t src_h,
+  struct drm_modeset_acquire_ctx *ctx)
 {
int ret = 0;
 
@@ -537,13 +538,26 @@ static int setplane_internal(struct drm_plane *plane,
 uint32_t src_x, uint32_t src_y,
 uint32_t src_w, uint32_t src_h)
 {
+   struct drm_modeset_acquire_ctx ctx;
int ret;
 
-   drm_modeset_lock_all(plane->dev);
+   drm_modeset_acquire_init(, 0);
+retry:
+   ret = drm_modeset_lock_all_ctx(plane->dev, );
+   if (ret)
+   goto fail;
+   plane->dev->mode_config.acquire_ctx = 
ret = __setplane_internal(plane, crtc, fb,
  crtc_x, crtc_y, crtc_w, crtc_h,
- src_x, src_y, src_w, src_h);
-   drm_modeset_unlock_all(plane->dev);
+ src_x, src_y, src_w, src_h, );
+
+fail:
+   if (ret == -EDEADLK) {
+   drm_modeset_backoff();
+   goto retry;
+   }
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
 
return ret;
 }
@@ -613,11 +627,22 @@ static int drm_mode_cursor_universal(struct drm_crtc 
*crtc,
int32_t crtc_x, crtc_y;
uint32_t crtc_w = 0, crtc_h = 0;
uint32_t src_w = 0, src_h = 0;
+   struct drm_modeset_acquire_ctx ctx;
int ret = 0;
 
BUG_ON(!crtc->cursor);
WARN_ON(crtc->cursor->crtc != crtc && crtc->cursor->crtc != NULL);
 
+   drm_modeset_acquire_init(, 0);
+retry:
+   ret = drm_modeset_lock(>mutex, );
+   if (ret)
+   goto fail;
+   ret = drm_modeset_lock(>cursor->mutex, );
+   if (ret)
+   goto fail;
+   crtc->acquire_ctx = 
+
/*
 * Obtain fb we'll be using (either new or existing) and take an extra
 * reference to it if fb != null.  setplane will take care of dropping
@@ -662,7 +687,7 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
 */
ret = __setplane_internal(crtc->cursor, crtc, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
-   0, 0, src_w, src_h);
+   0, 0, src_w, src_h, );
 
/* Update successful; save new cursor position, if necessary */
if (ret == 0 && req->flags & DRM_MODE_CURSOR_MOVE) {
@@ -670,6 +695,15 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
crtc->cursor_y = req->y;
}
 
+fail:
+   if (ret == -EDEADLK) {
+   drm_modeset_backoff();
+   goto retry;
+   }
+
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+
return ret;
 }
 
@@ -696,12 +730,10 @@ static int drm_mode_cursor_common(struct drm_device *dev,
 * If this crtc has a universal cursor plane, call that plane's update
 * handler rather than using legacy cursor handlers.
 */
-   drm_modeset_lock_crtc(crtc, crtc->cursor);
-   if (crtc->cursor) {
-   ret = drm_mode_cursor_universal(crtc, req, file_priv);
-   goto out;
-   }
+   if (crtc->cursor)
+   return drm_mode_cursor_universal(crtc, req, file_priv);
 
+   drm_modeset_lock_crtc(crtc, crtc->cursor);
if (req->flags & DRM_MODE_CURSOR_BO) {
if (!crtc->funcs->cursor_set && !crtc->funcs->cursor_set2) {
ret = -ENXIO;
-- 
2.11.0

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

[PATCH 02/19] drm: Add acquire ctx parameter to ->update_plane

[Daniel Vetter]

Just rolling it out, no code change here.

Cc: Ben Skeggs 
Cc: Russell King 
Cc: Rob Clark 
Cc: Laurent Pinchart 
Cc: Eric Anholt 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/armada/armada_overlay.c| 3 ++-
 drivers/gpu/drm/drm_atomic_helper.c| 4 +++-
 drivers/gpu/drm/drm_plane.c| 2 +-
 drivers/gpu/drm/drm_plane_helper.c | 4 +++-
 drivers/gpu/drm/i915/intel_display.c   | 5 +++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c  | 8 +---
 drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 --
 drivers/gpu/drm/shmobile/shmob_drm_plane.c | 3 ++-
 drivers/gpu/drm/vc4/vc4_plane.c| 6 --
 include/drm/drm_atomic_helper.h| 3 ++-
 include/drm/drm_plane.h| 4 +++-
 include/drm/drm_plane_helper.h | 3 ++-
 12 files changed, 34 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index 34cb73d0db77..b54fd8cbd3a6 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -94,7 +94,8 @@ static int
 armada_ovl_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
struct drm_framebuffer *fb,
int crtc_x, int crtc_y, unsigned crtc_w, unsigned crtc_h,
-   uint32_t src_x, uint32_t src_y, uint32_t src_w, uint32_t src_h)
+   uint32_t src_x, uint32_t src_y, uint32_t src_w, uint32_t src_h,
+   struct drm_modeset_acquire_ctx *ctx)
 {
struct armada_ovl_plane *dplane = drm_to_armada_ovl_plane(plane);
struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 278d72aa012f..8ef7c808670b 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2078,6 +2078,7 @@ EXPORT_SYMBOL(drm_atomic_helper_swap_state);
  * @src_y: y offset of @fb for panning
  * @src_w: width of source rectangle in @fb
  * @src_h: height of source rectangle in @fb
+ * @ctx: lock acquire context
  *
  * Provides a default plane update handler using the atomic driver interface.
  *
@@ -2090,7 +2091,8 @@ int drm_atomic_helper_update_plane(struct drm_plane 
*plane,
   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)
+  uint32_t src_w, uint32_t src_h,
+  struct drm_modeset_acquire_ctx *ctx)
 {
struct drm_atomic_state *state;
struct drm_plane_state *plane_state;
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 0d04888172a7..8a4e75929810 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -510,7 +510,7 @@ static int __setplane_internal(struct drm_plane *plane,
plane->old_fb = plane->fb;
ret = plane->funcs->update_plane(plane, crtc, fb,
 crtc_x, crtc_y, crtc_w, crtc_h,
-src_x, src_y, src_w, src_h);
+src_x, src_y, src_w, src_h, ctx);
if (!ret) {
plane->crtc = crtc;
plane->fb = fb;
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index de1ac5e08f4d..2339879f775d 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -275,6 +275,7 @@ EXPORT_SYMBOL(drm_plane_helper_check_update);
  * @src_y: y offset of @fb for panning
  * @src_w: width of source rectangle in @fb
  * @src_h: height of source rectangle in @fb
+ * @ctx: lock acquire context, not used here
  *
  * Provides a default plane update handler for primary planes.  This is handler
  * is called in response to a userspace SetPlane operation on the plane with a
@@ -303,7 +304,8 @@ int drm_primary_helper_update(struct drm_plane *plane, 
struct drm_crtc *crtc,
  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)
+ uint32_t src_w, uint32_t src_h,
+ struct drm_modeset_acquire_ctx *ctx)
 {
struct drm_mode_set set = {
.crtc = crtc,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 010e5ddb198a..e27ea89efd67 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13426,7 +13426,8 @@ intel_legacy_cursor_update(struct drm_plane *plane,
   

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:
> Quoting Rob Clark (2017-03-22 10:07:54)
>> I guess an interesting question (from someone who doesn't know meson
>> yet) would be whether meson could slurp in the Makefile.sources type
>> stuff that we have, which are shared so far between
>> android/scons/autotools (and for the most part, kept developers from
>> having to care *too* much about the different build systems)
>
> Jason and I have talked about that too. I'd suggested that we could write a
> module for meson to read makefile.sources (since we're surely not the only
> project that would benefit from such a module), except that android is moving 
> to
> blueprint[1] instead of android.mk files. As far as I can tell blueprint 
> doesn't
> support using makefile.sources, so it seems somewhat moot in a world of
> blueprint for android, meson for *.

I guess even if it is only a temporary thing, something that could
slurp in Makefile.sources seems like it would be useful for a
transition period.

I'm not totally up to speed on android/blueprint stuff.. but even some
simplified or different "here-are-my-sources" type file that could be
shared across build systems would be useful.  Meson sounds a bit more
extensible so maybe there is some potential to adapt to whatever
android forces on us ;-)


> I don't think that meson should try to generate blueprint files, since 
> blueprint
> is itself a metabuild system that generates ninja files, and is self
> boot-strapping Go code. I don't know if the community is going to want 
> blueprint
> to live in repo either, since one actually writes Go code for the build 
> system.
> (I'm not objecting prematurely, I'm just pointing out that the design is
> significantly different the Android.mk, and the community will probably want 
> to
> re-evaluate)
>
> If android doesn't mandate a migration to blueprint, or blueprint does handle
> makefile.sources (I don't think it does), I'd be happy to propose a module for
> meson that could read makefile.sources, and write said module, and get said
> module upstream.

I guess from my PoV with my developer hat on, as long as simple things
like adding/removing src files to an existing .so or .a require just
editing one build file for all build systems, that pretty much
guarantees that I don't forget to update one and anger
windows/android/$other_random_thing builders ;-)

(with my $enterprise_distro hat on, I think *probably* the main thing
is that we don't drop autotools build support before
gnome/gstreamer/etc.. not 100% sure about the py3 dependency but I
guess if we aren't the only one that needs it to build, that helps..)

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

[Bug 97338] Black squares in the Spec Ops: The Line chapter select screen

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Samuel Pitoiset  ---
Should be fixed with
https://cgit.freedesktop.org/mesa/mesa/commit/?id=e11049f2c367192dfb1540855f6571a5e29b77ec.

-- 
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 06/10] drm/fb-helper: Support deferred setup

[Daniel Vetter]

On Wed, Mar 22, 2017 at 10:06 PM, Thierry Reding
 wrote:
> On Tue, Mar 21, 2017 at 11:10:22AM +0100, Daniel Vetter wrote:
>> On Tue, Mar 21, 2017 at 09:13:54AM +0100, Thierry Reding wrote:
> [...]
>> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> > b/drivers/gpu/drm/drm_fb_helper.c
> [...]
>> > @@ -2437,11 +2476,16 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
>> >  int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper)
>> >  {
>> > struct drm_device *dev = fb_helper->dev;
>> > +   unsigned int width, height;
>> > int err = 0;
>> >
>> > if (!drm_fbdev_emulation)
>> > return 0;
>> >
>> > +   if (fb_helper->deferred_setup)
>> > +   return drm_fb_helper_initial_config(fb_helper,
>> > +   fb_helper->preferred_bpp);
>>
>> I think this must be moved under the protection of ->lock, you might race
>> otherwise (e.g. hpd vs. userspace forcing a re-probe, both noticing the
>> change).
>
> I think I had originally put this under the lock only to see that result
> in a deadlock. I can't quite remember why that was, but testing shows
> that this still happens. It's getting rather late, so I'll have to defer
> tracking this down to tomorrow.

initial_config also grabs your new lock, which means you'd need more
static _unlocked variants to make it work. I didn't see any other
obvious problem this would cause.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 06/10] drm/fb-helper: Support deferred setup

[Thierry Reding]

On Tue, Mar 21, 2017 at 11:10:22AM +0100, Daniel Vetter wrote:
> On Tue, Mar 21, 2017 at 09:13:54AM +0100, Thierry Reding wrote:
[...]
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
[...]
> > @@ -2437,11 +2476,16 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
> >  int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper)
> >  {
> > struct drm_device *dev = fb_helper->dev;
> > +   unsigned int width, height;
> > int err = 0;
> >  
> > if (!drm_fbdev_emulation)
> > return 0;
> >  
> > +   if (fb_helper->deferred_setup)
> > +   return drm_fb_helper_initial_config(fb_helper,
> > +   fb_helper->preferred_bpp);
> 
> I think this must be moved under the protection of ->lock, you might race
> otherwise (e.g. hpd vs. userspace forcing a re-probe, both noticing the
> change).

I think I had originally put this under the lock only to see that result
in a deadlock. I can't quite remember why that was, but testing shows
that this still happens. It's getting rather late, so I'll have to defer
tracking this down to tomorrow.

Thierry


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

Re: [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jani Nikula (2017-03-22 01:24:19)
> On Tue, 21 Mar 2017, Dylan Baker  wrote:
> > Quoting Jani Nikula (2017-03-21 07:44:55)
> >> How does meson handle build file backwards compatibility between meson
> >> versions? I don't intend to flame, but I've found for some reason many
> >> python projects don't seem to take this very seriously. Either having
> >> conditionals in build files to support building with several meson
> >> versions or always requiring the latest and greatest version would be
> >> rather annoying.
> >
> > Meson makes backwards compatible changes, and the version can be
> > queried using `meson.version()`, which works using meson's version
> > comparison mechanism. I would say this about meson, it's not a 'python
> > project', it's 'a project written in python',
> 
> This is what I meant above, although I clearly didn't write it that way.

I don't think I was exactly clear in what I said either, I would describe SCons
as a "python project", and meson as a "project written in python", since SCons
is python and has some of the warts that make backwards compatibility in python
projects hard (changes that work in the majority case break in some niche use
cases), where meson has a parser/generator written in python.

> > and they've taken great pains to not expose python in meson, and
> > reserve the right to reimplement in a different language if python
> > becomes an issue.
> 
> Right. That helps avoid many of the issues e.g. Sphinx has with the
> configuration files being pure python.

Yes, sphinx's configuration files are awful for just that reason.

Dylan


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

Re: [PATCH] drm: Extract drm_debugfs.h

[Ville Syrjälä]

On Wed, Mar 22, 2017 at 09:53:36PM +0100, Daniel Vetter wrote:
> Doc polish will follow in the next patch.
> 
> v2: Put the include guard #endif at the end (Ville).
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_debugfs.c |  5 ++-
>  include/drm/drmP.h| 44 +
>  include/drm/drm_debugfs.h | 77 
> +++
>  3 files changed, 82 insertions(+), 44 deletions(-)
>  create mode 100644 include/drm/drm_debugfs.h
> 
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 1d2d18d82d2e..4b02f4230562 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -34,9 +34,12 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +
> +#include 
>  #include 
>  #include 
> +#include 
> +
>  #include "drm_internal.h"
>  #include "drm_crtc_internal.h"
>  
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 0e383438f793..60f3255c43a8 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -78,6 +78,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct module;
>  
> @@ -371,27 +372,6 @@ struct drm_ioctl_desc {
>  #define DRM_SCANOUTPOS_ACCURATE (1 << 2)
>  
>  /**
> - * Info file list entry. This structure represents a debugfs or proc file to
> - * be created by the drm core
> - */
> -struct drm_info_list {
> - const char *name; /** file name */
> - int (*show)(struct seq_file*, void*); /** show callback */
> - u32 driver_features; /**< Required driver features for this entry */
> - void *data;
> -};
> -
> -/**
> - * debugfs node structure. This structure represents a debugfs file.
> - */
> -struct drm_info_node {
> - struct list_head list;
> - struct drm_minor *minor;
> - const struct drm_info_list *info_ent;
> - struct dentry *dent;
> -};
> -
> -/**
>   * DRM device structure. This structure represent a complete card that
>   * may contain multiple heads.
>   */
> @@ -592,28 +572,6 @@ int drm_invalid_op(struct drm_device *dev, void *data,
>   * DMA quiscent + idle. DMA quiescent usually requires the hardware lock.
>   */
>  
> - /* Debugfs support */
> -#if defined(CONFIG_DEBUG_FS)
> -extern int drm_debugfs_create_files(const struct drm_info_list *files,
> - int count, struct dentry *root,
> - struct drm_minor *minor);
> -extern int drm_debugfs_remove_files(const struct drm_info_list *files,
> - int count, struct drm_minor *minor);
> -#else
> -static inline int drm_debugfs_create_files(const struct drm_info_list *files,
> -int count, struct dentry *root,
> -struct drm_minor *minor)
> -{
> - return 0;
> -}
> -
> -static inline int drm_debugfs_remove_files(const struct drm_info_list *files,
> -int count, struct drm_minor *minor)
> -{
> - return 0;
> -}
> -#endif
> -
>  /* sysfs support (drm_sysfs.c) */
>  extern void drm_sysfs_hotplug_event(struct drm_device *dev);
>  
> diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
> new file mode 100644
> index ..56924196d08d
> --- /dev/null
> +++ b/include/drm/drm_debugfs.h
> @@ -0,0 +1,77 @@
> +/*
> + * Internal Header for the Direct Rendering Manager
> + *
> + * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
> + * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
> + * Copyright (c) 2009-2010, Code Aurora Forum.
> + * All rights reserved.
> + *
> + * Author: Rickard E. (Rik) Faith 
> + * Author: Gareth Hughes 
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jose Fonseca (2017-03-22 10:59:10)
> On 17/03/17 02:28, Brian Paul wrote:
> >
> > [snip]
> >
> > Sure, I'd like to see one build system instead of two.  Meson supports
> > Windows so that's good.  But the big issue is our automated build
> > system.  Replacing SCons with Meson could be a big deal in that
> > context.  It would at least involve pulling Meson into our toolchain and
> > rewriting a bunch of Python code to grok Meson.  I'd have to go off and
> > investigate that to even see if it's a possibility.  Maybe next week.
> 
> 
> I don't have any experience with Meson.  But for the record I don't have 
> much love for SCons.  I long stopped using SCons for anything but Mesa.
> 
> And my have good experience with cmake + ninja/msvc is positive.  So 
> tools with similar architecture sound good overall.
> 
> In fact, knowing what I know now, if I could go back in time, to when I 
> evaluated CMake and SCons, I'd chose CMake.
> 
> 
> BTW, it seems that newer SCons will drop Python 2 support [1], which 
> might force us to rewrite a lot of SConsfiles/scripts any way.  So 
> perhaps that's a good time to evaluate migrating to something else.
> 
> 
> 
> That said, moving to another build system is always a herculian task. 
> Thought the benefit of having a single build system is appealing and 
> might save time down the line.
>
>
>
> But there are many questions I have about Meson:  how confident are we 
> on Meson?  Are big projects using it?  How sure are we that it won't 
> become abandonware in a few years time?  How does it compare with other 
> newer gen build systems?
> 

Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users

Notably gnome is moving to meson (and some parts already use it), weston and
libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
can't say for sure it's going to be around forever, but its been in development
since late 2012 and still lands several patches a day, they were responsive to
me when I sent a patch (that I still need to respin), and they seem to be
picking up momentum from downstreams.

As to how it compares to other build systems, it's fairly different than cmake
and scons, it's much less scripting and much more declarative, you can look at
the libdrm patch or the meson in libepoxy (which is more mature) to see the
syntax. It doesn't expose python or a full scripting language, though it does
have some fairly simple logic like if/elif/else and foreach, and they support
modules that add functionality, but need to be merged upstream, this is how
pkgconfig writing is implemented, for example. One of the things that it does
better than autotools and (IMHO) cmake, is dependency management, in most cases
it requires no special handling, the only case it does in mesa (so far) is for
local python module dependencies in generators. I think that these are actually
strengths of meson, it's simplicity makes it easy to understand and use.

For support, it's written in pure python (using only the stdlib with no
external deps), and requires python 3.4+. It has backends for ninja on Linux,
ninja and visual studio on Windows, and xcode on macOS; Clang, GCC, and MSVC
are considered first class compilers, some others might work, but are
unsupported.

I have a partial port of piglit to meson that I put together to see what
porting from cmake to meson was like (with no plans to send to the list), I can
push that somewhere for you to look at if you want to see the difference.

> 
> We also have special requirements: one is cross-build from Linux to 
> MinGW, which on Mesa case requires building portions of the tree twice 
> -- once for host -- another for cross-mingw.

Cross compiling for mingw is supported, and it provides a way to differentiate
the build, host, and target machines [1], I've cross compiled for
aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag for
this, but the meson approach is to write an ini file once, and use it again and
again), and the first example of cross compiling is using mingw from linux [2]. 

[1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
[2]https://github.com/mesonbuild/meson/wiki/Cross-compilation

Dylan


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

[PATCH] drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos

[Daniel Vetter]

If we restrict this helper to only kms drivers (which is the case) we
can look up the correct mode easily ourselves. But it's a bit tricky:

- All legacy drivers look at crtc->hwmode. But that is update already
  at the beginning of the modeset helper, which means when we disable
  a pipe. Hence the final timestamps might be a bit off. But since
  this is an existing bug I'm not going to change it, but just try to
  be bug-for-bug compatible with the current code. This only applies
  to radeon

- i915 tries to get it perfect by updating crtc->hwmode when the pipe
  is off (i.e. vblank->enabled = false).

- All other atomic drivers look at crtc->state->adjusted_mode. Those
  that look at state->requested_mode simply don't adjust their mode,
  so it's the same. That has two problems: Accessing crtc->state from
  interrupt handling code is unsafe, and it's updated before we shut
  down the pipe. For nonblocking modesets it's even worse.

For atomic drivers try to implement what i915 does. To do that we add
a new hwmode field to the vblank structure, and update it from
drm_calc_timestamping_constants(). For atomic drivers that's called
from the right spot by the helper library already, so all fine. But
for safety let's enforce that.

For legacy driver this function is only called at the end (oh the
fun), which is broken, so again let's not bother and just stay
bug-for-bug compatible.

The  benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos
directly to implement ->get_vblank_timestamp in every driver, deleting
a lot of code.

v2: Completely new approach, trying to mimick the i915 solution.

v3: Fixup kerneldoc.

v4: Drop the WARN_ON to check that the vblank is off, atomic helpers
currently unconditionally call this. Recomputing the same stuff should
be harmless.

Cc: Mario Kleiner 
Cc: Eric Anholt 
Cc: Rob Clark 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: Alex Deucher 
Cc: Christian König 
Cc: Ben Skeggs 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  4 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   | 41 ---
 drivers/gpu/drm/drm_irq.c | 27 +---
 drivers/gpu/drm/i915/i915_irq.c   | 33 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 26 +---
 drivers/gpu/drm/nouveau/nouveau_display.c | 22 -
 drivers/gpu/drm/nouveau/nouveau_display.h |  2 --
 drivers/gpu/drm/nouveau/nouveau_drm.c |  2 +-
 drivers/gpu/drm/radeon/radeon_drv.c   |  6 +
 drivers/gpu/drm/radeon/radeon_kms.c   | 37 
 drivers/gpu/drm/vc4/vc4_crtc.c| 13 --
 drivers/gpu/drm/vc4/vc4_drv.c |  2 +-
 drivers/gpu/drm/vc4/vc4_drv.h |  3 ---
 include/drm/drm_irq.h | 15 +--
 15 files changed, 42 insertions(+), 193 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index edb3bb83e1a9..61bef9609b24 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1768,10 +1768,6 @@ int amdgpu_device_resume(struct drm_device *dev, bool 
resume, bool fbcon);
 u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
 int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
 void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe);
-bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
-int *max_error,
-struct timeval *vblank_time,
-bool in_vblank_irq);
 long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
 unsigned long arg);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8a61296fd4cc..ba169a0699d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -692,7 +692,7 @@ static struct drm_driver kms_driver = {
.get_vblank_counter = amdgpu_get_vblank_counter_kms,
.enable_vblank = amdgpu_enable_vblank_kms,
.disable_vblank = amdgpu_disable_vblank_kms,
-   .get_vblank_timestamp = amdgpu_get_vblank_timestamp_kms,
+   .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
.get_scanout_position = amdgpu_get_crtc_scanoutpos,
 #if defined(CONFIG_DEBUG_FS)
.debugfs_init = amdgpu_debugfs_init,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index ad295e822d45..32a492bd4e51 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ 

[PATCH] drm: update todo.rst

[Daniel Vetter]

Just drive-by, but we have gsoc running so better to update it now.

Great news is that two entries can be removed because essentially all
done.

v2: Keep a bunch of the todos, Gabriel is working on them.

Cc: Gabriel Krisman Bertazi 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/todo.rst | 31 ---
 1 file changed, 4 insertions(+), 27 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 0cdaddad2b9b..8f6943ccd834 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -16,7 +16,7 @@ De-midlayer drivers
 With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required
 to have a ``drm_bus`` structure set up. Drivers can directly set up the
 ``drm_device`` structure instead of relying on bus methods in ``drm_usb.c``
-and ``drm_platform.c``. The goal is to get rid of the driver's ``->load`` /
+and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` /
 ``->unload`` callbacks and open-code the load/unload sequence properly, using
 the new two-stage ``drm_device`` setup/teardown.
 
@@ -151,7 +151,7 @@ fine-grained per-buffer object and per-context lockings 
scheme. Currently the
 following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and
 ``udl``.
 
-Contact: Daniel Vetter
+Contact: Daniel Vetter, respective driver maintainers
 
 Switch to drm_connector_list_iter for any connector_list walking
 
@@ -193,6 +193,8 @@ plan is to switch to per-file driver API headers, which 
will also structure
 the kerneldoc better. This should also allow more fine-grained ``#include``
 directives.
 
+In the end no .c file should need to include ``drmP.h`` anymore.
+
 Contact: Daniel Vetter
 
 Add missing kerneldoc for exported functions
@@ -220,13 +222,8 @@ be hidden so that driver writers don't accidentally end up 
using it. And to
 prevent security issues in those legacy IOCTLs from being exploited on modern
 drivers. This has multiple possible subtasks:
 
-* Make sure legacy IOCTLs can't be used on modern drivers.
 * Extract support code for legacy features into a ``drm-legacy.ko`` kernel
   module and compile it only when one of the legacy drivers is enabled.
-* Extract legacy functions into their own headers and remove it that from the
-  monolithic ``drmP.h`` header.
-* Remove any lingering cruft from the OS abstraction layer from modern
-  drivers.
 
 This is mostly done, the only thing left is to split up ``drm_irq.c`` into
 legacy cruft and the parts needed by modern KMS drivers.
@@ -338,23 +335,3 @@ Driver Specific
 
 Outside DRM
 ===
-
-Better kerneldoc
-
-
-This is pretty much done, but there's some advanced topics:
-
-Come up with a way to hyperlink to struct members. Currently you can hyperlink
-to the struct using ``#struct_name``, but not to a member within. Would need
-buy-in from kerneldoc maintainers, and the big question is how to make it work
-without totally unsightly
-``drm_foo_bar_really_long_structure->even_longer_memeber`` all over the text
-which breaks text flow.
-
-Figure out how to integrate the asciidoc support for ascii-diagrams. We have a
-few of those (e.g. to describe mode timings), and asciidoc supports converting
-some ascii-art dialect into pngs. Would be really pretty to make that work.
-
-Contact: Daniel Vetter, Jani Nikula
-
-Jani is working on this already, hopefully lands in 4.8.
-- 
2.11.0

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

[PATCH] drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool

[Daniel Vetter]

There's really no reason for anything more:
- Calling this while the crtc vblank stuff isn't set up is a driver
  bug. Those places arlready DRM_ERROR.
- Calling this when the crtc is off is either a driver bug (callin
  drm_crtc_handle_vblank at the wrong time) or a core bug (for
  anything else). Again, we DRM_ERROR.
- EINVAL is checked at higher levels already, and if we'd use struct
  drm_crtc * instead of (dev, pipe) it would be real obvious that
  those are again core bugs.

The only valid failure mode is crap hardware that couldn't sample a
useful timestamp, to ask the core to just grab a not-so-accurate
timestampe. Bool is perfectly fine for that.

v2: Also fix up the one caller, I lost that in the shuffling (Jani).

Cc: Jani Nikula 
Cc: Mario Kleiner 
Cc: Eric Anholt 
Cc: Rob Clark 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: Alex Deucher 
Cc: Christian König 
Cc: Ben Skeggs 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  8 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   | 14 -
 drivers/gpu/drm/drm_irq.c | 49 ---
 drivers/gpu/drm/i915/i915_irq.c   |  8 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 12 
 drivers/gpu/drm/nouveau/nouveau_display.c |  4 +--
 drivers/gpu/drm/nouveau/nouveau_display.h |  4 +--
 drivers/gpu/drm/radeon/radeon_drv.c   |  8 ++---
 drivers/gpu/drm/radeon/radeon_kms.c   | 14 -
 drivers/gpu/drm/vc4/vc4_crtc.c|  2 +-
 drivers/gpu/drm/vc4/vc4_drv.h |  2 +-
 include/drm/drmP.h|  1 -
 include/drm/drm_drv.h |  7 ++---
 include/drm/drm_irq.h | 10 +++
 14 files changed, 64 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index c8860f05bfb9..acd8631d8024 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1768,10 +1768,10 @@ int amdgpu_device_resume(struct drm_device *dev, bool 
resume, bool fbcon);
 u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
 int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
 void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe);
-int amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
-   int *max_error,
-   struct timeval *vblank_time,
-   unsigned flags);
+bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
+int *max_error,
+struct timeval *vblank_time,
+unsigned flags);
 long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
 unsigned long arg);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 55f951bcc91f..ac42f707c046 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -838,19 +838,19 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
unsigned int pipe)
  *
  * Gets the timestamp on the requested crtc based on the
  * scanout position.  (all asics).
- * Returns postive status flags on success, negative error on failure.
+ * Returns true on success, false on failure.
  */
-int amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
-   int *max_error,
-   struct timeval *vblank_time,
-   unsigned flags)
+bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
+int *max_error,
+struct timeval *vblank_time,
+unsigned flags)
 {
struct drm_crtc *crtc;
struct amdgpu_device *adev = dev->dev_private;
 
if (pipe >= dev->num_crtcs) {
DRM_ERROR("Invalid crtc %u\n", pipe);
-   return -EINVAL;
+   return false;
}
 
/* Get associated drm_crtc: */
@@ -859,7 +859,7 @@ int amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, 
unsigned int pipe,
/* This can occur on driver load if some component fails to
 * initialize completely and driver is unloaded */
DRM_ERROR("Uninitialized crtc %d\n", pipe);
-   return -EINVAL;
+   return false;
}
 
/* Helper routine in DRM core does all the work: */
diff --git a/drivers/gpu/drm/drm_irq.c 

[PATCH] drm: Extract drm_ioctl.h

[Daniel Vetter]

To match the drm_ioctl.c we already have.

v2: Remove spurious space (Ville).

Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_ioctl.c |   1 +
 include/drm/drmP.h  |  61 +-
 include/drm/drm_ioctl.h | 102 
 3 files changed, 104 insertions(+), 60 deletions(-)
 create mode 100644 include/drm/drm_ioctl.h

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 601bb0ded9d2..7f4f4f48e390 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -28,6 +28,7 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include 
 #include 
 #include 
 #include "drm_legacy.h"
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index fc2a0744413d..248d2408e56b 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -80,6 +80,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct module;
 
@@ -318,49 +319,6 @@ struct pci_controller;
 
 #define DRM_IF_VERSION(maj, min) (maj << 16 | min)
 
-/**
- * Ioctl function type.
- *
- * \param inode device inode.
- * \param file_priv DRM file private pointer.
- * \param cmd command.
- * \param arg argument.
- */
-typedef int drm_ioctl_t(struct drm_device *dev, void *data,
-   struct drm_file *file_priv);
-
-typedef int drm_ioctl_compat_t(struct file *filp, unsigned int cmd,
-  unsigned long arg);
-
-#define DRM_IOCTL_NR(n)_IOC_NR(n)
-#define DRM_MAJOR   226
-
-#define DRM_AUTH   0x1
-#defineDRM_MASTER  0x2
-#define DRM_ROOT_ONLY  0x4
-#define DRM_CONTROL_ALLOW 0x8
-#define DRM_UNLOCKED   0x10
-#define DRM_RENDER_ALLOW 0x20
-
-struct drm_ioctl_desc {
-   unsigned int cmd;
-   int flags;
-   drm_ioctl_t *func;
-   const char *name;
-};
-
-/**
- * Creates a driver or general drm_ioctl_desc array entry for the given
- * ioctl, for use by drm_ioctl().
- */
-
-#define DRM_IOCTL_DEF_DRV(ioctl, _func, _flags)
\
-   [DRM_IOCTL_NR(DRM_IOCTL_##ioctl) - DRM_COMMAND_BASE] = {\
-   .cmd = DRM_IOCTL_##ioctl,   \
-   .func = _func,  \
-   .flags = _flags,\
-   .name = #ioctl  \
-}
 
 /* Flags and return codes for get_vblank_timestamp() driver function. */
 #define DRM_CALLED_FROM_VBLIRQ 1
@@ -550,23 +508,6 @@ static inline int drm_device_is_unplugged(struct 
drm_device *dev)
 /*@{*/
 
/* Driver support (drm_drv.h) */
-extern int drm_ioctl_permit(u32 flags, struct drm_file *file_priv);
-extern long drm_ioctl(struct file *filp,
- unsigned int cmd, unsigned long arg);
-#ifdef CONFIG_COMPAT
-extern long drm_compat_ioctl(struct file *filp,
-unsigned int cmd, unsigned long arg);
-#else
-/* Let drm_compat_ioctl be assigned to .compat_ioctl unconditionally */
-#define drm_compat_ioctl NULL
-#endif
-extern bool drm_ioctl_flags(unsigned int nr, unsigned int *flags);
-
-/* Misc. IOCTL support (drm_ioctl.c) */
-int drm_noop(struct drm_device *dev, void *data,
-struct drm_file *file_priv);
-int drm_invalid_op(struct drm_device *dev, void *data,
-  struct drm_file *file_priv);
 
 /*
  * These are exported to drivers so that they can implement fencing using
diff --git a/include/drm/drm_ioctl.h b/include/drm/drm_ioctl.h
new file mode 100644
index ..f17ee077f649
--- /dev/null
+++ b/include/drm/drm_ioctl.h
@@ -0,0 +1,102 @@
+/*
+ * Internal Header for the Direct Rendering Manager
+ *
+ * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
+ * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
+ * Copyright (c) 2009-2010, Code Aurora Forum.
+ * All rights reserved.
+ *
+ * Author: Rickard E. (Rik) Faith 
+ * Author: Gareth Hughes 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR 

[PATCH] drm/debugfs: Add kerneldoc

[Daniel Vetter]

I've decided to not document drm_debugfs_remove_files, it's on the way
out.

The biggest part is a huge todo.rst entry with what all should be
improved.

v2: Nits from Gabriel.

Cc: Gabriel Krisman Bertazi 
Reviewed-by: Gabriel Krisman Bertazi 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-uapi.rst |  9 
 Documentation/gpu/todo.rst | 26 +
 drivers/gpu/drm/drm_debugfs.c  | 51 ++
 drivers/gpu/drm/drm_internal.h |  2 +-
 include/drm/drm_debugfs.h  | 38 +--
 5 files changed, 74 insertions(+), 52 deletions(-)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 369e8ca12b8e..76356c86e358 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -210,6 +210,15 @@ Display CRC Support
 .. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
:export:
 
+Debugfs Support
+---
+
+.. kernel-doc:: include/drm/drm_debugfs.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_debugfs.c
+   :export:
+
 VBlank event handling
 =
 
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 64e9d16170ce..0cdaddad2b9b 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -272,6 +272,32 @@ This is a really varied tasks with lots of little bits and 
pieces:
 
 Contact: Daniel Vetter
 
+Clean up the debugfs support
+
+
+There's a bunch of issues with it:
+
+- The drm_info_list ->show() function doesn't even bother to cast to the drm
+  structure for you. This is lazy.
+
+- We probably want to have some support for debugfs files on crtc/connectors 
and
+  maybe other kms objects directly in core. There's even drm_print support in
+  the funcs for these objects to dump kms state, so it's all there. And then 
the
+  ->show() functions should obviously give you a pointer to the right object.
+
+- The drm_info_list stuff is centered on drm_minor instead of drm_device. For
+  anything we want to print drm_device (or maybe drm_file) is the right thing.
+
+- The drm_driver->debugfs_init hooks we have is just an artifact of the old
+  midlayered load sequence. DRM debugfs should work more like sysfs, where you
+  can create properties/files for an object anytime you want, and the core
+  takes care of publishing/unpuplishing all the files at register/unregister
+  time. Drivers shouldn't need to worry about these technicalities, and fixing
+  this (together with the drm_minor->drm_device move) would allow us to remove
+  debugfs_init.
+
+Contact: Daniel Vetter
+
 Better Testing
 ==
 
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 4b02f4230562..c1807d5754b2 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -1,10 +1,3 @@
-/**
- * \file drm_debugfs.c
- * debugfs support for DRM
- *
- * \author Ben Gamari 
- */
-
 /*
  * Created: Sun Dec 21 13:08:50 2008 by bgam...@gmail.com
  *
@@ -75,16 +68,15 @@ static const struct file_operations drm_debugfs_fops = {
 
 
 /**
- * Initialize a given set of debugfs files for a device
- *
- * \param files The array of files to create
- * \param count The number of files given
- * \param root DRI debugfs dir entry.
- * \param minor device minor number
- * \return Zero on success, non-zero on failure
+ * drm_debugfs_create_files - Initialize a given set of debugfs files for DRM
+ * minor
+ * @files: The array of files to create
+ * @count: The number of files given
+ * @root: DRI debugfs dir entry.
+ * @minor: device minor number
  *
  * Create a given set of debugfs files represented by an array of
- * _info_list in the given root directory. These files will be removed
+ *  drm_info_list in the given root directory. These files will be 
removed
  * automatically on drm_debugfs_cleanup().
  */
 int drm_debugfs_create_files(const struct drm_info_list *files, int count,
@@ -133,17 +125,6 @@ int drm_debugfs_create_files(const struct drm_info_list 
*files, int count,
 }
 EXPORT_SYMBOL(drm_debugfs_create_files);
 
-/**
- * Initialize the DRI debugfs filesystem for a device
- *
- * \param dev DRM device
- * \param minor device minor number
- * \param root DRI debugfs dir entry.
- *
- * Create the DRI debugfs root entry "/sys/kernel/debug/dri", the device 
debugfs root entry
- * "/sys/kernel/debug/dri/%minor%/", and each entry in debugfs_list as
- * "/sys/kernel/debug/dri/%minor%/%name%".
- */
 int drm_debugfs_init(struct drm_minor *minor, int minor_id,
 struct dentry *root)
 {
@@ -189,16 +170,6 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
 }
 
 
-/**
- * Remove a list of debugfs files
- *
- * \param files The list of files
- * \param count The number of files
- * \param minor The minor of which we should remove the files
- * 

[PATCH] drm: Extract drm_debugfs.h

[Daniel Vetter]

Doc polish will follow in the next patch.

v2: Put the include guard #endif at the end (Ville).

Cc: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_debugfs.c |  5 ++-
 include/drm/drmP.h| 44 +
 include/drm/drm_debugfs.h | 77 +++
 3 files changed, 82 insertions(+), 44 deletions(-)
 create mode 100644 include/drm/drm_debugfs.h

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 1d2d18d82d2e..4b02f4230562 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -34,9 +34,12 @@
 #include 
 #include 
 #include 
-#include 
+
+#include 
 #include 
 #include 
+#include 
+
 #include "drm_internal.h"
 #include "drm_crtc_internal.h"
 
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 0e383438f793..60f3255c43a8 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -78,6 +78,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct module;
 
@@ -371,27 +372,6 @@ struct drm_ioctl_desc {
 #define DRM_SCANOUTPOS_ACCURATE (1 << 2)
 
 /**
- * Info file list entry. This structure represents a debugfs or proc file to
- * be created by the drm core
- */
-struct drm_info_list {
-   const char *name; /** file name */
-   int (*show)(struct seq_file*, void*); /** show callback */
-   u32 driver_features; /**< Required driver features for this entry */
-   void *data;
-};
-
-/**
- * debugfs node structure. This structure represents a debugfs file.
- */
-struct drm_info_node {
-   struct list_head list;
-   struct drm_minor *minor;
-   const struct drm_info_list *info_ent;
-   struct dentry *dent;
-};
-
-/**
  * DRM device structure. This structure represent a complete card that
  * may contain multiple heads.
  */
@@ -592,28 +572,6 @@ int drm_invalid_op(struct drm_device *dev, void *data,
  * DMA quiscent + idle. DMA quiescent usually requires the hardware lock.
  */
 
-   /* Debugfs support */
-#if defined(CONFIG_DEBUG_FS)
-extern int drm_debugfs_create_files(const struct drm_info_list *files,
-   int count, struct dentry *root,
-   struct drm_minor *minor);
-extern int drm_debugfs_remove_files(const struct drm_info_list *files,
-   int count, struct drm_minor *minor);
-#else
-static inline int drm_debugfs_create_files(const struct drm_info_list *files,
-  int count, struct dentry *root,
-  struct drm_minor *minor)
-{
-   return 0;
-}
-
-static inline int drm_debugfs_remove_files(const struct drm_info_list *files,
-  int count, struct drm_minor *minor)
-{
-   return 0;
-}
-#endif
-
   /* sysfs support (drm_sysfs.c) */
 extern void drm_sysfs_hotplug_event(struct drm_device *dev);
 
diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
new file mode 100644
index ..56924196d08d
--- /dev/null
+++ b/include/drm/drm_debugfs.h
@@ -0,0 +1,77 @@
+/*
+ * Internal Header for the Direct Rendering Manager
+ *
+ * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
+ * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
+ * Copyright (c) 2009-2010, Code Aurora Forum.
+ * All rights reserved.
+ *
+ * Author: Rickard E. (Rik) Faith 
+ * Author: Gareth Hughes 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _DRM_DEBUGFS_H_
+#define _DRM_DEBUGFS_H_
+
+/**
+ * Info file list entry. This structure represents a debugfs or proc file to
+ * be created by the drm core
+ */
+struct drm_info_list {
+   const char *name; /** file name */
+   int 

Re: [PATCH v4 8/8] drm/dp: Track MST link bandwidth

[Daniel Vetter]

On Wed, Mar 22, 2017 at 01:30:30PM +0100, Maarten Lankhorst wrote:
> Op 16-03-17 om 08:10 schreef Dhinakaran Pandiyan:
> Is there any issue into attempting to release vcpi slots when they're already 
> released? If not, for patches 1-3 5-8
> 
> Reviewed-by: Maarten Lankhorst 

Merged patches 1-3 to drm-misc-next, thanks.
-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

Re: [PATCH] drm/doc: Document feature merge deadlines

[Daniel Vetter]

On Tue, Mar 21, 2017 at 03:38:26PM -0400, Sean Paul wrote:
> On Tue, Mar 21, 2017 at 04:52:28PM +0100, Daniel Vetter wrote:
> > The discussion pretty much concluded without objections, let's
> > document what we agreed on.
> > 
> > Cc'ing linux-doc for the new tag in Documentation/process/index.rst.
> > 
> > Cc: Jonathan Corbet 
> > Cc: linux-...@vger.kernel.org
> > Cc: Dave Airlie 
> > Cc: Sean Paul 
> > Cc: Jani Nikula 
> > Cc: Alex Deucher 
> > Cc: Lukas Wunner 
> > Signed-off-by: Daniel Vetter 
> 
> Reviewed-by: Sean Paul 

Dave also acked this on irc, so applied to drm-misc-next.
-Daniel

> 
> > ---
> >  Documentation/gpu/introduction.rst | 25 +
> >  Documentation/process/index.rst|  1 +
> >  2 files changed, 26 insertions(+)
> > 
> > diff --git a/Documentation/gpu/introduction.rst 
> > b/Documentation/gpu/introduction.rst
> > index 1f8bd5ef5f9d..05a82bdfbca4 100644
> > --- a/Documentation/gpu/introduction.rst
> > +++ b/Documentation/gpu/introduction.rst
> > @@ -60,3 +60,28 @@ checkpatch or sparse. We welcome such contributions.
> >  
> >  Anyone looking to kick it up a notch can find a list of janitorial tasks on
> >  the :ref:`TODO list `.
> > +
> > +Contribution Process
> > +
> > +
> > +Mostly the DRM subsystem works like any other kernel subsystem, see 
> > :ref:`the
> > +main process guidelines and documentation ` for how things 
> > work.
> > +Here we just document some of the specialities of the GPU subsystem.
> > +
> > +Feature Merge Deadlines
> > +---
> > +
> > +All feature work must be in the linux-next tree by the -rc6 release of the
> > +current release cycle, otherwise they must be postponed and can't reach 
> > the next
> > +merge window. All patches must have landed in the drm-next tree by latest 
> > -rc7,
> > +but if your branch is not in linux-next then this must have happened by 
> > -rc6
> > +already.
> > +
> > +After that point only bugfixes (like after the upstream merge window has 
> > closed
> > +with the -rc1 release) are allowed. No new platform enabling or new 
> > drivers are
> > +allowed.
> > +
> > +This means that there's a blackout-period of about one month where feature 
> > work
> > +can't be merged. The recommended way to deal with that is having a -next 
> > tree
> > +that's always open, but making sure to not feed it into linux-next during 
> > the
> > +blackout period. As an example, drm-misc works like that.
> > diff --git a/Documentation/process/index.rst 
> > b/Documentation/process/index.rst
> > index 10aa6920709a..82fc399fcd33 100644
> > --- a/Documentation/process/index.rst
> > +++ b/Documentation/process/index.rst
> > @@ -3,6 +3,7 @@
> > \renewcommand\thesection*
> > \renewcommand\thesubsection*
> >  
> > +.. _process_index:
> >  
> >  Working with the kernel development community
> >  =
> > -- 
> > 2.11.0
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

-- 
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 70199] clang+llvm from svn crashes when generating opencl code for 64 bit types

[bugzilla-daemon]

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

Jan Vesely  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |FIXED

--- Comment #12 from Jan Vesely  ---
64 bit integer division was implemented back in 2014 (r207508, r207589, fixed
in r222073). should be in llvm as old 3.6

-- 
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 05/16] drm: update todo.rst

[Daniel Vetter]

On Wed, Mar 22, 2017 at 03:31:00PM -0300, Gabriel Krisman Bertazi wrote:
> Daniel Vetter  writes:
> 
> > Just drive-by, but we have gsoc running so better to update it now.
> >
> > Great news is that two entries can be removed because essentially all
> > done.
> >
> > Signed-off-by: Daniel Vetter 
> > ---
> >  Documentation/gpu/todo.rst | 51 
> > --
> >  1 file changed, 4 insertions(+), 47 deletions(-)
> >
> > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > index 9ecd2ebb8dd8..7dc6de07a3bc 100644
> > --- a/Documentation/gpu/todo.rst
> > +++ b/Documentation/gpu/todo.rst
> > @@ -16,7 +16,7 @@ De-midlayer drivers
> >  With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer 
> > required
> >  to have a ``drm_bus`` structure set up. Drivers can directly set up the
> >  ``drm_device`` structure instead of relying on bus methods in ``drm_usb.c``
> > -and ``drm_platform.c``. The goal is to get rid of the driver's ``->load`` /
> > +and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` /
> >  ``->unload`` callbacks and open-code the load/unload sequence properly, 
> > using
> >  the new two-stage ``drm_device`` setup/teardown.
> >  
> > @@ -151,7 +151,7 @@ fine-grained per-buffer object and per-context
> > lockings scheme. Currently the
> >  following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and
> >  ``udl``.
> >  
> > -Contact: Daniel Vetter
> > +Contact: Daniel Vetter, respective driver maintainers
> >  
> >  Switch to drm_connector_list_iter for any connector_list walking
> >  
> > @@ -193,6 +193,8 @@ plan is to switch to per-file driver API headers, which 
> > will also structure
> >  the kerneldoc better. This should also allow more fine-grained ``#include``
> >  directives.
> >  
> > +In the end no .c file should need to include ``drmP.h`` anymore.
> > +
> >  Contact: Daniel Vetter
> >  
> >  Add missing kerneldoc for exported functions
> > @@ -208,31 +210,6 @@ See https://dri.freedesktop.org/docs/drm/ for what's 
> > there already.
> >  
> >  Contact: Daniel Vetter
> >  
> > -Hide legacy cruft better
> > -
> > -
> > -Way back DRM supported only drivers which shadow-attached to PCI devices 
> > with
> > -userspace or fbdev drivers setting up outputs. Modern DRM drivers take 
> > charge
> > -of the entire device, you can spot them with the DRIVER_MODESET flag.
> > -
> > -Unfortunately there's still large piles of legacy code around which needs 
> > to
> > -be hidden so that driver writers don't accidentally end up using it. And to
> > -prevent security issues in those legacy IOCTLs from being exploited on 
> > modern
> > -drivers. This has multiple possible subtasks:
> > -
> > -* Make sure legacy IOCTLs can't be used on modern drivers.
> > -* Extract support code for legacy features into a ``drm-legacy.ko`` kernel
> > -  module and compile it only when one of the legacy drivers is enabled.
> 
> I've been interested in taking up the work to split drm-legacy.ko from
> drm.ko.  The plan is to make it an optional module that legacy drivers
> depend on, in a way that you don't need to recompile drm.ko to use it.
> 
> I think the issue with the current CONFIG_DRM_VM, for instance, which
> hid some of the code for legacy drivers is the downside of requiring
> recompilation of drm.ko before using a legacy driver.
> 
> Anyway, if you agree with this change, can you keep this entry until
> that is done?

Yeah if you're working on this already I can keep it. But you could keep
working on this also even if there's no todo entry, we're not going to
reject good ideas :-)

I'll resend with only the first sub-task removed, since that is done.
-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

Re: [Intel-gfx] [PATCH 07/16] drm: Extract drm_ioctl.h

[Ville Syrjälä]

On Wed, Mar 22, 2017 at 09:15:23PM +0100, Daniel Vetter wrote:
> On Wed, Mar 22, 2017 at 03:47:31PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 22, 2017 at 09:36:08AM +0100, Daniel Vetter wrote:
> > > To match the drm_ioctl.c we already have.
> > > 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/drm_ioctl.c |   1 +
> > >  include/drm/drmP.h  |  61 +-
> > >  include/drm/drm_ioctl.h | 102 
> > > 
> > >  3 files changed, 104 insertions(+), 60 deletions(-)
> > >  create mode 100644 include/drm/drm_ioctl.h
> > > 
> > > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > > index 601bb0ded9d2..7f4f4f48e390 100644
> > > --- a/drivers/gpu/drm/drm_ioctl.c
> > > +++ b/drivers/gpu/drm/drm_ioctl.c

> > > +#define DRM_MAJOR   226
> > > +
> > > +#define DRM_AUTH 0x1
> > > +#define  DRM_MASTER  0x2
> > > +#define DRM_ROOT_ONLY0x4
> > > +#define DRM_CONTROL_ALLOW 0x8
> > > +#define DRM_UNLOCKED 0x10
> > > +#define DRM_RENDER_ALLOW 0x20
> > > +
> > > +struct drm_ioctl_desc {
> > > + unsigned int cmd;
> > > + int flags;
> > > + drm_ioctl_t *func;
> > > + const char *name;
> > > +};
> > > +
> > > +/**
> > 
> > s/**/*/ ?
> 
> It'll get addressed in the next patch, where I clean up the kernel-doc. I
> assume I can still get your r-b for this patch here?

Sure thing.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 07/16] drm: Extract drm_ioctl.h

[Daniel Vetter]

On Wed, Mar 22, 2017 at 03:47:31PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 22, 2017 at 09:36:08AM +0100, Daniel Vetter wrote:
> > To match the drm_ioctl.c we already have.
> > 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_ioctl.c |   1 +
> >  include/drm/drmP.h  |  61 +-
> >  include/drm/drm_ioctl.h | 102 
> > 
> >  3 files changed, 104 insertions(+), 60 deletions(-)
> >  create mode 100644 include/drm/drm_ioctl.h
> > 
> > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > index 601bb0ded9d2..7f4f4f48e390 100644
> > --- a/drivers/gpu/drm/drm_ioctl.c
> > +++ b/drivers/gpu/drm/drm_ioctl.c
> > @@ -28,6 +28,7 @@
> >   * OTHER DEALINGS IN THE SOFTWARE.
> >   */
> >  
> > +#include 
> >  #include 
> >  #include 
> >  #include "drm_legacy.h"
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index fc2a0744413d..248d2408e56b 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -80,6 +80,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> 
> Same question as for the debugfs thing. Why do we need this?

I forgot to scroll down, oops :(

> >  struct module;
> >  
> > @@ -318,49 +319,6 @@ struct pci_controller;
> >  
> >  #define DRM_IF_VERSION(maj, min) (maj << 16 | min)
> >  
> > -/**
> > - * Ioctl function type.
> > - *
> > - * \param inode device inode.
> > - * \param file_priv DRM file private pointer.
> > - * \param cmd command.
> > - * \param arg argument.
> > - */
> > -typedef int drm_ioctl_t(struct drm_device *dev, void *data,
> > -   struct drm_file *file_priv);
> > -
> > -typedef int drm_ioctl_compat_t(struct file *filp, unsigned int cmd,
> > -  unsigned long arg);
> > -
> > -#define DRM_IOCTL_NR(n)_IOC_NR(n)
> > -#define DRM_MAJOR   226
> > -
> > -#define DRM_AUTH   0x1
> > -#defineDRM_MASTER  0x2
> > -#define DRM_ROOT_ONLY  0x4
> > -#define DRM_CONTROL_ALLOW 0x8
> > -#define DRM_UNLOCKED   0x10
> > -#define DRM_RENDER_ALLOW 0x20
> > -
> > -struct drm_ioctl_desc {
> > -   unsigned int cmd;
> > -   int flags;
> > -   drm_ioctl_t *func;
> > -   const char *name;
> > -};
> > -
> > -/**
> > - * Creates a driver or general drm_ioctl_desc array entry for the given
> > - * ioctl, for use by drm_ioctl().
> > - */
> > -
> > -#define DRM_IOCTL_DEF_DRV(ioctl, _func, _flags)
> > \
> > -   [DRM_IOCTL_NR(DRM_IOCTL_##ioctl) - DRM_COMMAND_BASE] = {\
> > -   .cmd = DRM_IOCTL_##ioctl,   \
> > -   .func = _func,  \
> > -   .flags = _flags,\
> > -   .name = #ioctl  \
> > -}
> >  
> >  /* Flags and return codes for get_vblank_timestamp() driver function. */
> >  #define DRM_CALLED_FROM_VBLIRQ 1
> > @@ -550,23 +508,6 @@ static inline int drm_device_is_unplugged(struct 
> > drm_device *dev)
> >  /*@{*/
> >  
> > /* Driver support (drm_drv.h) */
> > -extern int drm_ioctl_permit(u32 flags, struct drm_file *file_priv);
> > -extern long drm_ioctl(struct file *filp,
> > - unsigned int cmd, unsigned long arg);
> > -#ifdef CONFIG_COMPAT
> > -extern long drm_compat_ioctl(struct file *filp,
> > -unsigned int cmd, unsigned long arg);
> > -#else
> > -/* Let drm_compat_ioctl be assigned to .compat_ioctl unconditionally */
> > -#define drm_compat_ioctl NULL
> > -#endif
> > -extern bool drm_ioctl_flags(unsigned int nr, unsigned int *flags);
> > -
> > -/* Misc. IOCTL support (drm_ioctl.c) */
> > -int drm_noop(struct drm_device *dev, void *data,
> > -struct drm_file *file_priv);
> > -int drm_invalid_op(struct drm_device *dev, void *data,
> > -  struct drm_file *file_priv);
> >  
> >  /*
> >   * These are exported to drivers so that they can implement fencing using
> > diff --git a/include/drm/drm_ioctl.h b/include/drm/drm_ioctl.h
> > new file mode 100644
> > index ..3c3677b5bdb2
> > --- /dev/null
> > +++ b/include/drm/drm_ioctl.h
> > @@ -0,0 +1,102 @@
> > +/*
> > + * Internal Header for the Direct Rendering Manager
> > + *
> > + * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
> > + * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
> > + * Copyright (c) 2009-2010, Code Aurora Forum.
> > + * All rights reserved.
> > + *
> > + * Author: Rickard E. (Rik) Faith 
> > + * Author: Gareth Hughes 
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the 
> > "Software"),
> > + * to deal in the Software without restriction, including without 
> > limitation
> > + * the rights to use, copy, modify, merge, 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson.  It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.

One of the things that's prompted this on our side (I've talked this over with
other people at Intel before starting), was that clearly we *don't* know
autotools well enough to get it right. Emil almost always finds cases were we've
done things *almost*, but not quite right.

For my part, it took me about 3 or 4 days of reading through the docs and
writing the libdrm port to get it right, and a lot of that is just the
boilerplate of having ~8 drivers that all need basically the same logic. 

> Next, my bigger concern is for distro and casual packagers and people
> that maintain large build systems with lots of existing custom
> configurations.  Changing from autotools would basically require many
> of these existing tools and systems to be rewritten and then deal with
> the debugging and fall out from that.  The potential decreased build
> time is a nice bonus, but frankly a lot of people/companies have years
> of investment in existing tools.

Sure, but we're also not the only ones investigating meson. Gnome is using it
already, libepoxy is using it, gstreamer is using it. There are patches for
weston (written by Daniel Stone) and libinput (written by Peter Hutterer), there
are some other projects in the graphics sphere that people are working on. So
even if we as a community decide that meson isn't for us, it's not going away.

Quoting Rob Clark (2017-03-22 10:07:54)
> I guess an interesting question (from someone who doesn't know meson
> yet) would be whether meson could slurp in the Makefile.sources type
> stuff that we have, which are shared so far between
> android/scons/autotools (and for the most part, kept developers from
> having to care *too* much about the different build systems)

Jason and I have talked about that too. I'd suggested that we could write a
module for meson to read makefile.sources (since we're surely not the only
project that would benefit from such a module), except that android is moving to
blueprint[1] instead of android.mk files. As far as I can tell blueprint doesn't
support using makefile.sources, so it seems somewhat moot in a world of
blueprint for android, meson for *.

I don't think that meson should try to generate blueprint files, since blueprint
is itself a metabuild system that generates ninja files, and is self
boot-strapping Go code. I don't know if the community is going to want blueprint
to live in repo either, since one actually writes Go code for the build system.
(I'm not objecting prematurely, I'm just pointing out that the design is
significantly different the Android.mk, and the community will probably want to
re-evaluate)

If android doesn't mandate a migration to blueprint, or blueprint does handle
makefile.sources (I don't think it does), I'd be happy to propose a module for
meson that could read makefile.sources, and write said module, and get said
module upstream.

[1] https://godoc.org/github.com/google/blueprint
> 
> If so, that makes it easier to coexist with existing build systems.  I
> don't think it would be a good idea to remove the autotools build
> anytime soon.. that should be the last one removed, after meson has
> replaced scons (and hopefully android?)

I would imagine that if we did merge meson, we would make at the very least one
release with meson and autotools (scons is VMWare's thing, they can migrate at
their leisure), if not two, to give us a chance to flush out the bugs and to
give various distros who don't have meson ready yet a chance. It'll also give
the fast moving and aggressive distros like Arch and Fedora and chance to
migrate and report bugs.

Dylan


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

Re: [Intel-gfx] [PATCH 02/16] drm: Extract drm_debugfs.h

[Daniel Vetter]

On Wed, Mar 22, 2017 at 03:34:10PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 22, 2017 at 09:36:03AM +0100, Daniel Vetter wrote:
> > Doc polish will follow in the next patch.
> > 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_debugfs.c |  5 ++-
> >  include/drm/drmP.h| 44 +
> >  include/drm/drm_debugfs.h | 76 
> > +++
> >  3 files changed, 81 insertions(+), 44 deletions(-)
> >  create mode 100644 include/drm/drm_debugfs.h
> > 
> > diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> > index 1d2d18d82d2e..4b02f4230562 100644
> > --- a/drivers/gpu/drm/drm_debugfs.c
> > +++ b/drivers/gpu/drm/drm_debugfs.c
> > @@ -34,9 +34,12 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > +
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> > +
> >  #include "drm_internal.h"
> >  #include "drm_crtc_internal.h"
> >  
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index 0e383438f793..60f3255c43a8 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -78,6 +78,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> 
> Why do we need this?
> 
> >  
> >  struct module;
> >  
> > @@ -371,27 +372,6 @@ struct drm_ioctl_desc {
> >  #define DRM_SCANOUTPOS_ACCURATE (1 << 2)
> >  
> >  /**
> > - * Info file list entry. This structure represents a debugfs or proc file 
> > to
> > - * be created by the drm core
> > - */
> > -struct drm_info_list {
> > -   const char *name; /** file name */
> > -   int (*show)(struct seq_file*, void*); /** show callback */
> > -   u32 driver_features; /**< Required driver features for this entry */
> > -   void *data;
> > -};
> > -
> > -/**
> > - * debugfs node structure. This structure represents a debugfs file.
> > - */
> > -struct drm_info_node {
> > -   struct list_head list;
> > -   struct drm_minor *minor;
> > -   const struct drm_info_list *info_ent;
> > -   struct dentry *dent;
> > -};
> > -
> > -/**
> >   * DRM device structure. This structure represent a complete card that
> >   * may contain multiple heads.
> >   */
> > @@ -592,28 +572,6 @@ int drm_invalid_op(struct drm_device *dev, void *data,
> >   * DMA quiscent + idle. DMA quiescent usually requires the hardware lock.
> >   */
> >  
> > -   /* Debugfs support */
> > -#if defined(CONFIG_DEBUG_FS)
> > -extern int drm_debugfs_create_files(const struct drm_info_list *files,
> > -   int count, struct dentry *root,
> > -   struct drm_minor *minor);
> > -extern int drm_debugfs_remove_files(const struct drm_info_list *files,
> > -   int count, struct drm_minor *minor);
> > -#else
> > -static inline int drm_debugfs_create_files(const struct drm_info_list 
> > *files,
> > -  int count, struct dentry *root,
> > -  struct drm_minor *minor)
> > -{
> > -   return 0;
> > -}
> > -
> > -static inline int drm_debugfs_remove_files(const struct drm_info_list 
> > *files,
> > -  int count, struct drm_minor *minor)
> > -{
> > -   return 0;
> > -}
> > -#endif
> > -
> >/* sysfs support (drm_sysfs.c) */
> >  extern void drm_sysfs_hotplug_event(struct drm_device *dev);
> >  
> > diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
> > new file mode 100644
> > index ..17e47c073fa9
> > --- /dev/null
> > +++ b/include/drm/drm_debugfs.h
> > @@ -0,0 +1,76 @@
> > +/*
> > + * Internal Header for the Direct Rendering Manager
> > + *
> > + * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
> > + * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
> > + * Copyright (c) 2009-2010, Code Aurora Forum.
> > + * All rights reserved.
> > + *
> > + * Author: Rickard E. (Rik) Faith 
> > + * Author: Gareth Hughes 
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the 
> > "Software"),
> > + * to deal in the Software without restriction, including without 
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the 
> > next
> > + * paragraph) shall be included in all copies or substantial portions of 
> > the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO 

Re: [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)

[Ville Syrjälä]

On Wed, Mar 22, 2017 at 04:06:32PM +0100, Mario Kleiner wrote:
> On 03/15/2017 10:00 PM, Ville Syrjälä wrote:
> > On Wed, Mar 15, 2017 at 08:40:25PM +, Chris Wilson wrote:
> >> On vblank instant-off systems, we can get into a situation where the cost
> >> of enabling and disabling the vblank IRQ around a drmWaitVblank query
> >> dominates. And with the advent of even deeper hardware sleep state,
> >> touching registers becomes ever more expensive.  However, we know that if
> >> the user wants the current vblank counter, they are also very likely to
> >> immediately queue a vblank wait and so we can keep the interrupt around
> >> and only turn it off if we have no further vblank requests queued within
> >> the interrupt interval.
> >>
> >> After vblank event delivery, this patch adds a shadow of one vblank where
> >> the interrupt is kept alive for the user to query and queue another vblank
> >> event. Similarly, if the user is using blocking drmWaitVblanks, the
> >> interrupt will be disabled on the IRQ following the wait completion.
> >> However, if the user is simply querying the current vblank counter and
> >> timestamp, the interrupt will be disabled after every IRQ and the user
> >> will enabled it again on the first query following the IRQ.
> >>
> >> v2: Mario Kleiner -
> >> After testing this, one more thing that would make sense is to move
> >> the disable block at the end of drm_handle_vblank() instead of at the
> >> top.
> >>
> >> Turns out that if high precision timestaming is disabled or doesn't
> >> work for some reason (as can be simulated by echo 0 >
> >> /sys/module/drm/parameters/timestamp_precision_usec), then with your
> >> delayed disable code at its current place, the vblank counter won't
> >> increment anymore at all for instant queries, ie. with your other
> >> "instant query" patches. Clients which repeatedly query the counter
> >> and wait for it to progress will simply hang, spinning in an endless
> >> query loop. There's that comment in vblank_disable_and_save:
> >>
> >> "* Skip this step if there isn't any high precision timestamp
> >>  * available. In that case we can't account for this and just
> >>  * hope for the best.
> >>  */
> >>
> >> With the disable happening after leading edge of vblank (== hw counter
> >> increment already happened) but before the vblank counter/timestamp
> >> handling in drm_handle_vblank, that step is needed to keep the counter
> >> progressing, so skipping it is bad.
> >>
> >> Now without high precision timestamping support, a kms driver must not
> >> set dev->vblank_disable_immediate = true, as this would cause problems
> >> for clients, so this shouldn't matter, but it would be good to still
> >> make this robust against a future kms driver which might have
> >> unreliable high precision timestamping, e.g., high precision
> >> timestamping that intermittently doesn't work.
> >>
> >> v3: Patch before coffee needs extra coffee.
> >>
> >> Testcase: igt/kms_vblank
> >> Signed-off-by: Chris Wilson 
> >> Cc: Ville Syrjälä 
> >> Cc: Daniel Vetter 
> >> Cc: Michel Dänzer 
> >> Cc: Laurent Pinchart 
> >> Cc: Dave Airlie ,
> >> Cc: Mario Kleiner 
> >
> > Yep. This seems like a good idea to me. I just neglected to review it
> > last time around (and maybe even before that?) for some reason. Locks
> > seem to be taken in the right order, so it at least looks safe to me.
> >
> > Reviewed-by: Ville Syrjälä 
> >
> 
> Hi,
> 
> as a followup to this one, maybe we should move the 
> drm_handle_vblank_events(dev, pipe); down, immediately after Chris new 
> delayed disable code?
> 
> The idea was to avoid lots of redundant enable->disable->enable... calls 
> by having some 1 frame delay before disable. This works for pure vblank 
> count/ts queries.
> 
> But both DRI2 and DRI3/Present use vblank events to trigger a 
> pageflip-ioctl at the right target vblank. With the current ordering we 
> may dispatch the vblank swap trigger event to the X-Server and drop the 
> vblank refcount to zero due to the vblank_put inside 
> drm_handle_vblank_events for the dispatched event, then detect in this 
> patch that refcount == 0 and disable vblanks, but a few microseconds 
> later the server will queue a pageflip ioctl which bumps the refcount 
> and reenables vblank irqs, so we have a redundant disable->enable.
> 
> Also many kms drivers now use drm_crtc_arm_vblank_event() for pageflip 
> completion handling at vblank, the pageflip completion events are also 
> dispatched via drm_handle_vblank_events(). After a pageflip completes, 
> it makes sense to have this "swap shadow" of 1 full frame, as animations 
> would likely queue a new vblank query/event immediately for the next 
> animation frame.

That does seem like a decent idea. It won't actually change anything for

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

[bugzilla-daemon]

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

omegap...@startmail.com changed:

   What|Removed |Added

 CC||omegap...@startmail.com

--- Comment #2 from omegap...@startmail.com ---
I have just built and installed from the debian-unstable branch off git
(https://anonscm.debian.org/cgit/pkg-xorg/driver/xserver-xorg-video-ati.git/)
which is directly tracking upstream - confirmed 7.9 is loaded, the problem is
still present.

Hmm, so XFCE4 Display could be responsible for blacking out the other monitors
momentarily too?

-- 
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 04/16] drm/debugfs: Add kerneldoc

[Gabriel Krisman Bertazi]

Daniel Vetter  writes:

> I've decided to not document drm_debugfs_remove_files, it's on the way
> out.
>
> The biggest part is a huge todor.rst entry with what all should be
> improved.

todo.rst

>
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-uapi.rst |  9 
>  Documentation/gpu/todo.rst | 26 +
>  drivers/gpu/drm/drm_debugfs.c  | 51 
> ++
>  drivers/gpu/drm/drm_internal.h |  2 +-
>  include/drm/drm_debugfs.h  | 38 +--
>  5 files changed, 74 insertions(+), 52 deletions(-)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 369e8ca12b8e..76356c86e358 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -210,6 +210,15 @@ Display CRC Support
>  .. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
> :export:
>  
> +Debugfs Support
> +---
> +
> +.. kernel-doc:: include/drm/drm_debugfs.h
> +   :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_debugfs.c
> +   :export:
> +
>  VBlank event handling
>  =
>  
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 64e9d16170ce..9ecd2ebb8dd8 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -272,6 +272,32 @@ This is a really varied tasks with lots of little bits 
> and pieces:
>  
>  Contact: Daniel Vetter
>  
> +Clean up the debugfs support
> +
> +
> +There's a bunch of issues with it:
> +
> +- The drm_info_list -> show function doesn't even bother to cast to the drm
> +  structure for you. This is lazy.
> +
> +- We probably want to have some support for debugfs files on crtc/connectors 
> and
> +  maybe other kms objects directly in core. There's even drm_print support in
> +  the funcs for these objects to dump kms state, so it's all there. And then 
> the
> +  ->show functions should obviously give you a pointer to the right object.

should you use ->show() ?  not sure.  Either way, extra space on the
previuous "->show" instance.

> +
> +- The drm_info_list stuff is centered on drm_minor instead of drm_device. For
> +  anything we want to print drm_device (or maybe drm_file) is the right 
> thing.
> +
> +- The drm_driver->debugfs_init hooks we have is just an artifact of the old
> +  midlayered load sequence. DRM debugfs should work more like sysfs, where 
> you
> +  can create properties/files for an object anytime you want, and the core
> +  takes care of publishing/unpuplishing all the files at register/unregister
> +  time. Drivers shouldn't need to worry about these technicalities, and 
> fixing
> +  this (together with the drm_minor->drm_device move) would allow us to 
> remove
> +  debugfs_init.
> +
> +Contact: Daniel Vetter
> +
>  Better Testing
>  ==
>  
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 4b02f4230562..c1807d5754b2 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -1,10 +1,3 @@
> -/**
> - * \file drm_debugfs.c
> - * debugfs support for DRM
> - *
> - * \author Ben Gamari 
> - */
> -
>  /*
>   * Created: Sun Dec 21 13:08:50 2008 by bgam...@gmail.com
>   *
> @@ -75,16 +68,15 @@ static const struct file_operations drm_debugfs_fops = {
>  
>  
>  /**
> - * Initialize a given set of debugfs files for a device
> - *
> - * \param files The array of files to create
> - * \param count The number of files given
> - * \param root DRI debugfs dir entry.
> - * \param minor device minor number
> - * \return Zero on success, non-zero on failure
> + * drm_debugfs_create_files - Initialize a given set of debugfs files for DRM
> + *   minor
> + * @files: The array of files to create
> + * @count: The number of files given
> + * @root: DRI debugfs dir entry.
> + * @minor: device minor number
>   *
>   * Create a given set of debugfs files represented by an array of
> - * _info_list in the given root directory. These files will be removed
> + *  drm_info_list in the given root directory. These files will be 
> removed
>   * automatically on drm_debugfs_cleanup().
>   */
>  int drm_debugfs_create_files(const struct drm_info_list *files, int count,
> @@ -133,17 +125,6 @@ int drm_debugfs_create_files(const struct drm_info_list 
> *files, int count,
>  }
>  EXPORT_SYMBOL(drm_debugfs_create_files);
>  
> -/**
> - * Initialize the DRI debugfs filesystem for a device
> - *
> - * \param dev DRM device
> - * \param minor device minor number
> - * \param root DRI debugfs dir entry.
> - *
> - * Create the DRI debugfs root entry "/sys/kernel/debug/dri", the device 
> debugfs root entry
> - * "/sys/kernel/debug/dri/%minor%/", and each entry in debugfs_list as
> - * "/sys/kernel/debug/dri/%minor%/%name%".
> - */
>  int drm_debugfs_init(struct drm_minor *minor, int minor_id,
>

Re: [PATCH 01/16] drm: drop extern from function decls

[Gabriel Krisman Bertazi]

Daniel Vetter  writes:

> It's the default storage class for functions, entirely redundant. And
> a lot of these headers are a bit inconsistent due to organically
> grown.
>

Reviewed-by: Gabriel Krisman Bertazi 


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

[PATCH 2/2] Android: disable pointer-arith and enum-conversion

[Rob Herring]

Disable some more warnings from clang. These don't appear to be warnings
worth fixing.

Signed-off-by: Rob Herring 
---
 Android.common.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Android.common.mk b/Android.common.mk
index f57b8d378565..35c0f02c213c 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -5,7 +5,9 @@ LOCAL_CFLAGS += \
 
 LOCAL_CFLAGS += \
-Wno-unused-parameter \
-   -Wno-missing-field-initializers
+   -Wno-missing-field-initializers \
+   -Wno-pointer-arith \
+   -Wno-enum-conversion
 
 # Quiet down the build system and remove any .h files from the sources
 LOCAL_SRC_FILES := $(patsubst %.h, , $(LOCAL_SRC_FILES))
-- 
2.10.1

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

[PATCH 1/2] Android: fix building of modetest and proptest

[Rob Herring]

These tests depend on tests/util/ headers, but expect the include path
to be tests/.

Signed-off-by: Rob Herring 
---
 Android.mk| 2 ++
 tests/util/Android.mk | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/Android.mk b/Android.mk
index 5209059e670f..292be2360263 100644
--- a/Android.mk
+++ b/Android.mk
@@ -24,6 +24,8 @@
 LIBDRM_COMMON_MK := $(call my-dir)/Android.common.mk
 
 LOCAL_PATH := $(call my-dir)
+LIBDRM_TOP := $(LOCAL_PATH)
+
 include $(CLEAR_VARS)
 
 # Import variables LIBDRM_{,H_,INCLUDE_H_,INCLUDE_VMWGFX_H_}FILES
diff --git a/tests/util/Android.mk b/tests/util/Android.mk
index 7656c4c29883..12eccb42add3 100644
--- a/tests/util/Android.mk
+++ b/tests/util/Android.mk
@@ -32,5 +32,7 @@ LOCAL_SHARED_LIBRARIES := libdrm
 
 LOCAL_SRC_FILES := $(UTIL_FILES)
 
+LOCAL_EXPORT_C_INCLUDE_DIRS := $(LIBDRM_TOP)/tests
+
 include $(LIBDRM_COMMON_MK)
 include $(BUILD_STATIC_LIBRARY)
-- 
2.10.1

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

RE: [RFC 0/5] HDMI 2.0+ video modes handling in DRM core

[Sharma, Shashank]

Hi Jose, 
I can't find the other patches of this series in dri patchwork, am I missing 
something ?

Also, I am planning to publish a series for YUV 420 handling, where I have 
re-used one of your patch to parse YUV 420 block, with some modifications :-).  

Regards
Shashank 
-Original Message-
From: Jose Abreu [mailto:jose.ab...@synopsys.com] 
Sent: Wednesday, March 22, 2017 8:13 PM
To: dri-devel@lists.freedesktop.org
Cc: Carlos Palminha ; Vetter, Daniel 
; Sharma, Shashank ; 
ville.syrj...@linux.intel.com
Subject: Re: [RFC 0/5] HDMI 2.0+ video modes handling in DRM core

++ Daniel

++ Ville

++ Shashank


On 22-03-2017 17:35, Jose Abreu wrote:
> Hi all,
>
> This is a RFC series that aims to collect comments regarding the 
> handling of HDMI 2.0+ video modes and features in the DRM core.
>
> Some of the HDMI 2.0 features are already implemented and only affect 
> kernel drivers (SDCD for example). There are some features, though, 
> which can, and will, affect userspace.
>
> It is clear that userspace can't be broken, so, based on previous 
> discussions I started implementing a "HDMI 2.0+ knob" which can be set 
> by userspace to enable HDMI 2.0+ features.
>
> For now this only limits the exposing of the video modes defined in 
> CEA-861-F, but it can be extended adding, for example, YCbCr 4:2:0.
>
> Please do not see this as a formal patch as this wasn't even compiled 
> tested but, please, feel free to comment :)
>
> NOTE: The adding of the new video modes timings was originally done by 
> Shashank Sharma  so, credit to him. I 
> modified it a little bit (added the HDMI 2.0+ flag) and I don't know 
> if I should add his signed-off-by as it was modified.
>
> Best regards,
> Jose Miguel Abreu
>
> Cc: Carlos Palminha 
> Cc: dri-devel@lists.freedesktop.org
>
> Jose Abreu (5):
>   drm: Add HDMI 2.0+ features exposing knob
>   drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag
>   drm: edid: Add HDMI 2.0 CEA video modes
>   drm: connector: Add hdmi2_allowed flag
>   drm: Do not expose HDMI 2.0+ modes to userspace/drivers unless asked
> to
>
>  drivers/gpu/drm/drm_connector.c|   2 +
>  drivers/gpu/drm/drm_edid.c | 258 
> +
>  drivers/gpu/drm/drm_ioctl.c|   5 +
>  drivers/gpu/drm/drm_probe_helper.c |   9 +-
>  include/drm/drm_connector.h|   2 +
>  include/drm/drm_file.h |   8 ++
>  include/drm/drm_modes.h|  14 ++
>  include/uapi/drm/drm.h |   7 +
>  include/uapi/drm/drm_mode.h|   9 ++
>  9 files changed, 313 insertions(+), 1 deletion(-)
>

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

[Bug 100239] Incorrect rendering in CS:GO

[bugzilla-daemon]

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

--- Comment #2 from Ernst Sjöstrand  ---
I can't reproduce this with my Fury, and have never seen it, for reference...
Any tweaks like R600_DEBUG etc?

-- 
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 100067] [OpenCL] const int in argument list crashes build

[bugzilla-daemon]

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

--- Comment #4 from Vedran Miletić  ---
Can you provide GDB backtraces of both minimal and mat-mul?

-- 
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 100067] [OpenCL] const int in argument list crashes build

[bugzilla-daemon]

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

--- Comment #3 from Vedran Miletić  ---
Created attachment 130386
  --> https://bugs.freedesktop.org/attachment.cgi?id=130386=edit
Kernel from minimal.cpp

Sorry, that was a false positive, local installation issue. I can't reproduce
it on Fiji with all current git or Hawaii Mesa 17.0.2/LLVM 3.9.1. Anyhow, I
extracted the OpenCL kernel and tried compiling it

$ clang -x cl -target amdgcn-- -mcpu=tonga
-Dcl_clang_storage_class_specifiers=1 -Xclang -mlink-bitcode-file -Xclang
/usr/local/lib64/clc/tonga-amdgcn--.bc -I/usr/local/include/clc -include
/usr/local/include/clc/clc.h minimal.cl

doesn't crash in LLVM and running Valgrind on the same command reports no
errors.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] drm: Remove fb hsub/vsub alignment requirement

[Ville Syrjälä]

On Tue, Mar 21, 2017 at 01:26:23PM -0700, Ben Widawsky wrote:
> On 17-03-21 20:12:15, Ville Syrjälä wrote:
> >From: Ville Syrjälä 
> >
> >Allow framebuffers dimesions to be misaligned w.r.t. the subsampling
> >factors. No real reason the core should have to enforce this, and
> >it definitely starts to cause us issues with the i915 CCS support.
> >So let's just lift the restriction.
> >
> >Let's start to round up when computing the color plane dimesions
> >so that we'll not end up with too low an estimate for the memory
> >requirements and whatnot.
> >
> >Cc: Ben Widawsky 
> >Cc: Jason Ekstrand 
> >Signed-off-by: Ville Syrjälä 
> 
> Both 1 and 2 are:
> Reviewed-by: Ben Widawsky 

Thanks. I've pushed patches 1-3 to drm-misc-next. That just leaves
us with the i915 stuff to deal with.

> 
> >---
> > drivers/gpu/drm/drm_framebuffer.c | 8 
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> >b/drivers/gpu/drm/drm_framebuffer.c
> >index 1138f90a7d5d..69e4c1487420 100644
> >--- a/drivers/gpu/drm/drm_framebuffer.c
> >+++ b/drivers/gpu/drm/drm_framebuffer.c
> >@@ -132,7 +132,7 @@ static int fb_plane_width(int width,
> > if (plane == 0)
> > return width;
> >
> >-return width / format->hsub;
> >+return DIV_ROUND_UP(width, format->hsub);
> > }
> >
> > static int fb_plane_height(int height,
> >@@ -141,7 +141,7 @@ static int fb_plane_height(int height,
> > if (plane == 0)
> > return height;
> >
> >-return height / format->vsub;
> >+return DIV_ROUND_UP(height, format->vsub);
> > }
> >
> > static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
> >@@ -158,12 +158,12 @@ static int framebuffer_check(const struct 
> >drm_mode_fb_cmd2 *r)
> > return -EINVAL;
> > }
> >
> >-if (r->width == 0 || r->width % info->hsub) {
> >+if (r->width == 0) {
> > DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
> > return -EINVAL;
> > }
> >
> >-if (r->height == 0 || r->height % info->vsub) {
> >+if (r->height == 0) {
> > DRM_DEBUG_KMS("bad framebuffer height %u\n", r->height);
> > return -EINVAL;
> > }
> >-- 
> >2.10.2
> >

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/16] drm: update todo.rst

[Gabriel Krisman Bertazi]

Daniel Vetter  writes:

> Just drive-by, but we have gsoc running so better to update it now.
>
> Great news is that two entries can be removed because essentially all
> done.
>
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/todo.rst | 51 
> --
>  1 file changed, 4 insertions(+), 47 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 9ecd2ebb8dd8..7dc6de07a3bc 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -16,7 +16,7 @@ De-midlayer drivers
>  With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required
>  to have a ``drm_bus`` structure set up. Drivers can directly set up the
>  ``drm_device`` structure instead of relying on bus methods in ``drm_usb.c``
> -and ``drm_platform.c``. The goal is to get rid of the driver's ``->load`` /
> +and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` /
>  ``->unload`` callbacks and open-code the load/unload sequence properly, using
>  the new two-stage ``drm_device`` setup/teardown.
>  
> @@ -151,7 +151,7 @@ fine-grained per-buffer object and per-context
> lockings scheme. Currently the
>  following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and
>  ``udl``.
>  
> -Contact: Daniel Vetter
> +Contact: Daniel Vetter, respective driver maintainers
>  
>  Switch to drm_connector_list_iter for any connector_list walking
>  
> @@ -193,6 +193,8 @@ plan is to switch to per-file driver API headers, which 
> will also structure
>  the kerneldoc better. This should also allow more fine-grained ``#include``
>  directives.
>  
> +In the end no .c file should need to include ``drmP.h`` anymore.
> +
>  Contact: Daniel Vetter
>  
>  Add missing kerneldoc for exported functions
> @@ -208,31 +210,6 @@ See https://dri.freedesktop.org/docs/drm/ for what's 
> there already.
>  
>  Contact: Daniel Vetter
>  
> -Hide legacy cruft better
> -
> -
> -Way back DRM supported only drivers which shadow-attached to PCI devices with
> -userspace or fbdev drivers setting up outputs. Modern DRM drivers take charge
> -of the entire device, you can spot them with the DRIVER_MODESET flag.
> -
> -Unfortunately there's still large piles of legacy code around which needs to
> -be hidden so that driver writers don't accidentally end up using it. And to
> -prevent security issues in those legacy IOCTLs from being exploited on modern
> -drivers. This has multiple possible subtasks:
> -
> -* Make sure legacy IOCTLs can't be used on modern drivers.
> -* Extract support code for legacy features into a ``drm-legacy.ko`` kernel
> -  module and compile it only when one of the legacy drivers is enabled.

I've been interested in taking up the work to split drm-legacy.ko from
drm.ko.  The plan is to make it an optional module that legacy drivers
depend on, in a way that you don't need to recompile drm.ko to use it.

I think the issue with the current CONFIG_DRM_VM, for instance, which
hid some of the code for legacy drivers is the downside of requiring
recompilation of drm.ko before using a legacy driver.

Anyway, if you agree with this change, can you keep this entry until
that is done?

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

[PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

[Zachary Michaels]

We were experiencing an infinite loop due to VRAM bos getting added back
to the VRAM lru on eviction via ttm_bo_mem_force_space, and reverting
this commit solves the problem.

Signed-off-by: Zachary Michaels 
Signed-off-by: Julien Isorce 
---
 drivers/gpu/drm/radeon/radeon_ttm.c | 25 +
 1 file changed, 1 insertion(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 0cf03ccbf0a7..d50777f1b48e 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -198,30 +198,7 @@ static void radeon_evict_flags(struct ttm_buffer_object 
*bo,
case TTM_PL_VRAM:
if (rbo->rdev->ring[radeon_copy_ring_index(rbo->rdev)].ready == 
false)
radeon_ttm_placement_from_domain(rbo, 
RADEON_GEM_DOMAIN_CPU);
-   else if (rbo->rdev->mc.visible_vram_size < 
rbo->rdev->mc.real_vram_size &&
-bo->mem.start < (rbo->rdev->mc.visible_vram_size >> 
PAGE_SHIFT)) {
-   unsigned fpfn = rbo->rdev->mc.visible_vram_size >> 
PAGE_SHIFT;
-   int i;
-
-   /* Try evicting to the CPU inaccessible part of VRAM
-* first, but only set GTT as busy placement, so this
-* BO will be evicted to GTT rather than causing other
-* BOs to be evicted from VRAM
-*/
-   radeon_ttm_placement_from_domain(rbo, 
RADEON_GEM_DOMAIN_VRAM |
-RADEON_GEM_DOMAIN_GTT);
-   rbo->placement.num_busy_placement = 0;
-   for (i = 0; i < rbo->placement.num_placement; i++) {
-   if (rbo->placements[i].flags & 
TTM_PL_FLAG_VRAM) {
-   if (rbo->placements[0].fpfn < fpfn)
-   rbo->placements[0].fpfn = fpfn;
-   } else {
-   rbo->placement.busy_placement =
-   >placements[i];
-   rbo->placement.num_busy_placement = 1;
-   }
-   }
-   } else
+   else
radeon_ttm_placement_from_domain(rbo, 
RADEON_GEM_DOMAIN_GTT);
break;
case TTM_PL_TT:
-- 
2.11.1

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

Re: [PATCH 12/16] drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp

[Ville Syrjälä]

On Wed, Mar 22, 2017 at 09:36:13AM +0100, Daniel Vetter wrote:
> It's overkill to have a flag parameter which is essentially used just
> as a boolean. This takes care of core + adjusting drivers.
> 
> Adjusting the scanout position callback is a bit harder, since radeon
> also supplies it's own driver-private flags in there.

This part worried me, but indeed radeon only passes the custom flag to
the scanout position hook. Patch lgtm

Reviewed-by: Ville Syrjälä 

> 
> Cc: Mario Kleiner 
> Cc: Eric Anholt 
> Cc: Rob Clark 
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: Ben Skeggs 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  6 ++---
>  drivers/gpu/drm/drm_irq.c | 41 
> +--
>  drivers/gpu/drm/i915/i915_irq.c   |  4 +--
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  4 +--
>  drivers/gpu/drm/nouveau/nouveau_display.c |  5 ++--
>  drivers/gpu/drm/nouveau/nouveau_display.h |  2 +-
>  drivers/gpu/drm/radeon/radeon_drv.c   |  2 +-
>  drivers/gpu/drm/radeon/radeon_kms.c   |  4 +--
>  drivers/gpu/drm/vc4/vc4_crtc.c|  4 +--
>  drivers/gpu/drm/vc4/vc4_drv.h |  2 +-
>  include/drm/drm_drv.h | 11 -
>  include/drm/drm_irq.h |  2 +-
>  13 files changed, 46 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index acd8631d8024..edb3bb83e1a9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1771,7 +1771,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
> unsigned int pipe);
>  bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int 
> pipe,
>int *max_error,
>struct timeval *vblank_time,
> -  unsigned flags);
> +  bool in_vblank_irq);
>  long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
>unsigned long arg);
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index ac42f707c046..ad295e822d45 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -834,7 +834,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
> unsigned int pipe)
>   * @crtc: crtc to get the timestamp for
>   * @max_error: max error
>   * @vblank_time: time value
> - * @flags: flags passed to the driver
> + * @in_vblank_irq: called from drm_handle_vblank()
>   *
>   * Gets the timestamp on the requested crtc based on the
>   * scanout position.  (all asics).
> @@ -843,7 +843,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
> unsigned int pipe)
>  bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int 
> pipe,
>int *max_error,
>struct timeval *vblank_time,
> -  unsigned flags)
> +  bool in_vblank_irq)
>  {
>   struct drm_crtc *crtc;
>   struct amdgpu_device *adev = dev->dev_private;
> @@ -864,7 +864,7 @@ bool amdgpu_get_vblank_timestamp_kms(struct drm_device 
> *dev, unsigned int pipe,
>  
>   /* Helper routine in DRM core does all the work: */
>   return drm_calc_vbltimestamp_from_scanoutpos(dev, pipe, max_error,
> -  vblank_time, flags,
> +  vblank_time, in_vblank_irq,
>>hwmode);
>  }
>  
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 2121ea29e1b2..059c3346db68 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -54,7 +54,7 @@
>  
>  static bool
>  drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
> -   struct timeval *tvblank, unsigned flags);
> +   struct timeval *tvblank, bool in_vblank_irq);
>  
>  static unsigned int drm_timestamp_precision = 20;  /* Default to 20 usecs. */
>  
> @@ -138,7 +138,7 @@ static void drm_reset_vblank_timestamp(struct drm_device 
> *dev, unsigned int pipe
>*/
>   do {
>   cur_vblank = __get_vblank_counter(dev, pipe);
> - rc = drm_get_last_vbltimestamp(dev, pipe, _vblank, 0);
> + rc = drm_get_last_vbltimestamp(dev, pipe, _vblank, false);
>   } while (cur_vblank != __get_vblank_counter(dev, pipe) && 

[Bug 96897] clpeak OpenCL benchmark hangs during compilation on Clover RadeonSI

[bugzilla-daemon]

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

--- Comment #4 from Vedran Miletić  ---
Not anymore on both LLVM 3.9.1 and LLVM git from today:

input.cl:34:106: error: call to 'mad' is ambiguous
input.cl:30:22: note: expanded from macro 'MAD_64'
input.cl:29:22: note: expanded from macro 'MAD_16'
input.cl:28:25: note: expanded from macro 'MAD_4'
/usr/local/include/clc/math/mad.inc:1:39: note: candidate function
/usr/local/include/clc/math/mad.inc:1:39: note: candidate function
/usr/local/include/clc/math/mad.inc:1:39: note: candidate function
/usr/local/include/clc/math/mad.inc:1:39: note: candidate function
/usr/local/include/clc/math/mad.inc:1:39: note: candidate function
/usr/local/include/clc/math/mad.inc:1:39: note: candidate function
/usr/local/include/clc/math/mad.inc:1:39: note: candidate function
/usr/local/include/clc/math/mad.inc:1:39: note: candidate function
/usr/local/include/clc/math/mad.inc:1:39: note: candidate function
/usr/local/include/clc/math/mad.inc:1:39: note: candidate function
/usr/local/include/clc/math/mad.inc:1:39: note: candidate function
/usr/local/include/clc/math/mad.inc:1:39: note: candidate function
input.cl:34:106: error: call to 'mad' is ambiguous

Did clpeak change or did we change? If we changed, did we regress?

-- 
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: [Intel-gfx] [PATCH 07/16] drm: Extract drm_ioctl.h

[Ville Syrjälä]

On Wed, Mar 22, 2017 at 06:56:32PM +0100, Daniel Vetter wrote:
> On Wed, Mar 22, 2017 at 03:47:31PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 22, 2017 at 09:36:08AM +0100, Daniel Vetter wrote:
> > > To match the drm_ioctl.c we already have.
> > > 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/drm_ioctl.c |   1 +
> > >  include/drm/drmP.h  |  61 +-
> > >  include/drm/drm_ioctl.h | 102 
> > > 
> > >  3 files changed, 104 insertions(+), 60 deletions(-)
> > >  create mode 100644 include/drm/drm_ioctl.h
> > > 
> > > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > > index 601bb0ded9d2..7f4f4f48e390 100644
> > > --- a/drivers/gpu/drm/drm_ioctl.c
> > > +++ b/drivers/gpu/drm/drm_ioctl.c
> > > @@ -28,6 +28,7 @@
> > >   * OTHER DEALINGS IN THE SOFTWARE.
> > >   */
> > >  
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include "drm_legacy.h"
> > > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > > index fc2a0744413d..248d2408e56b 100644
> > > --- a/include/drm/drmP.h
> > > +++ b/include/drm/drmP.h
> > > @@ -80,6 +80,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > 
> > Same question as for the debugfs thing. Why do we need this?
> 
> Try fixing up the drmP.h include hell, and you know that it'd take a few
> hundred patches. And right now it's impossible, because the most central
> structure (struct drm_device) is in here, so defacto we still have a
> monolithic header which needs everything.
> 
> First we need to split it completely, then all places that include drmP.h
> need to switch to individual headers (each time fixing up a pile of
> fallout), and then eventually (after fixing the few hundred places or so)
> we can remove all these include lines here (or well, get rid of drmP.h
> entirely). But not before. I tried.

OK. I thought this stuff wouldn't have spread that far beyond the
ioctl implementations, but I guess not.

Hmm. Had I spent any thought on this I would have realized that at
least DRM_IOCTL_DEF_DRV() is used in pretty much every driver.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel