Re: [PATCH 58/59] drm/todo: Add new debugfs todo

2019-06-14 Thread Greg Kroah-Hartman
On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> Greg is busy already, but maybe he won't do everything ...
> 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/todo.rst | 3 +++
>  1 file changed, 3 insertions(+)

Acked-by: Greg Kroah-Hartman 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: Use the correct style for SPDX License Identifier

2019-06-14 Thread Nishad Kamdar
This patch corrects the SPDX License Identifier style
in header files related to DRM Drivers for Intel 915 Graphics.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used)

Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46
and some manual changes.

Suggested-by: Joe Perches 
Signed-off-by: Nishad Kamdar 
---
 drivers/gpu/drm/i915/gem/i915_gem_clflush.h  | 3 +--
 drivers/gpu/drm/i915/gem/i915_gem_context.h  | 3 +--
 drivers/gpu/drm/i915/gem/i915_gem_context_types.h| 3 +--
 drivers/gpu/drm/i915/gem/i915_gem_ioctls.h   | 3 +--
 drivers/gpu/drm/i915/gem/i915_gem_object.h   | 3 +--
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 +--
 drivers/gpu/drm/i915/gem/i915_gem_pm.h   | 3 +--
 drivers/gpu/drm/i915/gem/i915_gemfs.h| 3 +--
 drivers/gpu/drm/i915/gem/selftests/huge_gem_object.h | 3 +--
 drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.h   | 3 +--
 drivers/gpu/drm/i915/gem/selftests/mock_context.h| 3 +--
 drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.h | 3 +--
 drivers/gpu/drm/i915/gem/selftests/mock_gem_object.h | 3 +--
 drivers/gpu/drm/i915/gt/intel_context.h  | 3 +--
 drivers/gpu/drm/i915/gt/intel_context_types.h| 3 +--
 drivers/gpu/drm/i915/gt/intel_engine_pm.h| 3 +--
 drivers/gpu/drm/i915/gt/intel_engine_types.h | 3 +--
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 3 +--
 drivers/gpu/drm/i915/gt/intel_gt_pm.h| 3 +--
 drivers/gpu/drm/i915/gt/intel_lrc_reg.h  | 3 +--
 drivers/gpu/drm/i915/gt/intel_reset.h| 3 +--
 drivers/gpu/drm/i915/gt/intel_sseu.h | 3 +--
 drivers/gpu/drm/i915/gt/intel_workarounds.h  | 3 +--
 drivers/gpu/drm/i915/gt/intel_workarounds_types.h| 3 +--
 drivers/gpu/drm/i915/i915_active.h   | 3 +--
 drivers/gpu/drm/i915/i915_active_types.h | 3 +--
 drivers/gpu/drm/i915/i915_gem_batch_pool.h   | 3 +--
 drivers/gpu/drm/i915/i915_globals.h  | 3 +--
 drivers/gpu/drm/i915/i915_gpu_error.h| 3 +--
 drivers/gpu/drm/i915/i915_oa_bdw.h   | 3 +--
 drivers/gpu/drm/i915/i915_oa_bxt.h   | 3 +--
 drivers/gpu/drm/i915/i915_oa_cflgt2.h| 3 +--
 drivers/gpu/drm/i915/i915_oa_cflgt3.h| 3 +--
 drivers/gpu/drm/i915/i915_oa_chv.h   | 3 +--
 drivers/gpu/drm/i915/i915_oa_cnl.h   | 3 +--
 drivers/gpu/drm/i915/i915_oa_glk.h   | 3 +--
 drivers/gpu/drm/i915/i915_oa_hsw.h   | 3 +--
 drivers/gpu/drm/i915/i915_oa_icl.h   | 3 +--
 drivers/gpu/drm/i915/i915_oa_kblgt2.h| 3 +--
 drivers/gpu/drm/i915/i915_oa_kblgt3.h| 3 +--
 drivers/gpu/drm/i915/i915_oa_sklgt2.h| 3 +--
 drivers/gpu/drm/i915/i915_oa_sklgt3.h| 3 +--
 drivers/gpu/drm/i915/i915_oa_sklgt4.h| 3 +--
 drivers/gpu/drm/i915/i915_pmu.h  | 3 +--
 drivers/gpu/drm/i915/i915_priolist_types.h   | 3 +--
 drivers/gpu/drm/i915/i915_query.h| 3 +--
 drivers/gpu/drm/i915/i915_scatterlist.h  | 3 +--
 drivers/gpu/drm/i915/i915_scheduler.h| 3 +--
 drivers/gpu/drm/i915/i915_scheduler_types.h  | 3 +--
 drivers/gpu/drm/i915/i915_sw_fence.h | 3 +--
 drivers/gpu/drm/i915/i915_timeline_types.h   | 3 +--
 drivers/gpu/drm/i915/i915_user_extensions.h  | 3 +--
 drivers/gpu/drm/i915/intel_huc_fw.h  | 3 +--
 drivers/gpu/drm/i915/intel_wakeref.h | 3 +--
 drivers/gpu/drm/i915/intel_wopcm.h   | 3 +--
 drivers/gpu/drm/i915/selftests/igt_flush_test.h  | 3 +--
 drivers/gpu/drm/i915/selftests/igt_live_test.h   | 3 +--
 drivers/gpu/drm/i915/selftests/igt_reset.h   | 3 +--
 drivers/gpu/drm/i915/selftests/igt_spinner.h | 3 +--
 drivers/gpu/drm/i915/selftests/igt_wedge_me.h| 3 +--
 drivers/gpu/drm/i915/selftests/mock_timeline.h   | 3 +--
 61 files changed, 61 insertions(+), 122 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.h 
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.h
index e6c382973129..9d7ee1579900 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.h
@@ -1,6 +1,5 @@
+/* SPDX-License-Identifier: MIT */
 /*
- * SPDX-License-Identifier: MIT
- *
  * Copyright © 2016 Intel Corporation
  */
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 630392c77e48..26a965805e7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -1,6 +1,5 @@
+/* SPDX-License-Identifier: MIT */
 /*
- * SPDX-License-Identifier: MIT
- *

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

2019-06-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #45 from Marek Olšák  ---
The problem might be in the kernel. See function rs400_gpu_init. I think it
should call r300_gpu_init instead of r420_pipes_init.

-- 
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 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

2019-06-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #44 from Marek Olšák  ---
RC410 most likely has only 1 pipe. 3 pipes would be for a discrete GPU that
isn't small.

-- 
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 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

2019-06-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #43 from Marek Olšák  ---
You can try to compare your num_gb_pipes with somebody else who has the same
GPU.

-- 
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: dev_pagemap related cleanups

2019-06-14 Thread Dan Williams
On Thu, Jun 13, 2019 at 11:14 PM Christoph Hellwig  wrote:
>
> On Thu, Jun 13, 2019 at 11:27:39AM -0700, Dan Williams wrote:
> > It also turns out the nvdimm unit tests crash with this signature on
> > that branch where base v5.2-rc3 passes:
>
> How do you run that test?

This is the unit test suite that gets kicked off by running "make
check" from the ndctl source repository. In this case it requires the
nfit_test set of modules to create a fake nvdimm environment.

The setup instructions are in the README, but feel free to send me
branches and I can kick off a test. One of these we'll get around to
making it automated for patch submissions to the linux-nvdimm mailing
list.

https://github.com/pmem/ndctl/blob/master/README.md
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/panel: Add helper for reading DT rotation

2019-06-14 Thread dbasehore .
On Fri, Jun 14, 2019 at 5:43 PM dbasehore .  wrote:
>
> On Wed, Jun 12, 2019 at 2:18 PM Sam Ravnborg  wrote:
> >
> > Hi Derek.
> >
> > On Mon, Jun 10, 2019 at 09:03:46PM -0700, Derek Basehore wrote:
> > > This adds a helper function for reading the rotation (panel
> > > orientation) from the device tree.
> > >
> > > Signed-off-by: Derek Basehore 
> > > ---
> > >  drivers/gpu/drm/drm_panel.c | 41 +
> > >  include/drm/drm_panel.h |  7 +++
> > >  2 files changed, 48 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> > > index dbd5b873e8f2..3b689ce4a51a 100644
> > > --- a/drivers/gpu/drm/drm_panel.c
> > > +++ b/drivers/gpu/drm/drm_panel.c
> > > @@ -172,6 +172,47 @@ struct drm_panel *of_drm_find_panel(const struct 
> > > device_node *np)
> > >   return ERR_PTR(-EPROBE_DEFER);
> > >  }
> > >  EXPORT_SYMBOL(of_drm_find_panel);
> > > +
> > > +/**
> > > + * of_drm_get_panel_orientation - look up the rotation of the panel 
> > > using a
> > > + * device tree node
> > > + * @np: device tree node of the panel
> > > + * @orientation: orientation enum to be filled in
> > The comment says "enum" but the type used is an int.
> > Why not use enum drm_panel_orientation?
> >
>
> The binding is just an int value, but I can change it to the enum.

Oops, I see what happened here. The way I wrote it should actually use the enum

>
> > > + *
> > > + * Looks up the rotation of a panel in the device tree. The rotation in 
> > > the
> > > + * device tree is counter clockwise.
> > > + *
> > > + * Return: 0 when a valid rotation value (0, 90, 180, or 270) is read or 
> > > the
> > > + * rotation property doesn't exist. -EERROR otherwise.
> > > + */
> > Initially I read -EEROOR as a specific error code.
> > But I gues the semantic is to say that a negative error code is returned
> > if something was wrong.
> > As we do not use the "-EERROR" syntax anywhere else in drm, please
> > reword like we do in other places.
> >
> >
> > Also - it is worth to mention that the rotation returned is
> > DRM_MODE_PANEL_ORIENTATION_UNKNOWN if the property is not specified.
> > I wonder if this is correct, as no property could also been
> > interpretated as DRM_MODE_PANEL_ORIENTATION_NORMAL.
> > And in most cases the roation property is optional, so one could
> > assume that no property equals 0 degree.
> >
> >
> > Sam
> >
> > > +int of_drm_get_panel_orientation(const struct device_node *np, int 
> > > *orientation)
> > > +{
> > > + int rotation, ret;
> > > +
> > > + ret = of_property_read_u32(np, "rotation", &rotation);
> > > + if (ret == -EINVAL) {
> > > + /* Don't return an error if there's no rotation property. */
> > > + *orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> > > + return 0;
> > > + }
> > > +
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + if (rotation == 0)
> > > + *orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> > > + else if (rotation == 90)
> > > + *orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
> > > + else if (rotation == 180)
> > > + *orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
> > > + else if (rotation == 270)
> > > + *orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
> > > + else
> > > + return -EINVAL;
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(of_drm_get_panel_orientation);
> > >  #endif
> > >
> > >  MODULE_AUTHOR("Thierry Reding ");
> > > diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> > > index 8c738c0e6e9f..13631b2efbaa 100644
> > > --- a/include/drm/drm_panel.h
> > > +++ b/include/drm/drm_panel.h
> > > @@ -197,11 +197,18 @@ int drm_panel_detach(struct drm_panel *panel);
> > >
> > >  #if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL)
> > >  struct drm_panel *of_drm_find_panel(const struct device_node *np);
> > > +int of_drm_get_panel_orientation(const struct device_node *np,
> > > +  int *orientation);
> > >  #else
> > >  static inline struct drm_panel *of_drm_find_panel(const struct 
> > > device_node *np)
> > >  {
> > >   return ERR_PTR(-ENODEV);
> > >  }
> > > +int of_drm_get_panel_orientation(const struct device_node *np,
> > > +  int *orientation)
> > > +{
> > > + return -ENODEV;
> > > +}
> > >  #endif
> > >
> > >  #endif
> > > --
> > > 2.22.0.rc2.383.gf4fbbf30c2-goog


Re: [PATCH 1/5] drm/panel: Add helper for reading DT rotation

2019-06-14 Thread dbasehore .
On Wed, Jun 12, 2019 at 2:18 PM Sam Ravnborg  wrote:
>
> Hi Derek.
>
> On Mon, Jun 10, 2019 at 09:03:46PM -0700, Derek Basehore wrote:
> > This adds a helper function for reading the rotation (panel
> > orientation) from the device tree.
> >
> > Signed-off-by: Derek Basehore 
> > ---
> >  drivers/gpu/drm/drm_panel.c | 41 +
> >  include/drm/drm_panel.h |  7 +++
> >  2 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> > index dbd5b873e8f2..3b689ce4a51a 100644
> > --- a/drivers/gpu/drm/drm_panel.c
> > +++ b/drivers/gpu/drm/drm_panel.c
> > @@ -172,6 +172,47 @@ struct drm_panel *of_drm_find_panel(const struct 
> > device_node *np)
> >   return ERR_PTR(-EPROBE_DEFER);
> >  }
> >  EXPORT_SYMBOL(of_drm_find_panel);
> > +
> > +/**
> > + * of_drm_get_panel_orientation - look up the rotation of the panel using a
> > + * device tree node
> > + * @np: device tree node of the panel
> > + * @orientation: orientation enum to be filled in
> The comment says "enum" but the type used is an int.
> Why not use enum drm_panel_orientation?
>

The binding is just an int value, but I can change it to the enum.

> > + *
> > + * Looks up the rotation of a panel in the device tree. The rotation in the
> > + * device tree is counter clockwise.
> > + *
> > + * Return: 0 when a valid rotation value (0, 90, 180, or 270) is read or 
> > the
> > + * rotation property doesn't exist. -EERROR otherwise.
> > + */
> Initially I read -EEROOR as a specific error code.
> But I gues the semantic is to say that a negative error code is returned
> if something was wrong.
> As we do not use the "-EERROR" syntax anywhere else in drm, please
> reword like we do in other places.
>
>
> Also - it is worth to mention that the rotation returned is
> DRM_MODE_PANEL_ORIENTATION_UNKNOWN if the property is not specified.
> I wonder if this is correct, as no property could also been
> interpretated as DRM_MODE_PANEL_ORIENTATION_NORMAL.
> And in most cases the roation property is optional, so one could
> assume that no property equals 0 degree.
>
>
> Sam
>
> > +int of_drm_get_panel_orientation(const struct device_node *np, int 
> > *orientation)
> > +{
> > + int rotation, ret;
> > +
> > + ret = of_property_read_u32(np, "rotation", &rotation);
> > + if (ret == -EINVAL) {
> > + /* Don't return an error if there's no rotation property. */
> > + *orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> > + return 0;
> > + }
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > + if (rotation == 0)
> > + *orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> > + else if (rotation == 90)
> > + *orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
> > + else if (rotation == 180)
> > + *orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
> > + else if (rotation == 270)
> > + *orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
> > + else
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(of_drm_get_panel_orientation);
> >  #endif
> >
> >  MODULE_AUTHOR("Thierry Reding ");
> > diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> > index 8c738c0e6e9f..13631b2efbaa 100644
> > --- a/include/drm/drm_panel.h
> > +++ b/include/drm/drm_panel.h
> > @@ -197,11 +197,18 @@ int drm_panel_detach(struct drm_panel *panel);
> >
> >  #if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL)
> >  struct drm_panel *of_drm_find_panel(const struct device_node *np);
> > +int of_drm_get_panel_orientation(const struct device_node *np,
> > +  int *orientation);
> >  #else
> >  static inline struct drm_panel *of_drm_find_panel(const struct device_node 
> > *np)
> >  {
> >   return ERR_PTR(-ENODEV);
> >  }
> > +int of_drm_get_panel_orientation(const struct device_node *np,
> > +  int *orientation)
> > +{
> > + return -ENODEV;
> > +}
> >  #endif
> >
> >  #endif
> > --
> > 2.22.0.rc2.383.gf4fbbf30c2-goog


Re: [PATCH] vc4: no need to check return value of debugfs_create functions

2019-06-14 Thread Eric Anholt
Greg Kroah-Hartman  writes:

> When calling debugfs functions, there is no need to ever check the
> return value.  The function can work or not, but the code logic should
> never do something different based on this.

Applied to drm-misc-next.  Thanks!


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

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

2019-06-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #42 from Richard Thier  ---
(In reply to Marek Olšák from comment #40)
> I'm afraid nobody remembers anymore how HyperZ works on r300. I can answer
> basic questions if you have any.

Hi!

Currently I have added this to radeon_drm_winsys.c:

385 if (ws->gen == DRV_R300) {
386 if (!radeon_get_drm_value(ws->fd, RADEON_INFO_NUM_GB_PIPES,
387   "GB pipe count",
388   &ws->info.r300_num_gb_pipes))
389 return false;
390 +   // FIXME: only works for my own setup (prenex):
391 +   ws->info.r300_num_gb_pipes=1;

Now I have no problems so far. It can be that HyperZ code is just good as-is,
but for some resoun the radeon_get_drm_value returns a bad gb_pipes number.

Currently testing with this a bit more throughly before moving further, but
everything seems to work so far, just this is not a proper fix.

Some questions I can have:

1.) Is there any way to ensure how many pipes a card has? One pipeline seems to
be really few for a GPU, but this is a mobile integrated card.

2.) Can the other indicated pipes be existing on my card but turned off for
some reason?

3.) radeon_get_drm_value - is this in the kernel source tree? I will have a
look later on the code behind it.

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

Re: [PATCH v4 01/18] kunit: test: add KUnit test runner core

2019-06-14 Thread Brendan Higgins
On Fri, May 17, 2019 at 11:53 AM Stephen Boyd  wrote:
>
> Quoting Brendan Higgins (2019-05-14 15:16:54)
> > diff --git a/include/kunit/test.h b/include/kunit/test.h
> > new file mode 100644
> > index 0..e682ea0e1f9a5
> > --- /dev/null
> > +++ b/include/kunit/test.h
> > @@ -0,0 +1,162 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Base unit test (KUnit) API.
> > + *
> > + * Copyright (C) 2019, Google LLC.
> > + * Author: Brendan Higgins 
> > + */
> > +
> > +#ifndef _KUNIT_TEST_H
> > +#define _KUNIT_TEST_H
> > +
> > +#include 
> > +#include 
>
> Is this include used here?

Err, it is used in the very next commit in the sequence. Sorry, I will
add it in the commit that actually uses it in the next revision.

> > +
> > +struct kunit;
> > +
> > +/**
> > + * struct kunit_case - represents an individual test case.
> > + * @run_case: the function representing the actual test case.
> > + * @name: the name of the test case.
> > + *
> > + * A test case is a function with the signature, ``void (*)(struct kunit 
> > *)``
> > + * that makes expectations (see KUNIT_EXPECT_TRUE()) about code under 
> > test. Each
> > + * test case is associated with a &struct kunit_module and will be run 
> > after the
> > + * module's init function and followed by the module's exit function.
> > + *
> > + * A test case should be static and should only be created with the 
> > KUNIT_CASE()
> > + * macro; additionally, every array of test cases should be terminated 
> > with an
> > + * empty test case.
> > + *
> > + * Example:
> > + *
> > + * .. code-block:: c
> > + *
> > + * void add_test_basic(struct kunit *test)
> > + * {
> > + * KUNIT_EXPECT_EQ(test, 1, add(1, 0));
> > + * KUNIT_EXPECT_EQ(test, 2, add(1, 1));
> > + * KUNIT_EXPECT_EQ(test, 0, add(-1, 1));
> > + * KUNIT_EXPECT_EQ(test, INT_MAX, add(0, INT_MAX));
> > + * KUNIT_EXPECT_EQ(test, -1, add(INT_MAX, INT_MIN));
> > + * }
> > + *
> > + * static struct kunit_case example_test_cases[] = {
> > + * KUNIT_CASE(add_test_basic),
> > + * {},
>
> Nitpick: Please drop the comma on the sentinel so nobody gets ideas to
> add another entry after it.

Good idea. Will fix here and elsewhere.

> > + * };
> > + *
> > + */
> > +struct kunit_case {
> > +   void (*run_case)(struct kunit *test);
> > +   const char name[256];
>
> Maybe 256 can be a #define KUNIT_NAME_MAX_LEN? Or it could just be a
> const char pointer to a literal pool? Are unit tests making up names at
> runtime?

Yeah, sorry, I forgot why I did it this way in the first place. Will
fix in next revision.

> > +
> > +   /* private: internal use only. */
> > +   bool success;
> > +};
> > +
> > +/**
> > + * KUNIT_CASE - A helper for creating a &struct kunit_case
> > + * @test_name: a reference to a test case function.
> > + *
> > + * Takes a symbol for a function representing a test case and creates a
> > + * &struct kunit_case object from it. See the documentation for
> > + * &struct kunit_case for an example on how to use it.
> > + */
> > +#define KUNIT_CASE(test_name) { .run_case = test_name, .name = #test_name }
> > +
> > +/**
> > + * struct kunit_module - describes a related collection of &struct 
> > kunit_case s.
> > + * @name: the name of the test. Purely informational.
> > + * @init: called before every test case.
> > + * @exit: called after every test case.
> > + * @test_cases: a null terminated array of test cases.
> > + *
> > + * A kunit_module is a collection of related &struct kunit_case s, such 
> > that
> > + * @init is called before every test case and @exit is called after every 
> > test
> > + * case, similar to the notion of a *test fixture* or a *test class* in 
> > other
> > + * unit testing frameworks like JUnit or Googletest.
> > + *
> > + * Every &struct kunit_case must be associated with a kunit_module for 
> > KUnit to
> > + * run it.
> > + */
> > +struct kunit_module {
> > +   const char name[256];
> > +   int (*init)(struct kunit *test);
> > +   void (*exit)(struct kunit *test);
> > +   struct kunit_case *test_cases;
>
> Can this variable be const? Or we expect test modules to adjust test_cases 
> after
> the fact?

I understand why it would be nice to do it that way, but we store the
failed result on test cases; I don't think it really makes sense to
have another parallel data structure just for the results on each test
case.

> > +};
> > +
> > +/**
> > + * struct kunit - represents a running instance of a test.
> > + * @priv: for user to store arbitrary data. Commonly used to pass data 
> > created
> > + * in the init function (see &struct kunit_module).
> > + *
> > + * Used to store information about the current context under which the 
> > test is
> > + * running. Most of this data is private and should only be accessed 
> > indirectly
> > + * via public functions; the one exception is @priv which can be used by 
> > the
> > + * test writer to s

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

2019-06-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #41 from Dieter Nützel  ---
(In reply to Marek Olšák from comment #40)
> I'm afraid nobody remembers anymore how HyperZ works on r300. I can answer
> basic questions if you have any.

Hello Marek!

Thanks for your offer, I know you were around...

I've found some hints for Richard under #note_14
Your Mesa git commit #12dcbd5954676ee32604d82cacbf9a4259967e13
r300g: enable Hyper-Z by default on r500

-- 
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 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

2019-06-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #40 from Marek Olšák  ---
I'm afraid nobody remembers anymore how HyperZ works on r300. I can answer
basic questions if you have any.

-- 
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 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

2019-06-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #39 from Dieter Nützel  ---
Oh and have a look, here:

Feature Matrix for Free Radeon Drivers
https://www.x.org/wiki/RadeonFeature/

r300 have some points open...;-)
https://www.x.org/wiki/RadeonFeature/#note_14

-- 
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 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

2019-06-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110897

Dieter Nützel  changed:

   What|Removed |Added

 CC||mar...@gmail.com,
   ||mic...@daenzer.net

--- Comment #38 from Dieter Nützel  ---
(In reply to Richard Thier from comment #37)
> (In reply to Dieter Nützel from comment #35)
> > Hello Richard,
> > 
> > very NICE progress!
> > 
> > Maybe you can run 'glmark2' with/without HyperZ.
> 
> Good idea.
> 
> Can you test if HyperZ works for you without any changes?

Sorry,

I'haven't any system for r300 (PCI/AGP) handy.
Latest here HD 4650, RV730 AGP (1 GB !), r600 (see older bug reports...;-)
But not booted for nearly 2 years...
Maybe I have an older r300 one (yep, 9550), but I have to dig in the basement
for it, if you need.

> The progress I
> made basically only works on my machine but above cosiekvfj seems to have no
> issues despite having the same card.

You made GREAT progress!

We have to ping Michel Dänzer and Marek Olšák for your open questions.
(see CC list)

> Actually if the gb_pipes number is wrong then the error is not even in the
> HyperZ code, but in the code that returns the wrong value from drm - that
> HyperZ code is just using.
> 
> Oh and keep in mind that I have no HiZ RAM! So if I measure speed gains
> others might measure a higher gain if they have HiZ RAM too as I think this
> way I have no hierarchical Z-buffer at all - when bigger tiles store min or
> max z values of theirs and first they are compared not pixels - but I have
> this compressed Z-buffer or zmask_ram - latter which is a lossless
> compression of the zbuffer. I read that they use tricks like storing the
> one-two triangles directions basically for whole tiles to save some bandwith
> and/or indicate if a tile is compressed or not at all.
> 
> This latter seems to help memory bandwith in case the triangles are bigger
> than the tiles (typically: walls in a game maybe?).

-- 
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 01/59] drm/todo: Improve drm_gem_object funcs todo

2019-06-14 Thread Eric Anholt
Daniel Vetter  writes:

> We're kinda going in the wrong direction. Spotted while typing better
> gem/prime docs.
>
> Cc: Thomas Zimmermann 
> Cc: Gerd Hoffmann 
> Cc: Rob Herring 
> Cc: Noralf Trønnes 
> Signed-off-by: Daniel Vetter 

That's a big series, but a great cleanup.  I took a look at a lot of it.
Patch 1-2, 4-10, 41-47, 49-50, and all the gem_prime_import/export drop
patches are:

Reviewed-by: Eric Anholt 

I don't currently have a plan for reading the shuffle in patch 3.


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

[PATCH 2/2] drm/rockchip: Base adjustments of the mode based on prev adjustments

2019-06-14 Thread Douglas Anderson
In vop_crtc_mode_fixup() we fixup the mode to show what we actually
will be able to achieve.  However we should base our adjustments on
any previous adjustments that were made.

As an example, the dw_hdmi driver may wish to make some small
adjustments to clock rates in its atomic_check() function.  If it
does, it will update the adjusted_mode.  We shouldn't throw away those
adjustments.

NOTE: the version of the dw_hdmi driver upstream doesn't _actually_
make such adjustments, but downstream in Chrome OS it does.  It is
plausible that one day we'll figure out how to cleanly make that
happen in an upstream-friendly way, so we should prepare by using the
right mode.

Signed-off-by: Douglas Anderson 
---

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

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index d124f34ab9fc..09a790c2f3a1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1006,8 +1006,8 @@ static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
struct vop *vop = to_vop(crtc);
 
adjusted_mode->clock =
-   DIV_ROUND_UP(clk_round_rate(vop->dclk, mode->clock * 1000),
-1000);
+   DIV_ROUND_UP(clk_round_rate(vop->dclk,
+   adjusted_mode->clock * 1000), 1000);
 
return true;
 }
-- 
2.22.0.410.gd8fdbe21b5-goog

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

[PATCH 1/2] drm/rockchip: Properly adjust to a true clock in adjusted_mode

2019-06-14 Thread Douglas Anderson
When fixing up the clock in vop_crtc_mode_fixup() we're not doing it
quite correctly.  Specifically if we've got the true clock 26667 Hz,
we'll perform this calculation:
   26667 / 1000 => 26

Later when we try to set the clock we'll do clk_set_rate(26 *
1000).  The common clock framework won't actually pick the proper clock
in this case since it always wants clocks <= the specified one.

Let's solve this by using DIV_ROUND_UP.

Fixes: b59b8de31497 ("drm/rockchip: return a true clock rate to adjusted_mode")
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Reviewed-by: Yakir Yang 
---
Back in 2016 Mark Yao said he applied this to his drm fixes [1], but it's
2019 and it's still missing so I'm posting again.

[1] https://patchwork.freedesktop.org/patch/103872/

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index e4580d8f21e1..d124f34ab9fc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1006,7 +1006,8 @@ static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
struct vop *vop = to_vop(crtc);
 
adjusted_mode->clock =
-   clk_round_rate(vop->dclk, mode->clock * 1000) / 1000;
+   DIV_ROUND_UP(clk_round_rate(vop->dclk, mode->clock * 1000),
+1000);
 
return true;
 }
-- 
2.22.0.410.gd8fdbe21b5-goog

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

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

2019-06-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #37 from Richard Thier  ---
(In reply to Dieter Nützel from comment #35)
> Hello Richard,
> 
> very NICE progress!
> 
> Maybe you can run 'glmark2' with/without HyperZ.

Good idea.

Can you test if HyperZ works for you without any changes? The progress I made
basically only works on my machine but above cosiekvfj seems to have no issues
despite having the same card.

Actually if the gb_pipes number is wrong then the error is not even in the
HyperZ code, but in the code that returns the wrong value from drm - that
HyperZ code is just using.

Oh and keep in mind that I have no HiZ RAM! So if I measure speed gains others
might measure a higher gain if they have HiZ RAM too as I think this way I have
no hierarchical Z-buffer at all - when bigger tiles store min or max z values
of theirs and first they are compared not pixels - but I have this compressed
Z-buffer or zmask_ram - latter which is a lossless compression of the zbuffer.
I read that they use tricks like storing the one-two triangles directions
basically for whole tiles to save some bandwith and/or indicate if a tile is
compressed or not at all.

This latter seems to help memory bandwith in case the triangles are bigger than
the tiles (typically: walls in a game maybe?).

-- 
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: [RESEND PATCH v2 1/2] drm/dp/mst: Reprobe EDID for MST ports on resume

2019-06-14 Thread Lyude Paul
uh, Sasha not sure if you're a bot or not but this patch isn't even upstream

On Fri, 2019-06-14 at 21:56 +, Sasha Levin wrote:
> Hi,
> 
> [This is an automated email]
> 
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
> 
> The bot has tested the following trees: v5.1.9, v4.19.50, v4.14.125,
> v4.9.181, v4.4.181.
> 
> v5.1.9: Build failed! Errors:
> drivers/gpu/drm/drm_dp_mst_topology.c:2672:9: error: implicit
> declaration of function ‘drm_dp_get_validated_port_ref’; did you mean
> ‘drm_mode_validate_driver’? [-Werror=implicit-function-declaration]
> drivers/gpu/drm/drm_dp_mst_topology.c:2676:9: error: implicit
> declaration of function ‘drm_dp_get_validated_mstb_ref’; did you mean
> ‘drm_mode_validate_size’? [-Werror=implicit-function-declaration]
> drivers/gpu/drm/drm_dp_mst_topology.c:2684:3: error: implicit
> declaration of function ‘drm_dp_put_mst_branch_device’; did you mean
> ‘drm_dp_get_mst_branch_device’? [-Werror=implicit-function-declaration]
> drivers/gpu/drm/drm_dp_mst_topology.c:2715:2: error: implicit
> declaration of function ‘drm_dp_put_port’; did you mean ‘drm_dp_get_port’?
> [-Werror=implicit-function-declaration]
> 
> v4.19.50: Build OK!
> v4.14.125: Build OK!
> v4.9.181: Build OK!
> v4.4.181: Build OK!
> 
> How should we proceed with this patch?
> 
> --
> Thanks,
> Sasha
-- 
Cheers,
Lyude Paul

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

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

2019-06-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #36 from Richard Thier  ---
Okay it seems pipes=1 is working on my machine.

diff --git a/src/gallium/drivers/r300/r300_texture_desc.c
b/src/gallium/drivers/r300/r300_texture_desc.c
index 77d272bfb6b..029b28570d7 100644
--- a/src/gallium/drivers/r300/r300_texture_desc.c
+++ b/src/gallium/drivers/r300/r300_texture_desc.c
@@ -358,6 +358,9 @@ static void r300_setup_hyperz_properties(struct r300_screen
*screen,
 pipes = screen->info.r300_num_z_pipes;
 } else {
 pipes = screen->info.r300_num_gb_pipes;
+   /* FIXME: Quickfix only for Mobility Radeon Xpress 200M in asus
laptop! */
+pipes = 2; // Half the screen is bad for me
+pipes = 1; // Whole screen is ok for me
 }

 for (i = 0; i <= tex->b.b.last_level; i++) {

I do not even dare uploading this patch as it likely only works on my specific
machine! The know-how seems to be worthy of knowing though so in case anyone
see something like this, they can try something similar until there is a proper
fix.

317 /* The tile size of 1 DWORD in ZMASK RAM is:
318  *
319  * GPUPipes4x4 mode   8x8 mode
320  * --
321  * R580   4P/1Z32x32  64x64
322  * RV570  3P/1Z48x16  96x32
323  * RV530  1P/2Z32x16  64x32
324  *1P/1Z16x16  32x32
325  */
326 static unsigned zmask_blocks_x_per_dw[4] = {4, 8, 12, 8};
327 static unsigned zmask_blocks_y_per_dw[4] = {4, 4,  4, 8};

I should have thought that pipes=1 is for me. As you can see here, there are
hardcoded values for X and Y block counts. Originally drm reports pipes=3 for
my card so I end up using the third column in this table: 12*4 blocks.

Now remembering I had to half both of them earlier using the hacky patch (6*2)
it was sure that "pipes=2" would not work still, because 4*8 = 32 is still much
more than 6*2=12 I provided. Of course 4*4=16 so now I see my earlier hack was
a bit miscalculated.

Also now I see exactly why 1/3 of the screen was only "working": because 12/4 =
3 and 4/4=1. You can clearly see this from the table!!! Wow!

I see that "r300_num_gb_pipes" is used at some of the other places:

src/gallium/drivers/r300/r300_query.c
src/gallium/drivers/r300/r300_emit.c (also for some queries)
src/gallium/drivers/r300/r300_context.c (only fprintf-ing for debugging)
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c (this where the drm query is)

I do not really know what kind of "queries" are these, but I might go and
change code so that winsys returns gb_pipes=1 itself without hacks at other
places and see if there are other glitches (a bit prolonged testing).

Who knows, maybe things actually get less glitchy if this query stuff is really
used and the value was bad before!

Then if I see that I really only have one pipeline, then maybe I should look at
the other side of this drm call to see why it returns this value and not else.

PS.: One other thing that I do not know is if pipes can exist maybe but can be
turned off or something? But I really have no idea about that.

PS.: I also grow to understand the logic why the smaller values here actually
make more to be properly rendered on screen! Because if there are two or three
pipes for example, you clear things similarly to this pattern:

01012323 etc (I saw them in docs or source comments). So if there would be
two pipes, you can z-delete two blocks at the same time etc. it is only simple
maths to see the smaller values are better here then.

-- 
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: [RESEND PATCH v2 1/2] drm/dp/mst: Reprobe EDID for MST ports on resume

2019-06-14 Thread Sasha Levin
Hi,

[This is an automated email]

This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all

The bot has tested the following trees: v5.1.9, v4.19.50, v4.14.125, v4.9.181, 
v4.4.181.

v5.1.9: Build failed! Errors:
drivers/gpu/drm/drm_dp_mst_topology.c:2672:9: error: implicit declaration 
of function ‘drm_dp_get_validated_port_ref’; did you mean 
‘drm_mode_validate_driver’? [-Werror=implicit-function-declaration]
drivers/gpu/drm/drm_dp_mst_topology.c:2676:9: error: implicit declaration 
of function ‘drm_dp_get_validated_mstb_ref’; did you mean 
‘drm_mode_validate_size’? [-Werror=implicit-function-declaration]
drivers/gpu/drm/drm_dp_mst_topology.c:2684:3: error: implicit declaration 
of function ‘drm_dp_put_mst_branch_device’; did you mean 
‘drm_dp_get_mst_branch_device’? [-Werror=implicit-function-declaration]
drivers/gpu/drm/drm_dp_mst_topology.c:2715:2: error: implicit declaration 
of function ‘drm_dp_put_port’; did you mean ‘drm_dp_get_port’? 
[-Werror=implicit-function-declaration]

v4.19.50: Build OK!
v4.14.125: Build OK!
v4.9.181: Build OK!
v4.4.181: Build OK!

How should we proceed with this patch?

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

Re: [PATCH 56/59] drm/todo: Update backlight todo

2019-06-14 Thread Sam Ravnborg
On Fri, Jun 14, 2019 at 10:36:12PM +0200, Daniel Vetter wrote:
> Basic helpers have been extracted, now there's a pile more todo still
> across the entire tree.
> 
> Signed-off-by: Daniel Vetter 
Acked-by: Sam Ravnborg 

Thanks for taking care of this.

I have considered enhancing drm_panel so if properly configured
then backligt enable/disable are done by the core.
Will land some patches one day, lets take any discussion based on
that.

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

[Bug 110897] HyperZ is broken for r300 (bad z for some micro and macrotiles?)

2019-06-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110897

--- Comment #35 from Dieter Nützel  ---
Hello Richard,

very NICE progress!

Maybe you can run 'glmark2' with/without HyperZ.

-- 
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 12/59] drm/atmel: Drop drm_gem_prime_export/import

2019-06-14 Thread Sam Ravnborg
On Fri, Jun 14, 2019 at 10:35:28PM +0200, Daniel Vetter wrote:
> They're the default.
> 
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Boris Brezillon 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Ludovic Desroches 
> Cc: linux-arm-ker...@lists.infradead.org
Reviewed-by: Sam Ravnborg 

And noted "drm_gem_object_funcs" in my personal TODO

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 274fdf18cde8..2b794a50e7ab 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -843,8 +843,6 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
>   .gem_vm_ops = &drm_gem_cma_vm_ops,
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_import = drm_gem_prime_import,
> - .gem_prime_export = drm_gem_prime_export,
>   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
>   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
>   .gem_prime_vmap = drm_gem_cma_prime_vmap,
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/59] drm/prime: Actually remove DRIVER_PRIME everywhere

2019-06-14 Thread Sam Ravnborg
Hi Daniel.

Minor nitpick..

> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 65d599065709..4fd09a9ad67a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -3193,7 +3193,7 @@ static struct drm_driver driver = {
>* deal with them for Intel hardware.
>*/
>   .driver_features =
> - DRIVER_GEM | DRIVER_PRIME |
> + DRIVER_GEM | 
>   DRIVER_RENDER | DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_SYNCOBJ,
Adds a whitespace.

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

Re: [PATCH 16/59] drm/hisilicon: Drop drm_gem_prime_export/import

2019-06-14 Thread Sam Ravnborg
On Fri, Jun 14, 2019 at 10:35:32PM +0200, Daniel Vetter wrote:
> They're the default.
> 
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Sam Ravnborg 
> Cc: Daniel Vetter 
> Cc: Xinliang Liu 
> Cc: "Noralf Trønnes" 
> Cc: CK Hu 
> Cc: Thomas Zimmermann 

Trivial - you can add my:
Reviewed-by: Sam Ravnborg 

> ---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> index 73f2b53f32cc..6e95d3b167cc 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -126,8 +126,6 @@ static struct drm_driver kirin_drm_driver = {
>  
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export   = drm_gem_prime_export,
> - .gem_prime_import   = drm_gem_prime_import,
>   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
>   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
>   .gem_prime_vmap = drm_gem_cma_prime_vmap,
> -- 
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH] drm/panfrost: Add support for mapping BOs on GPU page faults

2019-06-14 Thread Rob Herring
On Wed, Jun 12, 2019 at 6:55 AM Tomeu Vizoso  wrote:
>
> On Mon, 10 Jun 2019 at 19:06, Rob Herring  wrote:
> >
> > The midgard/bifrost GPUs need to allocate GPU memory which is allocated
> > on GPU page faults and not pinned in memory. The vendor driver calls
> > this functionality GROW_ON_GPF.
> >
> > This implementation assumes that BOs allocated with the
> > PANFROST_BO_NOMAP flag are never mmapped or exported. Both of those may
> > actually work, but I'm unsure if there's some interaction there. It
> > would cause the whole object to be pinned in memory which would defeat
> > the point of this.
> >
> > Issues/questions/thoughts:
> >
> > What's the difference between i_mapping and f_mapping?
> >
> > What kind of clean-up on close is needed? Based on vgem faults, there
> > doesn't seem to be any refcounting. Assume userspace is responsible for
> > not freeing the BO while a page fault can occur?
>
> Aren't we taking a reference on all BOs that a job relates to and
> unreferencing them once the job is done? I would think that that's
> enough, or am I missing something?

No, I think we're fine.

> > What about evictions? Need to call mapping_set_unevictable()? Maybe we
> > want these pages to be swappable, but then we need some notification to
> > unmap them.
>
> I'm not sure there's much point in swapping out pages with lifetimes
> of a few milliseconds.

The lifetime is *forever* though. If we don't allow swapping, then the
heap is grow only until the FD is closed. IIRC, the maximum size is on
the order of 1GB. Seems like you'd want to shrink it with some
trigger.

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

Re: [v7 00/16] Add Plane Color Properties

2019-06-14 Thread Ezequiel Garcia
(+ Boris, + Sean)

On Fri, 2019-06-14 at 13:17 -0300, Ezequiel Garcia wrote:
> On Thu, 28 Mar 2019 at 16:50, Uma Shankar  wrote:
> > This is how a typical display color hardware pipeline looks like:
> >  +---+
> >  |RAM|
> >  |  +--++-++-+   |
> >  |  | FB 1 ||  FB 2   || FB N|   |
> >  |  +--++-++-+   |
> >  +---+
> >|  Plane Color Hardware Block |
> >  ++
> >  | +---v-+   +---v---+   +---v--+ |
> >  | | Plane A |   | Plane B   |   | Plane N  | |
> >  | | DeGamma |   | Degamma   |   | Degamma  | |
> >  | +---+-+   +---+---+   +---+--+ |
> >  | | |   ||
> >  | +---v-+   +---v---+   +---v--+ |
> >  | |Plane A  |   | Plane B   |   | Plane N  | |
> >  | |CSC/CTM  |   | CSC/CTM   |   | CSC/CTM  | |
> >  | +---+-+   ++--+   ++-+ |
> >  | |  |   |   |
> >  | +---v-+   +v--+   +v-+ |
> >  | | Plane A |   | Plane B   |   | Plane N  | |
> >  | | Gamma   |   | Gamma |   | Gamma| |
> >  | +---+-+   ++--+   ++-+ |
> >  | |  |   |   |
> >  ++
> > +--v--v---v---|
> > > >   ||
> > > >   Pipe Blender||
> > +++
> > >||
> > >+---v--+ |
> > >|  Pipe DeGamma| |
> > >|  | |
> > >+---+--+ |
> > >|Pipe Color  |
> > >+---v--+ Hardware|
> > >|  Pipe CSC/CTM| |
> > >|  | |
> > >+---+--+ |
> > >||
> > >+---v--+ |
> > >|  Pipe Gamma  | |
> > >|  | |
> > >+---+--+ |
> > >||
> > +-+
> >  |
> >  v
> >Pipe Output
> > 
> > This patch series adds properties for plane color features. It adds
> > properties for degamma used to linearize data, CSC used for gamut
> > conversion, and gamma used to again non-linearize data as per panel
> > supported color space. These can be utilize by user space to convert
> > planes from one format to another, one color space to another etc.
> > 
> > Usersapce can take smart blending decisions and utilize these hardware
> > supported plane color features to get accurate color profile. The same
> > can help in consistent color quality from source to panel taking
> > advantage of advanced color features in hardware.
> > 
> > These patches just add the property interfaces and enable helper
> > functions.
> > 
> > This series adds Intel Gen9 specific plane gamma feature. We can
> > build up and add other platform/hardware specific implementation
> > on top of this series
> > 
> > Note: This is just to get a design feedback whether these interfaces
> > look ok. Based on community feedback on interfaces, we will implement
> > IGT tests to validate plane color features. This is un-tested currently.
> > 
> > Userspace implementation using these properties have been done in drm
> > hwcomposer by "Alexandru-Cosmin Gheorghe alexandru-cosmin.gheor...@arm.com"
> > from ARM. A merge request has been opened by Alexandru for drm_hwcomposer,
> > implementing the property changes for the same. Please review that as well:
> > https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/merge_requests/25
> > 
> > v2: Dropped legacy gamma table for plane as suggested by Maarten. Added
> > Gen9/BDW plane gamma feature and rebase on tot.
> > 
> > v3: Added a new drm_color_lut_ext structure to accommodate 32 bit precision
> > entries, pointed to by Brian, Starkey for HDR usecases. Addressed Sean,Paul
> > comments and moved plane color properties to drm_plane instead of
> > mode_config. Added property documentation as suggested by Daniel, Vetter.
> > Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov.
> > 
> > v4: Rebase
> > 
> > v5: Added "Display Color Hardware Pipeline" flow to kernel
> > documentation as suggested by "Ville Syrjala" and "Brian Starkey".
> > Moved the property creation to drm_color_mgmt.c file to consolidate
> > all color operations at one place. Addressed Alexandru's review comments.
> > 
> > v6: Rebase. Added supp

Re: [PATCH v5] docs: power: convert docs to ReST and rename to *.rst

2019-06-14 Thread Bjorn Helgaas
On Fri, Jun 14, 2019 at 02:36:31PM -0600, Jonathan Corbet wrote:
> On Thu, 13 Jun 2019 07:10:36 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > Convert the PM documents to ReST, in order to allow them to
> > build with Sphinx.
> > 
> > The conversion is actually:
> >   - add blank lines and identation in order to identify paragraphs;
> >   - fix tables markups;
> >   - add some lists markups;
> >   - mark literal blocks;
> >   - adjust title markups.
> > 
> > At its new index.rst, let's add a :orphan: while this is not linked to
> > the main index.rst file, in order to avoid build warnings.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > Acked-by: Mark Brown 
> > Acked-by: Bjorn Helgaas 
> > Acked-by: Srivatsa S. Bhat (VMware) 
> 
> So I can't apply this one due to conflicts in include/linux/pci.h.  Bjorn,
> perhaps the easiest thing is for you to take this one through your tree?

OK, I applied this to pci/docs for v5.3.  I applied this entire patch,
but if you would prefer that I only apply the PCI-related parts, let
me know and I'll split those out.

Bjorn


Re: [PATCH 46/59] drm/panfrost: don't set gem_obj->resv for prime import anymore

2019-06-14 Thread Rob Herring
On Fri, Jun 14, 2019 at 2:37 PM Daniel Vetter  wrote:
>
> This is now done in drm_prime.c
>
> Signed-off-by: Daniel Vetter 
> Cc: Rob Herring 
> Cc: Tomeu Vizoso 
> ---
>  drivers/gpu/drm/panfrost/panfrost_gem.c | 2 --
>  1 file changed, 2 deletions(-)

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

Re: [PATCH 01/59] drm/todo: Improve drm_gem_object funcs todo

2019-06-14 Thread Rob Herring
On Fri, Jun 14, 2019 at 2:36 PM Daniel Vetter  wrote:
>
> We're kinda going in the wrong direction. Spotted while typing better
> gem/prime docs.
>
> Cc: Thomas Zimmermann 
> Cc: Gerd Hoffmann 
> Cc: Rob Herring 
> Cc: Noralf Trønnes 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/todo.rst | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index b4a76c2703e5..23583f0e3755 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -228,6 +228,10 @@ struct drm_gem_object_funcs
>  GEM objects can now have a function table instead of having the callbacks on 
> the
>  DRM driver struct. This is now the preferred way and drivers can be moved 
> over.
>
> +Unfortunately some of the recently added GEM helpers are going in the wrong
> +direction by adding OPS macros that use the old, deprecated hooks. See
> +DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS, and 
> DRM_GEM_VRAM_DRIVER_PRIME.

At least for DRM_GEM_SHMEM_DRIVER_OPS, it should just be a matter of
removing in the single user (cirrus) and deleting the macro.

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

[PATCH 58/59] drm/todo: Add new debugfs todo

2019-06-14 Thread Daniel Vetter
Greg is busy already, but maybe he won't do everything ...

Cc: Greg Kroah-Hartman 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/todo.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 9717540ee28f..026e55c517e1 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -375,6 +375,9 @@ There's a bunch of issues with it:
   this (together with the drm_minor->drm_device move) would allow us to remove
   debugfs_init.
 
+- Drop the return code and error checking from all debugfs functions. Greg KH 
is
+  working on this already.
+
 Contact: Daniel Vetter
 
 KMS cleanups
-- 
2.20.1

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

[PATCH 55/59] drm/todo: remove gem_prime_import/export todo

2019-06-14 Thread Daniel Vetter
I've done that.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/todo.rst | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 81fbb15c94c6..21a7b7800d3e 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -206,13 +206,6 @@ efficient.
 
 Contact: Daniel Vetter
 
-Defaults for .gem_prime_import and export
--
-
-Most drivers don't need to set drm_driver->gem_prime_import and
-->gem_prime_export now that drm_gem_prime_import() and drm_gem_prime_export()
-are the default.
-
 struct drm_gem_object_funcs
 ---
 
-- 
2.20.1

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

[PATCH 53/59] drm/amdgpu: Fill out gem_object->resv

2019-06-14 Thread Daniel Vetter
That way we can ditch our gem_prime_res_obj implementation. Since ttm
absolutely needs the right reservation object all the boilerplate is
already there and we just have to wire it up correctly.

Note that gem/prime doesn't care when we do this, as long as we do it
before the bo is registered and someone can call the handle2fd ioctl
on it.

Aside: ttm_buffer_object.ttm_resv could probably be ditched in favour
of always passing a non-NULL resv to ttm_bo_init(). At least for gem
drivers that would avoid having two of these, on in ttm_buffer_object
and the other in drm_gem_object, one just there for confusion.

Signed-off-by: Daniel Vetter 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: Daniel Vetter 
Cc: "Michel Dänzer" 
Cc: Chris Wilson 
Cc: Huang Rui 
Cc: Felix Kuehling 
Cc: Andrey Grodzovsky 
Cc: Evan Quan 
Cc: Sonny Jiang 
Cc: Amber Lin 
Cc: "Michał Mirosław" 
Cc: Junwei Zhang 
Cc: Thomas Zimmermann 
Cc: Samuel Li 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 17 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |  2 ++
 4 files changed, 3 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 4809d4a5d72a..02cd845e77b3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -267,20 +267,6 @@ static void amdgpu_dma_buf_map_detach(struct dma_buf 
*dma_buf,
drm_gem_map_detach(dma_buf, attach);
 }
 
-/**
- * amdgpu_gem_prime_res_obj - &drm_driver.gem_prime_res_obj implementation
- * @obj: GEM BO
- *
- * Returns:
- * The BO's reservation object.
- */
-struct reservation_object *amdgpu_gem_prime_res_obj(struct drm_gem_object *obj)
-{
-   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
-
-   return bo->tbo.resv;
-}
-
 /**
  * amdgpu_dma_buf_begin_cpu_access - &dma_buf_ops.begin_cpu_access 
implementation
  * @dma_buf: Shared DMA buffer
@@ -339,8 +325,7 @@ const struct dma_buf_ops amdgpu_dmabuf_ops = {
  * @gobj: GEM BO
  * @flags: Flags such as DRM_CLOEXEC and DRM_RDWR.
  *
- * The main work is done by the &drm_gem_prime_export helper, which in turn
- * uses &amdgpu_gem_prime_res_obj.
+ * The main work is done by the &drm_gem_prime_export helper.
  *
  * Returns:
  * Shared DMA buffer representing the GEM BO from the given device.
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
index 7f73a4f94204..5012e6ab58f1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
@@ -34,7 +34,6 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_gem_object 
*gobj,
int flags);
 struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf);
-struct reservation_object *amdgpu_gem_prime_res_obj(struct drm_gem_object *);
 void *amdgpu_gem_prime_vmap(struct drm_gem_object *obj);
 void amdgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
 int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8e1b269351e8..3233c5abf5b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1333,7 +1333,6 @@ static struct drm_driver kms_driver = {
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
-   .gem_prime_res_obj = amdgpu_gem_prime_res_obj,
.gem_prime_get_sg_table = amdgpu_gem_prime_get_sg_table,
.gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
.gem_prime_vmap = amdgpu_gem_prime_vmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 16f96f2e3671..7b251fd26bd5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -505,6 +505,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
if (unlikely(r != 0))
return r;
 
+   bo->gem_base.resv = bo->tbo.resv;
+
if (!amdgpu_gmc_vram_full_visible(&adev->gmc) &&
bo->tbo.mem.mem_type == TTM_PL_VRAM &&
bo->tbo.mem.start < adev->gmc.visible_vram_size >> PAGE_SHIFT)
-- 
2.20.1

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

[PATCH 48/59] drm/vgem: Ditch attach trickery in the fence ioctl

2019-06-14 Thread Daniel Vetter
It looks like this was done purely to get a consistent place to look
up the reservation object pointer. With the drm_prime.c helper code
now also setting gem_object->resv for imported objects we can just use
that pointer directly, instead of first ensuring a dma-buf exists.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vgem/vgem_fence.c | 22 +-
 1 file changed, 1 insertion(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
b/drivers/gpu/drm/vgem/vgem_fence.c
index 72d43d5ec5ab..08997fdd3ccb 100644
--- a/drivers/gpu/drm/vgem/vgem_fence.c
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -100,22 +100,6 @@ static struct dma_fence *vgem_fence_create(struct 
vgem_file *vfile,
return &fence->base;
 }
 
-static int attach_dmabuf(struct drm_device *dev,
-struct drm_gem_object *obj)
-{
-   struct dma_buf *dmabuf;
-
-   if (obj->dma_buf)
-   return 0;
-
-   dmabuf = dev->driver->gem_prime_export(obj, 0);
-   if (IS_ERR(dmabuf))
-   return PTR_ERR(dmabuf);
-
-   obj->dma_buf = dmabuf;
-   return 0;
-}
-
 /*
  * vgem_fence_attach_ioctl (DRM_IOCTL_VGEM_FENCE_ATTACH):
  *
@@ -157,10 +141,6 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
if (!obj)
return -ENOENT;
 
-   ret = attach_dmabuf(dev, obj);
-   if (ret)
-   goto err;
-
fence = vgem_fence_create(vfile, arg->flags);
if (!fence) {
ret = -ENOMEM;
@@ -168,7 +148,7 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
}
 
/* Check for a conflicting fence */
-   resv = obj->dma_buf->resv;
+   resv = obj->resv;
if (!reservation_object_test_signaled_rcu(resv,
  arg->flags & 
VGEM_FENCE_WRITE)) {
ret = -EBUSY;
-- 
2.20.1

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

[PATCH 45/59] drm/msm: Drop robj from msm_gem_new_impl

2019-06-14 Thread Daniel Vetter
Only user was the prime import, and drm_prime.c takes care of that
now.

Signed-off-by: Daniel Vetter 
Cc: Rob Clark 
Cc: Sean Paul 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
 drivers/gpu/drm/msm/msm_gem.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 35f55dd25994..404b6fea9e35 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -947,7 +947,6 @@ int msm_gem_new_handle(struct drm_device *dev, struct 
drm_file *file,
 
 static int msm_gem_new_impl(struct drm_device *dev,
uint32_t size, uint32_t flags,
-   struct reservation_object *resv,
struct drm_gem_object **obj,
bool struct_mutex_locked)
 {
@@ -974,9 +973,6 @@ static int msm_gem_new_impl(struct drm_device *dev,
msm_obj->flags = flags;
msm_obj->madv = MSM_MADV_WILLNEED;
 
-   if (resv)
-   msm_obj->base.resv = resv;
-
INIT_LIST_HEAD(&msm_obj->submit_entry);
INIT_LIST_HEAD(&msm_obj->vmas);
 
@@ -1018,7 +1014,7 @@ static struct drm_gem_object *_msm_gem_new(struct 
drm_device *dev,
if (size == 0)
return ERR_PTR(-EINVAL);
 
-   ret = msm_gem_new_impl(dev, size, flags, NULL, &obj, 
struct_mutex_locked);
+   ret = msm_gem_new_impl(dev, size, flags, &obj, struct_mutex_locked);
if (ret)
goto fail;
 
@@ -1095,7 +1091,7 @@ struct drm_gem_object *msm_gem_import(struct drm_device 
*dev,
 
size = PAGE_ALIGN(dmabuf->size);
 
-   ret = msm_gem_new_impl(dev, size, MSM_BO_WC, dmabuf->resv, &obj, false);
+   ret = msm_gem_new_impl(dev, size, MSM_BO_WC, &obj, false);
if (ret)
goto fail;
 
-- 
2.20.1

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

[PATCH 49/59] drm/msm: Use drm_gem_fb_prepare_fb

2019-06-14 Thread Daniel Vetter
msm has switched over to drm_fb->obj[] a while ago already, so we can
just use the helper.

Signed-off-by: Daniel Vetter 
Cc: Rob Clark 
Cc: Sean Paul 
Cc: Jeykumar Sankaran 
Cc: Jordan Crouse 
Cc: Bruce Wang 
Cc: Fritz Koenig 
Cc: Daniel Vetter 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 5 +
 drivers/gpu/drm/msm/msm_atomic.c  | 5 +
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index d831cedb55ec..b10855374a8d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -792,10 +792,7 @@ static int dpu_plane_prepare_fb(struct drm_plane *plane,
 *   we can use msm_atomic_prepare_fb() instead of doing the
 *   implicit fence and fb prepare by hand here.
 */
-   obj = msm_framebuffer_bo(new_state->fb, 0);
-   fence = reservation_object_get_excl_rcu(obj->resv);
-   if (fence)
-   drm_atomic_set_fence_for_plane(new_state, fence);
+   drm_gem_fb_prepare_fb(plane, new_state);
 
if (pstate->aspace) {
ret = msm_framebuffer_prepare(new_state->fb,
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 131c23a267ee..e501c6f8d67b 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -54,10 +54,7 @@ int msm_atomic_prepare_fb(struct drm_plane *plane,
if (!new_state->fb)
return 0;
 
-   obj = msm_framebuffer_bo(new_state->fb, 0);
-   fence = reservation_object_get_excl_rcu(obj->resv);
-
-   drm_atomic_set_fence_for_plane(new_state, fence);
+   drm_gem_fb_prepare_fb(plane, new_state);
 
return msm_framebuffer_prepare(new_state->fb, kms->aspace);
 }
-- 
2.20.1

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

[PATCH 50/59] drm/vc4: Use drm_gem_fb_prepare_fb

2019-06-14 Thread Daniel Vetter
vc4 has switched to using drm_fb->obj[], so we can just use the helper
unchanged.

Signed-off-by: Daniel Vetter 
Cc: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 441e06d45c89..f59f8c404d80 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -1132,10 +1132,7 @@ static int vc4_prepare_fb(struct drm_plane *plane,
if (!state->fb)
return 0;
 
-   bo = to_vc4_bo(&drm_fb_cma_get_gem_obj(state->fb, 0)->base);
-
-   fence = reservation_object_get_excl_rcu(bo->base.base.resv);
-   drm_atomic_set_fence_for_plane(state, fence);
+   drm_gem_fb_prepare_fb(plane, state);
 
if (plane->state->fb == state->fb)
return 0;
-- 
2.20.1

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

[PATCH 56/59] drm/todo: Update backlight todo

2019-06-14 Thread Daniel Vetter
Basic helpers have been extracted, now there's a pile more todo still
across the entire tree.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/todo.rst | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 21a7b7800d3e..c4e7c0672a14 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -422,6 +422,19 @@ fit the available time.
 
 Contact: Daniel Vetter
 
+Backlight Refactoring
+-
+
+Backlight drivers have a triple enable/disable state, which is a bit overkill.
+Plan to fix this:
+
+1. Roll out backlight_enable() and backlight_disable() helpers everywhere. This
+   has started already.
+2. In all, only look at one of the three status bits set by the above helpers.
+3. Remove the other two status bits.
+
+Contact: Daniel Vetter
+
 Driver Specific
 ===
 
@@ -431,20 +444,6 @@ tinydrm
 Tinydrm is the helper driver for really simple fb drivers. The goal is to make
 those drivers as simple as possible, so lots of room for refactoring:
 
-- backlight helpers, probably best to put them into a new drm_backlight.c.
-  This is because drivers/video is de-facto unmaintained. We could also
-  move drivers/video/backlight to drivers/gpu/backlight and take it all
-  over within drm-misc, but that's more work. Backlight helpers require a fair
-  bit of reworking and refactoring. A simple example is the enabling of a 
backlight.
-  Tinydrm has helpers for this. It would be good if other drivers can also use 
the
-  helper. However, there are various cases we need to consider i.e different
-  drivers seem to have different ways of enabling/disabling a backlight.
-  We also need to consider the backlight drivers (like gpio_backlight). The 
situation
-  is further complicated by the fact that the backlight is tied to fbdev
-  via fb_notifier_callback() which has complicated logic. For further details, 
refer
-  to the following discussion thread:
-  https://groups.google.com/forum/#!topic/outreachy-kernel/8rBe30lwtdA
-
 - spi helpers, probably best put into spi core/helper code. Thierry said
   the spi maintainer is fast&reactive, so shouldn't be a big issue.
 
-- 
2.20.1

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

[PATCH 43/59] drm/lima: Drop resv argument from lima_bo_create_struct

2019-06-14 Thread Daniel Vetter
It was only used for prime import, which is now handled by
drm_prime.c.

Signed-off-by: Daniel Vetter 
Cc: Qiang Yu 
Cc: l...@lists.freedesktop.org
---
 drivers/gpu/drm/lima/lima_gem.c   | 2 +-
 drivers/gpu/drm/lima/lima_gem_prime.c | 3 +--
 drivers/gpu/drm/lima/lima_object.c| 9 +++--
 drivers/gpu/drm/lima/lima_object.h| 3 +--
 4 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
index 477c0f73..fd1a024703d2 100644
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -24,7 +24,7 @@ int lima_gem_create_handle(struct drm_device *dev, struct 
drm_file *file,
struct lima_bo *bo;
struct lima_device *ldev = to_lima_dev(dev);
 
-   bo = lima_bo_create(ldev, size, flags, NULL, NULL);
+   bo = lima_bo_create(ldev, size, flags, NULL);
if (IS_ERR(bo))
return PTR_ERR(bo);
 
diff --git a/drivers/gpu/drm/lima/lima_gem_prime.c 
b/drivers/gpu/drm/lima/lima_gem_prime.c
index 9c6d9f1dba55..e3eb251e0a12 100644
--- a/drivers/gpu/drm/lima/lima_gem_prime.c
+++ b/drivers/gpu/drm/lima/lima_gem_prime.c
@@ -18,8 +18,7 @@ struct drm_gem_object *lima_gem_prime_import_sg_table(
struct lima_device *ldev = to_lima_dev(dev);
struct lima_bo *bo;
 
-   bo = lima_bo_create(ldev, attach->dmabuf->size, 0, sgt,
-   attach->dmabuf->resv);
+   bo = lima_bo_create(ldev, attach->dmabuf->size, 0, sgt);
if (IS_ERR(bo))
return ERR_CAST(bo);
 
diff --git a/drivers/gpu/drm/lima/lima_object.c 
b/drivers/gpu/drm/lima/lima_object.c
index 5c41f859a72f..87123b1d083c 100644
--- a/drivers/gpu/drm/lima/lima_object.c
+++ b/drivers/gpu/drm/lima/lima_object.c
@@ -33,8 +33,7 @@ void lima_bo_destroy(struct lima_bo *bo)
kfree(bo);
 }
 
-static struct lima_bo *lima_bo_create_struct(struct lima_device *dev, u32 
size, u32 flags,
-struct reservation_object *resv)
+static struct lima_bo *lima_bo_create_struct(struct lima_device *dev, u32 
size, u32 flags)
 {
struct lima_bo *bo;
int err;
@@ -47,7 +46,6 @@ static struct lima_bo *lima_bo_create_struct(struct 
lima_device *dev, u32 size,
 
mutex_init(&bo->lock);
INIT_LIST_HEAD(&bo->va);
-   bo->gem.resv = resv;
 
err = drm_gem_object_init(dev->ddev, &bo->gem, size);
if (err) {
@@ -59,14 +57,13 @@ static struct lima_bo *lima_bo_create_struct(struct 
lima_device *dev, u32 size,
 }
 
 struct lima_bo *lima_bo_create(struct lima_device *dev, u32 size,
-  u32 flags, struct sg_table *sgt,
-  struct reservation_object *resv)
+  u32 flags, struct sg_table *sgt)
 {
int i, err;
size_t npages;
struct lima_bo *bo, *ret;
 
-   bo = lima_bo_create_struct(dev, size, flags, resv);
+   bo = lima_bo_create_struct(dev, size, flags);
if (IS_ERR(bo))
return bo;
 
diff --git a/drivers/gpu/drm/lima/lima_object.h 
b/drivers/gpu/drm/lima/lima_object.h
index 6738724afb7b..31ca2d8dc0a1 100644
--- a/drivers/gpu/drm/lima/lima_object.h
+++ b/drivers/gpu/drm/lima/lima_object.h
@@ -27,8 +27,7 @@ to_lima_bo(struct drm_gem_object *obj)
 }
 
 struct lima_bo *lima_bo_create(struct lima_device *dev, u32 size,
-  u32 flags, struct sg_table *sgt,
-  struct reservation_object *resv);
+  u32 flags, struct sg_table *sgt);
 void lima_bo_destroy(struct lima_bo *bo);
 void *lima_bo_vmap(struct lima_bo *bo);
 void lima_bo_vunmap(struct lima_bo *bo);
-- 
2.20.1

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

[PATCH 52/59] drm/nouveau: Fill out gem_object->resv

2019-06-14 Thread Daniel Vetter
That way we can ditch our gem_prime_res_obj implementation. Since ttm
absolutely needs the right reservation object all the boilerplate is
already there and we just have to wire it up correctly.

Note that gem/prime doesn't care when we do this, as long as we do it
before the bo is registered and someone can call the handle2fd ioctl
on it.

Aside: ttm_buffer_object.ttm_resv could probably be ditched in favour
of always passing a non-NULL resv to ttm_bo_init(). At least for gem
drivers that would avoid having two of these, on in ttm_buffer_object
and the other in drm_gem_object, one just there for confusion.

Signed-off-by: Daniel Vetter 
Cc: Ben Skeggs 
Cc: nouv...@lists.freedesktop.org
---
 drivers/gpu/drm/nouveau/nouveau_bo.c| 2 ++
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 1 -
 drivers/gpu/drm/nouveau/nouveau_gem.h   | 1 -
 drivers/gpu/drm/nouveau/nouveau_prime.c | 7 ---
 4 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 34a998012bf6..6f1217b3e6b9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -299,6 +299,8 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
  type, &nvbo->placement,
  align >> PAGE_SHIFT, false, acc_size, sg,
  robj, nouveau_bo_del_ttm);
+   nvbo->gem.resv = nvbo->bo.resv;
+
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 4377b836265f..2c36319c158f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1131,7 +1131,6 @@ driver_stub = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_pin = nouveau_gem_prime_pin,
-   .gem_prime_res_obj = nouveau_gem_prime_res_obj,
.gem_prime_unpin = nouveau_gem_prime_unpin,
.gem_prime_get_sg_table = nouveau_gem_prime_get_sg_table,
.gem_prime_import_sg_table = nouveau_gem_prime_import_sg_table,
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.h 
b/drivers/gpu/drm/nouveau/nouveau_gem.h
index fe39998f65cc..9dea015387fd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.h
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.h
@@ -33,7 +33,6 @@ extern int nouveau_gem_ioctl_info(struct drm_device *, void *,
  struct drm_file *);
 
 extern int nouveau_gem_prime_pin(struct drm_gem_object *);
-struct reservation_object *nouveau_gem_prime_res_obj(struct drm_gem_object *);
 extern void nouveau_gem_prime_unpin(struct drm_gem_object *);
 extern struct sg_table *nouveau_gem_prime_get_sg_table(struct drm_gem_object 
*);
 extern struct drm_gem_object *nouveau_gem_prime_import_sg_table(
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c 
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index 1fefc93af1d7..ec50017692d4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -107,10 +107,3 @@ void nouveau_gem_prime_unpin(struct drm_gem_object *obj)
 
nouveau_bo_unpin(nvbo);
 }
-
-struct reservation_object *nouveau_gem_prime_res_obj(struct drm_gem_object 
*obj)
-{
-   struct nouveau_bo *nvbo = nouveau_gem_object(obj);
-
-   return nvbo->bo.resv;
-}
-- 
2.20.1

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

[PATCH 42/59] drm/etnaviv: Drop resv argument from etnaviv_gem_new_impl

2019-06-14 Thread Daniel Vetter
Only user was the prime import, and drm_prime.c takes care of that
now.

Signed-off-by: Daniel Vetter 
Cc: Lucas Stach 
Cc: Russell King 
Cc: Christian Gmeiner 
Cc: etna...@lists.freedesktop.org
---
 drivers/gpu/drm/etnaviv/etnaviv_gem.c   | 14 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.h   |  3 +--
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c |  1 -
 3 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index e8778ebb72e6..17ca602db60a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -565,8 +565,7 @@ void etnaviv_gem_obj_add(struct drm_device *dev, struct 
drm_gem_object *obj)
 }
 
 static int etnaviv_gem_new_impl(struct drm_device *dev, u32 size, u32 flags,
-   struct reservation_object *robj, const struct etnaviv_gem_ops *ops,
-   struct drm_gem_object **obj)
+   const struct etnaviv_gem_ops *ops, struct drm_gem_object **obj)
 {
struct etnaviv_gem_object *etnaviv_obj;
unsigned sz = sizeof(*etnaviv_obj);
@@ -594,8 +593,6 @@ static int etnaviv_gem_new_impl(struct drm_device *dev, u32 
size, u32 flags,
 
etnaviv_obj->flags = flags;
etnaviv_obj->ops = ops;
-   if (robj)
-   etnaviv_obj->base.resv = robj;
 
mutex_init(&etnaviv_obj->lock);
INIT_LIST_HEAD(&etnaviv_obj->vram_list);
@@ -614,7 +611,7 @@ int etnaviv_gem_new_handle(struct drm_device *dev, struct 
drm_file *file,
 
size = PAGE_ALIGN(size);
 
-   ret = etnaviv_gem_new_impl(dev, size, flags, NULL,
+   ret = etnaviv_gem_new_impl(dev, size, flags,
   &etnaviv_gem_shmem_ops, &obj);
if (ret)
goto fail;
@@ -646,13 +643,12 @@ int etnaviv_gem_new_handle(struct drm_device *dev, struct 
drm_file *file,
 }
 
 int etnaviv_gem_new_private(struct drm_device *dev, size_t size, u32 flags,
-   struct reservation_object *robj, const struct etnaviv_gem_ops *ops,
-   struct etnaviv_gem_object **res)
+   const struct etnaviv_gem_ops *ops, struct etnaviv_gem_object **res)
 {
struct drm_gem_object *obj;
int ret;
 
-   ret = etnaviv_gem_new_impl(dev, size, flags, robj, ops, &obj);
+   ret = etnaviv_gem_new_impl(dev, size, flags, ops, &obj);
if (ret)
return ret;
 
@@ -734,7 +730,7 @@ int etnaviv_gem_new_userptr(struct drm_device *dev, struct 
drm_file *file,
struct etnaviv_gem_object *etnaviv_obj;
int ret;
 
-   ret = etnaviv_gem_new_private(dev, size, ETNA_BO_CACHED, NULL,
+   ret = etnaviv_gem_new_private(dev, size, ETNA_BO_CACHED,
  &etnaviv_gem_userptr_ops, &etnaviv_obj);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
index 753c458497d0..fcd5d71b502f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
@@ -112,8 +112,7 @@ void etnaviv_submit_put(struct etnaviv_gem_submit * submit);
 int etnaviv_gem_wait_bo(struct etnaviv_gpu *gpu, struct drm_gem_object *obj,
struct timespec *timeout);
 int etnaviv_gem_new_private(struct drm_device *dev, size_t size, u32 flags,
-   struct reservation_object *robj, const struct etnaviv_gem_ops *ops,
-   struct etnaviv_gem_object **res);
+   const struct etnaviv_gem_ops *ops, struct etnaviv_gem_object **res);
 void etnaviv_gem_obj_add(struct drm_device *dev, struct drm_gem_object *obj);
 struct page **etnaviv_gem_get_pages(struct etnaviv_gem_object *obj);
 void etnaviv_gem_put_pages(struct etnaviv_gem_object *obj);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index 00e8b6a817e3..a05292e8ed6f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -109,7 +109,6 @@ struct drm_gem_object 
*etnaviv_gem_prime_import_sg_table(struct drm_device *dev,
int ret, npages;
 
ret = etnaviv_gem_new_private(dev, size, ETNA_BO_WC,
- attach->dmabuf->resv,
  &etnaviv_gem_prime_ops, &etnaviv_obj);
if (ret < 0)
return ERR_PTR(ret);
-- 
2.20.1

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

[PATCH 51/59] drm/radeon: Fill out gem_object->resv

2019-06-14 Thread Daniel Vetter
That way we can ditch our gem_prime_res_obj implementation. Since ttm
absolutely needs the right reservation object all the boilerplate is
already there and we just have to wire it up correctly.

Note that gem/prime doesn't care when we do this, as long as we do it
before the bo is registered and someone can call the handle2fd ioctl
on it.

Aside: ttm_buffer_object.ttm_resv could probably be ditched in favour
of always passing a non-NULL resv to ttm_bo_init(). At least for gem
drivers that would avoid having two of these, on in ttm_buffer_object
and the other in drm_gem_object, one just there for confusion.

Signed-off-by: Daniel Vetter 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: "David (ChunMing) Zhou" 
Cc: amd-...@lists.freedesktop.org
---
 drivers/gpu/drm/radeon/radeon_drv.c| 2 --
 drivers/gpu/drm/radeon/radeon_object.c | 1 +
 drivers/gpu/drm/radeon/radeon_prime.c  | 7 ---
 3 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 4403e76e1ae0..a4a78dfdef37 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -152,7 +152,6 @@ struct drm_gem_object 
*radeon_gem_prime_import_sg_table(struct drm_device *dev,
struct sg_table *sg);
 int radeon_gem_prime_pin(struct drm_gem_object *obj);
 void radeon_gem_prime_unpin(struct drm_gem_object *obj);
-struct reservation_object *radeon_gem_prime_res_obj(struct drm_gem_object *);
 void *radeon_gem_prime_vmap(struct drm_gem_object *obj);
 void radeon_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
 
@@ -566,7 +565,6 @@ static struct drm_driver kms_driver = {
.gem_prime_export = radeon_gem_prime_export,
.gem_prime_pin = radeon_gem_prime_pin,
.gem_prime_unpin = radeon_gem_prime_unpin,
-   .gem_prime_res_obj = radeon_gem_prime_res_obj,
.gem_prime_get_sg_table = radeon_gem_prime_get_sg_table,
.gem_prime_import_sg_table = radeon_gem_prime_import_sg_table,
.gem_prime_vmap = radeon_gem_prime_vmap,
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 21f73fc86f38..7a2bad843f8a 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -262,6 +262,7 @@ int radeon_bo_create(struct radeon_device *rdev,
r = ttm_bo_init(&rdev->mman.bdev, &bo->tbo, size, type,
&bo->placement, page_align, !kernel, acc_size,
sg, resv, &radeon_ttm_bo_destroy);
+   bo->gem_base.resv = bo->tbo.resv;
up_read(&rdev->pm.mclk_lock);
if (unlikely(r != 0)) {
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_prime.c 
b/drivers/gpu/drm/radeon/radeon_prime.c
index deaffce50a2e..8ce3e8045d42 100644
--- a/drivers/gpu/drm/radeon/radeon_prime.c
+++ b/drivers/gpu/drm/radeon/radeon_prime.c
@@ -117,13 +117,6 @@ void radeon_gem_prime_unpin(struct drm_gem_object *obj)
 }
 
 
-struct reservation_object *radeon_gem_prime_res_obj(struct drm_gem_object *obj)
-{
-   struct radeon_bo *bo = gem_to_radeon_bo(obj);
-
-   return bo->tbo.resv;
-}
-
 struct dma_buf *radeon_gem_prime_export(struct drm_gem_object *gobj,
int flags)
 {
-- 
2.20.1

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

[PATCH 44/59] drm/mediatek: Use drm_atomic_helper_wait_for_fences

2019-06-14 Thread Daniel Vetter
If we use the gem fb helper as the prepare_fb hook, plus the
drm_prime.c import helpers now automatically setting obj->resv, we can
use the shared helpers to wait for fences instead of rolling our own.
Note that this relies on mtk setting drm_fb->obj, which is already
done in mtk_drm_framebuffer_init().

Aside: Probably can use the default commit_tail with this again, but I
didn't check for that.

Signed-off-by: Daniel Vetter 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: Matthias Brugger 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c   | 12 +-
 drivers/gpu/drm/mediatek/mtk_drm_fb.c| 28 
 drivers/gpu/drm/mediatek/mtk_drm_fb.h|  1 -
 drivers/gpu/drm/mediatek/mtk_drm_plane.c |  2 ++
 4 files changed, 3 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index dd8dab562500..2d5caf532431 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -38,22 +38,12 @@ static void mtk_atomic_schedule(struct mtk_drm_private 
*private,
schedule_work(&private->commit.work);
 }
 
-static void mtk_atomic_wait_for_fences(struct drm_atomic_state *state)
-{
-   struct drm_plane *plane;
-   struct drm_plane_state *new_plane_state;
-   int i;
-
-   for_each_new_plane_in_state(state, plane, new_plane_state, i)
-   mtk_fb_wait(new_plane_state->fb);
-}
-
 static void mtk_atomic_complete(struct mtk_drm_private *private,
struct drm_atomic_state *state)
 {
struct drm_device *drm = private->drm;
 
-   mtk_atomic_wait_for_fences(state);
+   drm_atomic_helper_wait_for_fences(drm, state, false);
 
/*
 * Mediatek drm supports runtime PM, so plane registers cannot be
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.c 
b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
index 4c3ad7de2d3b..396ba497986d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_fb.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
@@ -49,34 +49,6 @@ static struct drm_framebuffer 
*mtk_drm_framebuffer_init(struct drm_device *dev,
return fb;
 }
 
-/*
- * Wait for any exclusive fence in fb's gem object's reservation object.
- *
- * Returns -ERESTARTSYS if interrupted, else 0.
- */
-int mtk_fb_wait(struct drm_framebuffer *fb)
-{
-   struct drm_gem_object *gem;
-   struct reservation_object *resv;
-   long ret;
-
-   if (!fb)
-   return 0;
-
-   gem = fb->obj[0];
-   if (!gem || !gem->dma_buf || !gem->dma_buf->resv)
-   return 0;
-
-   resv = gem->dma_buf->resv;
-   ret = reservation_object_wait_timeout_rcu(resv, false, true,
- MAX_SCHEDULE_TIMEOUT);
-   /* MAX_SCHEDULE_TIMEOUT on success, -ERESTARTSYS if interrupted */
-   if (WARN_ON(ret < 0))
-   return ret;
-
-   return 0;
-}
-
 struct drm_framebuffer *mtk_drm_mode_fb_create(struct drm_device *dev,
   struct drm_file *file,
   const struct drm_mode_fb_cmd2 
*cmd)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.h 
b/drivers/gpu/drm/mediatek/mtk_drm_fb.h
index 6b80c28e33cf..eb64d26001c6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_fb.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.h
@@ -6,7 +6,6 @@
 #ifndef MTK_DRM_FB_H
 #define MTK_DRM_FB_H
 
-int mtk_fb_wait(struct drm_framebuffer *fb);
 struct drm_framebuffer *mtk_drm_mode_fb_create(struct drm_device *dev,
   struct drm_file *file,
   const struct drm_mode_fb_cmd2 
*cmd);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index f2ef83aed6f9..42cc9823eaaa 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mtk_drm_crtc.h"
 #include "mtk_drm_ddp_comp.h"
@@ -146,6 +147,7 @@ static void mtk_plane_atomic_disable(struct drm_plane 
*plane,
 }
 
 static const struct drm_plane_helper_funcs mtk_plane_helper_funcs = {
+   .prepare_fb = drm_gem_fb_prepare_fb,
.atomic_check = mtk_plane_atomic_check,
.atomic_update = mtk_plane_atomic_update,
.atomic_disable = mtk_plane_atomic_disable,
-- 
2.20.1

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

[PATCH 54/59] drm/prime: Ditch gem_prime_res_obj hook

2019-06-14 Thread Daniel Vetter
Everyone is just using gem_object->resv now.

Signed-off-by: Daniel Vetter 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
---
 Documentation/gpu/todo.rst  |  9 -
 drivers/gpu/drm/drm_prime.c |  3 ---
 include/drm/drm_drv.h   | 12 
 3 files changed, 24 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 23583f0e3755..81fbb15c94c6 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -196,15 +196,6 @@ Might be good to also have some igt testcases for this.
 
 Contact: Daniel Vetter, Noralf Tronnes
 
-Remove the ->gem_prime_res_obj callback
-
-
-The ->gem_prime_res_obj callback can be removed from drivers by using the
-reservation_object in the drm_gem_object. It may also be possible to use the
-generic drm_gem_reservation_object_wait helper for waiting for a bo.
-
-Contact: Daniel Vetter
-
 idr_init_base()
 ---
 
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 58d595f4a4f5..65e611337254 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -832,9 +832,6 @@ struct dma_buf *drm_gem_prime_export(struct drm_gem_object 
*obj,
.resv = obj->resv,
};
 
-   if (dev->driver->gem_prime_res_obj)
-   exp_info.resv = dev->driver->gem_prime_res_obj(obj);
-
return drm_gem_dmabuf_export(dev, &exp_info);
 }
 EXPORT_SYMBOL(drm_gem_prime_export);
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index ec1c638927b0..b01a30c64075 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -618,18 +618,6 @@ struct drm_driver {
 */
struct sg_table *(*gem_prime_get_sg_table)(struct drm_gem_object *obj);
 
-   /**
-* @gem_prime_res_obj:
-*
-* Optional hook to look up the &reservation_object for an buffer when
-* exporting it.
-*
-* FIXME: This hook is deprecated. User of this hook should be replaced
-* by setting &drm_gem_object.resv instead.
-*/
-   struct reservation_object * (*gem_prime_res_obj)(
-   struct drm_gem_object *obj);
-
/**
 * @gem_prime_import_sg_table:
 *
-- 
2.20.1

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

[PATCH 47/59] drm/vc4: Don set gem_obj->resv in prime import anymore

2019-06-14 Thread Daniel Vetter
This is done in drm_prime.c now.

Signed-off-by: Daniel Vetter 
Cc: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_bo.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index b0f9eb6632a2..707bcd9927f3 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -793,8 +793,6 @@ vc4_prime_import_sg_table(struct drm_device *dev,
if (IS_ERR(obj))
return obj;
 
-   obj->resv = attach->dmabuf->resv;
-
return obj;
 }
 
-- 
2.20.1

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

[PATCH 59/59] drm/doc: Document kapi doc expectations

2019-06-14 Thread Daniel Vetter
We've had this already for anything new. With my drm_prime.c cleanup I
also think documentations for everything already existing is complete,
and we can bake this in as a requirements subsystem wide.

Signed-off-by: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: Jani Nikula 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
---
 Documentation/gpu/introduction.rst | 13 +
 Documentation/gpu/todo.rst | 13 -
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/Documentation/gpu/introduction.rst 
b/Documentation/gpu/introduction.rst
index fccbe375244d..a94ad6ad1f54 100644
--- a/Documentation/gpu/introduction.rst
+++ b/Documentation/gpu/introduction.rst
@@ -51,6 +51,19 @@ and "FIXME" where the interface could be cleaned up.
 
 Also read the :ref:`guidelines for the kernel documentation at large 
`.
 
+Documentation Requirements for kAPI
+---
+
+All kernel APIs exported to other modules must be documented, including their
+datastructures and at least a short introductory section explaining the overall
+concepts. Documentation should be put into the code itself as kerneldoc 
comments
+as much as reasonable. Do not blindly document everything, but document only
+what's relevant for driver authors: Internal functions of drm.ko and definitely
+static functions should not have formal kerneldoc comments. Use normal C
+comments if you feel like a comment is warranted. Similar for data structures,
+annotate anything entirely private with ``/* private: */`` comments as per the
+documentation guide.
+
 Getting Started
 ===
 
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 026e55c517e1..25878dd048fd 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -299,19 +299,6 @@ In the end no .c file should need to include ``drmP.h`` 
anymore.
 
 Contact: Daniel Vetter
 
-Add missing kerneldoc for exported functions
-
-
-The DRM reference documentation is still lacking kerneldoc in a few areas. The
-task would be to clean up interfaces like moving functions around between
-files to better group them and improving the interfaces like dropping return
-values for functions that never fail. Then write kerneldoc for all exported
-functions and an overview section and integrate it all into the drm book.
-
-See https://dri.freedesktop.org/docs/drm/ for what's there already.
-
-Contact: Daniel Vetter
-
 Make panic handling work
 
 
-- 
2.20.1

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

[PATCH 57/59] drm/todo: Update mmap todo

2019-06-14 Thread Daniel Vetter
Thanks to Noralf some good progress already.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/todo.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index c4e7c0672a14..9717540ee28f 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -162,7 +162,7 @@ Clean up mmap forwarding
 
 A lot of drivers forward gem mmap calls to dma-buf mmap for imported buffers.
 And also a lot of them forward dma-buf mmap to the gem mmap implementations.
-Would be great to refactor this all into a set of small common helpers.
+There's drm_gem_prime_mmap() for this now, but still needs to be rolled out.
 
 Contact: Daniel Vetter
 
-- 
2.20.1

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

[PATCH 41/59] drm/prime: automatically set gem_obj->resv on import

2019-06-14 Thread Daniel Vetter
It's really the only reasonable thing to do, and it won't hurt drivers
which don't (yet) use drm_gem_object->resv.

Signed-off-by: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_prime.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index d545e681cb41..58d595f4a4f5 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -896,6 +896,7 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct 
drm_device *dev,
}
 
obj->import_attach = attach;
+   obj->resv = dma_buf->resv;
 
return obj;
 
-- 
2.20.1

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

[PATCH 24/59] drm/pl111: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Eric Anholt 
---
 drivers/gpu/drm/pl111/pl111_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index dd4aaa380250..90fa99a7dfa9 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -238,9 +238,7 @@ static struct drm_driver pl111_drm_driver = {
.gem_vm_ops = &drm_gem_cma_vm_ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_import = drm_gem_prime_import,
.gem_prime_import_sg_table = pl111_gem_import_sg_table,
-   .gem_prime_export = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

[PATCH 39/59] drm/zte: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Shawn Guo 
---
 drivers/gpu/drm/zte/zx_drm_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index 060ad5266bc7..ef019cad7e81 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -44,8 +44,6 @@ static struct drm_driver zx_drm_driver = {
.dumb_create = drm_gem_cma_dumb_create,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = drm_gem_prime_export,
-   .gem_prime_import = drm_gem_prime_import,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

[PATCH 31/59] drm/tilcdc: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 92307959435a..b6b71e86e238 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -521,8 +521,6 @@ static struct drm_driver tilcdc_driver = {
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_import   = drm_gem_prime_import,
-   .gem_prime_export   = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

[PATCH 30/59] drm/stm: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Yannick Fertre 
Cc: Philippe Cornu 
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: Maxime Coquelin 
Cc: Alexandre Torgue 
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
---
 drivers/gpu/drm/stm/drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 4026c33ccc39..331f5e8d779b 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -67,8 +67,6 @@ static struct drm_driver drv_driver = {
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = &drm_gem_cma_vm_ops,
-   .gem_prime_export = drm_gem_prime_export,
-   .gem_prime_import = drm_gem_prime_import,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

[PATCH 36/59] drm/vgem: Drop drm_gem_prime_export

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 68c340cfde51..d5ab6e46c242 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -445,7 +445,6 @@ static struct drm_driver vgem_driver = {
.gem_prime_pin = vgem_prime_pin,
.gem_prime_unpin = vgem_prime_unpin,
.gem_prime_import = vgem_prime_import,
-   .gem_prime_export = drm_gem_prime_export,
.gem_prime_import_sg_table = vgem_prime_import_sg_table,
.gem_prime_get_sg_table = vgem_prime_get_sg_table,
.gem_prime_vmap = vgem_prime_vmap,
-- 
2.20.1

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

[PATCH 22/59] drm/mxsfb: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Marek Vasut 
Cc: Stefan Agner 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: NXP Linux Team 
Cc: linux-arm-ker...@lists.infradead.org
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index b5bcaf4036bd..6d6a0b3e2bb0 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -322,8 +322,6 @@ static struct drm_driver mxsfb_driver = {
.dumb_create= drm_gem_cma_dumb_create,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export   = drm_gem_prime_export,
-   .gem_prime_import   = drm_gem_prime_import,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

[PATCH 35/59] drm/radeon: Drop drm_gem_prime_import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/radeon/radeon_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 4a6acaa3f843..4403e76e1ae0 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -564,7 +564,6 @@ static struct drm_driver kms_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = radeon_gem_prime_export,
-   .gem_prime_import = drm_gem_prime_import,
.gem_prime_pin = radeon_gem_prime_pin,
.gem_prime_unpin = radeon_gem_prime_unpin,
.gem_prime_res_obj = radeon_gem_prime_res_obj,
-- 
2.20.1

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

[PATCH 27/59] drm/rockchip: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Sandy Huang 
Cc: "Heiko Stübner" 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 59091b6241ec..782979f1b55a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -219,8 +219,6 @@ static struct drm_driver rockchip_drm_driver = {
.dumb_create= rockchip_gem_dumb_create,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_import   = drm_gem_prime_import,
-   .gem_prime_export   = drm_gem_prime_export,
.gem_prime_get_sg_table = rockchip_gem_prime_get_sg_table,
.gem_prime_import_sg_table  = rockchip_gem_prime_import_sg_table,
.gem_prime_vmap = rockchip_gem_prime_vmap,
-- 
2.20.1

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

Re: [PATCH 2/2] arm: dts: add ARM Mali GPU node for Odroid XU3

2019-06-14 Thread Rob Herring
On Fri, Jun 14, 2019 at 2:31 PM Joseph Kogut  wrote:
>
> Add device tree node for mali gpu on Odroid XU3 SoCs.
>
> Signed-off-by: Joseph Kogut 
> ---
>  .../boot/dts/exynos5422-odroidxu3-common.dtsi  | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 93a48f2dda49..1f2ae19d01af 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -48,6 +48,24 @@
> cooling-levels = <0 130 170 230>;
> };
>
> +   gpu: gpu@1180 {
> +   compatible = "samsung,exynos-mali", "arm,mali-t628";
> +   reg = <0x1180 0x5000>;
> +   interrupts = <0 117 0>,
> +<0 219 0>,
> +<0 74  0>;
> +   interrupt-names = "gpu", "job", "mmu";

Please use the order defined in the binding doc.

> +   clocks = <&clock CLK_G3D>,
> +<&clock CLK_DOUT_ACLK_G3D>,
> +<&clock CLK_FOUT_VPLL>;

The binding doc says a single clock.

> +   mali-supply = <&buck4_reg>;
> +   operating-points = <

The binding doc says operating-points-v2.

> +   /* KHz  uV   */
> +   60  115
> +   177000  812500
> +   >;
> +   };
> +
> thermal-zones {
> cpu0_thermal: cpu0-thermal {
> thermal-sensors = <&tmu_cpu0 0>;
> --
> 2.22.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 29/59] drm/sti: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

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

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index d9f63c9f287b..faea4dcb21b1 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -152,8 +152,6 @@ static struct drm_driver sti_driver = {
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = drm_gem_prime_export,
-   .gem_prime_import = drm_gem_prime_import,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

[PATCH 32/59] drm/tve2000: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Linus Walleij 
---
 drivers/gpu/drm/tve200/tve200_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/tve200/tve200_drv.c 
b/drivers/gpu/drm/tve200/tve200_drv.c
index a1f614e21fcc..830a5af25ac4 100644
--- a/drivers/gpu/drm/tve200/tve200_drv.c
+++ b/drivers/gpu/drm/tve200/tve200_drv.c
@@ -152,8 +152,6 @@ static struct drm_driver tve200_drm_driver = {
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_import = drm_gem_prime_import,
-   .gem_prime_export = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

[PATCH 23/59] drm/nouveau: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Ben Skeggs 
Cc: nouv...@lists.freedesktop.org
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 8cb174f95448..4377b836265f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1130,8 +1130,6 @@ driver_stub = {
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = drm_gem_prime_export,
-   .gem_prime_import = drm_gem_prime_import,
.gem_prime_pin = nouveau_gem_prime_pin,
.gem_prime_res_obj = nouveau_gem_prime_res_obj,
.gem_prime_unpin = nouveau_gem_prime_unpin,
-- 
2.20.1

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

[PATCH 40/59] drm/vram-helper: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Thomas Zimmermann 
Cc: Gerd Hoffmann 
---
 include/drm/drm_gem_vram_helper.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/drm/drm_gem_vram_helper.h 
b/include/drm/drm_gem_vram_helper.h
index 9581ea0a4f7e..1a0ea18e7a74 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -142,8 +142,6 @@ int drm_gem_vram_driver_gem_prime_mmap(struct 
drm_gem_object *obj,
   struct vm_area_struct *vma);
 
 #define DRM_GEM_VRAM_DRIVER_PRIME \
-   .gem_prime_export = drm_gem_prime_export, \
-   .gem_prime_import = drm_gem_prime_import, \
.gem_prime_pin= drm_gem_vram_driver_gem_prime_pin, \
.gem_prime_unpin  = drm_gem_vram_driver_gem_prime_unpin, \
.gem_prime_vmap   = drm_gem_vram_driver_gem_prime_vmap, \
-- 
2.20.1

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

[PATCH 37/59] drm/virtio: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: David Airlie 
Cc: Gerd Hoffmann 
Cc: virtualizat...@lists.linux-foundation.org
---
 drivers/gpu/drm/virtio/virtgpu_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 0afdf51fdcfd..99bcd290f1fb 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -207,8 +207,6 @@ static struct drm_driver driver = {
 #endif
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = drm_gem_prime_export,
-   .gem_prime_import = drm_gem_prime_import,
.gem_prime_get_sg_table = virtgpu_gem_prime_get_sg_table,
.gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
.gem_prime_vmap = virtgpu_gem_prime_vmap,
-- 
2.20.1

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

[PATCH 38/59] drm/xen: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Oleksandr Andrushchenko 
Cc: xen-de...@lists.xenproject.org
---
 drivers/gpu/drm/xen/xen_drm_front.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index aeffec82a5ce..051822ee5b36 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -491,8 +491,6 @@ static struct drm_driver xen_drm_driver = {
.gem_free_object_unlocked  = xen_drm_drv_free_object_unlocked,
.prime_handle_to_fd= drm_gem_prime_handle_to_fd,
.prime_fd_to_handle= drm_gem_prime_fd_to_handle,
-   .gem_prime_import  = drm_gem_prime_import,
-   .gem_prime_export  = drm_gem_prime_export,
.gem_prime_import_sg_table = xen_drm_front_gem_import_sg_table,
.gem_prime_get_sg_table= xen_drm_front_gem_get_sg_table,
.gem_prime_vmap= xen_drm_front_gem_prime_vmap,
-- 
2.20.1

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

[PATCH 21/59] drm/msm: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Rob Clark 
Cc: Sean Paul 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
 drivers/gpu/drm/msm/msm_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 87f92d3906ab..da5a88413964 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1034,8 +1034,6 @@ static struct drm_driver msm_driver = {
.dumb_map_offset= msm_gem_dumb_map_offset,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export   = drm_gem_prime_export,
-   .gem_prime_import   = drm_gem_prime_import,
.gem_prime_pin  = msm_gem_prime_pin,
.gem_prime_unpin= msm_gem_prime_unpin,
.gem_prime_get_sg_table = msm_gem_prime_get_sg_table,
-- 
2.20.1

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

[PATCH 34/59] drm/vc3: Drop drm_gem_prime_import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index ed4fe7ed9e64..a295aa91d3c5 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -201,7 +201,6 @@ static struct drm_driver vc4_drm_driver = {
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_import = drm_gem_prime_import,
.gem_prime_export = vc4_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = vc4_prime_import_sg_table,
-- 
2.20.1

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

[PATCH 46/59] drm/panfrost: don't set gem_obj->resv for prime import anymore

2019-06-14 Thread Daniel Vetter
This is now done in drm_prime.c

Signed-off-by: Daniel Vetter 
Cc: Rob Herring 
Cc: Tomeu Vizoso 
---
 drivers/gpu/drm/panfrost/panfrost_gem.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c 
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 886875ae31d3..590d378fab1b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -91,8 +91,6 @@ panfrost_gem_prime_import_sg_table(struct drm_device *dev,
 
pobj = to_panfrost_bo(obj);
 
-   obj->resv = attach->dmabuf->resv;
-
panfrost_mmu_map(pobj);
 
return obj;
-- 
2.20.1

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

[PATCH 25/59] drm/qxl: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Dave Airlie 
Cc: Gerd Hoffmann 
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
 drivers/gpu/drm/qxl/qxl_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 61e1ce16fc25..d8f64886474b 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -256,8 +256,6 @@ static struct drm_driver qxl_driver = {
 #endif
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = drm_gem_prime_export,
-   .gem_prime_import = drm_gem_prime_import,
.gem_prime_pin = qxl_gem_prime_pin,
.gem_prime_unpin = qxl_gem_prime_unpin,
.gem_prime_get_sg_table = qxl_gem_prime_get_sg_table,
-- 
2.20.1

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

[PATCH 33/59] drm/vboxvideo: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Hans de Goede 
---
 drivers/gpu/drm/vboxvideo/vbox_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c 
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index a7fd194c81a9..fa5e3149124d 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -212,8 +212,6 @@ static struct drm_driver driver = {
DRM_GEM_VRAM_DRIVER,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = drm_gem_prime_export,
-   .gem_prime_import = drm_gem_prime_import,
.gem_prime_pin = vbox_gem_prime_pin,
.gem_prime_unpin = vbox_gem_prime_unpin,
.gem_prime_get_sg_table = vbox_gem_prime_get_sg_table,
-- 
2.20.1

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

[PATCH 18/59] drm/mcde: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Linus Walleij 
---
 drivers/gpu/drm/mcde/mcde_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index f731d689d52f..a1917e21d53b 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -254,8 +254,6 @@ static struct drm_driver mcde_drm_driver = {
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_import = drm_gem_prime_import,
-   .gem_prime_export = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

[PATCH 17/59] drm/imx: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Philipp Zabel 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: NXP Linux Team 
Cc: linux-arm-ker...@lists.infradead.org
---
 drivers/gpu/drm/imx/imx-drm-core.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 384db6d86da0..bdefaa1635eb 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -154,8 +154,6 @@ static struct drm_driver imx_drm_driver = {
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_import   = drm_gem_prime_import,
-   .gem_prime_export   = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

[PATCH 11/59] drm/arm: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: "James (Qian) Wang" 
Cc: Liviu Dudau 
Cc: Brian Starkey 
---
 drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 --
 drivers/gpu/drm/arm/hdlcd_drv.c | 2 --
 drivers/gpu/drm/arm/malidp_drv.c| 2 --
 3 files changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index b9d699cc7bbf..45f05bc94487 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -63,8 +63,6 @@ static struct drm_driver komeda_kms_driver = {
.dumb_create= komeda_gem_cma_dumb_create,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export   = drm_gem_prime_export,
-   .gem_prime_import   = drm_gem_prime_import,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table  = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index b126555895d8..27c46a2838c5 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -240,8 +240,6 @@ static struct drm_driver hdlcd_driver = {
.dumb_create = drm_gem_cma_dumb_create,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = drm_gem_prime_export,
-   .gem_prime_import = drm_gem_prime_import,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 5dccc7130739..3ecdf1311335 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -574,8 +574,6 @@ static struct drm_driver malidp_driver = {
.dumb_create = malidp_dumb_create,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = drm_gem_prime_export,
-   .gem_prime_import = drm_gem_prime_import,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

[PATCH 06/59] drm/prime: Actually remove DRIVER_PRIME everywhere

2019-06-14 Thread Daniel Vetter
Split out to make the functional changes stick out more.

v2: amdgpu gained DRIVER_SYNCOBJ_TIMELINE.

v3: amdgpu lost DRIVER_SYNCOBJ_TIMELINE.

Signed-off-by: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: etna...@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: l...@lists.freedesktop.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-asp...@lists.ozlabs.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-te...@vger.kernel.org
Cc: nouv...@lists.freedesktop.org
Cc: NXP Linux Team 
Cc: spice-de...@lists.freedesktop.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: VMware Graphics 
Cc: xen-de...@lists.xenproject.org
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
 drivers/gpu/drm/arc/arcpgu_drv.c| 3 +--
 drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 +-
 drivers/gpu/drm/arm/hdlcd_drv.c | 4 +---
 drivers/gpu/drm/arm/malidp_drv.c| 3 +--
 drivers/gpu/drm/armada/armada_drv.c | 3 +--
 drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 3 +--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 4 +---
 drivers/gpu/drm/bochs/bochs_drv.c   | 3 +--
 drivers/gpu/drm/cirrus/cirrus.c | 2 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c   | 4 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   | 3 +--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 3 +--
 drivers/gpu/drm/i915/i915_drv.c | 2 +-
 drivers/gpu/drm/imx/imx-drm-core.c  | 3 +--
 drivers/gpu/drm/lima/lima_drv.c | 2 +-
 drivers/gpu/drm/mcde/mcde_drv.c | 2 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 3 +--
 drivers/gpu/drm/meson/meson_drv.c   | 4 +---
 drivers/gpu/drm/msm/msm_drv.c   | 1 -
 drivers/gpu/drm/mxsfb/mxsfb_drv.c   | 3 +--
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c  | 2 +-
 drivers/gpu/drm/panfrost/panfrost_drv.c | 3 +--
 drivers/gpu/drm/pl111/pl111_drv.c   | 2 +-
 drivers/gpu/drm/qxl/qxl_drv.c   | 3 +--
 drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 3 +--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 3 +--
 drivers/gpu/drm/shmobile/shmob_drm_drv.c| 3 +--
 drivers/gpu/drm/sti/sti_drv.c   | 3 +--
 drivers/gpu/drm/stm/drv.c   | 3 +--
 drivers/gpu/drm/sun4i/sun4i_drv.c   | 2 +-
 drivers/gpu/drm/tegra/drm.c | 2 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +--
 drivers/gpu/drm/tinydrm/hx8357d.c   | 2 +-
 drivers/gpu/drm/tinydrm/ili9225.c   | 3 +--
 drivers/gpu/drm/tinydrm/ili9341.c   | 2 +-
 drivers/gpu/drm/tinydrm/mi0283qt.c  | 3 +--
 drivers/gpu/drm/tinydrm/repaper.c   | 3 +--
 drivers/gpu/drm/tinydrm/st7586.c| 3 +--
 drivers/gpu/drm/tinydrm/st7735r.c   | 3 +--
 drivers/gpu/drm/tve200/tve200_drv.c | 3 +--
 drivers/gpu/drm/udl/udl_drv.c   | 2 +-
 drivers/gpu/drm/v3d/v3d_drv.c   | 1 -
 drivers/gpu/drm/vboxvideo/vbox_drv.c| 2 +-
 drivers/gpu/drm/vc4/vc4_drv.c   | 1 -
 drivers/gpu/drm/vgem/vgem_drv.c | 3 +--
 drivers/gpu/drm/virtio/virtgpu_drv.c| 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
 drivers/gpu/drm/xen/xen_drm_front.c | 3 +--
 drivers/gpu/drm/zte/zx_drm_drv.c| 3 +--
 include/drm/drm_drv.h   | 6 --
 54 files changed, 50 insertions(+), 94 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 0a577a389024..8e1b269351e8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1309,7 +1309,7 @@ static struct drm_driver kms_driver = {
.driver_features =
DRIVER_USE_AGP | DRIVER_ATOMIC |
DRIVER_GEM |
-   DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ,
+   DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ,
.load = amdgpu_driver_load_kms,
.open = amdgpu_driver_open_kms,
.postclose = amdgpu_driver_postclose_kms,
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index af60c6d7a5f4..74240cc1c300 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -135,8 +135,7 @@ static int arcpgu_debugfs_init(struct drm_minor *minor)
 #endif
 
 static struct drm_driver arcpgu_drm_driver = {
-   .driver_

[PATCH 03/59] drm/prime: Update docs

2019-06-14 Thread Daniel Vetter
Yes this is a bit a big patch, but since it's essentially a complete
rewrite of all the prime docs I didn't see how to better split it up.

Changes:
- Consistently point to drm_gem_object_funcs as the preferred hooks,
  where applicable.

- Reorder all the functions in drm_prime.[hc] into three groups: core,
  export helpers, import helpers.

- Document all the hooks in &drm_driver that lacked kerneldoc.

- Completely new overview section, which now also includes the cleaned
  up lifetime/reference counting subchapter. I also mentioned the weak
  references in there due to the lookup caches.

- Completely rewritten helper intro section, highlight the
  import/export related functionality.

- Polish for all the functions and more cross references.

I also sprinkled a bunch of todos all over.

Most important: 0 code changes in here. The cleanup motivated by
reading and improving all this will follow later on.

v2: Actually update the prime helper docs. Plus add a few FIXMEs that
I won't address right away in subsequent cleanup patches.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-mm.rst |  40 +-
 drivers/gpu/drm/drm_prime.c  | 851 ++-
 include/drm/drm_drv.h| 104 -
 include/drm/drm_gem.h|  18 +-
 include/drm/drm_prime.h  |  42 +-
 5 files changed, 576 insertions(+), 479 deletions(-)

diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index c8ebd4f66a6a..b664f054c259 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -433,43 +433,11 @@ PRIME is the cross device buffer sharing framework in 
drm, originally
 created for the OPTIMUS range of multi-gpu platforms. To userspace PRIME
 buffers are dma-buf based file descriptors.
 
-Overview and Driver Interface
--
+Overview and Lifetime Rules
+---
 
-Similar to GEM global names, PRIME file descriptors are also used to
-share buffer objects across processes. They offer additional security:
-as file descriptors must be explicitly sent over UNIX domain sockets to
-be shared between applications, they can't be guessed like the globally
-unique GEM names.
-
-Drivers that support the PRIME API must set the DRIVER_PRIME bit in the
-struct :c:type:`struct drm_driver `
-driver_features field, and implement the prime_handle_to_fd and
-prime_fd_to_handle operations.
-
-int (\*prime_handle_to_fd)(struct drm_device \*dev, struct drm_file
-\*file_priv, uint32_t handle, uint32_t flags, int \*prime_fd); int
-(\*prime_fd_to_handle)(struct drm_device \*dev, struct drm_file
-\*file_priv, int prime_fd, uint32_t \*handle); Those two operations
-convert a handle to a PRIME file descriptor and vice versa. Drivers must
-use the kernel dma-buf buffer sharing framework to manage the PRIME file
-descriptors. Similar to the mode setting API PRIME is agnostic to the
-underlying buffer object manager, as long as handles are 32bit unsigned
-integers.
-
-While non-GEM drivers must implement the operations themselves, GEM
-drivers must use the :c:func:`drm_gem_prime_handle_to_fd()` and
-:c:func:`drm_gem_prime_fd_to_handle()` helper functions. Those
-helpers rely on the driver gem_prime_export and gem_prime_import
-operations to create a dma-buf instance from a GEM object (dma-buf
-exporter role) and to create a GEM object from a dma-buf instance
-(dma-buf importer role).
-
-struct dma_buf \* (\*gem_prime_export)(struct drm_device \*dev,
-struct drm_gem_object \*obj, int flags); struct drm_gem_object \*
-(\*gem_prime_import)(struct drm_device \*dev, struct dma_buf
-\*dma_buf); These two operations are mandatory for GEM drivers that
-support PRIME.
+.. kernel-doc:: drivers/gpu/drm/drm_prime.c
+   :doc: overview and lifetime rules
 
 PRIME Helper Functions
 --
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index d0c01318076b..f08159a8b03a 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -38,47 +38,53 @@
 
 #include "drm_internal.h"
 
-/*
- * DMA-BUF/GEM Object references and lifetime overview:
- *
- * On the export the dma_buf holds a reference to the exporting GEM
- * object. It takes this reference in handle_to_fd_ioctl, when it
- * first calls .prime_export and stores the exporting GEM object in
- * the dma_buf priv. This reference needs to be released when the
- * final reference to the &dma_buf itself is dropped and its
- * &dma_buf_ops.release function is called. For GEM-based drivers,
- * the dma_buf should be exported using drm_gem_dmabuf_export() and
- * then released by drm_gem_dmabuf_release().
- *
- * On the import the importing GEM object holds a reference to the
- * dma_buf (which in turn holds a ref to the exporting GEM object).
- * It takes that reference in the fd_to_handle ioctl.
- * It calls dma_buf_get, creates an attachment to it and stores the
- * attachment in the GEM object. When this attachment is destroyed
- * when the imported object i

[PATCH 15/59] drm/fsl-dcu: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Stefan Agner 
Cc: Alison Wang 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index d18ff729d7f6..661725d8f7dc 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -143,8 +143,6 @@ static struct drm_driver fsl_dcu_drm_driver = {
.gem_vm_ops = &drm_gem_cma_vm_ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_import   = drm_gem_prime_import,
-   .gem_prime_export   = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

[PATCH 12/59] drm/atmel: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Boris Brezillon 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Cc: Ludovic Desroches 
Cc: linux-arm-ker...@lists.infradead.org
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 274fdf18cde8..2b794a50e7ab 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -843,8 +843,6 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
.gem_vm_ops = &drm_gem_cma_vm_ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_import = drm_gem_prime_import,
-   .gem_prime_export = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

[PATCH 14/59] drm/exynos: Drop drm_gem_prime_export

2019-06-14 Thread Daniel Vetter
They're the default. We can't do the same on the import side, due to
the exynos_drm->dma_dev not necessarily matching the overall drm
device.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index e43640fc42d3..4d270390eba2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -124,7 +124,6 @@ static struct drm_driver exynos_drm_driver = {
.dumb_create= exynos_drm_gem_dumb_create,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export   = drm_gem_prime_export,
.gem_prime_import   = exynos_drm_gem_prime_import,
.gem_prime_get_sg_table = exynos_drm_gem_prime_get_sg_table,
.gem_prime_import_sg_table  = exynos_drm_gem_prime_import_sg_table,
-- 
2.20.1

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

[PATCH 07/59] drm/arm/komeda: Remove DRIVER_HAVE_IRQ

2019-06-14 Thread Daniel Vetter
Read the docs, komeda is not an old enough driver for this :-)

Signed-off-by: Daniel Vetter 
Cc: "James (Qian) Wang" 
Cc: Liviu Dudau 
---
 drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 0c6396dc323f..b9d699cc7bbf 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -55,8 +55,7 @@ static irqreturn_t komeda_kms_irq_handler(int irq, void *data)
 }
 
 static struct drm_driver komeda_kms_driver = {
-   .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
-  DRIVER_HAVE_IRQ,
+   .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.lastclose  = drm_fb_helper_lastclose,
.irq_handler= komeda_kms_irq_handler,
.gem_free_object_unlocked   = drm_gem_cma_free_object,
-- 
2.20.1

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

[PATCH 16/59] drm/hisilicon: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Daniel Vetter 
Cc: Xinliang Liu 
Cc: "Noralf Trønnes" 
Cc: CK Hu 
Cc: Thomas Zimmermann 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 73f2b53f32cc..6e95d3b167cc 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -126,8 +126,6 @@ static struct drm_driver kirin_drm_driver = {
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export   = drm_gem_prime_export,
-   .gem_prime_import   = drm_gem_prime_import,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

Re: [PATCH v4 14/28] docs: locking: convert docs to ReST and rename to *.rst

2019-06-14 Thread Jonathan Corbet
On Wed, 12 Jun 2019 14:52:50 -0300
Mauro Carvalho Chehab  wrote:

> Convert the locking documents to ReST and add them to the
> kernel development book where it belongs.
> 
> Most of the stuff here is just to make Sphinx to properly
> parse the text file, as they're already in good shape,
> not requiring massive changes in order to be parsed.
> 
> The conversion is actually:
>   - add blank lines and identation in order to identify paragraphs;
>   - fix tables markups;
>   - add some lists markups;
>   - mark literal blocks;
>   - adjust title markups.
> 
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> Acked-by: Federico Vaga 

This patch contains linux-next changes and doesn't apply to docs-next.
Perhaps the best thing to do is to apply it to the locking tree?

Thanks,

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

[PATCH 09/59] drm/prime: Align gem_prime_export with obj_funcs.export

2019-06-14 Thread Daniel Vetter
The idea is that gem_prime_export is deprecated in favor of
obj_funcs.export. That's much easier to do if both have matching
function signatures.

Signed-off-by: Daniel Vetter 
Cc: Russell King 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Zhenyu Wang 
Cc: Zhi Wang 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tomi Valkeinen 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: "David (ChunMing) Zhou" 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: Dave Airlie 
Cc: Eric Anholt 
Cc: "Michel Dänzer" 
Cc: Chris Wilson 
Cc: Huang Rui 
Cc: Felix Kuehling 
Cc: Hawking Zhang 
Cc: Feifei Xu 
Cc: Jim Qu 
Cc: Evan Quan 
Cc: Matthew Auld 
Cc: Mika Kuoppala 
Cc: Thomas Zimmermann 
Cc: Kate Stewart 
Cc: Sumit Semwal 
Cc: Jilayne Lovejoy 
Cc: Thomas Gleixner 
Cc: Mikulas Patocka 
Cc: Greg Kroah-Hartman 
Cc: Junwei Zhang 
Cc: intel-gvt-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c  | 7 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h  | 3 +--
 drivers/gpu/drm/armada/armada_gem.c  | 5 ++---
 drivers/gpu/drm/armada/armada_gem.h  | 3 +--
 drivers/gpu/drm/drm_prime.c  | 9 -
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   | 5 ++---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 8 
 drivers/gpu/drm/i915/gvt/dmabuf.c| 2 +-
 drivers/gpu/drm/i915/i915_drv.h  | 3 +--
 drivers/gpu/drm/omapdrm/omap_gem.h   | 3 +--
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c| 5 ++---
 drivers/gpu/drm/radeon/radeon_drv.c  | 3 +--
 drivers/gpu/drm/radeon/radeon_prime.c| 5 ++---
 drivers/gpu/drm/tegra/gem.c  | 7 +++
 drivers/gpu/drm/tegra/gem.h  | 3 +--
 drivers/gpu/drm/udl/udl_dmabuf.c | 5 ++---
 drivers/gpu/drm/udl/udl_drv.h| 3 +--
 drivers/gpu/drm/vc4/vc4_bo.c | 5 ++---
 drivers/gpu/drm/vc4/vc4_drv.h| 3 +--
 drivers/gpu/drm/vgem/vgem_fence.c| 2 +-
 include/drm/drm_drv.h| 4 ++--
 include/drm/drm_prime.h  | 3 +--
 22 files changed, 39 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 489041df1f45..4809d4a5d72a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -345,8 +345,7 @@ const struct dma_buf_ops amdgpu_dmabuf_ops = {
  * Returns:
  * Shared DMA buffer representing the GEM BO from the given device.
  */
-struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
-   struct drm_gem_object *gobj,
+struct dma_buf *amdgpu_gem_prime_export(struct drm_gem_object *gobj,
int flags)
 {
struct amdgpu_bo *bo = gem_to_amdgpu_bo(gobj);
@@ -356,9 +355,9 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device 
*dev,
bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)
return ERR_PTR(-EPERM);
 
-   buf = drm_gem_prime_export(dev, gobj, flags);
+   buf = drm_gem_prime_export(gobj, flags);
if (!IS_ERR(buf)) {
-   buf->file->f_mapping = dev->anon_inode->i_mapping;
+   buf->file->f_mapping = gobj->dev->anon_inode->i_mapping;
buf->ops = &amdgpu_dmabuf_ops;
}
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
index c7056cbe8685..7f73a4f94204 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
@@ -30,8 +30,7 @@ struct drm_gem_object *
 amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
 struct dma_buf_attachment *attach,
 struct sg_table *sg);
-struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
-   struct drm_gem_object *gobj,
+struct dma_buf *amdgpu_gem_prime_export(struct drm_gem_object *gobj,
int flags);
 struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf);
diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 642d0e70d0f8..7e7fcc3f1f7f 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -485,8 +485,7 @@ static const struct dma_buf_ops armada_gem_prime_dmabuf_ops 
= {
 };
 
 struct dma_buf *
-armada_gem_prime_export(struct drm_device *dev, struct drm_gem_object *obj,
-   int flags)
+armada_gem_prime_e

[PATCH 26/59] drm/rcar-du: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: Kieran Bingham 
Cc: linux-renesas-...@vger.kernel.org
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 83685250319d..9c93eb4fad8b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -446,8 +446,6 @@ static struct drm_driver rcar_du_driver = {
.gem_vm_ops = &drm_gem_cma_vm_ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_import   = drm_gem_prime_import,
-   .gem_prime_export   = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1



[PATCH 28/59] drm/shmob: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: Kieran Bingham 
Cc: linux-renesas-...@vger.kernel.org
---
 drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c 
b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
index 9047a49ff35e..6c106b7a3bfe 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
@@ -133,8 +133,6 @@ static struct drm_driver shmob_drm_driver = {
.gem_vm_ops = &drm_gem_cma_vm_ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_import   = drm_gem_prime_import,
-   .gem_prime_export   = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1



[PATCH 10/59] drm/arc: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Alexey Brodkin 
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 74240cc1c300..6b7f791685ec 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -149,8 +149,6 @@ static struct drm_driver arcpgu_drm_driver = {
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_print_info = drm_gem_cma_print_info,
.gem_vm_ops = &drm_gem_cma_vm_ops,
-   .gem_prime_export = drm_gem_prime_export,
-   .gem_prime_import = drm_gem_prime_import,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

[PATCH 13/59] drm/etnaviv: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Lucas Stach 
Cc: Russell King 
Cc: Christian Gmeiner 
Cc: etna...@lists.freedesktop.org
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index db3b00031fcf..400fbb2588f1 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -469,8 +469,6 @@ static struct drm_driver etnaviv_drm_driver = {
.gem_vm_ops = &vm_ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export   = drm_gem_prime_export,
-   .gem_prime_import   = drm_gem_prime_import,
.gem_prime_pin  = etnaviv_gem_prime_pin,
.gem_prime_unpin= etnaviv_gem_prime_unpin,
.gem_prime_get_sg_table = etnaviv_gem_prime_get_sg_table,
-- 
2.20.1

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

[PATCH 19/59] drm/mtk: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: Matthias Brugger 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 1f8b8943b0c6..dd8dab562500 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -329,8 +329,6 @@ static struct drm_driver mtk_drm_driver = {
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = drm_gem_prime_export,
-   .gem_prime_import = drm_gem_prime_import,
.gem_prime_get_sg_table = mtk_gem_prime_get_sg_table,
.gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
.gem_prime_mmap = mtk_drm_gem_mmap_buf,
-- 
2.20.1

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

[PATCH 20/59] drm/meson: Drop drm_gem_prime_export/import

2019-06-14 Thread Daniel Vetter
They're the default.

Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.

Signed-off-by: Daniel Vetter 
Cc: Neil Armstrong 
Cc: Kevin Hilman 
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
---
 drivers/gpu/drm/meson/meson_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index 140363f93575..37dca83d6eb1 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -101,8 +101,6 @@ static struct drm_driver meson_driver = {
/* PRIME Ops */
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_import   = drm_gem_prime_import,
-   .gem_prime_export   = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
.gem_prime_vmap = drm_gem_cma_prime_vmap,
-- 
2.20.1

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

Re: [PATCH v5] docs: power: convert docs to ReST and rename to *.rst

2019-06-14 Thread Jonathan Corbet
On Thu, 13 Jun 2019 07:10:36 -0300
Mauro Carvalho Chehab  wrote:

> Convert the PM documents to ReST, in order to allow them to
> build with Sphinx.
> 
> The conversion is actually:
>   - add blank lines and identation in order to identify paragraphs;
>   - fix tables markups;
>   - add some lists markups;
>   - mark literal blocks;
>   - adjust title markups.
> 
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> Acked-by: Mark Brown 
> Acked-by: Bjorn Helgaas 
> Acked-by: Srivatsa S. Bhat (VMware) 

So I can't apply this one due to conflicts in include/linux/pci.h.  Bjorn,
perhaps the easiest thing is for you to take this one through your tree?

Thanks,

jon


[PATCH 08/59] drm/omapdrm: drop fb_debug_enter/leave

2019-06-14 Thread Daniel Vetter
This is a no-op on atomic drivers because with atomic it's simply too
complicated to get all the locking and workers and nonblocking
synchronization correct, from essentially an NMI context. Well, too
complicated = impossible. Also, omapdrm never implemented the
mode_set_base_atomic hook, so I kinda wonder why this was ever added.

Drop the hooks.

Signed-off-by: Daniel Vetter 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index 50aabd854f4d..0dad42e819ba 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -87,8 +87,6 @@ static struct fb_ops omap_fb_ops = {
.fb_setcmap = drm_fb_helper_setcmap,
.fb_blank   = drm_fb_helper_blank,
.fb_pan_display = omap_fbdev_pan_display,
-   .fb_debug_enter = drm_fb_helper_debug_enter,
-   .fb_debug_leave = drm_fb_helper_debug_leave,
.fb_ioctl   = drm_fb_helper_ioctl,
 
.fb_read = drm_fb_helper_sys_read,
-- 
2.20.1

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

[PATCH 02/59] drm/gem: Unexport drm_gem_(un)pin/v(un)map

2019-06-14 Thread Daniel Vetter
They're purely for internal use, not for drivers.

Cc: Noralf Trønnes 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem.c  | 32 
 drivers/gpu/drm/drm_internal.h |  5 +
 include/drm/drm_gem.h  |  5 -
 3 files changed, 5 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 8a55f71325b1..a8c4468f03d9 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1216,15 +1216,6 @@ void drm_gem_print_info(struct drm_printer *p, unsigned 
int indent,
obj->dev->driver->gem_print_info(p, indent, obj);
 }
 
-/**
- * drm_gem_pin - Pin backing buffer in memory
- * @obj: GEM object
- *
- * Make sure the backing buffer is pinned in memory.
- *
- * Returns:
- * 0 on success or a negative error code on failure.
- */
 int drm_gem_pin(struct drm_gem_object *obj)
 {
if (obj->funcs && obj->funcs->pin)
@@ -1234,14 +1225,7 @@ int drm_gem_pin(struct drm_gem_object *obj)
else
return 0;
 }
-EXPORT_SYMBOL(drm_gem_pin);
 
-/**
- * drm_gem_unpin - Unpin backing buffer from memory
- * @obj: GEM object
- *
- * Relax the requirement that the backing buffer is pinned in memory.
- */
 void drm_gem_unpin(struct drm_gem_object *obj)
 {
if (obj->funcs && obj->funcs->unpin)
@@ -1249,16 +1233,7 @@ void drm_gem_unpin(struct drm_gem_object *obj)
else if (obj->dev->driver->gem_prime_unpin)
obj->dev->driver->gem_prime_unpin(obj);
 }
-EXPORT_SYMBOL(drm_gem_unpin);
 
-/**
- * drm_gem_vmap - Map buffer into kernel virtual address space
- * @obj: GEM object
- *
- * Returns:
- * A virtual pointer to a newly created GEM object or an ERR_PTR-encoded 
negative
- * error code on failure.
- */
 void *drm_gem_vmap(struct drm_gem_object *obj)
 {
void *vaddr;
@@ -1275,13 +1250,7 @@ void *drm_gem_vmap(struct drm_gem_object *obj)
 
return vaddr;
 }
-EXPORT_SYMBOL(drm_gem_vmap);
 
-/**
- * drm_gem_vunmap - Remove buffer mapping from kernel virtual address space
- * @obj: GEM object
- * @vaddr: Virtual address (can be NULL)
- */
 void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr)
 {
if (!vaddr)
@@ -1292,7 +1261,6 @@ void drm_gem_vunmap(struct drm_gem_object *obj, void 
*vaddr)
else if (obj->dev->driver->gem_prime_vunmap)
obj->dev->driver->gem_prime_vunmap(obj, vaddr);
 }
-EXPORT_SYMBOL(drm_gem_vunmap);
 
 /**
  * drm_gem_lock_reservations - Sets up the ww context and acquires
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index d18c7b91a1a8..51a2055c8f18 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -133,6 +133,11 @@ void drm_gem_release(struct drm_device *dev, struct 
drm_file *file_private);
 void drm_gem_print_info(struct drm_printer *p, unsigned int indent,
const struct drm_gem_object *obj);
 
+int drm_gem_pin(struct drm_gem_object *obj);
+void drm_gem_unpin(struct drm_gem_object *obj);
+void *drm_gem_vmap(struct drm_gem_object *obj);
+void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr);
+
 /* drm_debugfs.c drm_debugfs_crc.c */
 #if defined(CONFIG_DEBUG_FS)
 int drm_debugfs_init(struct drm_minor *minor, int minor_id,
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 5047c7ee25f5..a9121fe66ea2 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -401,9 +401,4 @@ int drm_gem_dumb_destroy(struct drm_file *file,
 struct drm_device *dev,
 uint32_t handle);
 
-int drm_gem_pin(struct drm_gem_object *obj);
-void drm_gem_unpin(struct drm_gem_object *obj);
-void *drm_gem_vmap(struct drm_gem_object *obj);
-void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr);
-
 #endif /* __DRM_GEM_H__ */
-- 
2.20.1

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

[PATCH 04/59] drm/prime: Unconditionally set up the prime file private

2019-06-14 Thread Daniel Vetter
It's tiny, already embedded, and setup/teardown cost is trivial.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_file.c | 9 +++--
 drivers/gpu/drm/drm_gem.c  | 3 +--
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 754af25fe255..ea34bc991858 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -147,8 +147,7 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
drm_syncobj_open(file);
 
-   if (drm_core_check_feature(dev, DRIVER_PRIME))
-   drm_prime_init_file_private(&file->prime);
+   drm_prime_init_file_private(&file->prime);
 
if (dev->driver->open) {
ret = dev->driver->open(dev, file);
@@ -159,8 +158,7 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
return file;
 
 out_prime_destroy:
-   if (drm_core_check_feature(dev, DRIVER_PRIME))
-   drm_prime_destroy_file_private(&file->prime);
+   drm_prime_destroy_file_private(&file->prime);
if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
drm_syncobj_release(file);
if (drm_core_check_feature(dev, DRIVER_GEM))
@@ -253,8 +251,7 @@ void drm_file_free(struct drm_file *file)
if (dev->driver->postclose)
dev->driver->postclose(dev, file);
 
-   if (drm_core_check_feature(dev, DRIVER_PRIME))
-   drm_prime_destroy_file_private(&file->prime);
+   drm_prime_destroy_file_private(&file->prime);
 
WARN_ON(!list_empty(&file->event_list));
 
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index a8c4468f03d9..e6c12c6ec728 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -254,8 +254,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
else if (dev->driver->gem_close_object)
dev->driver->gem_close_object(obj, file_priv);
 
-   if (drm_core_check_feature(dev, DRIVER_PRIME))
-   drm_gem_remove_prime_handles(obj, file_priv);
+   drm_gem_remove_prime_handles(obj, file_priv);
drm_vma_node_revoke(&obj->vma_node, file_priv);
 
drm_gem_object_handle_put_unlocked(obj);
-- 
2.20.1

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

[PATCH 01/59] drm/todo: Improve drm_gem_object funcs todo

2019-06-14 Thread Daniel Vetter
We're kinda going in the wrong direction. Spotted while typing better
gem/prime docs.

Cc: Thomas Zimmermann 
Cc: Gerd Hoffmann 
Cc: Rob Herring 
Cc: Noralf Trønnes 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/todo.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index b4a76c2703e5..23583f0e3755 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -228,6 +228,10 @@ struct drm_gem_object_funcs
 GEM objects can now have a function table instead of having the callbacks on 
the
 DRM driver struct. This is now the preferred way and drivers can be moved over.
 
+Unfortunately some of the recently added GEM helpers are going in the wrong
+direction by adding OPS macros that use the old, deprecated hooks. See
+DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS, and 
DRM_GEM_VRAM_DRIVER_PRIME.
+
 Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate
 -
 
-- 
2.20.1

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

[PATCH 00/59] prime doc polish and ... a few cleanups

2019-06-14 Thread Daniel Vetter
Hi all,

So I figured let's get going and polish the docs for the last part of drm
core/helpers that hasn't yet seen some neat polish last few years. With
the goal to make docs for driver kapi a requirement henceforth - see last
patch. Aside from that final doc patch I also included some todo.rst
updates, bunch of things have progressed quite a bit.

Of course spotted some lower-hanging fruit to untangle the prime helpers
and interfaces, and decided to at least fix a few of those.

Patch series survived some light testing on i915+vgem, but that's it. So
review, testing, comments and anything else really highgly welcome.

Cheers, Daniel

Daniel Vetter (59):
  drm/todo: Improve drm_gem_object funcs todo
  drm/gem: Unexport drm_gem_(un)pin/v(un)map
  drm/prime: Update docs
  drm/prime: Unconditionally set up the prime file private
  drm/prime: Make DRIVER_PRIME a no-op
  drm/prime: Actually remove DRIVER_PRIME everywhere
  drm/arm/komeda: Remove DRIVER_HAVE_IRQ
  drm/omapdrm: drop fb_debug_enter/leave
  drm/prime: Align gem_prime_export with obj_funcs.export
  drm/arc: Drop drm_gem_prime_export/import
  drm/arm: Drop drm_gem_prime_export/import
  drm/atmel: Drop drm_gem_prime_export/import
  drm/etnaviv: Drop drm_gem_prime_export/import
  drm/exynos: Drop drm_gem_prime_export
  drm/fsl-dcu: Drop drm_gem_prime_export/import
  drm/hisilicon: Drop drm_gem_prime_export/import
  drm/imx: Drop drm_gem_prime_export/import
  drm/mcde: Drop drm_gem_prime_export/import
  drm/mtk: Drop drm_gem_prime_export/import
  drm/meson: Drop drm_gem_prime_export/import
  drm/msm: Drop drm_gem_prime_export/import
  drm/mxsfb: Drop drm_gem_prime_export/import
  drm/nouveau: Drop drm_gem_prime_export/import
  drm/pl111: Drop drm_gem_prime_export/import
  drm/qxl: Drop drm_gem_prime_export/import
  drm/rcar-du: Drop drm_gem_prime_export/import
  drm/rockchip: Drop drm_gem_prime_export/import
  drm/shmob: Drop drm_gem_prime_export/import
  drm/sti: Drop drm_gem_prime_export/import
  drm/stm: Drop drm_gem_prime_export/import
  drm/tilcdc: Drop drm_gem_prime_export/import
  drm/tve2000: Drop drm_gem_prime_export/import
  drm/vboxvideo: Drop drm_gem_prime_export/import
  drm/vc3: Drop drm_gem_prime_import
  drm/radeon: Drop drm_gem_prime_import
  drm/vgem: Drop drm_gem_prime_export
  drm/virtio: Drop drm_gem_prime_export/import
  drm/xen: Drop drm_gem_prime_export/import
  drm/zte: Drop drm_gem_prime_export/import
  drm/vram-helper: Drop drm_gem_prime_export/import
  drm/prime: automatically set gem_obj->resv on import
  drm/etnaviv: Drop resv argument from etnaviv_gem_new_impl
  drm/lima: Drop resv argument from lima_bo_create_struct
  drm/mediatek: Use drm_atomic_helper_wait_for_fences
  drm/msm: Drop robj from msm_gem_new_impl
  drm/panfrost: don't set gem_obj->resv for prime import anymore
  drm/vc4: Don set gem_obj->resv in prime import anymore
  drm/vgem: Ditch attach trickery in the fence ioctl
  drm/msm: Use drm_gem_fb_prepare_fb
  drm/vc4: Use drm_gem_fb_prepare_fb
  drm/radeon: Fill out gem_object->resv
  drm/nouveau: Fill out gem_object->resv
  drm/amdgpu: Fill out gem_object->resv
  drm/prime: Ditch gem_prime_res_obj hook
  drm/todo: remove gem_prime_import/export todo
  drm/todo: Update backlight todo
  drm/todo: Update mmap todo
  drm/todo: Add new debugfs todo
  drm/doc: Document kapi doc expectations

 Documentation/gpu/drm-mm.rst  |  40 +-
 Documentation/gpu/introduction.rst|  13 +
 Documentation/gpu/todo.rst|  65 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c   |  24 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h   |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|   2 +
 drivers/gpu/drm/arc/arcpgu_drv.c  |   5 +-
 .../gpu/drm/arm/display/komeda/komeda_kms.c   |   5 +-
 drivers/gpu/drm/arm/hdlcd_drv.c   |   6 +-
 drivers/gpu/drm/arm/malidp_drv.c  |   5 +-
 drivers/gpu/drm/armada/armada_drv.c   |   3 +-
 drivers/gpu/drm/armada/armada_gem.c   |   5 +-
 drivers/gpu/drm/armada/armada_gem.h   |   3 +-
 drivers/gpu/drm/aspeed/aspeed_gfx_drv.c   |   3 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c  |   6 +-
 drivers/gpu/drm/bochs/bochs_drv.c |   3 +-
 drivers/gpu/drm/cirrus/cirrus.c   |   2 +-
 drivers/gpu/drm/drm_file.c|   9 +-
 drivers/gpu/drm/drm_gem.c |  35 +-
 drivers/gpu/drm/drm_internal.h|   5 +
 drivers/gpu/drm/drm_prime.c   | 861 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c |   6 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.c |  14 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.h |   3 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c   |   1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |   3 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c |   5 +-
 .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c   |   5 +-
 drivers/gpu/drm/

[PATCH 05/59] drm/prime: Make DRIVER_PRIME a no-op

2019-06-14 Thread Daniel Vetter
Drivers must fill out the handle_to_fd and fd_to_handle hooks to
enable export/import prime functionality already. The additional
DRIVER_PRIME flag doesn't serve any real purpose, since the overall
flag doesn't even tell you whether import or export or maybe even both
is supported.

Ditch it.

This patch just makes it defunct, subsequent patches will remove it
from all the drivers.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_prime.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index f08159a8b03a..78f6f10b2060 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -47,8 +47,7 @@
  * between applications, they can't be guessed like the globally unique GEM
  * names.
  *
- * Drivers that support the PRIME API must set the DRIVER_PRIME bit in the
- * &drm_driver.driver_features field, and implement the
+ * Drivers that support the PRIME API implement the
  * &drm_driver.prime_handle_to_fd and &drm_driver.prime_fd_to_handle 
operations.
  * GEM based drivers must use drm_gem_prime_handle_to_fd() an
  * drm_gem_prime_fd_to_handle() to implement these. For GEM based drivers the
@@ -361,9 +360,6 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
 {
struct drm_prime_handle *args = data;
 
-   if (!drm_core_check_feature(dev, DRIVER_PRIME))
-   return -EOPNOTSUPP;
-
if (!dev->driver->prime_fd_to_handle)
return -ENOSYS;
 
@@ -512,9 +508,6 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
 {
struct drm_prime_handle *args = data;
 
-   if (!drm_core_check_feature(dev, DRIVER_PRIME))
-   return -EOPNOTSUPP;
-
if (!dev->driver->prime_handle_to_fd)
return -ENOSYS;
 
-- 
2.20.1

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

Re: [PATCH v2 17/28] drivers: Introduce bus_find_device_by_of_node() helper

2019-06-14 Thread Wolfram Sang
On Fri, Jun 14, 2019 at 06:54:12PM +0100, Suzuki K Poulose wrote:
> Add a wrapper to bus_find_device() to search for a device
> by the of_node pointer, reusing the generic match function.
> Also convert the existing users to make use of the new helper.
> 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: dri-devel@lists.freedesktop.org
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: devicet...@vger.kernel.org
> Cc: Florian Fainelli 
> Cc: Frank Rowand 
> Cc: Heiko Stuebner 
> Cc: Liam Girdwood 
> Cc: linux-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-...@vger.kernel.org
> Cc: Mathieu Poirier 
> Cc: Rob Herring 
> Cc: Srinivas Kandagatla 
> Cc: Takashi Iwai 
> Cc: Wolfram Sang 
> Cc: Greg Kroah-Hartman 
> Cc: "Rafael J. Wysocki" 
> Signed-off-by: Suzuki K Poulose 

Acked-by: Wolfram Sang  # for the I2C parts



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

Re: [PATCH v2 06/28] drivers: Add generic helper to match by of_node

2019-06-14 Thread Wolfram Sang
> +
> +int device_match_of_node(struct device *dev, const void *np)
> +{
> + return dev->of_node == np;
> +}
> +EXPORT_SYMBOL_GPL(device_match_of_node);

Is it an option to 'static inline' this simple function in the header,
saving the EXPORT?



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

Re: [PATCH 3/6] drm/gem: use new ww_mutex_(un)lock_for_each macros

2019-06-14 Thread Daniel Vetter
On Fri, Jun 14, 2019 at 08:51:11PM +0200, Christian König wrote:
> Am 14.06.19 um 20:24 schrieb Daniel Vetter:
> > 
> > On Fri, Jun 14, 2019 at 8:10 PM Christian König 
> >  wrote:
> > > [SNIP]
> > > WW_MUTEX_LOCK_BEGIN()
> > > 
> > > lock(lru_lock);
> > > 
> > > while (bo = list_first(lru)) {
> > >   if (kref_get_unless_zero(bo)) {
> > >   unlock(lru_lock);
> > >   WW_MUTEX_LOCK(bo->ww_mutex);
> > >   lock(lru_lock);
> > >   } else {
> > >   /* bo is getting freed, steal it from the freeing process
> > >* or just ignore */
> > >   }
> > > }
> > > unlock(lru_lock)
> > > 
> > > WW_MUTEX_LOCK_END;
> 
> Ah, now I know what you mean. And NO, that approach doesn't work.
> 
> See for the correct ww_mutex dance we need to use the iterator multiple
> times.
> 
> Once to give us the BOs which needs to be locked and another time to give us
> the BOs which needs to be unlocked in case of a contention.
> 
> That won't work with the approach you suggest here.

A right, drat.

Maybe give up on the idea to make this work for ww_mutex in general, and
just for drm_gem_buffer_object? I'm just about to send out a patch series
which makes sure that a lot more drivers set gem_bo.resv correctly (it
will alias with ttm_bo.resv for ttm drivers ofc). Then we could add a
list_head to gem_bo (won't really matter, but not something we can do with
ww_mutex really), so that the unlock walking doesn't need to reuse the
same iterator. That should work I think ...

Also, it would almost cover everything you want to do. For ttm we'd need
to make ttm_bo a subclass of gem_bo (and maybe not initialize that
embedded gem_bo for vmwgfx and shadow bo and driver internal stuff).

Just some ideas, since copypasting the ww_mutex dance into all drivers is
indeed not great.
-Daniel

> 
> Regards,
> Christian.
> 
> > 
> > 
> > Also I think if we allow this we could perhaps use this to implement the
> > modeset macros too.
> > -Daniel
> > 
> > 
> > 
> > 
> > > > This is kinda what we went with for modeset locks with
> > > > DRM_MODESET_LOCK_ALL_BEGIN/END, you can grab more locks in between the
> > > > pair at least. But it's a lot more limited use-cases, maybe too fragile 
> > > > an
> > > > idea for ww_mutex in full generality.
> > > > 
> > > > Not going to type this out because too much w/e mode here already, but I
> > > > can give it a stab next week.
> > > > -Daniel
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> > 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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: [RFC/WIP] drm/rockchip: Support CRTC gamma LUT

2019-06-14 Thread Doug Anderson
Hi,

On Thu, Jun 13, 2019 at 12:23 PM Ezequiel Garcia  wrote:
>
> @@ -1744,6 +1793,41 @@ int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, 
> unsigned int mstimeout)
>  }
>  EXPORT_SYMBOL(rockchip_drm_wait_vact_end);
>
> +static int vop_gamma_lut_request(struct device *dev,
> +struct resource *res, struct vop *vop)
> +{
> +   resource_size_t offset = vop->data->gamma_lut_addr_off;
> +   resource_size_t size = VOP_GAMMA_LUT_SIZE * 4;
> +
> +   /*
> +* Some SoCs (e.g. RK3288) have the gamma LUT address after
> +* the MMU registers, which means we can't request and ioremap
> +* the entire register set. Other (e.g. RK3399) have gamma LUT
> +* address before MMU.
> +*
> +* Therefore, we need to request and ioremap those that haven't
> +* been already.
> +*/
> +   if (vop->len >= (offset + size)) {
> +   vop->lut_regs = vop->regs + offset;
> +   return 0;
> +   }
> +
> +   if (!devm_request_mem_region(dev, res->start + offset,
> +size, dev_name(dev))) {
> +   dev_warn(dev, "can't request gamma lut region\n");
> +   return -EBUSY;
> +   }
> +
> +   vop->lut_regs = devm_ioremap(dev, res->start + offset, size);
> +   if (!vop->lut_regs) {
> +   dev_err(dev, "can't ioremap gamma lut address\n");
> +   devm_release_mem_region(dev, res->start + offset, size);
> +   return -ENOMEM;
> +   }

I'm curious here.  I was always under the impression that you were
supposed to specify all of your memory regions in the device tree.
...but here the device tree on rk3288 says:

vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
reg = <0x0 0xff93 0x0 0x19c>;
...
};

...and we're now mapping 4096 bytes starting at 0xff931000.  Is that
really legit?  Wouldn't it be better to put this extra memory range in
the dts?

Hrm, but then I guess you need to figure out what to do about older
device trees.  Do you disable the gamma LUT feature?  ...or do you do
exactly what the code here is doing and just map it anyway?  I guess
you could just keep the code here (and it'll work fine), but maybe in
parallel we should add it to the .dts file and bindings?

---

I will say that, though I don't know much (anything?) about gamma
LUTs, I ran the Chrome OS "gamma_test" program and saw a pretty RGB
gradient on the both the internal screen and HDMI monitor on my
rk3288-veyron-jerry.  Thus:

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

[PATCH] staging: android: fix style problem

2019-06-14 Thread Saiyam Doshi
checkpatch reported "WARNING: line over 80 characters". This
patch fixes it by aligning function arguments.

Signed-off-by: Saiyam Doshi 
---
 drivers/staging/android/ion/ion_chunk_heap.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index 3cdde9c1a717..6aceab2e77e4 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -107,7 +107,9 @@ static struct ion_heap_ops chunk_heap_ops = {
.unmap_kernel = ion_heap_unmap_kernel,
 };
 
-struct ion_heap *ion_chunk_heap_create(phys_addr_t base, size_t size, size_t 
chunk_size)
+struct ion_heap *ion_chunk_heap_create(phys_addr_t base,
+  size_t size,
+  size_t chunk_size)
 {
struct ion_chunk_heap *chunk_heap;
int ret;
-- 
2.20.1



  1   2   3   4   >