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

[Tomeu Vizoso]

On Mon, 17 Jun 2019 at 16:56, Rob Herring  wrote:
>
> On Sun, Jun 16, 2019 at 11:15 PM Tomeu Vizoso
>  wrote:
> >
> > On Fri, 14 Jun 2019 at 23:22, Rob Herring  wrote:
> > >
> > > 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.
> >
> > I thought that the lifetime of the *contents* of the heap was that of
> > the job chain that wrote them? Otherwise, only the GPU would know what
> > can be discarded.
>
> Yes, that's probably true. To take that to the extreme, we could
> allocate and free the heap BO on each job chain. But we don't do that
> because of the overhead. So mapping and unmapping is a similar trade
> off of frequency vs. overhead. The question is when do we allow pages
> to be swapped out (as that is unhandled in the current patch)? Our
> choices are:
>
> - at any time. This is what the patch currently does as we don't
> prevent eviction. Though we'd need some mechanism to be notified when
> a page is evicted which is currently missing.
> - when a job finishes. We'd have to iterate thru BO's and mark pages
> evict-able on NOMAP BOs. Not sure where we do that in the driver.

My understanding is that any contents of NOMAP memory aren't expected
to persist across jobs. So, when a job finishes we can unmap all pages
that the job faulted on.

If we do that, then we won't have a strong need to allow NOMAP pages
to be swapped out because jobs aren't expected to take that long.

I could very well be missing something that is needed by Arm's blob
and not by Panfrost atm, but I don't see in kbase any mechanism for
the kernel to know when the GPU is done with a page, other than the
job that mapped it having finished.

Btw, I tested this patch locally and things seemed to work just fine.

Thanks,

Tomeu

> - when the BO is freed. This is the easiest to implement...
>
> Rob
> ___
> 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 v3 0/7] Hexdump Enhancements

[Joe Perches]

On Thu, 2019-06-20 at 11:14 +1000, Alastair D'Silva wrote:
> On Wed, 2019-06-19 at 17:35 -0700, Joe Perches wrote:
> > On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote:
> > > On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
> > > > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> > > > > From: Alastair D'Silva 
> > > > > 
> > > > > Apologies for the large CC list, it's a heads up for those
> > > > > responsible
> > > > > for subsystems where a prototype change in generic code causes
> > > > > a
> > > > > change
> > > > > in those subsystems.
> > > > > 
> > > > > This series enhances hexdump.
> > > > 
> > > > Still not a fan of these patches.
> > > 
> > > I'm afraid there's not too much action I can take on that, I'm
> > > happy to
> > > address specific issues though.
> > > 
> > > > > These improve the readability of the dumped data in certain
> > > > > situations
> > > > > (eg. wide terminals are available, many lines of empty bytes
> > > > > exist,
> > > > > etc).
> > 
> > I think it's generally overkill for the desired uses.
> 
> I understand where you're coming from, however, these patches make it a
> lot easier to work with large chucks of binary data. I think it makes
> more sense to have these patches upstream, even though committed code
> may not necessarily have all the features enabled, as it means that
> devs won't have to apply out-of-tree patches during development to make
> larger dumps manageable.
> 
> > > > Changing hexdump's last argument from bool to int is odd.
> > > > 
> > > 
> > > Think of it as replacing a single boolean with many booleans.
> > 
> > I understand it.  It's odd.
> > 
> > I would rather not have a mixture of true, false, and apparently
> > random collections of bitfields like 0xd or 0b1011 or their
> > equivalent or'd defines.
> > 
> 
> Where's the mixture? What would you propose instead?

create a hex_dump_to_buffer_ext with a new argument
and a new static inline for the old hex_dump_to_buffer
without modifying the argument list that calls
hex_dump_to_buffer with whatever added argument content
you need.

Something like:

static inline
int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
   int groupsize, char *linebuf, size_t linebuflen,
   bool ascii)
{
return hex_dump_to_buffer_ext(buf, len, rowsize, groupsize,
  linebuf, linebuflen, ascii, 0);
}

and remove EXPORT_SYMBOL(hex_dump_to_buffer)
  


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

[Bug 96838] No console/display output on front/secondary VGA

[bugzilla-daemon]

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

--- Comment #1 from Michael Silver  ---
I can confirm this on a Dell PowerEdge 2800 running Ubuntu 18.04.

-- 
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 v5 00/18] kunit: introduce KUnit, the Linux kernel unit testing framework

[Frank Rowand]

Hi Brendan,

I am only responding to this because you asked me to in the v4 thread.

Thank you for evaluating my comments in the v4 thread and asking me to
comment on v5

On 6/17/19 1:25 AM, Brendan Higgins wrote:
> ## TL;DR
> 
> A not so quick follow-up to Stephen's suggestions on PATCH v4. Nothing
> that really changes any functionality or usage with the minor exception
> of a couple public functions that Stephen asked me to rename.
> Nevertheless, a good deal of clean up and fixes. See changes below.
> 
> As for our current status, right now we got Reviewed-bys on all patches
> except:
> 
> - [PATCH v5 08/18] objtool: add kunit_try_catch_throw to the noreturn
>   list
> 
> However, it would probably be good to get reviews/acks from the
> subsystem maintainers on:
> 
> - [PATCH v5 06/18] kbuild: enable building KUnit
> - [PATCH v5 08/18] objtool: add kunit_try_catch_throw to the noreturn
>   list
> - [PATCH v5 15/18] Documentation: kunit: add documentation for KUnit
> - [PATCH v5 17/18] kernel/sysctl-test: Add null pointer test for
>   sysctl.c:proc_dointvec()
> - [PATCH v5 18/18] MAINTAINERS: add proc sysctl KUnit test to PROC
>   SYSCTL section
> 
> Other than that, I think we should be good to go.
> 
> One last thing, I updated the background to include my thoughts on KUnit
> vs. in kernel testing with kselftest in the background sections as
> suggested by Frank in the discussion on PATCH v2.
> 
> ## Background
> 
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
> 
> Unlike Autotest and kselftest, KUnit is a true unit testing framework;
> it does not require installing the kernel on a test machine or in a VM
> (however, KUnit still allows you to run tests on test machines or in VMs
> if you want[1]) and does not require tests to be written in userspace
> running on a host kernel. Additionally, KUnit is fast: From invocation
> to completion KUnit can run several dozen tests in under a second.
> Currently, the entire KUnit test suite for KUnit runs in under a second
> from the initial invocation (build time excluded).
> 
> KUnit is heavily inspired by JUnit, Python's unittest.mock, and
> Googletest/Googlemock for C++. KUnit provides facilities for defining
> unit test cases, grouping related test cases into test suites, providing
> common infrastructure for running tests, mocking, spying, and much more.
> 

I looked only at this section, as was specifically requested:

> ### But wait! Doesn't kselftest support in kernel testing?!
> 
> In a previous version of this patchset Frank pointed out that kselftest
> already supports writing a test that resides in the kernel using the
> test module feature[2]. LWN did a really great summary on this
> discussion here[3].
> 
> Kselftest has a feature that allows a test module to be loaded into a
> kernel using the kselftest framework; this does allow someone to write
> tests against kernel code not directly exposed to userland; however, it
> does not provide much of a framework around how to structure the tests.
> The kselftest test module feature just provides a header which has a
> standardized way of reporting test failures, 


> and then provides
> infrastructure to load and run the tests using the kselftest test
> harness.

The in-kernel tests can also be invoked at boot time if they are
configured (Kconfig) as in-kernel instead of as modules.  I did not
check how many of the tests have tri-state configuration to allow
this, but the few that I looked at did.

> 
> The kselftest test module does not seem to be opinionated at all in
> regards to how tests are structured, how they check for failures, how
> tests are organized. Even in the method it provides for reporting
> failures is pretty simple; it doesn't have any more advanced failure
> reporting or logging features. Given what's there, I think it is fair to
> say that it is not actually a framework, but a feature that makes it
> possible for someone to do some checks in kernel space.

I would call that description a little dismissive.  The set of in-kernel
tests that I looked like followed a common pattern and reported results
in a uniform manner.

> 
> Furthermore, kselftest test module has very few users. I checked for all
> the tests that use it using the following grep command:
> 
> grep -Hrn -e 'kselftest_module\.h'
> 
> and only got three results: lib/test_strscpy.c, lib/test_printf.c, and
> lib/test_bitmap.c.

You missed many tests.  I listed much more than that in the v4 thread, and
someone else also listed more in the v4 thread.


> 
> So despite kselftest test module's existence, there really is no feature
> overlap between kselftest and KUnit, save one: that you can use either
> to write an in-kernel test, but this is a very small feature in
> comparison to everything that KUnit allows you to do. KUnit is a full
> x-unit style unit testing framework, whereas kselftest looks a lot more
> like an end-to-end/functional testing framework, 

Re: [PATCH 2/3] drm/lima: Reduce the amount of logs on deferred probe

[Qiang Yu]

It looks like lima_clk_init will have the same problem if devm_clk_get
returns -EPROBE_DEFER.

Regards,
Qiang

On Wed, Jun 19, 2019 at 2:55 AM Krzysztof Kozlowski  wrote:
>
> There is no point to print deferred probe (and its failures to get
> resources) as an error.  For example getting a regulator causes three
> unneeded error messages:
>
> lima 1300.gpu: failed to get regulator: -517
> lima 1300.gpu: regulator init fail -517
> lima 1300.gpu: Fatal error during GPU init
>
> Also do not print clock rates before the initialization finishes
> because they will be duplicated after deferral.  Each probe step already
> prints error so remove the final error message "Fatal error during GPU
> init".
>
> In case of multiple probe tries this would pollute the dmesg.
>
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/gpu/drm/lima/lima_device.c | 17 ++---
>  drivers/gpu/drm/lima/lima_drv.c|  4 +---
>  2 files changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_device.c 
> b/drivers/gpu/drm/lima/lima_device.c
> index 570d0e93f9a9..bb2eaa4f370e 100644
> --- a/drivers/gpu/drm/lima/lima_device.c
> +++ b/drivers/gpu/drm/lima/lima_device.c
> @@ -80,7 +80,6 @@ const char *lima_ip_name(struct lima_ip *ip)
>  static int lima_clk_init(struct lima_device *dev)
>  {
> int err;
> -   unsigned long bus_rate, gpu_rate;
>
> dev->clk_bus = devm_clk_get(dev->dev, "bus");
> if (IS_ERR(dev->clk_bus)) {
> @@ -94,12 +93,6 @@ static int lima_clk_init(struct lima_device *dev)
> return PTR_ERR(dev->clk_gpu);
> }
>
> -   bus_rate = clk_get_rate(dev->clk_bus);
> -   dev_info(dev->dev, "bus rate = %lu\n", bus_rate);
> -
> -   gpu_rate = clk_get_rate(dev->clk_gpu);
> -   dev_info(dev->dev, "mod rate = %lu", gpu_rate);
> -
> err = clk_prepare_enable(dev->clk_bus);
> if (err)
> return err;
> @@ -145,7 +138,8 @@ static int lima_regulator_init(struct lima_device *dev)
> dev->regulator = NULL;
> if (ret == -ENODEV)
> return 0;
> -   dev_err(dev->dev, "failed to get regulator: %d\n", ret);
> +   if (ret != -EPROBE_DEFER)
> +   dev_err(dev->dev, "failed to get regulator: %d\n", 
> ret);
> return ret;
> }
>
> @@ -297,10 +291,8 @@ int lima_device_init(struct lima_device *ldev)
> }
>
> err = lima_regulator_init(ldev);
> -   if (err) {
> -   dev_err(ldev->dev, "regulator init fail %d\n", err);
> +   if (err)
> goto err_out0;
> -   }
>
> ldev->empty_vm = lima_vm_create(ldev);
> if (!ldev->empty_vm) {
> @@ -343,6 +335,9 @@ int lima_device_init(struct lima_device *ldev)
> if (err)
> goto err_out5;
>
> +   dev_info(ldev->dev, "bus rate = %lu\n", clk_get_rate(ldev->clk_bus));
> +   dev_info(ldev->dev, "mod rate = %lu", clk_get_rate(ldev->clk_gpu));
> +
> return 0;
>
>  err_out5:
> diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
> index b29c26cd13b2..cebc44592e47 100644
> --- a/drivers/gpu/drm/lima/lima_drv.c
> +++ b/drivers/gpu/drm/lima/lima_drv.c
> @@ -307,10 +307,8 @@ static int lima_pdev_probe(struct platform_device *pdev)
> ldev->ddev = ddev;
>
> err = lima_device_init(ldev);
> -   if (err) {
> -   dev_err(>dev, "Fatal error during GPU init\n");
> +   if (err)
> goto err_out1;
> -   }
>
> /*
>  * Register the DRM device with the core and the connectors with
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/lima: Mark 64-bit number as ULL to silence Smatch warning

[Qiang Yu]

Looks good for me, patch is:
Reviewed-by: Qiang Yu 

I'll apply it to drm-misc-next.

Regards,
Qiang

On Wed, Jun 19, 2019 at 2:55 AM Krzysztof Kozlowski  wrote:
>
> Mark long numbers with ULL to silence the Smatch warning:
>
> drivers/gpu/drm/lima/lima_device.c:314:32: warning: constant 0x1 
> is so big it is long long
>
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/gpu/drm/lima/lima_vm.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_vm.h b/drivers/gpu/drm/lima/lima_vm.h
> index caee2f8a29b4..e0bdedcf14dd 100644
> --- a/drivers/gpu/drm/lima/lima_vm.h
> +++ b/drivers/gpu/drm/lima/lima_vm.h
> @@ -15,9 +15,9 @@
>  #define LIMA_VM_NUM_PT_PER_BT (1 << LIMA_VM_NUM_PT_PER_BT_SHIFT)
>  #define LIMA_VM_NUM_BT (LIMA_PAGE_ENT_NUM >> LIMA_VM_NUM_PT_PER_BT_SHIFT)
>
> -#define LIMA_VA_RESERVE_START  0xFFF0
> +#define LIMA_VA_RESERVE_START  0x0FFF0ULL
>  #define LIMA_VA_RESERVE_DLBU   LIMA_VA_RESERVE_START
> -#define LIMA_VA_RESERVE_END0x1
> +#define LIMA_VA_RESERVE_END0x1ULL
>
>  struct lima_device;
>
> --
> 2.17.1
>

Re: [PATCH v3 0/7] Hexdump Enhancements

[Joe Perches]

On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote:
> On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
> > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> > > From: Alastair D'Silva 
> > > 
> > > Apologies for the large CC list, it's a heads up for those
> > > responsible
> > > for subsystems where a prototype change in generic code causes a
> > > change
> > > in those subsystems.
> > > 
> > > This series enhances hexdump.
> > 
> > Still not a fan of these patches.
> 
> I'm afraid there's not too much action I can take on that, I'm happy to
> address specific issues though.
> 
> > > These improve the readability of the dumped data in certain
> > > situations
> > > (eg. wide terminals are available, many lines of empty bytes exist,
> > > etc).

I think it's generally overkill for the desired uses.

> > Changing hexdump's last argument from bool to int is odd.
> > 
> 
> Think of it as replacing a single boolean with many booleans.

I understand it.  It's odd.

I would rather not have a mixture of true, false, and apparently
random collections of bitfields like 0xd or 0b1011 or their
equivalent or'd defines.


> There's only a handful of consumers, I don't think there is a value-add 
> in creating more wrappers vs updating the existing callers.

Perhaps more reason not to modify the existing api.


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

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

[Stephen Boyd]

Quoting Brendan Higgins (2019-06-17 01:25:56)
> diff --git a/kunit/test.c b/kunit/test.c
> new file mode 100644
> index 0..d05d254f1521f
> --- /dev/null
> +++ b/kunit/test.c
> @@ -0,0 +1,210 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Base unit test (KUnit) API.
> + *
> + * Copyright (C) 2019, Google LLC.
> + * Author: Brendan Higgins 
> + */
> +
> +#include 
> +#include 
> +
> +static bool kunit_get_success(struct kunit *test)
> +{
> +   unsigned long flags;
> +   bool success;
> +
> +   spin_lock_irqsave(>lock, flags);
> +   success = test->success;
> +   spin_unlock_irqrestore(>lock, flags);

I still don't understand the locking scheme in this code. Is the
intention to make getter and setter APIs that are "safe" by adding in a
spinlock that is held around getting and setting various members in the
kunit structure?

In what situation is there more than one thread reading or writing the
kunit struct? Isn't it only a single process that is going to be
operating on this structure? And why do we need to disable irqs? Are we
expecting to be modifying the unit tests from irq contexts?

> +
> +   return success;
> +}
> +
> +static void kunit_set_success(struct kunit *test, bool success)
> +{
> +   unsigned long flags;
> +
> +   spin_lock_irqsave(>lock, flags);
> +   test->success = success;
> +   spin_unlock_irqrestore(>lock, flags);
> +}
> +
> +static int kunit_vprintk_emit(int level, const char *fmt, va_list args)
> +{
> +   return vprintk_emit(0, level, NULL, 0, fmt, args);
> +}
> +
> +static int kunit_printk_emit(int level, const char *fmt, ...)
> +{
> +   va_list args;
> +   int ret;
> +
> +   va_start(args, fmt);
> +   ret = kunit_vprintk_emit(level, fmt, args);
> +   va_end(args);
> +
> +   return ret;
> +}
> +
> +static void kunit_vprintk(const struct kunit *test,
> + const char *level,
> + struct va_format *vaf)
> +{
> +   kunit_printk_emit(level[1] - '0', "\t# %s: %pV", test->name, vaf);
> +}
> +
> +static bool kunit_has_printed_tap_version;

Can you please move this into function local scope in the function
below?

> +
> +static void kunit_print_tap_version(void)
> +{
> +   if (!kunit_has_printed_tap_version) {
> +   kunit_printk_emit(LOGLEVEL_INFO, "TAP version 14\n");
> +   kunit_has_printed_tap_version = true;
> +   }
> +}
> +
[...]
> +
> +static bool kunit_module_has_succeeded(struct kunit_module *module)
> +{
> +   const struct kunit_case *test_case;
> +   bool success = true;
> +
> +   for (test_case = module->test_cases; test_case->run_case; test_case++)
> +   if (!test_case->success) {
> +   success = false;
> +   break;

Why not 'return false'?

> +   }
> +
> +   return success;

And 'return true'?

> +}
> +
> +static size_t kunit_module_counter = 1;
> +
> +static void kunit_print_subtest_end(struct kunit_module *module)
> +{
> +   kunit_print_ok_not_ok(false,
> + kunit_module_has_succeeded(module),
> + kunit_module_counter++,
> + module->name);
> +}
> +
> +static void kunit_print_test_case_ok_not_ok(struct kunit_case *test_case,
> +   size_t test_number)
> +{
> +   kunit_print_ok_not_ok(true,
> + test_case->success,
> + test_number,
> + test_case->name);
> +}
> +
> +void kunit_init_test(struct kunit *test, const char *name)
> +{
> +   spin_lock_init(>lock);
> +   test->name = name;
> +   test->success = true;
> +}
> +
> +/*
> + * Performs all logic to run a test case.
> + */
> +static void kunit_run_case(struct kunit_module *module,
> +  struct kunit_case *test_case)
> +{
> +   struct kunit test;
> +   int ret = 0;
> +
> +   kunit_init_test(, test_case->name);
> +
> +   if (module->init) {
> +   ret = module->init();
> +   if (ret) {
> +   kunit_err(, "failed to initialize: %d\n", ret);
> +   kunit_set_success(, false);
> +   return;
> +   }
> +   }
> +
> +   if (!ret)
> +   test_case->run_case();

Do we need this if condition? ret can only be set to non-zero above but
then we'll exit the function early so it seems unnecessary. Given that,
ret should probably be moved into the module->init path.

> +
> +   if (module->exit)
> +   module->exit();
> +
> +   test_case->success = kunit_get_success();
> +}
> +

[PATCH] drm/nouveau/kms/gf119-: allow both 256- and 1024-sized LUTs to be used

[Ilia Mirkin]

The hardware supports either size. Also add checks to ensure that only
these two sizes may be used for supplying a LUT.

Finally, experimental evidence suggests you can't mix sizes for degamma
and gamma. Disallow this as well.

Signed-off-by: Ilia Mirkin 
---

Note that all the gv100+ changes are purely speculative.

Tested on a GK208 with 8- and 10-bpc formats (but still 8bpc output).

This is on top of the patches which I've sent in the past. You'll end up
with some conflicts, I suspect, but I can't rebase easily on your changes
since they're not in a linux tree.

 drivers/gpu/drm/nouveau/dispnv50/base907c.c |  4 ++--
 drivers/gpu/drm/nouveau/dispnv50/corec57d.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/head.c | 26 +
 drivers/gpu/drm/nouveau/dispnv50/head.h | 10 +---
 drivers/gpu/drm/nouveau/dispnv50/head507d.c | 10 +++-
 drivers/gpu/drm/nouveau/dispnv50/head827d.c |  2 ++
 drivers/gpu/drm/nouveau/dispnv50/head907d.c | 12 --
 drivers/gpu/drm/nouveau/dispnv50/head917d.c |  2 ++
 drivers/gpu/drm/nouveau/dispnv50/headc37d.c |  6 +++--
 drivers/gpu/drm/nouveau/dispnv50/headc57d.c |  9 +++
 drivers/gpu/drm/nouveau/dispnv50/lut.c  |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/wndw.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/wndw.h |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c |  4 ++--
 drivers/gpu/drm/nouveau/dispnv50/wndwc57e.c |  3 +--
 15 files changed, 70 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/base907c.c 
b/drivers/gpu/drm/nouveau/dispnv50/base907c.c
index fd0c1d84730b..76db448205d2 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/base907c.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/base907c.c
@@ -76,9 +76,9 @@ base907c_xlut_set(struct nv50_wndw *wndw, struct 
nv50_wndw_atom *asyw)
 }
 
 static void
-base907c_ilut(struct nv50_wndw *wndw, struct nv50_wndw_atom *asyw)
+base907c_ilut(struct nv50_wndw *wndw, struct nv50_wndw_atom *asyw, int size)
 {
-   asyw->xlut.i.mode = 7;
+   asyw->xlut.i.mode = size == 1024 ? 4 : 7;
asyw->xlut.i.enable = 2;
asyw->xlut.i.load = head907d_olut_load;
 }
diff --git a/drivers/gpu/drm/nouveau/dispnv50/corec57d.c 
b/drivers/gpu/drm/nouveau/dispnv50/corec57d.c
index b606d68cda10..700df4762b6d 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/corec57d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/corec57d.c
@@ -36,7 +36,7 @@ corec57d_init(struct nv50_core *core)
evo_data(push, 0x000f);
evo_data(push, 0x);
evo_mthd(push, 0x1010 + (i * 0x080), 1);
-   evo_data(push, 0x00117fff);
+   evo_data(push, 0x00127fff);
}
evo_mthd(push, 0x0200, 1);
evo_data(push, 0x0001);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c 
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index 8cac8b724b70..407c91bd09b9 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -193,7 +193,23 @@ nv50_head_atomic_check_lut(struct nv50_head *head,
   struct nv50_head_atom *asyh)
 {
struct nv50_disp *disp = nv50_disp(head->base.base.dev);
+   struct drm_property_blob *ilut = asyh->state.degamma_lut;
struct drm_property_blob *olut = asyh->state.gamma_lut;
+   int ilut_size = ilut ? drm_color_lut_size(ilut) : 0;
+   int olut_size = olut ? drm_color_lut_size(olut) : 0;
+
+   if (!head->func->lut_chk(ilut_size)) {
+   DRM_DEBUG_KMS("Invalid DEGAMMA_LUT size: %d\n", ilut_size);
+   return -EINVAL;
+   }
+   if (!head->func->lut_chk(olut_size)) {
+   DRM_DEBUG_KMS("Invalid GAMMA_LUT size: %d\n", olut_size);
+   return -EINVAL;
+   }
+   if (ilut && olut && ilut_size != olut_size) {
+   DRM_DEBUG_KMS("DEGAMMA_LUT size (%d) must match GAMMA_LUT size 
(%d)\n",
+ ilut_size, olut_size);
+   }
 
/* Determine whether core output LUT should be enabled. */
if (olut) {
@@ -217,7 +233,7 @@ nv50_head_atomic_check_lut(struct nv50_head *head,
 
asyh->olut.handle = disp->core->chan.vram.handle;
asyh->olut.buffer = !asyh->olut.buffer;
-   head->func->olut(head, asyh);
+   head->func->olut(head, asyh, olut_size);
return 0;
 }
 
@@ -491,12 +507,14 @@ nv50_head_create(struct drm_device *dev, int index)
drm_crtc_init_with_planes(dev, crtc, >plane, >plane,
  _head_func, "head-%d", head->base.index);
drm_crtc_helper_add(crtc, _head_help);
-   drm_mode_crtc_set_gamma_size(crtc, 256);
+   drm_mode_crtc_set_gamma_size(crtc, head->func->lut_size);
if (disp->disp->object.oclass >= GF110_DISP &&
disp->disp->object.oclass < GV100_DISP)
-   drm_crtc_enable_color_mgmt(crtc, 256, true, 256);
+   

[RFC PATCH 1/4] dt-bindings: display: Convert common panel bindings to DT schema

[Rob Herring]

Convert the common panel bindings to DT schema consolidating scattered
definitions to a single schema file.

The 'simple-panel' binding just a collection of properties and not a
complete binding itself. All of the 'simple-panel' properties are
covered by the panel-common.txt binding with the exception of the
'no-hpd' property, so add that to the schema.

As there are lots of references to simple-panel.txt, just keep the file
with a reference to panel-common.yaml for now until all the bindings are
converted.

Cc: Thierry Reding 
Cc: Sam Ravnborg 
Cc: Maxime Ripard 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring 
---
Note there's still some references to panel-common.txt that I need to 
update or just go ahead and convert to schema.

 .../bindings/display/panel/panel-common.txt   | 101 -
 .../bindings/display/panel/panel-common.yaml  | 143 ++
 .../bindings/display/panel/panel.txt  |   4 -
 .../bindings/display/panel/simple-panel.txt   |  29 +---
 4 files changed, 144 insertions(+), 133 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/panel-common.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/panel-common.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/panel/panel.txt

diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt 
b/Documentation/devicetree/bindings/display/panel/panel-common.txt
deleted file mode 100644
index 5d2519af4bb5..
--- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
+++ /dev/null
@@ -1,101 +0,0 @@
-Common Properties for Display Panel
-===
-
-This document defines device tree properties common to several classes of
-display panels. It doesn't constitue a device tree binding specification by
-itself but is meant to be referenced by device tree bindings.
-
-When referenced from panel device tree bindings the properties defined in this
-document are defined as follows. The panel device tree bindings are
-responsible for defining whether each property is required or optional.
-
-
-Descriptive Properties
---
-
-- width-mm,
-- height-mm: The width-mm and height-mm specify the width and height of the
-  physical area where images are displayed. These properties are expressed in
-  millimeters and rounded to the closest unit.
-
-- label: The label property specifies a symbolic name for the panel as a
-  string suitable for use by humans. It typically contains a name inscribed on
-  the system (e.g. as an affixed label) or specified in the system's
-  documentation (e.g. in the user's manual).
-
-  If no such name exists, and unless the property is mandatory according to
-  device tree bindings, it shall rather be omitted than constructed of
-  non-descriptive information. For instance an LCD panel in a system that
-  contains a single panel shall not be labelled "LCD" if that name is not
-  inscribed on the system or used in a descriptive fashion in system
-  documentation.
-
-
-Display Timings

-
-- panel-timing: Most display panels are restricted to a single resolution and
-  require specific display timings. The panel-timing subnode expresses those
-  timings as specified in the timing subnode section of the display timing
-  bindings defined in
-  Documentation/devicetree/bindings/display/panel/display-timing.txt.
-
-
-Connectivity
-
-
-- ports: Panels receive video data through one or multiple connections. While
-  the nature of those connections is specific to the panel type, the
-  connectivity is expressed in a standard fashion using ports as specified in
-  the device graph bindings defined in
-  Documentation/devicetree/bindings/graph.txt.
-
-- ddc-i2c-bus: Some panels expose EDID information through an I2C-compatible
-  bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a
-  phandle to the system I2C controller connected to that bus.
-
-
-Control I/Os
-
-
-Many display panels can be controlled through pins driven by GPIOs. The nature
-and timing of those control signals are device-specific and left for panel
-device tree bindings to specify. The following GPIO specifiers can however be
-used for panels that implement compatible control signals.
-
-- enable-gpios: Specifier for a GPIO connected to the panel enable control
-  signal. The enable signal is active high and enables operation of the panel.
-  This property can also be used for panels implementing an active low power
-  down signal, which is a negated version of the enable signal. Active low
-  enable signals (or active high power down signals) can be supported by
-  inverting the GPIO specifier polarity flag.
-
-  Note that the enable signal control panel operation only and must not be
-  confused with a backlight enable signal.
-
-- reset-gpios: Specifier for a GPIO coonnected to the panel reset control
-  signal. 

[RFC PATCH 2/4] dt-bindings: display: Convert ampire, am-480272h3tmqw-t01h panel to DT schema

[Rob Herring]

Convert the ampire,am-480272h3tmqw-t01h panel binding to DT schema.

Cc: Thierry Reding 
Cc: Sam Ravnborg 
Cc: Maxime Ripard 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring 
---
 .../panel/ampire,am-480272h3tmqw-t01h.txt | 26 
 .../panel/ampire,am-480272h3tmqw-t01h.yaml| 41 +++
 2 files changed, 41 insertions(+), 26 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
 
b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
deleted file mode 100644
index 6812280cb109..
--- 
a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
-
-This binding is compatible with the simple-panel binding, which is specified
-in simple-panel.txt in this directory.
-
-Required properties:
-- compatible: should be "ampire,am-480272h3tmqw-t01h"
-
-Optional properties:
-- power-supply: regulator to provide the supply voltage
-- enable-gpios: GPIO pin to enable or disable the panel
-- backlight: phandle of the backlight device attached to the panel
-
-Optional nodes:
-- Video port for RGB input.
-
-Example:
-   panel_rgb: panel-rgb {
-   compatible = "ampire,am-480272h3tmqw-t01h";
-   enable-gpios = < 8 1>;
-   port {
-   panel_in_rgb: endpoint {
-   remote-endpoint = <_out_rgb>;
-   };
-   };
-   };
diff --git 
a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
 
b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
new file mode 100644
index ..cc2f6ec6ebf6
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/display/panel/ampire,am-480272h3tmqw-t01h.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
+
+maintainers:
+  - Thierry Reding 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+const: ampire,am-480272h3tmqw-t01h
+
+  power-supply: true
+  enable-gpios: true
+  backlight: true
+  port: true
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+panel_rgb: panel {
+  compatible = "ampire,am-480272h3tmqw-t01h";
+  enable-gpios = < 8 1>;
+  port {
+panel_in_rgb: endpoint {
+  remote-endpoint = <_out_rgb>;
+};
+  };
+};
+
+...
-- 
2.20.1

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

[RFC PATCH 3/4] dt-bindings: display: Convert panel-lvds to DT schema

[Rob Herring]

Convert the panel-lvds binding to use DT schema. The panel-lvds schema
inherits from the panel-common.yaml schema and specific LVDS panel
bindings should inherit from this schema.

Cc: Thierry Reding 
Cc: Sam Ravnborg 
Cc: Maxime Ripard 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring 
---
 .../bindings/display/panel/panel-lvds.txt | 121 --
 .../bindings/display/panel/panel-lvds.yaml| 107 
 2 files changed, 107 insertions(+), 121 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/panel-lvds.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/panel-lvds.yaml

diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt 
b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
deleted file mode 100644
index 250850a2150b..
--- a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
+++ /dev/null
@@ -1,121 +0,0 @@
-LVDS Display Panel
-==
-
-LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
-incompatible data link layers have been used over time to transmit image data
-to LVDS panels. This bindings supports display panels compatible with the
-following specifications.
-
-[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
-1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
-[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
-Semiconductor
-[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
-Electronics Standards Association (VESA)
-
-Device compatible with those specifications have been marketed under the
-FPD-Link and FlatLink brands.
-
-
-Required properties:
-
-- compatible: Shall contain "panel-lvds" in addition to a mandatory
-  panel-specific compatible string defined in individual panel bindings. The
-  "panel-lvds" value shall never be used on its own.
-- width-mm: See panel-common.txt.
-- height-mm: See panel-common.txt.
-- data-mapping: The color signals mapping order, "jeida-18", "jeida-24"
-  or "vesa-24".
-
-Optional properties:
-
-- label: See panel-common.txt.
-- gpios: See panel-common.txt.
-- backlight: See panel-common.txt.
-- power-supply: See panel-common.txt.
-- data-mirror: If set, reverse the bit order described in the data mappings
-  below on all data lanes, transmitting bits for slots 6 to 0 instead of
-  0 to 6.
-
-Required nodes:
-
-- panel-timing: See panel-common.txt.
-- ports: See panel-common.txt. These bindings require a single port subnode
-  corresponding to the panel LVDS input.
-
-
-LVDS data mappings are defined as follows.
-
-- "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
-  [VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
-
-Slot   0   1   2   3   4   5   6
-    _
-Clock  \___/
- __  __  __  __  __  __  __
-DATA0  ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
-DATA1  ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
-DATA2  ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
-
-- "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
-  specifications. Data are transferred as follows on 4 LVDS lanes.
-
-Slot   0   1   2   3   4   5   6
-    _
-Clock  \___/
- __  __  __  __  __  __  __
-DATA0  ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
-DATA1  ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
-DATA2  ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
-DATA3  ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
-
-- "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
-  Data are transferred as follows on 4 LVDS lanes.
-
-Slot   0   1   2   3   4   5   6
-    _
-Clock  \___/
- __  __  __  __  __  __  __
-DATA0  ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
-DATA1  ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
-DATA2  ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
-DATA3  ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
-
-Control signals are mapped as follows.
-
-CTL0: HSync
-CTL1: VSync
-CTL2: Data Enable
-CTL3: 0
-
-
-Example

-
-panel {
-   compatible = "mitsubishi,aa121td01", "panel-lvds";
-
-   width-mm = <261>;
-   height-mm = <163>;
-
-   data-mapping = "jeida-24";
-
-   panel-timing {
-   /* 1280x800 @60Hz */
-   clock-frequency = 

[RFC PATCH 4/4] dt-bindings: display: Convert innolux,ee101ia-01 panel to DT schema

[Rob Herring]

Convert the innolux,ee101ia-01 LVDS panel binding to DT schema.

Cc: Thierry Reding 
Cc: Sam Ravnborg 
Cc: Maxime Ripard 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring 
---
 .../display/panel/innolux,ee101ia-01d.txt |  7 ---
 .../display/panel/innolux,ee101ia-01d.yaml| 21 +++
 2 files changed, 21 insertions(+), 7 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt
deleted file mode 100644
index e5ca4ccd55ed..
--- a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt
+++ /dev/null
@@ -1,7 +0,0 @@
-Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel
-
-Required properties:
-- compatible: should be "innolux,ee101ia-01d"
-
-This binding is compatible with the lvds-panel binding, which is specified
-in panel-lvds.txt in this directory.
diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml 
b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
new file mode 100644
index ..53d0e9c6169f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/innolux,ee101ia-01d.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel
+
+maintainers:
+  - Thierry Reding 
+
+allOf:
+  - $ref: panel-lvds.yaml#
+
+properties:
+  compatible:
+items:
+  - const: innolux,ee101ia-01d
+  - {} # panel-lvds, but not listed here to avoid false select
+
+...
-- 
2.20.1

Re: [PATCH] drm/bridge: dw-hdmi: Use automatic CTS generation mode when using non-AHB audio

[Doug Anderson]

Hi,

On Wed, Jun 12, 2019 at 1:51 AM Neil Armstrong  wrote:
>
> When using an I2S source using a different clock source (usually the I2S
> audio HW uses dedicated PLLs, different from the HDMI PHY PLL), fixed
> CTS values will cause some frequent audio drop-out and glitches as
> reported on Amlogic, Allwinner and Rockchip SoCs setups.
>
> Setting the CTS in automatic mode will let the HDMI controller generate
> automatically the CTS value to match the input audio clock.
>
> The DesignWare DW-HDMI User Guide explains:
>   For Automatic CTS generation
>   Write "0" on the bit field "CTS_manual", Register 0x3205: AUD_CTS3
>
> The DesignWare DW-HDMI Databook explains :
>   If "CTS_manual" bit equals 0b this registers contains "audCTS[19:0]"
>   generated by the Cycle time counter according to specified timing.
>
> Cc: Jernej Skrabec 
> Cc: Maxime Ripard 
> Cc: Jonas Karlman 
> Cc: Heiko Stuebner 
> Cc: Jerome Brunet 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44 +++
>  1 file changed, 29 insertions(+), 15 deletions(-)

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

Re: [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail

[Daniel Vetter]

On Wed, Jun 19, 2019 at 10:42 PM Jason Gunthorpe  wrote:
>
> On Wed, Jun 19, 2019 at 10:18:43PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 19, 2019 at 10:13 PM Jason Gunthorpe  wrote:
> > > On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> > > > On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe  wrote:
> > > > > On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> > > > > > On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> > > > > > > On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> > > > > > > > Just a bit of paranoia, since if we start pushing this deep into
> > > > > > > > callchains it's hard to spot all places where an mmu notifier
> > > > > > > > implementation might fail when it's not allowed to.
> > > > > > > >
> > > > > > > > Inspired by some confusion we had discussing i915 mmu notifiers 
> > > > > > > > and
> > > > > > > > whether we could use the newly-introduced return value to 
> > > > > > > > handle some
> > > > > > > > corner cases. Until we realized that these are only for when a 
> > > > > > > > task
> > > > > > > > has been killed by the oom reaper.
> > > > > > > >
> > > > > > > > An alternative approach would be to split the callback into two
> > > > > > > > versions, one with the int return value, and the other with void
> > > > > > > > return value like in older kernels. But that's a lot more churn 
> > > > > > > > for
> > > > > > > > fairly little gain I think.
> > > > > > > >
> > > > > > > > Summary from the m-l discussion on why we want something at 
> > > > > > > > warning
> > > > > > > > level: This allows automated tooling in CI to catch bugs without
> > > > > > > > humans having to look at everything. If we just upgrade the 
> > > > > > > > existing
> > > > > > > > pr_info to a pr_warn, then we'll have false positives. And 
> > > > > > > > as-is, no
> > > > > > > > one will ever spot the problem since it's lost in the massive 
> > > > > > > > amounts
> > > > > > > > of overall dmesg noise.
> > > > > > > >
> > > > > > > > v2: Drop the full WARN_ON backtrace in favour of just a pr_warn 
> > > > > > > > for
> > > > > > > > the problematic case (Michal Hocko).
> > > > >
> > > > > I disagree with this v2 note, the WARN_ON/WARN will trigger checkers
> > > > > like syzkaller to report a bug, while a random pr_warn probably will
> > > > > not.
> > > > >
> > > > > I do agree the backtrace is not useful here, but we don't have a
> > > > > warn-no-backtrace version..
> > > > >
> > > > > IMHO, kernel/driver bugs should always be reported by WARN &
> > > > > friends. We never expect to see the print, so why do we care how big
> > > > > it is?
> > > > >
> > > > > Also note that WARN integrates an unlikely() into it so the codegen is
> > > > > automatically a bit more optimal that the if & pr_warn combination.
> > > >
> > > > Where do you make a difference between a WARN without backtrace and a
> > > > pr_warn? They're both dumped at the same log-level ...
> > >
> > > WARN panics the kernel when you set
> > >
> > > /proc/sys/kernel/panic_on_warn
> > >
> > > So auto testing tools can set that and get a clean detection that the
> > > kernel has failed the test in some way.
> > >
> > > Otherwise you are left with frail/ugly grepping of dmesg.
> >
> > Hm right.
> >
> > Anyway, I'm happy to repaint the bikeshed in any color that's desired,
> > if that helps with landing it. WARN_WITHOUT_BACKTRACE might take a bit
> > longer (need to find a bit of time, plus it'll definitely attract more
> > comments).
>
> I was actually just writing something very similar when looking at the
> hmm things..
>
> Also, is the test backwards?

Yes, in the last rebase I screwed things up :-/
-Daniel

> mmu_notifier_range_blockable() == true means the callback must return
> zero
>
> mmu_notififer_range_blockable() == false means the callback can return
> 0 or -EAGAIN.
>
> Suggest this:
>
> pr_info("%pS callback failed with %d in 
> %sblockable context.\n",
> mn->ops->invalidate_range_start, _ret,
> !mmu_notifier_range_blockable(range) 
> ? "non-" : "");
> +   WARN_ON(mmu_notifier_range_blockable(range) ||
> +   _ret != -EAGAIN);
> ret = _ret;
> }
> }
>
> To express the API invariant.
>
> Jason



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

Re: [PATCH] drm/bridge/synopsys: dw-hdmi: Handle audio for more clock rates

[Doug Anderson]

Hi,

On Wed, Jun 19, 2019 at 8:23 AM Neil Armstrong  wrote:
>
> On 18/06/2019 19:23, Jernej Škrabec wrote:
> > Hi!
> >
> > Dne torek, 18. junij 2019 ob 01:55:58 CEST je Douglas Anderson napisal(a):
> >> Let's add some better support for HDMI audio to dw_hdmi.
> >> Specifically:
> >>
> >> 1. For 44.1 kHz audio the old code made the assumption that an N of
> >> 6272 was right most of the time.  That wasn't true and the new table
> >> should give better 44.1 kHz audio for many more rates.
> >>
> >> 2. The new table has values from the HDMI spec for 297 MHz and 594
> >> MHz.
> >>
> >> 3. There is now code to try to come up with a more idea N/CTS for
> >> clock rates that aren't in the table.  This code is a bit slow because
> >> it iterates over every possible value of N and picks the best one, but
> >> it should make a good fallback.
> >>
> >> 4. The new code allows for platforms that know they make a clock rate
> >> slightly differently to pick different N/CTS values.  For instance on
> >> rk3288 we can make 25,176,471 Hz instead of 25,174,825.1748... Hz
> >> (25.2 MHz / 1.001).  A future patch to the rk3288 platform code could
> >> enable support for this clock rate and specify the N/CTS that would be
> >> ideal.
> >>
> >> NOTE: the oddest part of this patch comes about because computing the
> >> ideal N/CTS means knowing the _exact_ clock rate, not a rounded
> >> version of it.  The drm framework makes this harder by rounding rates
> >> to kHz, but even if it didn't there might be cases where the ideal
> >> rate could only be calculated if we knew the real (non-integral) rate.
> >> This means that in cases where we know (or believe) that the true rate
> >> is something other than the rate we are told by drm.
> >>
> >> Signed-off-by: Douglas Anderson 
> >
> > Which bus is used for audio transfer on your device? If it is I2S, which is
> > commonly used, then please be aware of this patch:
> > https://lists.freedesktop.org/archives/dri-devel/2019-June/221539.html
> >
> > It avoids exact N/CTS calculation by enabling auto detection. It is well
> > tested on multiple SoCs from Allwinner, Amlogic and Rockchip.
> >
> > Best regards,
> > Jernej
> >
> >
> Hi Douglas,
>
> Thanks for your work !
>
> If you could rebase on top of 
> https://lists.freedesktop.org/archives/dri-devel/2019-June/221539.html
> so we can make use of your extended N table with automatic CTS HW 
> calculation, it would be great !

Thanks to you and Jernej for pointing me at this.  It seems likely
that patch by itself would solve problems we found and I'll pick that
into my tree.

Probably my patch is no longer quite as useful atop yours, but I'll
still post a v2 since (in theory) folks that aren't using I2S might
find it useful.  I guess it's also possible (?) that picking an N
where CTS would be able to be integral has some type of advantage,
even with auto CTS?


> Finally could you add the plat_data tmds table as a separate patch to 
> simplify review ?

Sure.  I'm probably not going to be able to post the patch to actually
use it, so I guess we could just not bother applying the 2nd patch
unless someone ever needs it.

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

[PATCH v2 2/2] drm/bridge/synopsys: dw-hdmi: Allow platforms to provide custom audio tables

[Douglas Anderson]

On some platforms using dw_hdmi it may not be possible to make an HDMI
pixel clock exactly, but it may be possible to make a rate that is
close enough to be within spec.  For instance on rk3288 we can make
25,176,471 Hz instead of 25,174,825.1748... Hz (25.2 MHz / 1.001).  A
future patch to the rk3288 platform code could enable support for this
clock rate and specify the N/CTS that would be ideal.

NOTE: I haven't yet posted said patch due to complexities with knowing
whether dw_hdmi can control the dynamic PLL on rk3288.  Thus for now
there are no users of this feature yet.

Signed-off-by: Douglas Anderson 
---

Changes in v2:
- Split out the ability of a platform to provide custom tables.

 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 27 ++-
 include/drm/bridge/dw_hdmi.h  |  8 +++
 2 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7cdffebcc7cb..b6027edf2942 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -60,13 +60,6 @@ enum hdmi_datamap {
YCbCr422_12B = 0x12,
 };
 
-struct dw_hdmi_audio_tmds_n {
-   unsigned long tmds;
-   unsigned int n_32k;
-   unsigned int n_44k1;
-   unsigned int n_48k;
-};
-
 /*
  * Unless otherwise noted, entries in this table are 100% optimization.
  * Values can be obtained from hdmi_compute_n() but that function is
@@ -603,6 +596,7 @@ static void hdmi_set_cts_n(struct dw_hdmi *hdmi, unsigned 
int cts,
 static int hdmi_match_tmds_n_table(struct dw_hdmi *hdmi, unsigned int freq,
   unsigned long pixel_clk)
 {
+   const struct dw_hdmi_plat_data *plat_data = hdmi->plat_data;
const struct dw_hdmi_audio_tmds_n *tmds_n = NULL;
int mult = 1;
int i;
@@ -612,10 +606,21 @@ static int hdmi_match_tmds_n_table(struct dw_hdmi *hdmi, 
unsigned int freq,
freq /= 2;
}
 
-   for (i = 0; common_tmds_n_table[i].tmds != 0; i++) {
-   if (pixel_clk == common_tmds_n_table[i].tmds) {
-   tmds_n = _tmds_n_table[i];
-   break;
+   if (plat_data->tmds_n_table) {
+   for (i = 0; plat_data->tmds_n_table[i].tmds != 0; i++) {
+   if (pixel_clk == plat_data->tmds_n_table[i].tmds) {
+   tmds_n = _data->tmds_n_table[i];
+   break;
+   }
+   }
+   }
+
+   if (tmds_n == NULL) {
+   for (i = 0; common_tmds_n_table[i].tmds != 0; i++) {
+   if (pixel_clk == common_tmds_n_table[i].tmds) {
+   tmds_n = _tmds_n_table[i];
+   break;
+   }
}
}
 
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index c402364aec0d..5ee6b0a127aa 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -90,6 +90,13 @@ enum dw_hdmi_phy_type {
DW_HDMI_PHY_VENDOR_PHY = 0xfe,
 };
 
+struct dw_hdmi_audio_tmds_n {
+   unsigned long tmds;
+   unsigned int n_32k;
+   unsigned int n_44k1;
+   unsigned int n_48k;
+};
+
 struct dw_hdmi_mpll_config {
unsigned long mpixelclock;
struct {
@@ -137,6 +144,7 @@ struct dw_hdmi_plat_data {
const struct dw_hdmi_mpll_config *mpll_cfg;
const struct dw_hdmi_curr_ctrl *cur_ctr;
const struct dw_hdmi_phy_config *phy_config;
+   const struct dw_hdmi_audio_tmds_n *tmds_n_table;
int (*configure_phy)(struct dw_hdmi *hdmi,
 const struct dw_hdmi_plat_data *pdata,
 unsigned long mpixelclock);
-- 
2.22.0.410.gd8fdbe21b5-goog

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

[PATCH v2 1/2] drm/bridge/synopsys: dw-hdmi: Handle audio for more clock rates

[Douglas Anderson]

Let's add some better support for HDMI audio to dw_hdmi.
Specifically:

1. For 44.1 kHz audio the old code made the assumption that an N of
6272 was right most of the time.  That wasn't true and the new table
should pick a more ideal value.

2. The new table has values from the HDMI spec for 297 MHz and 594
MHz.

3. There is now code to try to come up with a more idea N/CTS for
clock rates that aren't in the table.  This code is a bit slow because
it iterates over every possible value of N and picks the best one, but
it should make a good fallback.

NOTES:
- The oddest part of this patch comes about because computing the
  ideal N/CTS means knowing the _exact_ clock rate, not a rounded
  version of it.  The drm framework makes this harder by rounding
  rates to kHz, but even if it didn't there might be cases where the
  ideal rate could only be calculated if we knew the real
  (non-integral) rate.  This means that in cases where we know (or
  believe) that the true rate is something other than the rate we are
  told by drm.
- This patch makes much less of a difference after the patch
  ("drm/bridge: dw-hdmi: Use automatic CTS generation mode when using
  non-AHB audio"), at least if you're using I2S audio.  The main goal
  of picking a good N is to make it possible to get a nice integral
  CTS value, but if CTS is automatic then that's much less critical.

Signed-off-by: Douglas Anderson 
---

Changes in v2:
- Atop ("drm/bridge: dw-hdmi: Use automatic CTS generation mode when
  using non-AHB audio").
- Split out the ability of a platform to provide custom tables.

 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 203 +-
 1 file changed, 162 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index de4c3669c83f..7cdffebcc7cb 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -60,6 +60,82 @@ enum hdmi_datamap {
YCbCr422_12B = 0x12,
 };
 
+struct dw_hdmi_audio_tmds_n {
+   unsigned long tmds;
+   unsigned int n_32k;
+   unsigned int n_44k1;
+   unsigned int n_48k;
+};
+
+/*
+ * Unless otherwise noted, entries in this table are 100% optimization.
+ * Values can be obtained from hdmi_compute_n() but that function is
+ * slow so we pre-compute values we expect to see.
+ *
+ * All 32k and 48k values are expected to be the same (due to the way
+ * the math works) for any rate that's an exact kHz.
+ *
+ * If a particular platform knows that it makes a rate slightly
+ * differently then it should add a platform-specific match.
+ */
+static const struct dw_hdmi_audio_tmds_n common_tmds_n_table[] = {
+   /* Doesn't match computations, assumes real clock = 25.2 MHz / 1.001 */
+   { .tmds = 25175000, .n_32k = 4576, .n_44k1 = 7007, .n_48k = 6864, },
+
+   { .tmds = 2520, .n_32k = 4096, .n_44k1 = 5656, .n_48k = 6144, },
+   { .tmds = 2700, .n_32k = 4096, .n_44k1 = 5488, .n_48k = 6144, },
+   { .tmds = 27027000, .n_32k = 4096, .n_44k1 = 6272, .n_48k = 6144, },
+   { .tmds = 2832, .n_32k = 4096, .n_44k1 = 5586, .n_48k = 6144, },
+   { .tmds = 3024, .n_32k = 4096, .n_44k1 = 5642, .n_48k = 6144, },
+   { .tmds = 3150, .n_32k = 4096, .n_44k1 = 5600, .n_48k = 6144, },
+   { .tmds = 3200, .n_32k = 4096, .n_44k1 = 5733, .n_48k = 6144, },
+   { .tmds = 3375, .n_32k = 4096, .n_44k1 = 6272, .n_48k = 6144, },
+   { .tmds = 3600, .n_32k = 4096, .n_44k1 = 5684, .n_48k = 6144, },
+   { .tmds = 4000, .n_32k = 4096, .n_44k1 = 5733, .n_48k = 6144, },
+   { .tmds = 4950, .n_32k = 4096, .n_44k1 = 5488, .n_48k = 6144, },
+   { .tmds = 5000, .n_32k = 4096, .n_44k1 = 5292, .n_48k = 6144, },
+   { .tmds = 5400, .n_32k = 4096, .n_44k1 = 5684, .n_48k = 6144, },
+   { .tmds = 6500, .n_32k = 4096, .n_44k1 = 7056, .n_48k = 6144, },
+   { .tmds = 6825, .n_32k = 4096, .n_44k1 = 5376, .n_48k = 6144, },
+   { .tmds = 7100, .n_32k = 4096, .n_44k1 = 7056, .n_48k = 6144, },
+   { .tmds = 7200, .n_32k = 4096, .n_44k1 = 5635, .n_48k = 6144, },
+   { .tmds = 7325, .n_32k = 4096, .n_44k1 = 14112, .n_48k = 6144, },
+
+   /* Doesn't match computations, assumes real clock = 74.25 MHz / 1.001 */
+   { .tmds = 74176000, .n_32k = 11648, .n_44k1 = 17836, .n_48k = 11648, },
+
+   { .tmds = 7425, .n_32k = 4096, .n_44k1 = 6272, .n_48k = 6144, },
+   { .tmds = 7500, .n_32k = 4096, .n_44k1 = 5880, .n_48k = 6144, },
+   { .tmds = 7875, .n_32k = 4096, .n_44k1 = 5600, .n_48k = 6144, },
+   { .tmds = 7880, .n_32k = 4096, .n_44k1 = 5292, .n_48k = 6144, },
+   { .tmds = 7950, .n_32k = 4096, .n_44k1 = 4704, .n_48k = 6144, },
+   { .tmds = 8350, .n_32k = 4096, .n_44k1 = 7056, .n_48k = 6144, },
+   { .tmds = 8550, .n_32k = 4096, .n_44k1 = 5488, .n_48k = 6144, },
+   { .tmds = 8875, .n_32k = 

Re: [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail

[Jason Gunthorpe]

On Wed, Jun 19, 2019 at 10:18:43PM +0200, Daniel Vetter wrote:
> On Wed, Jun 19, 2019 at 10:13 PM Jason Gunthorpe  wrote:
> > On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> > > On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe  wrote:
> > > > On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> > > > > On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> > > > > > On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> > > > > > > Just a bit of paranoia, since if we start pushing this deep into
> > > > > > > callchains it's hard to spot all places where an mmu notifier
> > > > > > > implementation might fail when it's not allowed to.
> > > > > > >
> > > > > > > Inspired by some confusion we had discussing i915 mmu notifiers 
> > > > > > > and
> > > > > > > whether we could use the newly-introduced return value to handle 
> > > > > > > some
> > > > > > > corner cases. Until we realized that these are only for when a 
> > > > > > > task
> > > > > > > has been killed by the oom reaper.
> > > > > > >
> > > > > > > An alternative approach would be to split the callback into two
> > > > > > > versions, one with the int return value, and the other with void
> > > > > > > return value like in older kernels. But that's a lot more churn 
> > > > > > > for
> > > > > > > fairly little gain I think.
> > > > > > >
> > > > > > > Summary from the m-l discussion on why we want something at 
> > > > > > > warning
> > > > > > > level: This allows automated tooling in CI to catch bugs without
> > > > > > > humans having to look at everything. If we just upgrade the 
> > > > > > > existing
> > > > > > > pr_info to a pr_warn, then we'll have false positives. And as-is, 
> > > > > > > no
> > > > > > > one will ever spot the problem since it's lost in the massive 
> > > > > > > amounts
> > > > > > > of overall dmesg noise.
> > > > > > >
> > > > > > > v2: Drop the full WARN_ON backtrace in favour of just a pr_warn 
> > > > > > > for
> > > > > > > the problematic case (Michal Hocko).
> > > >
> > > > I disagree with this v2 note, the WARN_ON/WARN will trigger checkers
> > > > like syzkaller to report a bug, while a random pr_warn probably will
> > > > not.
> > > >
> > > > I do agree the backtrace is not useful here, but we don't have a
> > > > warn-no-backtrace version..
> > > >
> > > > IMHO, kernel/driver bugs should always be reported by WARN &
> > > > friends. We never expect to see the print, so why do we care how big
> > > > it is?
> > > >
> > > > Also note that WARN integrates an unlikely() into it so the codegen is
> > > > automatically a bit more optimal that the if & pr_warn combination.
> > >
> > > Where do you make a difference between a WARN without backtrace and a
> > > pr_warn? They're both dumped at the same log-level ...
> >
> > WARN panics the kernel when you set
> >
> > /proc/sys/kernel/panic_on_warn
> >
> > So auto testing tools can set that and get a clean detection that the
> > kernel has failed the test in some way.
> >
> > Otherwise you are left with frail/ugly grepping of dmesg.
> 
> Hm right.
> 
> Anyway, I'm happy to repaint the bikeshed in any color that's desired,
> if that helps with landing it. WARN_WITHOUT_BACKTRACE might take a bit
> longer (need to find a bit of time, plus it'll definitely attract more
> comments).

I was actually just writing something very similar when looking at the
hmm things..

Also, is the test backwards?

mmu_notifier_range_blockable() == true means the callback must return
zero

mmu_notififer_range_blockable() == false means the callback can return
0 or -EAGAIN.

Suggest this:

pr_info("%pS callback failed with %d in 
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
!mmu_notifier_range_blockable(range) ? 
"non-" : "");
+   WARN_ON(mmu_notifier_range_blockable(range) ||
+   _ret != -EAGAIN);
ret = _ret;
}
}

To express the API invariant.

Jason

Re: [PATCH 2/6] dt-bindings: display: msm: gmu: add optional ocmem property

[Rob Clark]

On Wed, Jun 19, 2019 at 1:17 PM Rob Herring  wrote:
>
> On Sun, Jun 16, 2019 at 7:29 AM Brian Masney  wrote:
> >
> > Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> > must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> > optional ocmem property to the Adreno Graphics Management Unit bindings.
> >
> > Signed-off-by: Brian Masney 
> > ---
> >  Documentation/devicetree/bindings/display/msm/gmu.txt | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
> > b/Documentation/devicetree/bindings/display/msm/gmu.txt
> > index 90af5b0a56a9..c746b95e95d4 100644
> > --- a/Documentation/devicetree/bindings/display/msm/gmu.txt
> > +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
> > @@ -31,6 +31,10 @@ Required properties:
> >  - iommus: phandle to the adreno iommu
> >  - operating-points-v2: phandle to the OPP operating points
> >
> > +Optional properties:
> > +- ocmem: phandle to the On Chip Memory (OCMEM) that's present on some 
> > Snapdragon
> > + SoCs. See 
> > Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml.
>
> We already have a couple of similar properties. Lets standardize on
> 'sram' as that is what TI already uses.
>
> Also, is the whole OCMEM allocated to the GMU? If not you should have
> child nodes to subdivide the memory.
>

iirc, downstream a large chunk of OCMEM is statically allocated for
GPU.. the remainder is dynamically allocated for different use-cases.
The upstream driver Brian is proposing only handles the static
allocation case (and I don't think we have upstream support for the
various audio and video use-cases that used dynamic OCMEM allocation
downstream)

Although maybe we should still have a child node to separate the
statically and dynamically allocated parts?  I'm not sure what would
make the most sense..

BR,
-R

Re: [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail

[Daniel Vetter]

On Wed, Jun 19, 2019 at 10:13 PM Jason Gunthorpe  wrote:
> On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe  wrote:
> > > On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> > > > On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> > > > > On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> > > > > > Just a bit of paranoia, since if we start pushing this deep into
> > > > > > callchains it's hard to spot all places where an mmu notifier
> > > > > > implementation might fail when it's not allowed to.
> > > > > >
> > > > > > Inspired by some confusion we had discussing i915 mmu notifiers and
> > > > > > whether we could use the newly-introduced return value to handle 
> > > > > > some
> > > > > > corner cases. Until we realized that these are only for when a task
> > > > > > has been killed by the oom reaper.
> > > > > >
> > > > > > An alternative approach would be to split the callback into two
> > > > > > versions, one with the int return value, and the other with void
> > > > > > return value like in older kernels. But that's a lot more churn for
> > > > > > fairly little gain I think.
> > > > > >
> > > > > > Summary from the m-l discussion on why we want something at warning
> > > > > > level: This allows automated tooling in CI to catch bugs without
> > > > > > humans having to look at everything. If we just upgrade the existing
> > > > > > pr_info to a pr_warn, then we'll have false positives. And as-is, no
> > > > > > one will ever spot the problem since it's lost in the massive 
> > > > > > amounts
> > > > > > of overall dmesg noise.
> > > > > >
> > > > > > v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
> > > > > > the problematic case (Michal Hocko).
> > >
> > > I disagree with this v2 note, the WARN_ON/WARN will trigger checkers
> > > like syzkaller to report a bug, while a random pr_warn probably will
> > > not.
> > >
> > > I do agree the backtrace is not useful here, but we don't have a
> > > warn-no-backtrace version..
> > >
> > > IMHO, kernel/driver bugs should always be reported by WARN &
> > > friends. We never expect to see the print, so why do we care how big
> > > it is?
> > >
> > > Also note that WARN integrates an unlikely() into it so the codegen is
> > > automatically a bit more optimal that the if & pr_warn combination.
> >
> > Where do you make a difference between a WARN without backtrace and a
> > pr_warn? They're both dumped at the same log-level ...
>
> WARN panics the kernel when you set
>
> /proc/sys/kernel/panic_on_warn
>
> So auto testing tools can set that and get a clean detection that the
> kernel has failed the test in some way.
>
> Otherwise you are left with frail/ugly grepping of dmesg.

Hm right.

Anyway, I'm happy to repaint the bikeshed in any color that's desired,
if that helps with landing it. WARN_WITHOUT_BACKTRACE might take a bit
longer (need to find a bit of time, plus it'll definitely attract more
comments).

Michal?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: KMS documentation for userspace

[Jani Nikula]

On Wed, 19 Jun 2019, Daniel Vetter  wrote:
> - figure out what to do with the libdrm manpages. Some stuff we really
> want to also document there. But geez nroff. Maybe we need to stuff
> libdrm into the kernel, dunno.

How would people feel about converting libdrm man pages to rst, and
using rst2man in the build? We did that for igt man pages [1]. Looking
at the diff, I think it's plain to see how that could lower the bar for
contributing. And perhaps it would be easier to refactor and move
documentation around too.

I forget, I probably used pandoc or something to do the bulk of the igt
conversion, and added some manual polish on top. I'm not volunteering
for the libdrm man page conversion though. ;)

BR,
Jani.


[1] 
https://gitlab.freedesktop.org/drm/igt-gpu-tools/commit/cc7387f17ce5750fc640355d94ed60b6936c2d7b

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/6] dt-bindings: display: msm: gmu: add optional ocmem property

[Rob Herring]

On Sun, Jun 16, 2019 at 7:29 AM Brian Masney  wrote:
>
> Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> optional ocmem property to the Adreno Graphics Management Unit bindings.
>
> Signed-off-by: Brian Masney 
> ---
>  Documentation/devicetree/bindings/display/msm/gmu.txt | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
> b/Documentation/devicetree/bindings/display/msm/gmu.txt
> index 90af5b0a56a9..c746b95e95d4 100644
> --- a/Documentation/devicetree/bindings/display/msm/gmu.txt
> +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
> @@ -31,6 +31,10 @@ Required properties:
>  - iommus: phandle to the adreno iommu
>  - operating-points-v2: phandle to the OPP operating points
>
> +Optional properties:
> +- ocmem: phandle to the On Chip Memory (OCMEM) that's present on some 
> Snapdragon
> + SoCs. See 
> Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml.

We already have a couple of similar properties. Lets standardize on
'sram' as that is what TI already uses.

Also, is the whole OCMEM allocated to the GMU? If not you should have
child nodes to subdivide the memory.

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

Re: [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail

[Jason Gunthorpe]

On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe  wrote:
> > On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> > > On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> > > > On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> > > > > Just a bit of paranoia, since if we start pushing this deep into
> > > > > callchains it's hard to spot all places where an mmu notifier
> > > > > implementation might fail when it's not allowed to.
> > > > >
> > > > > Inspired by some confusion we had discussing i915 mmu notifiers and
> > > > > whether we could use the newly-introduced return value to handle some
> > > > > corner cases. Until we realized that these are only for when a task
> > > > > has been killed by the oom reaper.
> > > > >
> > > > > An alternative approach would be to split the callback into two
> > > > > versions, one with the int return value, and the other with void
> > > > > return value like in older kernels. But that's a lot more churn for
> > > > > fairly little gain I think.
> > > > >
> > > > > Summary from the m-l discussion on why we want something at warning
> > > > > level: This allows automated tooling in CI to catch bugs without
> > > > > humans having to look at everything. If we just upgrade the existing
> > > > > pr_info to a pr_warn, then we'll have false positives. And as-is, no
> > > > > one will ever spot the problem since it's lost in the massive amounts
> > > > > of overall dmesg noise.
> > > > >
> > > > > v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
> > > > > the problematic case (Michal Hocko).
> >
> > I disagree with this v2 note, the WARN_ON/WARN will trigger checkers
> > like syzkaller to report a bug, while a random pr_warn probably will
> > not.
> >
> > I do agree the backtrace is not useful here, but we don't have a
> > warn-no-backtrace version..
> >
> > IMHO, kernel/driver bugs should always be reported by WARN &
> > friends. We never expect to see the print, so why do we care how big
> > it is?
> >
> > Also note that WARN integrates an unlikely() into it so the codegen is
> > automatically a bit more optimal that the if & pr_warn combination.
> 
> Where do you make a difference between a WARN without backtrace and a
> pr_warn? They're both dumped at the same log-level ...

WARN panics the kernel when you set 

/proc/sys/kernel/panic_on_warn

So auto testing tools can set that and get a clean detection that the
kernel has failed the test in some way.

Otherwise you are left with frail/ugly grepping of dmesg.

Jason

Re: [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail

[Daniel Vetter]

On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe  wrote:
> On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> > On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> > > On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> > > > Just a bit of paranoia, since if we start pushing this deep into
> > > > callchains it's hard to spot all places where an mmu notifier
> > > > implementation might fail when it's not allowed to.
> > > >
> > > > Inspired by some confusion we had discussing i915 mmu notifiers and
> > > > whether we could use the newly-introduced return value to handle some
> > > > corner cases. Until we realized that these are only for when a task
> > > > has been killed by the oom reaper.
> > > >
> > > > An alternative approach would be to split the callback into two
> > > > versions, one with the int return value, and the other with void
> > > > return value like in older kernels. But that's a lot more churn for
> > > > fairly little gain I think.
> > > >
> > > > Summary from the m-l discussion on why we want something at warning
> > > > level: This allows automated tooling in CI to catch bugs without
> > > > humans having to look at everything. If we just upgrade the existing
> > > > pr_info to a pr_warn, then we'll have false positives. And as-is, no
> > > > one will ever spot the problem since it's lost in the massive amounts
> > > > of overall dmesg noise.
> > > >
> > > > v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
> > > > the problematic case (Michal Hocko).
>
> I disagree with this v2 note, the WARN_ON/WARN will trigger checkers
> like syzkaller to report a bug, while a random pr_warn probably will
> not.
>
> I do agree the backtrace is not useful here, but we don't have a
> warn-no-backtrace version..
>
> IMHO, kernel/driver bugs should always be reported by WARN &
> friends. We never expect to see the print, so why do we care how big
> it is?
>
> Also note that WARN integrates an unlikely() into it so the codegen is
> automatically a bit more optimal that the if & pr_warn combination.

Where do you make a difference between a WARN without backtrace and a
pr_warn? They're both dumped at the same log-level ...

I can easily throw an unlikely around this here if that's the only
thing that's blocking the merge.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: KMS documentation for userspace

[Daniel Vetter]

On Wed, Jun 19, 2019 at 9:36 PM Simon Ser  wrote:
>
> Hi all,
>
> With Wayland compositors and DRM leases, the number of DRM userspace
> programs has increased (and will probably continue to increase).
> However it's been pretty hard to find good DRM docs for userspace.
>
> The resources currently available are:
>
> - The kernel docs, although only the high level overview is useful to
>   userspace.
> - User-contributed tutorials, like [1] and [2].
> - To help userspace understand hardware capabilities and limitations,
>   I've recently started a DRM database dump project [3].
>
> (Anything else I've missed?)
>
> We still lack docs that describe how to properly use the KMS API and
> the KMS properties. There is a deprecated list at [4], and another list
> mixed with kernel structs at [5]. This is not great for userspace
> developers.
>
> So I wanted to know if there's interest from the kernel community to
> maintain documentation for userspace? Or should userspace maintain its
> own docs of the kernel API?
>
> I don't know what would be the best place for these docs. If they live
> in kernel doc comments, then references to kernel functions and
> guidelines for kernel devs will appear (just like in the current docs).
> If they live outside of the kernel source code or outside of the kernel
> tree, they might get outdated.
>
> Thoughts?

tldr; Yes, I just didn't get around to it yet.

The rough plan is to actually document ioctls and properties and all
that stuff in drm-uapi.rst, and then cross-link that with the
driver-side documentation. Current status:
- ioctl docs: doesn't exist
- property docs: spotty, needs to be extracted from
https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#kms-properties
without going crazy (I think you got your links for references 4 and 5
wrong, but it's all the same chapter anyway)
- figure out whether we can use the media uapi sphinx stuff to catch
when new ioctls/structs/props have been added without corresponding
documentation
- figure out what to do with the libdrm manpages. Some stuff we really
want to also document there. But geez nroff. Maybe we need to stuff
libdrm into the kernel, dunno.

I'd say 5-10 years of chugging along until this is fixed. The
in-kernel docs took about as long:

commit 2d2ef822758e3f5da59c40a392d0c6d89394d4b4
Author: Jesse Barnes 
Date:   Mon Oct 26 13:06:31 2009 -0700

drm: add initial DRM developer documentation

If you are exceendingly bored and want to get started right away,
document everything in include/uapi/drm/drm*.h as a start :-)

Cheers, Daniel

> Thanks,
>
> [1]: https://github.com/ascent12/drm_doc
> [2]: https://gitlab.freedesktop.org/daniels/kms-quads
> [3]: https://drmdb.emersion.fr/
> [4]: 
> https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#standard-connector-properties
> [5]: 
> https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#existing-kms-properties
>
> --
> Simon Ser
> https://emersion.fr
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: [PATCH 18/22] mm: mark DEVICE_PUBLIC as broken

[Dan Williams]

On Wed, Jun 19, 2019 at 12:42 PM Jason Gunthorpe  wrote:
>
> On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote:
> > On 6/13/19 5:43 PM, Ira Weiny wrote:
> > > On Thu, Jun 13, 2019 at 07:58:29PM +, Jason Gunthorpe wrote:
> > >> On Thu, Jun 13, 2019 at 12:53:02PM -0700, Ralph Campbell wrote:
> > >>>
> > ...
> > >> Hum, so the only thing this config does is short circuit here:
> > >>
> > >> static inline bool is_device_public_page(const struct page *page)
> > >> {
> > >> return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) &&
> > >> IS_ENABLED(CONFIG_DEVICE_PUBLIC) &&
> > >> is_zone_device_page(page) &&
> > >> page->pgmap->type == MEMORY_DEVICE_PUBLIC;
> > >> }
> > >>
> > >> Which is called all over the place..
> > >
> > >   yes but the earlier patch:
> > >
> > > [PATCH 03/22] mm: remove hmm_devmem_add_resource
> > >
> > > Removes the only place type is set to MEMORY_DEVICE_PUBLIC.
> > >
> > > So I think it is ok.  Frankly I was wondering if we should remove the 
> > > public
> > > type altogether but conceptually it seems ok.  But I don't see any users 
> > > of it
> > > so...  should we get rid of it in the code rather than turning the config 
> > > off?
> > >
> > > Ira
> >
> > That seems reasonable. I recall that the hope was for those IBM Power 9
> > systems to use _PUBLIC, as they have hardware-based coherent device (GPU)
> > memory, and so the memory really is visible to the CPU. And the IBM team
> > was thinking of taking advantage of it. But I haven't seen anything on
> > that front for a while.
>
> Does anyone know who those people are and can we encourage them to
> send some patches? :)

I expect marking it CONFIG_BROKEN with the threat of deleting it if no
patches show up *is* the encouragement.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

KMS documentation for userspace

[Simon Ser]

Hi all,

With Wayland compositors and DRM leases, the number of DRM userspace
programs has increased (and will probably continue to increase).
However it's been pretty hard to find good DRM docs for userspace.

The resources currently available are:

- The kernel docs, although only the high level overview is useful to
  userspace.
- User-contributed tutorials, like [1] and [2].
- To help userspace understand hardware capabilities and limitations,
  I've recently started a DRM database dump project [3].

(Anything else I've missed?)

We still lack docs that describe how to properly use the KMS API and
the KMS properties. There is a deprecated list at [4], and another list
mixed with kernel structs at [5]. This is not great for userspace
developers.

So I wanted to know if there's interest from the kernel community to
maintain documentation for userspace? Or should userspace maintain its
own docs of the kernel API?

I don't know what would be the best place for these docs. If they live
in kernel doc comments, then references to kernel functions and
guidelines for kernel devs will appear (just like in the current docs).
If they live outside of the kernel source code or outside of the kernel
tree, they might get outdated.

Thoughts?

Thanks,

[1]: https://github.com/ascent12/drm_doc
[2]: https://gitlab.freedesktop.org/daniels/kms-quads
[3]: https://drmdb.emersion.fr/
[4]: 
https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#standard-connector-properties
[5]: 
https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#existing-kms-properties

--
Simon Ser
https://emersion.fr


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

Re: [PATCH v2] drm/msm/dsi: Add parentheses to quirks check in dsi_phy_hw_v3_0_lane_settings

[Rob Clark]

On Wed, Jun 19, 2019 at 12:32 PM Sean Paul  wrote:
>
> On Wed, Jun 19, 2019 at 12:17:23PM -0700, Nathan Chancellor wrote:
> > Clang warns:
> >
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
> > only applied to the left hand side of this bitwise operator
> > [-Wlogical-not-parentheses]
> > if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> > ^ ~
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: note: add parentheses
> > after the '!' to evaluate the bitwise operator first
> > if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> > ^
> >  (   )
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: note: add parentheses
> > around left hand side expression to silence this warning
> > if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> > ^
> > ()
> > 1 warning generated.
> >
> > Add parentheses around the bitwise AND so it is evaluated first then
> > negated.
> >
> > Fixes: 3dbbf8f09e83 ("drm/msm/dsi: Add old timings quirk for 10nm phy")
>
> Hmm, so it looks like this patch isn't upstream. What tree are you basing this
> on?

it is in msm-next-staging.. (which will be pushed to msm-next after
some testing)

I've pulled Nathan's patch in on top..

BR,
-R

>
> Sean
>
> > Link: https://github.com/ClangBuiltLinux/linux/issues/547
> > Reported-by: kbuild test robot 
> > Reviewed-by: Jeffrey Hugo 
> > Reviewed-by: Sean Paul 
> > Signed-off-by: Nathan Chancellor 
> > ---
> >
> > v1 -> v2:
> >
> > * Fix broken link (thanks to Sean for pointing it out)
> > * Add Sean's reviewed-by
> >
> >  drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c 
> > b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> > index eb28937f4b34..47403d4f2d28 100644
> > --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> > +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> > @@ -77,7 +77,7 @@ static void dsi_phy_hw_v3_0_lane_settings(struct 
> > msm_dsi_phy *phy)
> > tx_dctrl[i]);
> >   }
> >
> > - if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> > + if (!(phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK)) {
> >   /* Toggle BIT 0 to release freeze I/0 */
> >   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 
> > 0x05);
> >   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 
> > 0x04);
> > --
> > 2.22.0
> >
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/msm/dsi: Add parentheses to quirks check in dsi_phy_hw_v3_0_lane_settings

[Sean Paul]

On Wed, Jun 19, 2019 at 12:17:23PM -0700, Nathan Chancellor wrote:
> Clang warns:
> 
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
> only applied to the left hand side of this bitwise operator
> [-Wlogical-not-parentheses]
> if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> ^ ~
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: note: add parentheses
> after the '!' to evaluate the bitwise operator first
> if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> ^
>  (   )
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: note: add parentheses
> around left hand side expression to silence this warning
> if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> ^
> ()
> 1 warning generated.
> 
> Add parentheses around the bitwise AND so it is evaluated first then
> negated.
> 
> Fixes: 3dbbf8f09e83 ("drm/msm/dsi: Add old timings quirk for 10nm phy")

Hmm, so it looks like this patch isn't upstream. What tree are you basing this
on?

Sean

> Link: https://github.com/ClangBuiltLinux/linux/issues/547
> Reported-by: kbuild test robot 
> Reviewed-by: Jeffrey Hugo 
> Reviewed-by: Sean Paul 
> Signed-off-by: Nathan Chancellor 
> ---
> 
> v1 -> v2:
> 
> * Fix broken link (thanks to Sean for pointing it out)
> * Add Sean's reviewed-by
> 
>  drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c 
> b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> index eb28937f4b34..47403d4f2d28 100644
> --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> @@ -77,7 +77,7 @@ static void dsi_phy_hw_v3_0_lane_settings(struct 
> msm_dsi_phy *phy)
> tx_dctrl[i]);
>   }
>  
> - if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> + if (!(phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK)) {
>   /* Toggle BIT 0 to release freeze I/0 */
>   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 
> 0x05);
>   dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 
> 0x04);
> -- 
> 2.22.0
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS

[PULL] drm-misc-fixes

[Sean Paul]

Hey team,
2 fixes this week, the 5.2 trickle continues.


drm-misc-fixes-2019-06-19:
panfrost- Only unmap BO's if they're mapped (Boris)
core- Handle buffer desc copy_to_user failure properly (Dan)

Cc: Boris Brezillon 
Cc: Dan Carpenter 

Cheers, Sean


The following changes since commit 48eaeb7664c76139438724d520a1ea4a84a3ed92:

  drm: add fallback override/firmware EDID modes workaround (2019-06-12 
13:26:25 +0300)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-06-19

for you to fetch changes up to 74b67efa8d7b4f90137f0ab9a80dd319da050350:

  drm: return -EFAULT if copy_to_user() fails (2019-06-18 13:08:48 -0400)


panfrost- Only unmap BO's if they're mapped (Boris)
core- Handle buffer desc copy_to_user failure properly (Dan)

Cc: Boris Brezillon 
Cc: Dan Carpenter 


Boris Brezillon (1):
  drm/panfrost: Make sure a BO is only unmapped when appropriate

Dan Carpenter (1):
  drm: return -EFAULT if copy_to_user() fails

 drivers/gpu/drm/drm_bufs.c  | 5 -
 drivers/gpu/drm/drm_ioc32.c | 5 -
 drivers/gpu/drm/panfrost/panfrost_gem.c | 3 ++-
 drivers/gpu/drm/panfrost/panfrost_gem.h | 1 +
 drivers/gpu/drm/panfrost/panfrost_mmu.c | 8 
 5 files changed, 19 insertions(+), 3 deletions(-)

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

[PATCH v2] drm/msm/dsi: Add parentheses to quirks check in dsi_phy_hw_v3_0_lane_settings

[Nathan Chancellor]

Clang warns:

drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
only applied to the left hand side of this bitwise operator
[-Wlogical-not-parentheses]
if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
^ ~
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: note: add parentheses
after the '!' to evaluate the bitwise operator first
if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
^
 (   )
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: note: add parentheses
around left hand side expression to silence this warning
if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
^
()
1 warning generated.

Add parentheses around the bitwise AND so it is evaluated first then
negated.

Fixes: 3dbbf8f09e83 ("drm/msm/dsi: Add old timings quirk for 10nm phy")
Link: https://github.com/ClangBuiltLinux/linux/issues/547
Reported-by: kbuild test robot 
Reviewed-by: Jeffrey Hugo 
Reviewed-by: Sean Paul 
Signed-off-by: Nathan Chancellor 
---

v1 -> v2:

* Fix broken link (thanks to Sean for pointing it out)
* Add Sean's reviewed-by

 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index eb28937f4b34..47403d4f2d28 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -77,7 +77,7 @@ static void dsi_phy_hw_v3_0_lane_settings(struct msm_dsi_phy 
*phy)
  tx_dctrl[i]);
}
 
-   if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
+   if (!(phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK)) {
/* Toggle BIT 0 to release freeze I/0 */
dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 
0x05);
dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 
0x04);
-- 
2.22.0

Re: [PATCH] drm/msm/dsi: Add parentheses to quirks check in dsi_phy_hw_v3_0_lane_settings

[Nathan Chancellor]

On Wed, Jun 19, 2019 at 03:13:40PM -0400, Sean Paul wrote:
> On Wed, Jun 19, 2019 at 12:19 PM Nathan Chancellor
>  wrote:
> >
> > Clang warns:
> >
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
> > only applied to the left hand side of this bitwise operator
> > [-Wlogical-not-parentheses]
> > if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> > ^ ~
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: note: add parentheses
> > after the '!' to evaluate the bitwise operator first
> > if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> > ^
> >  (   )
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: note: add parentheses
> > around left hand side expression to silence this warning
> > if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> > ^
> > ()
> > 1 warning generated.
> >
> > Add parentheses around the bitwise AND so it is evaluated first then
> > negated.
> >
> > Fixes: 3dbbf8f09e83 ("drm/msm/dsi: Add old timings quirk for 10nm phy")
> > Link: https://github.com/ClangBuiltLinux/linux/547
> 
> This link is broken, could you please fix it up?

Thanks for catching this, v2 on the way.

Cheers,
Nathan

> 
> The rest is:
> Reviewed-by: Sean Paul 
> 
> 
> 
> > Reported-by: kbuild test robot 
> > Reviewed-by: Jeffrey Hugo 
> > Signed-off-by: Nathan Chancellor 
> > ---
> >  drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c 
> > b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> > index eb28937f4b34..47403d4f2d28 100644
> > --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> > +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> > @@ -77,7 +77,7 @@ static void dsi_phy_hw_v3_0_lane_settings(struct 
> > msm_dsi_phy *phy)
> >   tx_dctrl[i]);
> > }
> >
> > -   if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> > +   if (!(phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK)) {
> > /* Toggle BIT 0 to release freeze I/0 */
> > dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 
> > 0x05);
> > dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 
> > 0x04);
> > --
> > 2.22.0
> >

Re: [PATCH] drm/msm/dsi: Add parentheses to quirks check in dsi_phy_hw_v3_0_lane_settings

[Sean Paul]

On Wed, Jun 19, 2019 at 12:19 PM Nathan Chancellor
 wrote:
>
> Clang warns:
>
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
> only applied to the left hand side of this bitwise operator
> [-Wlogical-not-parentheses]
> if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> ^ ~
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: note: add parentheses
> after the '!' to evaluate the bitwise operator first
> if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> ^
>  (   )
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: note: add parentheses
> around left hand side expression to silence this warning
> if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> ^
> ()
> 1 warning generated.
>
> Add parentheses around the bitwise AND so it is evaluated first then
> negated.
>
> Fixes: 3dbbf8f09e83 ("drm/msm/dsi: Add old timings quirk for 10nm phy")
> Link: https://github.com/ClangBuiltLinux/linux/547

This link is broken, could you please fix it up?

The rest is:
Reviewed-by: Sean Paul 



> Reported-by: kbuild test robot 
> Reviewed-by: Jeffrey Hugo 
> Signed-off-by: Nathan Chancellor 
> ---
>  drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c 
> b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> index eb28937f4b34..47403d4f2d28 100644
> --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
> @@ -77,7 +77,7 @@ static void dsi_phy_hw_v3_0_lane_settings(struct 
> msm_dsi_phy *phy)
>   tx_dctrl[i]);
> }
>
> -   if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
> +   if (!(phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK)) {
> /* Toggle BIT 0 to release freeze I/0 */
> dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 
> 0x05);
> dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3), 
> 0x04);
> --
> 2.22.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/etnaviv: optionally set gpu linear window to cma area

[Sven Van Asbroeck]

On Vivante GPUs with an iommu-v1, the gpu linear window's
position must be determined at probe time, and cannot change
during the driver's lifetime.

The existing code attempts to guess a suitable window position
using the dma mask, but this does not always work [1].

According to a recent thread [2], Lucas Stach mentions that
on MC2.0 GPUs, one may simply point the window to the start
of the global cma area.

This patch provides an optional method to set the window
to the cma area, by adding a phandle to the etnaviv driver's
devicetree node, pointing to the global cma area.

Note that on iommu-v2 GPUs, this setting has no effect:
they do not depend on a fixed window position.



/ {
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;

cma_area: linux,cma {
compatible = "shared-dma-pool";
reusable;
size = <0x1000>;
linux,cma-default;
};
};
};

/* Tell the Vivante GPUS where the CMA area is */

_3d {
default-cma-region = <_area>;
};

_2d {
default-cma-region = <_area>;
};



[1] iMX6Q 2G ram, 256M cma, v5.2-rc4 kernel:
cma area @ 0x3000 (auto-assigned by kernel)
dma mask is 0x
driver sets gpu window to 0x8000
result: gpu iommu-v1 cannot access cma area

[2] https://lkml.org/lkml/2017/11/15/599

To: Lucas Stach 
Cc: Russell King 
Cc: Christian Gmeiner 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: etna...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: Alexey Brodkin 
Cc: Gaël PORTAY 
Signed-off-by: Sven Van Asbroeck 
---

devicetree documentation patch to follow, depending on how this patch
is received.

 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 48 +--
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h |  2 ++
 2 files changed, 39 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 72d01e873160..7ed8705744d0 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -687,6 +688,12 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
 prefetch);
 }
 
+static bool gpu_is_3d_mc10(const struct etnaviv_chip_identity *id)
+{
+   return (id->features & chipFeatures_PIPE_3D) &&
+   !(id->minor_features0 & chipMinorFeatures0_MC20);
+}
+
 int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
 {
int ret, i;
@@ -713,23 +720,33 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
goto fail;
}
 
-   /*
-* Set the GPU linear window to be at the end of the DMA window, where
-* the CMA area is likely to reside. This ensures that we are able to
-* map the command buffers while having the linear window overlap as
-* much RAM as possible, so we can optimize mappings for other buffers.
-*
-* For 3D cores only do this if MC2.0 is present, as with MC1.0 it leads
-* to different views of the memory on the individual engines.
-*/
-   if (!(gpu->identity.features & chipFeatures_PIPE_3D) ||
-   (gpu->identity.minor_features0 & chipMinorFeatures0_MC20)) {
+   if (!gpu_is_3d_mc10(>identity) && gpu->cma_base) {
+   /*
+* If we know the location of the CMA area, point the
+* GPU linear window to it. This ensures that we are able to
+* map the command buffers while having the linear window
+* overlap as much RAM as possible, so we can optimize mappings
+* for other buffers.
+*/
+   gpu->memory_base = (u32)gpu->cma_base;
+   } else if (!gpu_is_3d_mc10(>identity)) {
+   /*
+* Set the GPU linear window to be at the end of the DMA window,
+* where the CMA area is likely to reside. In most cases, this
+* ensures that we are able to map the command buffers while
+* having the linear window overlap as much RAM as possible, so
+* we can optimize mappings for other buffers.
+*/
u32 dma_mask = (u32)dma_get_required_mask(gpu->dev);
if (dma_mask < PHYS_OFFSET + SZ_2G)
gpu->memory_base = PHYS_OFFSET;
else
gpu->memory_base = dma_mask - SZ_2G + 1;
} else if (PHYS_OFFSET >= SZ_2G) {
+   /*
+* For MC1.0 3D cores, moving the linear window leads to
+* different views of the memory on the individual engines.
+*/
dev_info(gpu->dev, "Need to move linear window on MC1.0, 
disabling TS\n");

[PATCH] drm/edid: use for_each_displayid_db where applicable

[Andres Rodriguez]

Replace the duplicated versions of the while loop with the new macro.

Signed-off-by: Andres Rodriguez 
Cc: Dave Airlie 
---

This patch depends on "drm/edid: parse CEA blocks embedded in DisplayID"

I didn't send them together to avoid grouping the portion that
was cc:stable and the "touch ups" into the same series.

 drivers/gpu/drm/drm_edid.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a4e3f6b22dbb..5ff046175478 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4730,11 +4730,7 @@ static int add_displayid_detailed_modes(struct 
drm_connector *connector,
return 0;
 
idx += sizeof(struct displayid_hdr);
-   while (block = (struct displayid_block *)[idx],
-  idx + sizeof(struct displayid_block) <= length &&
-  idx + sizeof(struct displayid_block) + block->num_bytes <= 
length &&
-  block->num_bytes > 0) {
-   idx += block->num_bytes + sizeof(struct displayid_block);
+   for_each_displayid_db(displayid, block, idx, length) {
switch (block->tag) {
case DATA_BLOCK_TYPE_1_DETAILED_TIMING:
num_modes += add_displayid_detailed_1_modes(connector, 
block);
@@ -5279,11 +5275,7 @@ static int drm_parse_display_id(struct drm_connector 
*connector,
return ret;
 
idx += sizeof(struct displayid_hdr);
-   while (block = (struct displayid_block *)[idx],
-  idx + sizeof(struct displayid_block) <= length &&
-  idx + sizeof(struct displayid_block) + block->num_bytes <= 
length &&
-  block->num_bytes > 0) {
-   idx += block->num_bytes + sizeof(struct displayid_block);
+   for_each_displayid_db(displayid, block, idx, length) {
DRM_DEBUG_KMS("block id 0x%x, rev %d, len %d\n",
  block->tag, block->rev, block->num_bytes);
 
-- 
2.19.1

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

Re: [RFC] Exposing plane type mask and handling 'all' planes

[Ville Syrjälä]

On Wed, Jun 19, 2019 at 06:49:11PM +0100, Emil Velikov wrote:
> On Wed, 19 Jun 2019 at 17:33, Ville Syrjälä
>  wrote:
> >
> > On Wed, Jun 19, 2019 at 05:03:53PM +0100, Emil Velikov wrote:
> > > Hi all,
> > >
> > > Recently I have been looking at i915 and its rather interesting planes.
> > >
> > > In particular newer hardware is capable of using 3 universal planes and
> > > a separate cursor-only plane. At the same time only 1 top-most plane can
> > > be enabled - lets calls those plane3 or cursor.
> > >
> > > Hence currently the hardware has an extra plane which we do not use.
> >
> > Only skl (and derivatives) have that. More modern platforms went back to
> > the dedicated cursor plane. So IMO no point in exposing this mess at
> > all.
> >
> I suspect you're talking about Ice Lake, correct?

And glk. The other relevant platform joined the fight club so we don't
talk about it.

> 
> > >
> > > The current DRM design does not allow us to fully utilise the HW and I
> > > would love to address that. Here are three approaches that come to mind:
> > >
> > > 1) Extend the DRM plane UAPI to:
> > >  - expose a mask of supported types, and
> > >  - allow userspace to select the type
> > >
> > > 2) Keep the exposed planes as-is and let the driver orchestrate which
> > >one gets used.
> > >  - flip between cursor/plane3 based on the use-case/API used, or
> > >  - opt for plane3/cursor for atomic and legacy modeset code path, or
> > >  - other
> > >
> > > 3) Expose plane3 and cursor, whereby using one of them "marks" the other
> > >as used.
> > >  - is this allowed by the modeset semantics/policy?
> > >  - does existing user-space have fallback path?
> > >
> > >
> > > Personally, I would love existing user-space to just work without
> > > modification. At the same time opting for 2 this will cause a serious
> > > amount of complication, and in case of 3 the whole thing will be very
> > > fragile. So my current inclination is towards 1.
> > >
> > > Open questions:
> > >  - Do we know of other hardware with this or related design which does
> > > not fit the current DRM design?
> > >  - Vendor KMS specific UAPI, is frowned upon. So if we are to extend the
> > > UAPI, does the current approach sound useful for other HW?
> > >  - Does this approach sound reasonable, can other share their view on a
> > > better approach, that achieves the goal?
> > >
> Speaking hypothetically:
> 
> If the mutually exclusive design was very common, which of the
> proposed solutions you think will be the best fit?
> May I ask you for a mini-brain dump how you foresee that being implemented :-)

I would go for option 2. Option 1 is pretty much the same thing with a
slight hint for userspace that maybe the plane can do a bit more than
just "cursory" things. The problem is that we have no actual definition
of what these "cursory" things are. It's totally hardware/driver
specific. Eg. i915 already allows you to do various things with the
cursor plane that may not work on other hardware. Also I'm sure there's
plenty of hardware out there with no special purpose cursor planes, so
those drivers will probably just designate one regular plane as
"the cursor" anyway.

So I think we've been pretty much doing option 2 all along. So if some
userspace wanted to it could just ignore the cursor type hint and try
to use the plane in any way it sees fit. The usual rule of "try
CHECK_ONLY and see it you get an error" applies here as well.

If we did want to go for option 1 then I think it should take the form
of some better defined plane capabilities. The problem is that there
are alwayas tons of hardware specific exceptions so you wouldn't be
able to blindly trust the caps anyway.

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

Re: [Freedreno] [PATCH 6/6] drm/msm/gpu: add ocmem init/cleanup functions

[Jordan Crouse]

On Wed, Jun 19, 2019 at 12:15:26PM -0600, Jordan Crouse wrote:
> On Sun, Jun 16, 2019 at 09:29:30AM -0400, Brian Masney wrote:
> > The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
> > that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
> > and adreno_gpu_ocmem_cleanup) that removes some duplicated code. We also
> > need to change the ifdef check for CONFIG_MSM_OCMEM to CONFIG_QCOM_OCMEM
> > now that OCMEM support is upstream.

Sorry for reviewing v1 when there was a v2 in flight. That will teach me to not
keep up on my email. I think you caught most of this, but a few things I still
saw.



Jordan

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

[PATCH] drm/self_refresh: Fix possible NULL deref in failure path

[Sean Paul]

From: Sean Paul 

If state allocation fails, we still try to give back the reference on
it. Also initialize ret in case the crtc is not enabled and we hit the
eject button.

Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in 
drivers")
Cc: Daniel Vetter 
Cc: Jose Souza 
Cc: Zain Wang 
Cc: Tomasz Figa 
Cc: Ville Syrjälä 
Cc: Sam Ravnborg 
Cc: Sean Paul 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Reported-by: Dan Carpenter 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/drm_self_refresh_helper.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c 
b/drivers/gpu/drm/drm_self_refresh_helper.c
index e0d2ad1f070cb..4b9424a8f1f1c 100644
--- a/drivers/gpu/drm/drm_self_refresh_helper.c
+++ b/drivers/gpu/drm/drm_self_refresh_helper.c
@@ -69,14 +69,14 @@ static void drm_self_refresh_helper_entry_work(struct 
work_struct *work)
struct drm_connector *conn;
struct drm_connector_state *conn_state;
struct drm_crtc_state *crtc_state;
-   int i, ret;
+   int i, ret = 0;
 
drm_modeset_acquire_init(, 0);
 
state = drm_atomic_state_alloc(dev);
if (!state) {
ret = -ENOMEM;
-   goto out;
+   goto out_drop_locks;
}
 
 retry:
@@ -116,6 +116,8 @@ static void drm_self_refresh_helper_entry_work(struct 
work_struct *work)
}
 
drm_atomic_state_put(state);
+
+out_drop_locks:
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
 }
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

Re: [Freedreno] [PATCH 6/6] drm/msm/gpu: add ocmem init/cleanup functions

[Jordan Crouse]

On Sun, Jun 16, 2019 at 09:29:30AM -0400, Brian Masney wrote:
> The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
> that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
> and adreno_gpu_ocmem_cleanup) that removes some duplicated code. We also
> need to change the ifdef check for CONFIG_MSM_OCMEM to CONFIG_QCOM_OCMEM
> now that OCMEM support is upstream.
> 
> Signed-off-by: Brian Masney 
> ---
>  drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 33 +++-
>  drivers/gpu/drm/msm/adreno/a3xx_gpu.h   |  3 +-
>  drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 30 ++
>  drivers/gpu/drm/msm/adreno/a4xx_gpu.h   |  3 +-
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 41 +
>  drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 ++
>  6 files changed, 74 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> index c3b4bc6e4155..72720bb2aca1 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> @@ -17,10 +17,6 @@
>   * this program.  If not, see .
>   */
>  
> -#ifdef CONFIG_MSM_OCMEM
> -#  include 
> -#endif
> -
>  #include "a3xx_gpu.h"
>  
>  #define A3XX_INT0_MASK \
> @@ -206,9 +202,9 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
>   gpu_write(gpu, REG_A3XX_RBBM_GPR0_CTL, 0x);
>  
>   /* Set the OCMEM base address for A330, etc */
> - if (a3xx_gpu->ocmem_hdl) {
> + if (a3xx_gpu->ocmem.hdl) {
>   gpu_write(gpu, REG_A3XX_RB_GMEM_BASE_ADDR,
> - (unsigned int)(a3xx_gpu->ocmem_base >> 14));
> + (unsigned int)(a3xx_gpu->ocmem.base >> 14));
>   }
>  
>   /* Turn on performance counters: */
> @@ -329,10 +325,7 @@ static void a3xx_destroy(struct msm_gpu *gpu)
>  
>   adreno_gpu_cleanup(adreno_gpu);
>  
> -#ifdef CONFIG_MSM_OCMEM
> - if (a3xx_gpu->ocmem_base)
> - ocmem_free(OCMEM_GRAPHICS, a3xx_gpu->ocmem_hdl);
> -#endif
> + adreno_gpu_ocmem_cleanup(_gpu->ocmem);
>  
>   kfree(a3xx_gpu);
>  }
> @@ -507,17 +500,10 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
>  
>   /* if needed, allocate gmem: */
>   if (adreno_is_a330(adreno_gpu)) {
> -#ifdef CONFIG_MSM_OCMEM
> - /* TODO this is different/missing upstream: */
> - struct ocmem_buf *ocmem_hdl =
> - ocmem_allocate(OCMEM_GRAPHICS, 
> adreno_gpu->gmem);
> -
> - a3xx_gpu->ocmem_hdl = ocmem_hdl;
> - a3xx_gpu->ocmem_base = ocmem_hdl->addr;
> - adreno_gpu->gmem = ocmem_hdl->len;
> - DBG("using %dK of OCMEM at 0x%08x", adreno_gpu->gmem / 1024,
> - a3xx_gpu->ocmem_base);
> -#endif
> + ret = adreno_gpu_ocmem_init(_gpu->base.pdev->dev,
> + adreno_gpu, _gpu->ocmem);
> + if (ret)
> + goto fail;
>   }
>  
>   if (!gpu->aspace) {
> @@ -530,11 +516,14 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
>*/
>   DRM_DEV_ERROR(dev->dev, "No memory protection without IOMMU\n");
>   ret = -ENXIO;
> - goto fail;
> + goto fail_cleanup_ocmem;
>   }
>  
>   return gpu;
>  
> +fail_cleanup_ocmem:
> + adreno_gpu_ocmem_cleanup(_gpu->ocmem);
> +
>  fail:
>   if (a3xx_gpu)
>   a3xx_destroy(_gpu->base.base);

a3xx_destroy is going to have to be able to cleanup the ocmem anyway, so you
might as well stick it in there instead of having a second goto label.

> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h 
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
> index ab60dc9e344e..727c34f38f9e 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
> @@ -30,8 +30,7 @@ struct a3xx_gpu {
>   struct adreno_gpu base;
>  
>   /* if OCMEM is used for GMEM: */
> - uint32_t ocmem_base;
> - void *ocmem_hdl;
> + struct adreno_ocmem ocmem;
>  };
>  #define to_a3xx_gpu(x) container_of(x, struct a3xx_gpu, base)
>  
> diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> index ab2b752566d8..b8f825107796 100644
> --- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> @@ -2,9 +2,6 @@
>  /* Copyright (c) 2014 The Linux Foundation. All rights reserved.
>   */
>  #include "a4xx_gpu.h"
> -#ifdef CONFIG_MSM_OCMEM
> -#  include 
> -#endif
>  
>  #define A4XX_INT0_MASK \
>   (A4XX_INT0_RBBM_AHB_ERROR |\
> @@ -188,7 +185,7 @@ static int a4xx_hw_init(struct msm_gpu *gpu)
>   (1 << 30) | 0x);
>  
>   gpu_write(gpu, REG_A4XX_RB_GMEM_BASE_ADDR,
> - (unsigned int)(a4xx_gpu->ocmem_base >> 14));
> + (unsigned int)(a4xx_gpu->ocmem.base >> 14));
>  
>   

[PATCH] drm/edid: parse CEA blocks embedded in DisplayID

[Andres Rodriguez]

DisplayID blocks allow embedding of CEA blocks. The payloads are
identical to traditional top level CEA extension blocks, but the header
is slightly different.

This change allows the CEA parser to find a CEA block inside a DisplayID
block. Additionally, it adds support for parsing the embedded CTA
header. No further changes are necessary due to payload parity.

This change fixes audio support for the Valve Index HMD.

Signed-off-by: Andres Rodriguez 
Cc: Dave Airlie 
Cc: Jani Nikula 
Cc:  # v4.15
---
 drivers/gpu/drm/drm_edid.c  | 81 -
 include/drm/drm_displayid.h | 10 +
 2 files changed, 80 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 649cfd8b4200..a4e3f6b22dbb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1339,6 +1339,7 @@ MODULE_PARM_DESC(edid_fixup,
 
 static void drm_get_displayid(struct drm_connector *connector,
  struct edid *edid);
+static int validate_displayid(u8 *displayid, int length, int idx);
 
 static int drm_edid_block_checksum(const u8 *raw_edid)
 {
@@ -2883,16 +2884,46 @@ static u8 *drm_find_edid_extension(const struct edid 
*edid, int ext_id)
return edid_ext;
 }
 
-static u8 *drm_find_cea_extension(const struct edid *edid)
-{
-   return drm_find_edid_extension(edid, CEA_EXT);
-}
 
 static u8 *drm_find_displayid_extension(const struct edid *edid)
 {
return drm_find_edid_extension(edid, DISPLAYID_EXT);
 }
 
+static u8 *drm_find_cea_extension(const struct edid *edid)
+{
+   int ret;
+   int idx = 1;
+   int length = EDID_LENGTH;
+   struct displayid_block *block;
+   u8 *cea;
+   u8 *displayid;
+
+   /* Look for a top level CEA extension block */
+   cea = drm_find_edid_extension(edid, CEA_EXT);
+   if (cea)
+   return cea;
+
+   /* CEA blocks can also be found embedded in a DisplayID block */
+   displayid = drm_find_displayid_extension(edid);
+   if (!displayid)
+   return NULL;
+
+   ret = validate_displayid(displayid, length, idx);
+   if (ret)
+   return NULL;
+
+   idx += sizeof(struct displayid_hdr);
+   for_each_displayid_db(displayid, block, idx, length) {
+   if (block->tag == DATA_BLOCK_CTA) {
+   cea = (u8 *)block;
+   break;
+   }
+   }
+
+   return cea;
+}
+
 /*
  * Calculate the alternate clock for the CEA mode
  * (60Hz vs. 59.94Hz etc.)
@@ -3616,13 +3647,38 @@ cea_revision(const u8 *cea)
 static int
 cea_db_offsets(const u8 *cea, int *start, int *end)
 {
-   /* Data block offset in CEA extension block */
-   *start = 4;
-   *end = cea[2];
-   if (*end == 0)
-   *end = 127;
-   if (*end < 4 || *end > 127)
-   return -ERANGE;
+
+   /* DisplayID CTA extension blocks and top-level CEA EDID
+* block header definitions differ in the following bytes:
+*   1) Byte 2 of the header specifies length differently,
+*   2) Byte 3 is only present in the CEA top level block.
+*
+* The different definitions for byte 2 follow.
+*
+* DisplayID CTA extension block defines byte 2 as:
+*   Number of payload bytes
+*
+* CEA EDID block defines byte 2 as:
+*   Byte number (decimal) within this block where the 18-byte
+*   DTDs begin. If no non-DTD data is present in this extension
+*   block, the value should be set to 04h (the byte after next).
+*   If set to 00h, there are no DTDs present in this block and
+*   no non-DTD data.
+*/
+   if (cea[0] == DATA_BLOCK_CTA) {
+   *start = 3;
+   *end = *start + cea[2];
+   } else if (cea[0] == CEA_EXT) {
+   /* Data block offset in CEA extension block */
+   *start = 4;
+   *end = cea[2];
+   if (*end == 0)
+   *end = 127;
+   if (*end < 4 || *end > 127)
+   return -ERANGE;
+   } else
+   return -ENOTSUPP;
+
return 0;
 }
 
@@ -5240,6 +5296,9 @@ static int drm_parse_display_id(struct drm_connector 
*connector,
case DATA_BLOCK_TYPE_1_DETAILED_TIMING:
/* handled in mode gathering code. */
break;
+   case DATA_BLOCK_CTA:
+   /* handled in the cea parser code. */
+   break;
default:
DRM_DEBUG_KMS("found DisplayID tag 0x%x, unhandled\n", 
block->tag);
break;
diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h
index c0d4df6a606f..9d3b745c3107 100644
--- a/include/drm/drm_displayid.h
+++ b/include/drm/drm_displayid.h
@@ -40,6 +40,7 @@
 #define DATA_BLOCK_DISPLAY_INTERFACE 0x0f
 #define 

Re: [Freedreno] [PATCH 2/6] dt-bindings: display: msm: gmu: add optional ocmem property

[Jordan Crouse]

On Sun, Jun 16, 2019 at 09:29:26AM -0400, Brian Masney wrote:
> Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> optional ocmem property to the Adreno Graphics Management Unit bindings.
> 
> Signed-off-by: Brian Masney 
> ---
>  Documentation/devicetree/bindings/display/msm/gmu.txt | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
> b/Documentation/devicetree/bindings/display/msm/gmu.txt
> index 90af5b0a56a9..c746b95e95d4 100644
> --- a/Documentation/devicetree/bindings/display/msm/gmu.txt
> +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
> @@ -31,6 +31,10 @@ Required properties:
>  - iommus: phandle to the adreno iommu
>  - operating-points-v2: phandle to the OPP operating points
>  
> +Optional properties:
> +- ocmem: phandle to the On Chip Memory (OCMEM) that's present on some 
> Snapdragon
> + SoCs. See 
> Documentation/devicetree/bindings/soc/qcom/qcom,ocmem.yaml.
> +
>  Example:

You should add a full-fledged a4xx example here including a ocmem phandle.

Jordan

>  / {

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC] Exposing plane type mask and handling 'all' planes

[Emil Velikov]

On Wed, 19 Jun 2019 at 17:33, Ville Syrjälä
 wrote:
>
> On Wed, Jun 19, 2019 at 05:03:53PM +0100, Emil Velikov wrote:
> > Hi all,
> >
> > Recently I have been looking at i915 and its rather interesting planes.
> >
> > In particular newer hardware is capable of using 3 universal planes and
> > a separate cursor-only plane. At the same time only 1 top-most plane can
> > be enabled - lets calls those plane3 or cursor.
> >
> > Hence currently the hardware has an extra plane which we do not use.
>
> Only skl (and derivatives) have that. More modern platforms went back to
> the dedicated cursor plane. So IMO no point in exposing this mess at
> all.
>
I suspect you're talking about Ice Lake, correct?

> >
> > The current DRM design does not allow us to fully utilise the HW and I
> > would love to address that. Here are three approaches that come to mind:
> >
> > 1) Extend the DRM plane UAPI to:
> >  - expose a mask of supported types, and
> >  - allow userspace to select the type
> >
> > 2) Keep the exposed planes as-is and let the driver orchestrate which
> >one gets used.
> >  - flip between cursor/plane3 based on the use-case/API used, or
> >  - opt for plane3/cursor for atomic and legacy modeset code path, or
> >  - other
> >
> > 3) Expose plane3 and cursor, whereby using one of them "marks" the other
> >as used.
> >  - is this allowed by the modeset semantics/policy?
> >  - does existing user-space have fallback path?
> >
> >
> > Personally, I would love existing user-space to just work without
> > modification. At the same time opting for 2 this will cause a serious
> > amount of complication, and in case of 3 the whole thing will be very
> > fragile. So my current inclination is towards 1.
> >
> > Open questions:
> >  - Do we know of other hardware with this or related design which does
> > not fit the current DRM design?
> >  - Vendor KMS specific UAPI, is frowned upon. So if we are to extend the
> > UAPI, does the current approach sound useful for other HW?
> >  - Does this approach sound reasonable, can other share their view on a
> > better approach, that achieves the goal?
> >
Speaking hypothetically:

If the mutually exclusive design was very common, which of the
proposed solutions you think will be the best fit?
May I ask you for a mini-brain dump how you foresee that being implemented :-)

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

Re: [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail

[Jason Gunthorpe]

On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> > On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> > > Just a bit of paranoia, since if we start pushing this deep into
> > > callchains it's hard to spot all places where an mmu notifier
> > > implementation might fail when it's not allowed to.
> > > 
> > > Inspired by some confusion we had discussing i915 mmu notifiers and
> > > whether we could use the newly-introduced return value to handle some
> > > corner cases. Until we realized that these are only for when a task
> > > has been killed by the oom reaper.
> > > 
> > > An alternative approach would be to split the callback into two
> > > versions, one with the int return value, and the other with void
> > > return value like in older kernels. But that's a lot more churn for
> > > fairly little gain I think.
> > > 
> > > Summary from the m-l discussion on why we want something at warning
> > > level: This allows automated tooling in CI to catch bugs without
> > > humans having to look at everything. If we just upgrade the existing
> > > pr_info to a pr_warn, then we'll have false positives. And as-is, no
> > > one will ever spot the problem since it's lost in the massive amounts
> > > of overall dmesg noise.
> > > 
> > > v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
> > > the problematic case (Michal Hocko).

I disagree with this v2 note, the WARN_ON/WARN will trigger checkers
like syzkaller to report a bug, while a random pr_warn probably will
not.

I do agree the backtrace is not useful here, but we don't have a
warn-no-backtrace version..

IMHO, kernel/driver bugs should always be reported by WARN &
friends. We never expect to see the print, so why do we care how big
it is?

Also note that WARN integrates an unlikely() into it so the codegen is
automatically a bit more optimal that the if & pr_warn combination.

Jason

Re: dev_pagemap related cleanups v2

[Dan Williams]

On Wed, Jun 19, 2019 at 9:37 AM Jason Gunthorpe  wrote:
>
> On Wed, Jun 19, 2019 at 11:40:32AM +0200, Christoph Hellwig wrote:
> > On Tue, Jun 18, 2019 at 12:47:10PM -0700, Dan Williams wrote:
> > > > Git tree:
> > > >
> > > > git://git.infradead.org/users/hch/misc.git hmm-devmem-cleanup.2
> > > >
> > > > Gitweb:
> > > >
> > > > 
> > > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/hmm-devmem-cleanup.2
> >
> > >
> > > Attached is my incremental fixups on top of this series, with those
> > > integrated you can add:
> >
> > I've folded your incremental bits in and pushed out a new
> > hmm-devmem-cleanup.3 to the repo above.  Let me know if I didn't mess
> > up anything else.  I'll wait for a few more comments and Jason's
> > planned rebase of the hmm branch before reposting.
>
> I said I wouldn't rebase the hmm.git (as it needs to go to DRM, AMD
> and RDMA git trees)..
>
> Instead I will merge v5.2-rc5 to the tree before applying this series.
>
> I've understood this to be Linus's prefered workflow.
>
> So, please send the next iteration of this against either
> plainv5.2-rc5 or v5.2-rc5 merged with hmm.git and I'll sort it out.

Just make sure that when you backmerge v5.2-rc5 you have a clear
reason in the merge commit message about why you needed to do it.
While needless rebasing is top of the pet peeve list, second place, as
I found out, is mystery merges without explanations.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Exposing plane type mask and handling 'all' planes

[Ville Syrjälä]

On Wed, Jun 19, 2019 at 05:03:53PM +0100, Emil Velikov wrote:
> Hi all,
> 
> Recently I have been looking at i915 and its rather interesting planes.
> 
> In particular newer hardware is capable of using 3 universal planes and
> a separate cursor-only plane. At the same time only 1 top-most plane can
> be enabled - lets calls those plane3 or cursor.
> 
> Hence currently the hardware has an extra plane which we do not use.

Only skl (and derivatives) have that. More modern platforms went back to
the dedicated cursor plane. So IMO no point in exposing this mess at
all.

> 
> The current DRM design does not allow us to fully utilise the HW and I
> would love to address that. Here are three approaches that come to mind:
> 
> 1) Extend the DRM plane UAPI to:
>  - expose a mask of supported types, and
>  - allow userspace to select the type
> 
> 2) Keep the exposed planes as-is and let the driver orchestrate which
>one gets used.
>  - flip between cursor/plane3 based on the use-case/API used, or
>  - opt for plane3/cursor for atomic and legacy modeset code path, or
>  - other
> 
> 3) Expose plane3 and cursor, whereby using one of them "marks" the other
>as used.
>  - is this allowed by the modeset semantics/policy?
>  - does existing user-space have fallback path?
> 
> 
> Personally, I would love existing user-space to just work without
> modification. At the same time opting for 2 this will cause a serious
> amount of complication, and in case of 3 the whole thing will be very
> fragile. So my current inclination is towards 1.
> 
> Open questions:
>  - Do we know of other hardware with this or related design which does
> not fit the current DRM design?
>  - Vendor KMS specific UAPI, is frowned upon. So if we are to extend the
> UAPI, does the current approach sound useful for other HW?
>  - Does this approach sound reasonable, can other share their view on a 
> better approach, that achieves the goal?
> 
> Input and ideas from the Intel team and DRM community are very much
> appreciated.
> 
> Thanks
> Emil
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v3 0/7] Hexdump Enhancements

[Joe Perches]

On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva 
> 
> Apologies for the large CC list, it's a heads up for those responsible
> for subsystems where a prototype change in generic code causes a change
> in those subsystems.
> 
> This series enhances hexdump.

Still not a fan of these patches.

> These improve the readability of the dumped data in certain situations
> (eg. wide terminals are available, many lines of empty bytes exist, etc).

Changing hexdump's last argument from bool to int is odd.

Perhaps a new function should be added instead of changing
the existing hexdump.

> The default behaviour of hexdump is unchanged, however, the prototype
> for hex_dump_to_buffer() has changed, and print_hex_dump() has been
> renamed to print_hex_dump_ext(), with a wrapper replacing it for
> compatibility with existing code, which would have been too invasive to
> change.
> 
> Hexdump selftests have be run & confirmed passed.


___
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

[Ville Syrjälä]

On Wed, Jun 19, 2019 at 12:33:33PM -0300, Ezequiel Garcia wrote:
> On Wed, 2019-06-19 at 18:03 +0300, Ville Syrjälä wrote:
> > On Wed, Jun 19, 2019 at 10:18:18AM -0300, Ezequiel Garcia wrote:
> > > On Wed, 2019-06-19 at 06:20 +, Shankar, Uma wrote:
> > > > > -Original Message-
> > > > > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On 
> > > > > Behalf Of
> > > > > Ezequiel Garcia
> > > > > Sent: Friday, June 14, 2019 9:48 PM
> > > > > To: Shankar, Uma 
> > > > > Cc: Emil Velikov ; 
> > > > > intel-...@lists.freedesktop.org; Syrjala,
> > > > > Ville ; Lankhorst, Maarten 
> > > > > ;
> > > > > dri-devel 
> > > > > Subject: Re: [v7 00/16] Add Plane Color Properties
> > > > > 
> > > > > 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 

Re: use exact allocation for dma coherent memory

[Jason Gunthorpe]

On Mon, Jun 17, 2019 at 10:33:42AM +0200, Christoph Hellwig wrote:
> > drivers/infiniband/hw/cxgb4/qp.c
> >129  static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq)
> >130  {
> >131  sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev), 
> > sq->memsize,
> >132 &(sq->dma_addr), GFP_KERNEL);
> >133  if (!sq->queue)
> >134  return -ENOMEM;
> >135  sq->phys_addr = virt_to_phys(sq->queue);
> >136  dma_unmap_addr_set(sq, mapping, sq->dma_addr);
> >137  return 0;
> >138  }
> > 
> > Is this a bug?
> 
> Yes.  This will blow up badly on many platforms, as sq->queue
> might be vmapped, ioremapped, come from a pool without page backing.

Gah, this addr gets fed into io_remap_pfn_range/remap_pfn_range too..

Potnuri, you should fix this.. 

You probably need to use dma_mmap_from_dev_coherent() in the mmap ?

Jason

Re: [PATCH] drm/komeda: Adds power management support

[Liviu Dudau]

Hi Lowry,

On Mon, Jun 17, 2019 at 06:55:49AM +0100, Lowry Li (Arm Technology China) wrote:
> Adds runtime and system power management support in KMS kernel driver.
> 
> Depends on:
> - https://patchwork.freedesktop.org/series/61650/
> - https://patchwork.freedesktop.org/series/60083/
> 
> Signed-off-by: Lowry Li (Arm Technology China) 
> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_crtc.c |  2 +
>  drivers/gpu/drm/arm/display/komeda/komeda_dev.c  | 30 +
>  drivers/gpu/drm/arm/display/komeda/komeda_dev.h  |  2 +
>  drivers/gpu/drm/arm/display/komeda/komeda_drv.c  | 54 
> ++--
>  4 files changed, 85 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 66c5e0d..1b4ea8a 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -257,6 +257,7 @@ void komeda_crtc_handle_event(struct komeda_crtc   *kcrtc,
>  komeda_crtc_atomic_enable(struct drm_crtc *crtc,
> struct drm_crtc_state *old)
>  {
> + pm_runtime_get_sync(crtc->dev->dev);
>   komeda_crtc_prepare(to_kcrtc(crtc));
>   drm_crtc_vblank_on(crtc);
>   komeda_crtc_do_flush(crtc, old);
> @@ -330,6 +331,7 @@ void komeda_crtc_handle_event(struct komeda_crtc   *kcrtc,
>  
>   drm_crtc_vblank_off(crtc);
>   komeda_crtc_unprepare(kcrtc);
> + pm_runtime_put(crtc->dev->dev);
>  }
>  
>  static void
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> index 405c64d..edd0943 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> @@ -308,3 +308,33 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
>  
>   devm_kfree(dev, mdev);
>  }
> +
> +int komeda_dev_resume(struct komeda_dev *mdev)
> +{
> + int ret = 0;
> +
> + if (mdev->iommu && mdev->funcs->connect_iommu) {
> + ret = mdev->funcs->connect_iommu(mdev);
> + if (ret < 0) {
> + DRM_ERROR("connect iommu failed.\n");
> + return ret;
> + }
> + }
> +
> + return mdev->funcs->enable_irq(mdev);
> +}
> +
> +int komeda_dev_suspend(struct komeda_dev *mdev)
> +{
> + int ret = 0;
> +
> + if (mdev->iommu && mdev->funcs->disconnect_iommu) {
> + ret = mdev->funcs->disconnect_iommu(mdev);
> + if (ret < 0) {
> + DRM_ERROR("disconnect iommu failed.\n");
> + return ret;
> + }
> + }
> +
> + return mdev->funcs->disable_irq(mdev);
> +}
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h 
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> index d1c86b6..096f9f7 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> @@ -207,4 +207,6 @@ struct komeda_dev {
>  
>  struct komeda_dev *dev_to_mdev(struct device *dev);
>  
> +int komeda_dev_resume(struct komeda_dev *mdev);
> +int komeda_dev_suspend(struct komeda_dev *mdev);
>  #endif /*_KOMEDA_DEV_H_*/
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> index cfa5068..aa4cef1 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "komeda_dev.h"
>  #include "komeda_kms.h"
> @@ -32,6 +33,9 @@ static void komeda_unbind(struct device *dev)
>   return;
>  
>   komeda_kms_detach(mdrv->kms);
> +
> + pm_runtime_disable(dev);
> +
>   komeda_dev_destroy(mdrv->mdev);
>  
>   dev_set_drvdata(dev, NULL);
> @@ -52,6 +56,9 @@ static int komeda_bind(struct device *dev)
>   err = PTR_ERR(mdrv->mdev);
>   goto free_mdrv;
>   }
> + dev_set_drvdata(dev, mdrv);
> +
> + pm_runtime_enable(dev);
>  
>   mdrv->kms = komeda_kms_attach(mdrv->mdev);
>   if (IS_ERR(mdrv->kms)) {
> @@ -59,11 +66,10 @@ static int komeda_bind(struct device *dev)
>   goto destroy_mdev;
>   }
>  
> - dev_set_drvdata(dev, mdrv);
> -
>   return 0;
>  
>  destroy_mdev:
> + pm_runtime_disable(dev);
>   komeda_dev_destroy(mdrv->mdev);
>  
>  free_mdrv:
> @@ -134,13 +140,55 @@ static int komeda_platform_remove(struct 
> platform_device *pdev)
>  
>  MODULE_DEVICE_TABLE(of, komeda_of_match);
>  
> +static int komeda_rt_pm_suspend(struct device *dev)
> +{
> + dev_info(dev, "%s\n", __func__);
> + return 0;
> +}
> +
> +static int komeda_rt_pm_resume(struct device *dev)
> +{
> + dev_info(dev, "%s\n", __func__);
> + return 0;
> +}


Useful only for debugging? I think you've missed an opportunity here to turn
off clocks and disable interrupts.

> +
> +static int 

[RFC] Exposing plane type mask and handling 'all' planes

[Emil Velikov]

Hi all,

Recently I have been looking at i915 and its rather interesting planes.

In particular newer hardware is capable of using 3 universal planes and
a separate cursor-only plane. At the same time only 1 top-most plane can
be enabled - lets calls those plane3 or cursor.

Hence currently the hardware has an extra plane which we do not use.

The current DRM design does not allow us to fully utilise the HW and I
would love to address that. Here are three approaches that come to mind:

1) Extend the DRM plane UAPI to:
 - expose a mask of supported types, and
 - allow userspace to select the type

2) Keep the exposed planes as-is and let the driver orchestrate which
   one gets used.
 - flip between cursor/plane3 based on the use-case/API used, or
 - opt for plane3/cursor for atomic and legacy modeset code path, or
 - other

3) Expose plane3 and cursor, whereby using one of them "marks" the other
   as used.
 - is this allowed by the modeset semantics/policy?
 - does existing user-space have fallback path?


Personally, I would love existing user-space to just work without
modification. At the same time opting for 2 this will cause a serious
amount of complication, and in case of 3 the whole thing will be very
fragile. So my current inclination is towards 1.

Open questions:
 - Do we know of other hardware with this or related design which does
not fit the current DRM design?
 - Vendor KMS specific UAPI, is frowned upon. So if we are to extend the
UAPI, does the current approach sound useful for other HW?
 - Does this approach sound reasonable, can other share their view on a 
better approach, that achieves the goal?

Input and ideas from the Intel team and DRM community are very much
appreciated.

Thanks
Emil
___
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

[Ezequiel Garcia]

On Wed, 2019-06-19 at 18:03 +0300, Ville Syrjälä wrote:
> On Wed, Jun 19, 2019 at 10:18:18AM -0300, Ezequiel Garcia wrote:
> > On Wed, 2019-06-19 at 06:20 +, Shankar, Uma wrote:
> > > > -Original Message-
> > > > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On 
> > > > Behalf Of
> > > > Ezequiel Garcia
> > > > Sent: Friday, June 14, 2019 9:48 PM
> > > > To: Shankar, Uma 
> > > > Cc: Emil Velikov ; 
> > > > intel-...@lists.freedesktop.org; Syrjala,
> > > > Ville ; Lankhorst, Maarten 
> > > > ;
> > > > dri-devel 
> > > > Subject: Re: [v7 00/16] Add Plane Color Properties
> > > > 
> > > > 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
> > > > > 

Re: [PATCH] drm: self_refresh: Fix a reversed condition in drm_self_refresh_helper_cleanup()

[Jani Nikula]

On Wed, 19 Jun 2019, Sean Paul  wrote:
> On Wed, Jun 19, 2019 at 01:01:41PM +0300, Dan Carpenter wrote:
>> This test is flipped around so it either leads to a memory leak or a
>> NULL dereference.
>> 
>> Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in 
>> drivers")
>> Signed-off-by: Dan Carpenter 
>
> Thanks for the patch and your bug report! I've applied this to -misc-next and
> will dig into the bug report shortly.
>
>> ---
>> I'm not totally sure what the prefered patch prefix for this code.  One
>> thing that would help is when we're adding new files we should specify
>> the prefix that they're going to use:
>> 
>> - drm: Add helpers to kick off self refresh mode in drivers
>> + drm: refresh mode: Add helpers to kick off self refresh mode in drivers
>> 
>> It's a small thing and email always sounds whiny but I'm sending this
>> suggestion to everyone today so...
>
> There's no hard rule. For drivers we use drm/, and for core people
> use drm or drm/.

checkpatch.pl should have a git log popularity contest based check for
the prefix. For new files, first come first served. ;)

BR,
Jani.


>
>> 
>>  drivers/gpu/drm/drm_self_refresh_helper.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c 
>> b/drivers/gpu/drm/drm_self_refresh_helper.c
>> index 2b3daaf77841..e0d2ad1f070c 100644
>> --- a/drivers/gpu/drm/drm_self_refresh_helper.c
>> +++ b/drivers/gpu/drm/drm_self_refresh_helper.c
>> @@ -205,7 +205,7 @@ void drm_self_refresh_helper_cleanup(struct drm_crtc 
>> *crtc)
>>  struct drm_self_refresh_data *sr_data = crtc->self_refresh_data;
>>  
>>  /* Helper is already uninitialized */
>> -if (sr_data)
>> +if (!sr_data)
>>  return;
>>  
>>  crtc->self_refresh_data = NULL;
>> -- 
>> 2.20.1
>> 
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge/synopsys: dw-hdmi: Handle audio for more clock rates

[Neil Armstrong]

On 18/06/2019 19:23, Jernej Škrabec wrote:
> Hi!
> 
> Dne torek, 18. junij 2019 ob 01:55:58 CEST je Douglas Anderson napisal(a):
>> Let's add some better support for HDMI audio to dw_hdmi.
>> Specifically:
>>
>> 1. For 44.1 kHz audio the old code made the assumption that an N of
>> 6272 was right most of the time.  That wasn't true and the new table
>> should give better 44.1 kHz audio for many more rates.
>>
>> 2. The new table has values from the HDMI spec for 297 MHz and 594
>> MHz.
>>
>> 3. There is now code to try to come up with a more idea N/CTS for
>> clock rates that aren't in the table.  This code is a bit slow because
>> it iterates over every possible value of N and picks the best one, but
>> it should make a good fallback.
>>
>> 4. The new code allows for platforms that know they make a clock rate
>> slightly differently to pick different N/CTS values.  For instance on
>> rk3288 we can make 25,176,471 Hz instead of 25,174,825.1748... Hz
>> (25.2 MHz / 1.001).  A future patch to the rk3288 platform code could
>> enable support for this clock rate and specify the N/CTS that would be
>> ideal.
>>
>> NOTE: the oddest part of this patch comes about because computing the
>> ideal N/CTS means knowing the _exact_ clock rate, not a rounded
>> version of it.  The drm framework makes this harder by rounding rates
>> to kHz, but even if it didn't there might be cases where the ideal
>> rate could only be calculated if we knew the real (non-integral) rate.
>> This means that in cases where we know (or believe) that the true rate
>> is something other than the rate we are told by drm.
>>
>> Signed-off-by: Douglas Anderson 
> 
> Which bus is used for audio transfer on your device? If it is I2S, which is 
> commonly used, then please be aware of this patch:
> https://lists.freedesktop.org/archives/dri-devel/2019-June/221539.html
> 
> It avoids exact N/CTS calculation by enabling auto detection. It is well 
> tested on multiple SoCs from Allwinner, Amlogic and Rockchip.
> 
> Best regards,
> Jernej
> 
> 
Hi Douglas,

Thanks for your work !

If you could rebase on top of 
https://lists.freedesktop.org/archives/dri-devel/2019-June/221539.html
so we can make use of your extended N table with automatic CTS HW calculation, 
it would be great !

Finally could you add the plat_data tmds table as a separate patch to simplify 
review ?

Thanks,
Neil

Re: [PATCH] drm: self_refresh: Fix a reversed condition in drm_self_refresh_helper_cleanup()

[Sean Paul]

On Wed, Jun 19, 2019 at 01:01:41PM +0300, Dan Carpenter wrote:
> This test is flipped around so it either leads to a memory leak or a
> NULL dereference.
> 
> Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in 
> drivers")
> Signed-off-by: Dan Carpenter 

Thanks for the patch and your bug report! I've applied this to -misc-next and
will dig into the bug report shortly.

> ---
> I'm not totally sure what the prefered patch prefix for this code.  One
> thing that would help is when we're adding new files we should specify
> the prefix that they're going to use:
> 
> - drm: Add helpers to kick off self refresh mode in drivers
> + drm: refresh mode: Add helpers to kick off self refresh mode in drivers
> 
> It's a small thing and email always sounds whiny but I'm sending this
> suggestion to everyone today so...

There's no hard rule. For drivers we use drm/, and for core people
use drm or drm/.

> 
>  drivers/gpu/drm/drm_self_refresh_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c 
> b/drivers/gpu/drm/drm_self_refresh_helper.c
> index 2b3daaf77841..e0d2ad1f070c 100644
> --- a/drivers/gpu/drm/drm_self_refresh_helper.c
> +++ b/drivers/gpu/drm/drm_self_refresh_helper.c
> @@ -205,7 +205,7 @@ void drm_self_refresh_helper_cleanup(struct drm_crtc 
> *crtc)
>   struct drm_self_refresh_data *sr_data = crtc->self_refresh_data;
>  
>   /* Helper is already uninitialized */
> - if (sr_data)
> + if (!sr_data)
>   return;
>  
>   crtc->self_refresh_data = NULL;
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

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

[Ville Syrjälä]

On Wed, Jun 19, 2019 at 10:18:18AM -0300, Ezequiel Garcia wrote:
> On Wed, 2019-06-19 at 06:20 +, Shankar, Uma wrote:
> > > -Original Message-
> > > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On 
> > > Behalf Of
> > > Ezequiel Garcia
> > > Sent: Friday, June 14, 2019 9:48 PM
> > > To: Shankar, Uma 
> > > Cc: Emil Velikov ; 
> > > intel-...@lists.freedesktop.org; Syrjala,
> > > Ville ; Lankhorst, Maarten 
> > > ;
> > > dri-devel 
> > > Subject: Re: [v7 00/16] Add Plane Color Properties
> > > 
> > > 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_req
> > > > uests/25
> > > > 
> > > > v2: Dropped legacy gamma table for plane as 

Re: [PATCH v3 hmm 11/12] mm/hmm: Remove confusing comment and logic from hmm_release

[Jason Gunthorpe]

On Wed, Jun 19, 2019 at 01:07:05AM -0700, Christoph Hellwig wrote:
> On Wed, Jun 19, 2019 at 12:53:55AM +, Kuehling, Felix wrote:
> > This code is derived from our old MMU notifier code. Before HMM we used 
> > to register a single MMU notifier per mm_struct and look up virtual 
> > address ranges that had been registered for mirroring via driver API 
> > calls. The idea was to reuse a single MMU notifier for the life time of 
> > the process. It would remain registered until we got a notifier_release.
> > 
> > hmm_mirror took the place of that when we converted the code to HMM.
> > 
> > I suppose we could destroy the mirror earlier, when we have no more 
> > registered virtual address ranges, and create a new one if needed later.
> 
> I didn't write the code, but if you look at hmm_mirror it already is
> a multiplexer over the mmu notifier, and the intent clearly seems that
> you register one per range that you want to mirror, and not multiplex
> it once again.  In other words - I think each amdgpu_mn_node should
> probably have its own hmm_mirror.  And while the amdgpu_mn_node objects
> are currently stored in an interval tree it seems like they are only
> linearly iterated anyway, so a list actually seems pretty suitable.  If
> not we need to improve the core data structures instead of working
> around them.

This looks a lot like the ODP code (amdgpu_mn_node == ib_umem_odp)

The interval tree is to quickly find the driver object(s) that have
the virtual pages during invalidation:

static int amdgpu_mn_sync_pagetables_gfx(struct hmm_mirror *mirror,
const struct hmm_update *update)
{
it = interval_tree_iter_first(>objects, start, end);
while (it) {
[..]
amdgpu_mn_invalidate_node(node, start, end);

And following the ODP model there should be a single hmm_mirror per-mm
(user can fork and stuff, this is something I want to have core code
help with). 

The hmm_mirror can either exist so long as objects exist, or it can
exist until the chardev is closed - but never longer than the
chardev's lifetime.

Maybe we should be considering providing a mmu notifier & interval
tree & lock abstraction since ODP & AMD are very similar here..

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

[PATCH v1] backlight: pwm_bl: convert to use SPDX identifier

[Andy Shevchenko]

Reduce size of duplicated comments by switching to use SPDX identifier.

No functional change.

While here, correct MODULE_LICENSE() string to be aligned with license text.

Signed-off-by: Andy Shevchenko 
---
 drivers/video/backlight/pwm_bl.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index fb45f866b923..1f7f8d5c0bf1 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -1,13 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
- * linux/drivers/video/backlight/pwm_bl.c
- *
- * simple PWM based backlight control, board code has to setup
+ * Simple PWM based backlight control, board code has to setup
  * 1) pin configuration so PWM waveforms can output
  * 2) platform_data being correctly configured
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #include 
@@ -708,5 +703,5 @@ static struct platform_driver pwm_backlight_driver = {
 module_platform_driver(pwm_backlight_driver);
 
 MODULE_DESCRIPTION("PWM based Backlight Driver");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
 MODULE_ALIAS("platform:pwm-backlight");
-- 
2.20.1

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

Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir

[Andrea Parri]

>  rename Documentation/{ => driver-api}/atomic_bitops.rst (99%)

Same here: NAK, this document does not belong to driver-api.

I also realize that, despite previous notices, you keep touching
documentation without even CC-ing the people who care...

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

Re: [PATCH v3 hmm 06/12] mm/hmm: Hold on to the mmget for the lifetime of the range

[Jason Gunthorpe]

On Wed, Jun 19, 2019 at 01:18:58AM -0700, Christoph Hellwig wrote:
> > mutex_lock(>lock);
> > -   list_del(>list);
> > +   list_del_init(>list);
> > mutex_unlock(>lock);
> 
> I don't see the point why this is a list_del_init - that just
> reinitializeѕ range->list, but doesn't change anything for the list
> head it was removed from.  (and if the list_del_init was intended
> a later patch in your branch reverts it to plain list_del..)

Just following the instructions:

/**
 * list_empty_careful - tests whether a list is empty and not being modified
 * @head: the list to test
 *
 * Description:
 * tests whether a list is empty _and_ checks that no other CPU might be
 * in the process of modifying either member (next or prev)
 *
 * NOTE: using list_empty_careful() without synchronization
 * can only be safe if the only activity that can happen
 * to the list entry is list_del_init(). Eg. it cannot be used
 * if another CPU could re-list_add() it.
 */

Agree it doesn't seem obvious why this is relevant when checking the
list head..

Maybe the comment is a bit misleading?

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

Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir

[Jonathan Corbet]

On Wed, 19 Jun 2019 12:42:39 +0200
Peter Zijlstra  wrote:

> No, the other way around, Sphinx can recognize local files and treat
> them special. That way we keep the text readable.
> 
> Same with that :c:func:'foo' crap, that needs to die, and Sphinx needs
> to be taught about foo().

I did a patch to make that latter part happen, but haven't been able to
find the time to address the comments and get it out there.  It definitely
cleaned up the source files a lot and is worth doing.  Will try to get
back to it soon.

The local file links should be easy to do; we shouldn't need to add any
markup for those.

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

Re: [PATCH v2 2/2] drm/panel: Add support for Raydium RM67191 panel driver

[Fabio Estevam]

On Tue, Jun 18, 2019 at 10:31 AM Robert Chiras  wrote:

> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> @@ -0,0 +1,709 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * i.MX drm driver - Raydium MIPI-DSI panel driver

Please remove the "i.MX drm driver" as there is nothing i.MX specific
in this driver.


> + *
> + * Copyright 2019 NXP
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Write Manufacture Command Set Control */
> +#define WRMAUCCTR 0xFE
> +
> +#define COL_FMT_16BPP 0x55
> +#define COL_FMT_18BPP 0x66
> +#define COL_FMT_24BPP 0x77
> +
> +/* Manufacturer Command Set pages (CMD2) */
> +struct cmd_set_entry {
> +   u8 cmd;
> +   u8 param;
> +};
> +
> +/*
> + * There is no description in the Reference Manual about these commands.
> + * We received them from vendor, so just use them as is.
> + */
> +static const struct cmd_set_entry manufacturer_cmd_set[] = {
> +   {0xFE, 0x0B},
> +   {0x28, 0x40},
> +   {0x29, 0x4F},
> +   {0xFE, 0x0E},
> +   {0x4B, 0x00},
> +   {0x4C, 0x0F},
> +   {0x4D, 0x20},
> +   {0x4E, 0x40},
> +   {0x4F, 0x60},
> +   {0x50, 0xA0},
> +   {0x51, 0xC0},
> +   {0x52, 0xE0},
> +   {0x53, 0xFF},
> +   {0xFE, 0x0D},
> +   {0x18, 0x08},
> +   {0x42, 0x00},
> +   {0x08, 0x41},
> +   {0x46, 0x02},
> +   {0x72, 0x09},
> +   {0xFE, 0x0A},
> +   {0x24, 0x17},
> +   {0x04, 0x07},
> +   {0x1A, 0x0C},
> +   {0x0F, 0x44},
> +   {0xFE, 0x04},
> +   {0x00, 0x0C},
> +   {0x05, 0x08},
> +   {0x06, 0x08},
> +   {0x08, 0x08},
> +   {0x09, 0x08},
> +   {0x0A, 0xE6},
> +   {0x0B, 0x8C},
> +   {0x1A, 0x12},
> +   {0x1E, 0xE0},
> +   {0x29, 0x93},
> +   {0x2A, 0x93},
> +   {0x2F, 0x02},
> +   {0x31, 0x02},
> +   {0x33, 0x05},
> +   {0x37, 0x2D},
> +   {0x38, 0x2D},
> +   {0x3A, 0x1E},
> +   {0x3B, 0x1E},
> +   {0x3D, 0x27},
> +   {0x3F, 0x80},
> +   {0x40, 0x40},
> +   {0x41, 0xE0},
> +   {0x4F, 0x2F},
> +   {0x50, 0x1E},
> +   {0xFE, 0x06},
> +   {0x00, 0xCC},
> +   {0x05, 0x05},
> +   {0x07, 0xA2},
> +   {0x08, 0xCC},
> +   {0x0D, 0x03},
> +   {0x0F, 0xA2},
> +   {0x32, 0xCC},
> +   {0x37, 0x05},
> +   {0x39, 0x83},
> +   {0x3A, 0xCC},
> +   {0x41, 0x04},
> +   {0x43, 0x83},
> +   {0x44, 0xCC},
> +   {0x49, 0x05},
> +   {0x4B, 0xA2},
> +   {0x4C, 0xCC},
> +   {0x51, 0x03},
> +   {0x53, 0xA2},
> +   {0x75, 0xCC},
> +   {0x7A, 0x03},
> +   {0x7C, 0x83},
> +   {0x7D, 0xCC},
> +   {0x82, 0x02},
> +   {0x84, 0x83},
> +   {0x85, 0xEC},
> +   {0x86, 0x0F},
> +   {0x87, 0xFF},
> +   {0x88, 0x00},
> +   {0x8A, 0x02},
> +   {0x8C, 0xA2},
> +   {0x8D, 0xEA},
> +   {0x8E, 0x01},
> +   {0x8F, 0xE8},
> +   {0xFE, 0x06},
> +   {0x90, 0x0A},
> +   {0x92, 0x06},
> +   {0x93, 0xA0},
> +   {0x94, 0xA8},
> +   {0x95, 0xEC},
> +   {0x96, 0x0F},
> +   {0x97, 0xFF},
> +   {0x98, 0x00},
> +   {0x9A, 0x02},
> +   {0x9C, 0xA2},
> +   {0xAC, 0x04},
> +   {0xFE, 0x06},
> +   {0xB1, 0x12},
> +   {0xB2, 0x17},
> +   {0xB3, 0x17},
> +   {0xB4, 0x17},
> +   {0xB5, 0x17},
> +   {0xB6, 0x11},
> +   {0xB7, 0x08},
> +   {0xB8, 0x09},
> +   {0xB9, 0x06},
> +   {0xBA, 0x07},
> +   {0xBB, 0x17},
> +   {0xBC, 0x17},
> +   {0xBD, 0x17},
> +   {0xBE, 0x17},
> +   {0xBF, 0x17},
> +   {0xC0, 0x17},
> +   {0xC1, 0x17},
> +   {0xC2, 0x17},
> +   {0xC3, 0x17},
> +   {0xC4, 0x0F},
> +   {0xC5, 0x0E},
> +   {0xC6, 0x00},
> +   {0xC7, 0x01},
> +   {0xC8, 0x10},
> +   {0xFE, 0x06},
> +   {0x95, 0xEC},
> +   {0x8D, 0xEE},
> +   {0x44, 0xEC},
> +   {0x4C, 0xEC},
> +   {0x32, 0xEC},
> +   {0x3A, 0xEC},
> +   {0x7D, 0xEC},
> +   {0x75, 0xEC},
> +   {0x00, 0xEC},
> +   {0x08, 0xEC},
> +   {0x85, 0xEC},
> +   {0xA6, 0x21},
> +   {0xA7, 0x05},
> +   {0xA9, 0x06},
> +   {0x82, 0x06},
> +   {0x41, 0x06},
> +   {0x7A, 0x07},
> +   {0x37, 0x07},
> +   {0x05, 0x06},
> +   {0x49, 0x06},
> +   {0x0D, 0x04},
> +   {0x51, 0x04},
> +};
> +
> +static const u32 rad_bus_formats[] = {
> +   MEDIA_BUS_FMT_RGB888_1X24,
> +   MEDIA_BUS_FMT_RGB666_1X18,
> +   MEDIA_BUS_FMT_RGB565_1X16,
> +};
> +
> +struct rad_panel {
> +   struct drm_panel panel;
> +   struct mipi_dsi_device *dsi;
> +
> +   struct gpio_desc *reset;
> +   struct backlight_device *backlight;
> +
> +   bool prepared;
> +   bool enabled;
> +
> +   struct videomode vm;
> +   u32 width_mm;
> +   u32 height_mm;
> +};
> +
> 

Re: [PATCH 1/3] dt-bindings: display: renesas: Add r8a774a1 support

[Simon Horman]

On Wed, Jun 19, 2019 at 08:08:09AM +, Fabrizio Castro wrote:
> Hi Laurent,
> 
> Thank you for your feedback!
> 
> > From: linux-renesas-soc-ow...@vger.kernel.org 
> >  On Behalf Of Laurent Pinchart
> > Sent: 18 June 2019 17:44
> > Subject: Re: [PATCH 1/3] dt-bindings: display: renesas: Add r8a774a1 support
> > 
> > Hi Fabrizio,
> > 
> > Thank you for the patch.
> > 
> > On Tue, Jun 18, 2019 at 04:18:37PM +0100, Fabrizio Castro wrote:
> > > Document RZ/G2M (R8A774A1) SoC bindings.
> > >
> > > Signed-off-by: Fabrizio Castro 
> > 
> > Reviewed-by: Laurent Pinchart 
> > 
> > I don't have pending changes for this file for this kernel release. As
> > your series contains DT changes, I'm fine if this patch gets merged
> > through the ARM SoC tree along with the rest. Otherwise please let me
> > know if I should handle it myself.
> 
> Thank you Laurent, I think this patch can go along with the rest, if that's 
> OK with
> Simon?

Thanks,

I've queued this up in the renesas tree for inclusion in v5.3.

[Bug 110949] Continuious warnings from agd5f 5.3-wip branch

[bugzilla-daemon]

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

--- Comment #2 from Mike Lothian  ---
It reverts cleanly and the warnings go away once its gone

-- 
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 110949] Continuious warnings from agd5f 5.3-wip branch

[bugzilla-daemon]

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

Mike Lothian  changed:

   What|Removed |Added

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

--- Comment #1 from Mike Lothian  ---
37fb6e8a96fbc9c809c58f9490267ffe7101ac33 is the first bad commit
commit 37fb6e8a96fbc9c809c58f9490267ffe7101ac33
Author: Nicholas Kazlauskas 
Date:   Fri Jun 7 11:16:55 2019 -0400

drm/amd/display: Enable fast plane updates when state->allow_modeset = true

[Why]
Whenever the a modeset is allowed (but not neccessarily required) we
currently recreate all the planes in the state. Most IGT tests and
legacy IOCTLs create atomic commits with this flag set, so the pipes
are often unnecessarily reprogrammed.

Poor performance and stuttering can occur when many of these commits
are frequently issued.

This flag was needed when the appropriate conditions for checking
whether the planes needed a reset were not in place, but
should_reset_plane should cover everything needed now.

[How]
Drop the check for state->allow_modeset in should_reset_plane.

All planes on a CRTC should reset in the following conditions:
- The CRTC needs a modeset
- The CRTC degamma changes
- Planes are added or removed to the CRTC

These conditions are all covered in should_reset_plane.

We still can't drop the format change check in should_reset_plane since
fill_dc_plane_info_and_addr isn't called when validating the state, so
we can't tell if a FULL update is needed or not.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: David Francis 
Signed-off-by: Alex Deucher 

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 
 1 file changed, 8 deletions(-)

-- 
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: [PULL] topic/remove-fbcon-notifiers for v5.3

[Bartlomiej Zolnierkiewicz]

On 6/18/19 1:46 PM, Maarten Lankhorst wrote:
> Op 18-06-2019 om 13:17 schreef Bartlomiej Zolnierkiewicz:
>> Hi,
>>
>> On 6/18/19 11:20 AM, Maarten Lankhorst wrote:
>>> Op 14-06-2019 om 11:25 schreef Maarten Lankhorst:
 Hi all,

 As discussed with Daniel V, I'm just doing the paperwork here as drm-misc 
 maintainer.

 This is the topic pull request for the fbdev notifier removal.

 Bar, please make a final check and pull into your fbdev tree.

 Lee, please make a final check and pull into your backlight tree.

 Greg, this is just fyi, you already acked all the vt and staging patches 
 in here
 to land through other trees.

 I'll pull this into drm-misc-next once Bart & Lee acked it.

 Cheers, Maarten.
>>> Bart, Lee, ping?
>> Looks OK to me (I have test pulled it locally and there is only trivial
>> merge conflict on removed mxsfb fbdev driver) but it seems that all
>> patches miss your "S-o-B:" line (there is only "Reviewed-by:" tag which
>> is OK but has a different meaning)?
> 
> Hey,
> 
> I created the topic branch, but daniel pushed the patches to it. :)
> 
> That explains why there's a R-B but no S-o-B.

I see, that's kind of interesting work-flow.. :)

Anyway, I've pulled topic/remove-fbcon-notifiers-2019-06-14-1 tag
(and also topic/remove-fbcon-notifiers branch to get a buildfix)
into fbdev-for-next, thanks!

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

> Cheers,
> 
> Maarten
> 
>> Best regards,
>> --
>> Bartlomiej Zolnierkiewicz
>> Samsung R Institute Poland
>> Samsung Electronics
>>
 topic/remove-fbcon-notifiers-2019-06-14-1:
 
 topic/remove-fbcon-notifiers:
 - remove fbdev notifier usage for fbcon, as prep work to clean up the 
 fbcon locking
 - assorted locking checks in vt/console code
 - assorted notifier and cleanups in fbdev and backlight code

 The following changes since commit 
 d1fdb6d8f6a4109a4263176c84b899076a5f8008:

   Linux 5.2-rc4 (2019-06-08 20:24:46 -0700)

 are available in the Git repository at:

   git://anongit.freedesktop.org/drm/drm-misc 
 tags/topic/remove-fbcon-notifiers-2019-06-14-1

 for you to fetch changes up to 1dcff4ae65185e8c0300972f6d8d39d9a9db2bda:

   backlight: simplify lcd notifier (2019-06-13 10:07:20 +0200)

 
 Daniel Vetter (33):
   dummycon: Sprinkle locking checks
   fbdev: locking check for fb_set_suspend
   vt: might_sleep() annotation for do_blank_screen
   vt: More locking checks
   fbdev/sa1100fb: Remove dead code
   fbdev/cyber2000: Remove struct display
   fbdev/aty128fb: Remove dead code
   fbcon: s/struct display/struct fbcon_display/
   fbcon: Remove fbcon_has_exited
   fbcon: call fbcon_fb_(un)registered directly
   fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify
   fbdev/omap: sysfs files can't disappear before the device is gone
   fbdev: sysfs files can't disappear before the device is gone
   staging/olpc: lock_fb_info can't fail
   fbdev/atyfb: lock_fb_info can't fail
   fbdev: lock_fb_info cannot fail
   fbcon: call fbcon_fb_bind directly
   fbdev: make unregister/unlink functions not fail
   fbdev: unify unlink_framebuffer paths
   fbdev/sh_mob: Remove fb notifier callback
   fbdev: directly call fbcon_suspended/resumed
   fbcon: Call fbcon_mode_deleted/new_modelist directly
   fbdev: Call fbcon_get_requirement directly
   Revert "backlight/fbcon: Add FB_EVENT_CONBLANK"
   fbmem: pull fbcon_fb_blanked out of fb_blank
   fbdev: remove FBINFO_MISC_USEREVENT around fb_blank
   fb: Flatten control flow in fb_set_var
   fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls
   vgaswitcheroo: call fbcon_remap_all directly
   fbcon: Call con2fb_map functions directly
   fbcon: Document what I learned about fbcon locking
   staging/olpc_dcon: Add drm conversion to TODO
   backlight: simplify lcd notifier

  arch/arm/mach-pxa/am200epd.c|  13 +-
  drivers/gpu/vga/vga_switcheroo.c|  11 +-
  drivers/media/pci/ivtv/ivtvfb.c |   6 +-
  drivers/staging/fbtft/fbtft-core.c  |   4 +-
  drivers/staging/olpc_dcon/TODO  |   7 +
  drivers/staging/olpc_dcon/olpc_dcon.c   |   6 +-
  drivers/tty/vt/vt.c |  18 ++
  drivers/video/backlight/backlight.c |   2 +-
  drivers/video/backlight/lcd.c   |  12 -
  drivers/video/console/dummycon.c|   6 +
  

[Bug 110702] segfault in radeonsi HEVC hardware decoding with yuv420p10le

[bugzilla-daemon]

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

--- Comment #11 from Pierre-Eric Pelloux-Prayer 
 ---
(In reply to Christian König from comment #10)
> (In reply to Pierre-Eric Pelloux-Prayer from comment #9)
> > The driver fails when trying to allocate a buffer for this video with a
> > ENOMEM error (the requested size is 3 GB).
> 
> Well that strongly sounds like we miscalculated the necessary size somewhere.

Indeed.
The size is computed by the `calc_ctx_size_h265_main10()` function.

I'm not familiar enough with hevc to fix it though (but the calculation seems
to overflow because context_buffer_size_per_ctb_row is 1GB and is multiplied by
max_references (= 23) and the result is stored in an unsigned int).

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

Re: [PATCH v2 2/2] drm/panel: Add support for Raydium RM67191 panel driver

[Fabio Estevam]

Hi Robert,

On Tue, Jun 18, 2019 at 10:31 AM Robert Chiras  wrote:

> +static const struct display_timing rad_default_timing = {
> +   .pixelclock = { 6600, 13200, 13200 },
> +   .hactive = { 1080, 1080, 1080 },
> +   .hfront_porch = { 20, 20, 20 },
> +   .hsync_len = { 2, 2, 2 },
> +   .hback_porch = { 34, 34, 34 },
> +   .vactive = { 1920, 1920, 1920 },
> +   .vfront_porch = { 10, 10, 10 },
> +   .vsync_len = { 2, 2, 2 },
> +   .vback_porch = { 4, 4, 4 },

Are you sure that the sync_len and porch parameters are the same for
both 66MHz and 132MHz?

Re: [PATCH v2 2/2] drm/panel: Add support for Raydium RM67191 panel driver

[Sam Ravnborg]

On Tue, Jun 18, 2019 at 04:30:46PM +0300, Robert Chiras wrote:
> This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI
> protocol).
> 
> Signed-off-by: Robert Chiras 
Please include in the changelog a list of what was updated - like this:

v2:
- added kconif symbol sorted (sam)
- another nitpick (foo)
- etc

In general try to namme who gave feedback to give them some credit.

Who is maintainer for this onwards?

> ---
>  drivers/gpu/drm/panel/Kconfig |   9 +
>  drivers/gpu/drm/panel/Makefile|   1 +
>  drivers/gpu/drm/panel/panel-raydium-rm67191.c | 709 
> ++
>  3 files changed, 719 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-raydium-rm67191.c
> 
> +static int rad_panel_prepare(struct drm_panel *panel)
> +{
> + struct rad_panel *rad = to_rad_panel(panel);
> +
> + if (rad->prepared)
> + return 0;
> +
> + if (rad->reset) {
> + gpiod_set_value_cansleep(rad->reset, 1);
> + usleep_range(3000, 5000);
> + gpiod_set_value_cansleep(rad->reset, 0);

So writing a 0 will release reset.
> + usleep_range(18000, 2);
> + }
> +
> + rad->prepared = true;
> +
> + return 0;
> +}
> +
> +static int rad_panel_unprepare(struct drm_panel *panel)
> +{
> + struct rad_panel *rad = to_rad_panel(panel);
> +
> + if (!rad->prepared)
> + return 0;
> +
> + if (rad->reset) {
> + gpiod_set_value_cansleep(rad->reset, 1);
> + usleep_range(15000, 17000);
> + gpiod_set_value_cansleep(rad->reset, 0);
Looks strange that reset is released in unprepare.
I would expect it to stay reset to minimize power etc.

> +
> + ret = drm_display_info_set_bus_formats(>display_info,
> +rad_bus_formats,
> +ARRAY_SIZE(rad_bus_formats));

Other drivers has this as the last stement in their enable function.
I did not check why, but maybe something to invest a few minutes into.
Be different only if there is a reason to do so.

> + if (ret)
> + return ret;
> +
> + drm_mode_probed_add(panel->connector, mode);
> +
> + return 1;
> +}
> +
> +
> +#ifdef CONFIG_PM
> +static int rad_panel_suspend(struct device *dev)
> +{
> + struct rad_panel *rad = dev_get_drvdata(dev);
> +
> + if (!rad->reset)
> + return 0;
> +
> + devm_gpiod_put(dev, rad->reset);
> + rad->reset = NULL;
> +
> + return 0;
> +}
> +
> +static int rad_panel_resume(struct device *dev)
> +{
> + struct rad_panel *rad = dev_get_drvdata(dev);
> +
> + if (rad->reset)
> + return 0;
> +
> + rad->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(rad->reset))
> + rad->reset = NULL;
> +
> + return PTR_ERR_OR_ZERO(rad->reset);
> +}
> +
> +#endif

Use __maybe_unused for the tw functions above.
And loose the ifdef...

> +
> +static const struct dev_pm_ops rad_pm_ops = {
> + SET_RUNTIME_PM_OPS(rad_panel_suspend, rad_panel_resume, NULL)
> + SET_SYSTEM_SLEEP_PM_OPS(rad_panel_suspend, rad_panel_resume)
> +};
> +
> +static const struct of_device_id rad_of_match[] = {
> + { .compatible = "raydium,rm67191", },
> + { }
We often, but not always, write this as { /* sentinal */ },

> +};
> +MODULE_DEVICE_TABLE(of, rad_of_match);
> +
> +static struct mipi_dsi_driver rad_panel_driver = {
> + .driver = {
> + .name = "panel-raydium-rm67191",
> + .of_match_table = rad_of_match,
> + .pm = _pm_ops,
> + },
> + .probe = rad_panel_probe,
> + .remove = rad_panel_remove,
> + .shutdown = rad_panel_shutdown,
> +};
> +module_mipi_dsi_driver(rad_panel_driver);
> +
> +MODULE_AUTHOR("Robert Chiras ");
> +MODULE_DESCRIPTION("DRM Driver for Raydium RM67191 MIPI DSI panel");
> +MODULE_LICENSE("GPL v2");

With the above trivialities considered/fixed:
Reviewed-by: Sam Ravnborg 

Sam

[Bug 110949] Continuious warnings from agd5f 5.3-wip branch

[bugzilla-daemon]

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

Bug ID: 110949
   Summary: Continuious warnings from agd5f 5.3-wip branch
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: m...@fireburn.co.uk

Created attachment 144594
  --> https://bugs.freedesktop.org/attachment.cgi?id=144594=edit
Compressed log

Jun 19 14:20:01 quark kernel: [drm] pstate TEST_DEBUG_DATA: 0x36F6F00F
Jun 19 14:20:01 quark kernel: WARNING: CPU: 6 PID: 229 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:872
dcn10_verify_allow_pstate_change_high+0x20/0x240
Jun 19 14:20:01 quark kernel: Modules linked in:
Jun 19 14:20:01 quark kernel: CPU: 6 PID: 229 Comm: kworker/u32:8 Tainted: G   
W 5.2.0-rc2-agd5f+ #380
Jun 19 14:20:01 quark kernel: Hardware name: System manufacturer System Product
Name/ROG STRIX X470-I GAMING, BIOS 2202 04/11/2019
Jun 19 14:20:01 quark kernel: Workqueue: events_unbound commit_work
Jun 19 14:20:01 quark kernel: RIP:
0010:dcn10_verify_allow_pstate_change_high+0x20/0x240
Jun 19 14:20:01 quark kernel: Code: 66 2e 0f 1f 84 00 00 00 00 00 55 53 48 89
fb 48 8b 87 80 02 00 00 48 8b b8 b0 01 00 00 e8 28 02 01 00 84 c0 0f 85 1b 02
00 00 <0f> 0b 80 bb 97 01 00 00 00 0f 84 0c 02 00 00 48 8b 83 80 02 00 00
Jun 19 14:20:01 quark kernel: RSP: 0018:c949fb00 EFLAGS: 00010246
Jun 19 14:20:01 quark kernel: RAX:  RBX: 8887fbc38000 RCX:

Jun 19 14:20:01 quark kernel: RDX:  RSI: 00b96148 RDI:

Jun 19 14:20:01 quark kernel: RBP: c949fb78 R08: 0400 R09:
000140f9
Jun 19 14:20:01 quark kernel: R10: 0007 R11:  R12:
8887fbc38000
Jun 19 14:20:01 quark kernel: R13: 8887fb404800 R14: 0001 R15:
0004
Jun 19 14:20:01 quark kernel: FS:  ()
GS:00b8() knlGS:
Jun 19 14:20:01 quark kernel: CS:  0010 DS:  ES:  CR0: 80050033
Jun 19 14:20:01 quark kernel: CR2: 7fcaaf660368 CR3: 0007efd26000 CR4:
003406a0
Jun 19 14:20:01 quark kernel: Call Trace:
Jun 19 14:20:01 quark kernel:  ? dc_commit_updates_for_stream+0xa7e/0xec0
Jun 19 14:20:01 quark kernel:  ?
amdgpu_dm_commit_planes.constprop.0+0x70c/0x910
Jun 19 14:20:01 quark kernel:  ? amdgpu_dm_atomic_commit_tail+0x359/0xde0
Jun 19 14:20:01 quark kernel:  ? load_balance+0x177/0x9e0
Jun 19 14:20:01 quark kernel:  ? sched_clock_cpu+0x10/0xd0
Jun 19 14:20:01 quark kernel:  ? preempt_count_add+0x74/0xa0
Jun 19 14:20:01 quark kernel:  ? _raw_spin_lock_irq+0xf/0x30
Jun 19 14:20:01 quark kernel:  ? _raw_spin_unlock_irq+0xe/0x20
Jun 19 14:20:01 quark kernel:  ? wait_for_completion_timeout+0xe3/0x110
Jun 19 14:20:01 quark kernel:  ? _raw_spin_unlock_irq+0xe/0x20
Jun 19 14:20:01 quark kernel:  ? finish_task_switch+0x7a/0x240
Jun 19 14:20:01 quark kernel:  ? __update_idle_core+0x1b/0xa0
Jun 19 14:20:01 quark kernel:  ? commit_tail+0x34/0x60
Jun 19 14:20:01 quark kernel:  ? commit_tail+0x34/0x60
Jun 19 14:20:01 quark kernel:  ? process_one_work+0x199/0x310
Jun 19 14:20:01 quark kernel:  ? worker_thread+0x45/0x3c0
Jun 19 14:20:01 quark kernel:  ? kthread+0xf8/0x130
Jun 19 14:20:01 quark kernel:  ? wq_update_unbound_numa+0x10/0x10
Jun 19 14:20:01 quark kernel:  ? kthread_park+0x80/0x80
Jun 19 14:20:01 quark kernel:  ? ret_from_fork+0x1f/0x30
Jun 19 14:20:01 quark kernel: ---[ end trace 25db1648dbe2f9f1 ]---

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

Re: [PATCH v2 1/2] dt-bindings: display: panel: Add support for Raydium RM67191 panel

[Fabio Estevam]

Hi Robert,

On Tue, Jun 18, 2019 at 10:33 AM Robert Chiras  wrote:

> +Optional properties:
> +- reset-gpios: a GPIO spec for the RST_B GPIO pin
> +- pinctrl-0phandle to the pin settings for the reset pin
> +- width-mm:physical panel width [mm]
> +- height-mm:   physical panel height [mm]
> +- display-timings: timings for the connected panel according to [1]

Still not convinced we need the 'display-timings' property, even as an
optional property. My understanding is that passing display timings in
the devicetree is not encouraged.

Last time you said you need to pass ''display-timings' to workaround
the problem of connecting this panel to mx8m DCSS or eLCDIF.

The panel timings come from the LCD manufacturer and it is agnostic to
what display controller interface it is connected to.

So I suggest making sure the timings passed in the driver are correct
as per the vendor datasheet. If they are correct and one specific
interface is not able to drive it, then probably it is a bug in this
specific display controller interface or in the SoC clock driver.

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

[Ezequiel Garcia]

On Wed, 2019-06-19 at 06:20 +, Shankar, Uma wrote:
> > -Original Message-
> > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf 
> > Of
> > Ezequiel Garcia
> > Sent: Friday, June 14, 2019 9:48 PM
> > To: Shankar, Uma 
> > Cc: Emil Velikov ; 
> > intel-...@lists.freedesktop.org; Syrjala,
> > Ville ; Lankhorst, Maarten 
> > ;
> > dri-devel 
> > Subject: Re: [v7 00/16] Add Plane Color Properties
> > 
> > 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_req
> > > uests/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 

[Bug 110702] segfault in radeonsi HEVC hardware decoding with yuv420p10le

[bugzilla-daemon]

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

--- Comment #10 from Christian König  ---
(In reply to Pierre-Eric Pelloux-Prayer from comment #9)
> The driver fails when trying to allocate a buffer for this video with a
> ENOMEM error (the requested size is 3 GB).

Well that strongly sounds like we miscalculated the necessary size somewhere.

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

Re: [PATCH v2 1/2] dt-bindings: display: panel: Add support for Raydium RM67191 panel

[Sam Ravnborg]

Hi Robert.

Thanks for the contribution.

On Tue, Jun 18, 2019 at 04:30:45PM +0300, Robert Chiras wrote:
> Add dt-bindings documentation for Raydium RM67191 DSI panel.
> 
> Signed-off-by: Robert Chiras 
> ---
>  .../bindings/display/panel/raydium,rm67191.txt | 43 
> ++
>  1 file changed, 43 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt 
> b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
> new file mode 100644
> index 000..0952610
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
> @@ -0,0 +1,43 @@
> +Raydium RM67171 OLED LCD panel with MIPI-DSI protocol
> +
> +Required properties:
> +- compatible:"raydium,rm67191"
> +- reg:   virtual channel for MIPI-DSI protocol
> + must be <0>
> +- dsi-lanes: number of DSI lanes to be used
> + must be <3> or <4>
> +- port:  input port node with endpoint definition as
> + defined in Documentation/devicetree/bindings/graph.txt;
> + the input port should be connected to a MIPI-DSI device
> + driver
> +
> +Optional properties:
> +- reset-gpios:   a GPIO spec for the RST_B GPIO pin
> +- pinctrl-0  phandle to the pin settings for the reset pin
pinctrl is not included in bindings, they are implicit.

> +- width-mm:  physical panel width [mm]
> +- height-mm: physical panel height [mm]
Please refer to panel-common.txt for the above.

> +- display-timings:   timings for the connected panel according to [1]
> +- video-mode:0 - burst-mode
> + 1 - non-burst with sync event
> + 2 - non-burst with sync pulse
> +
> +[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
> +
> +Example:
> +
> + panel@0 {
> + compatible = "raydium,rm67191";
> + reg = <0>;
> + pinctrl-0 = <_mipi_dsi_0_1_en>;
> + pinctrl-names = "default";
> + reset-gpios = < 7 GPIO_ACTIVE_LOW>;
> + dsi-lanes = <4>;
> + width-mm = <68>;
> + height-mm = <121>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };

With the above fixed:
Signed-off-by: Sam Ravnborg 

Note: You need r-b from DT maintainer before we can apply it.

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

[Bug 110702] segfault in radeonsi HEVC hardware decoding with yuv420p10le

[bugzilla-daemon]

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

--- Comment #9 from Pierre-Eric Pelloux-Prayer 
 ---
Thanks, I could reproduce on a Raven setup using the files from comment 7 and
8.

The driver fails when trying to allocate a buffer for this video with a ENOMEM
error (the requested size is 3 GB).

-- 
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 v1 12/22] docs: driver-api: add .rst files from the main dir

[Mauro Carvalho Chehab]

Em Wed, 19 Jun 2019 12:42:39 +0200
Peter Zijlstra  escreveu:

> On Wed, Jun 19, 2019 at 07:22:18AM -0300, Mauro Carvalho Chehab wrote:
> > Hi Daniel,
> > 
> > Em Wed, 19 Jun 2019 11:05:57 +0200
> > Daniel Vetter  escreveu:
> >   
> > > On Tue, Jun 18, 2019 at 10:55 PM Mauro Carvalho Chehab
> > >  wrote:  
> > > > diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> > > > index fa30dfcfc3c8..b0f948d8733b 100644
> > > > --- a/Documentation/gpu/drm-mm.rst
> > > > +++ b/Documentation/gpu/drm-mm.rst
> > > > @@ -320,7 +320,7 @@ struct :c:type:`struct file_operations 
> > > > ` get_unmapped_area
> > > >  field with a pointer on :c:func:`drm_gem_cma_get_unmapped_area`.
> > > >
> > > >  More detailed information about get_unmapped_area can be found in
> > > > -Documentation/nommu-mmap.rst
> > > > +Documentation/driver-api/nommu-mmap.rst
> > > 
> > > Random drive-by comment: Could we convert these into hyperlinks within
> > > sphinx somehow, without making them less useful as raw file references
> > > (with vim I can just type 'gf' and it works, emacs probably the same).
> > > -Daniel  
> > 
> > Short answer: I don't know how vim/emacs would recognize Sphinx tags.  
> 
> No, the other way around, Sphinx can recognize local files and treat
> them special. That way we keep the text readable.
> 
> Same with that :c:func:'foo' crap, that needs to die, and Sphinx needs
> to be taught about foo().

Just did a test today at Jon's extension (with is currently on a
separate branch). At least the version that it is there at his automarkup
branch still needs some work, as it currently breaks titles and tables:

6.4 :c:func:`resync_start()`, :c:func:`resync_finish()`
---
/devel/v4l/docs/Documentation/driver-api/md/md-cluster.rst:323: 
WARNING: Title underline too short.


/devel/v4l/docs/Documentation/driver-api/serial/tty.rst:74: WARNING: 
Malformed table.
Text in column margin in table line 34.

=== 
===
:c:func:`open()`Called when the line discipline 
is attached to

-

That's said, once it gets fixed to address those complex cases, a
regex like:

\bDocumentation/([\w\d\-\_\/]+)\.rst\b

could be converted to :doc: tag. It should be smart enough to convert
the relative paths, as we refer to the files from the git root directory
(with makes a lot sense to me), while Sphinx :doc: use relative patches
from the location where the parsed file is.

Something like the enclosed patch.

Thanks,
Mauro

[PATCH] automarkup.py: convert Documentation/* to hyperlinks

Auto-create hyperlinks when it finds a Documentation/.. occurrence.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/sphinx/automarkup.py 
b/Documentation/sphinx/automarkup.py
index 39c8f4d5af82..9d6926b61241 100644
--- a/Documentation/sphinx/automarkup.py
+++ b/Documentation/sphinx/automarkup.py
@@ -9,6 +9,7 @@
 from __future__ import print_function
 import re
 import sphinx
+#import sys# Just for debug
 
 #
 # Regex nastiness.  Of course.
@@ -31,10 +32,26 @@ RE_literal = 
re.compile(r'^(\s*)(.*::\s*|\.\.\s+code-block::.*)$')
 #
 RE_whitesp = re.compile(r'^(\s*)')
 
+#
+# Get a documentation reference
+#
+RE_doc_links = re.compile(r'\bDocumentation/([\w\d\-\_\/]+)\.rst\b')
+
+#
+# Doc link false-positives
+#
+RE_false_doc_links = re.compile(r':ref:`\s*Documentation/[\w\d\-\_\/]+\.rst')
+
 def MangleFile(app, docname, text):
 ret = [ ]
 previous = ''
 literal = False
+
+rel_dir = ''
+
+for depth in range(0, docname.count('/')):
+rel_dir += "../"
+
 for line in text[0].split('\n'):
 #
 # See if we might be ending a literal block, as denoted by
@@ -63,7 +80,17 @@ def MangleFile(app, docname, text):
 # Normal line - perform substitutions.
 #
 else:
-ret.append(RE_function.sub(r'\1:c:func:`\2`\3', line))
+new_line = RE_function.sub(r'\1:c:func:`\2`\3', line)
+
+if not RE_false_doc_links.search(new_line):
+new_line = RE_doc_links.sub(r':doc:`' + rel_dir + r'\1`', 
new_line)
+
+ #   # Just for debug - should be removed on production
+ #   if new_line != line:
+ #   print ("===>" + new_line, file=sys.stderr)
+
+ret.append(new_line)
+
 #
 # Might we be starting a literal block?  If so make note of
 # the fact.



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

[Bug 109456] KVM VFIO guest X hang with guest kernel > 4.15

[bugzilla-daemon]

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

--- Comment #7 from Alex Williamson  ---
Can you test this QEMU patch that's already in qemu.git for 4.1:

https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3412d8ec9810b819f8b79e8e0c6b87217c876e32

Alternatively, setting the pci-hole64-size=0 can also avoid this issue:

 -global i440FX-pcihost.pci-hole64-size=0

or

 -global q35-host.pci-hole64-size=0

depending on your VM machine type.

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

Re: [PATCH 2/2] drm/prime: Update docs

[Noralf Trønnes]

Den 18.06.2019 11.20, skrev 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.
> 
> - Document all the hooks in _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.
> 
> v3:
> - Split out the function moving. This patch is now exclusively
>   documentation changes.
> - Typos and nits (Sam).
> 
> Cc: Sam Ravnborg 
> Cc: Eric Anholt 
> Cc: Emil Velikov 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-mm.rst |  40 +--
>  drivers/gpu/drm/drm_prime.c  | 197 +--
>  include/drm/drm_drv.h| 104 +++---
>  include/drm/drm_gem.h|  18 ++--
>  4 files changed, 226 insertions(+), 133 deletions(-)
> 



> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 68b4de85370c..2234206288fa 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 _buf itself is dropped and its
> - * _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 is destroyed, we remove the attachment
> - * and drop the reference to the dma_buf.
> - *
> - * When all the references to the _buf are dropped, i.e. when
> - * userspace has closed both handles to the imported GEM object (through the
> - * FD_TO_HANDLE IOCTL) and closed the file descriptor of the exported
> - * (through the HANDLE_TO_FD IOCTL) dma_buf, and all kernel-internal 
> references
> - * are also gone, then the dma_buf gets destroyed.  This can also happen as a
> - * part of the clean up procedure in the drm_release() function if userspace
> - * fails to properly clean up.  Note that both the kernel and userspace (by
> - * keeeping the PRIME file descriptors open) can hold references onto a
> - * _buf.
> - *
> - * Thus the chain of references always flows in one direction
> - * (avoiding loops): importing_gem -> dmabuf -> exporting_gem
> - *
> - * Self-importing: if userspace is using PRIME as a replacement for flink
> - * then it will get a fd->handle request for a GEM object that it created.
> - * Drivers should detect this situation and return back the gem object
> - * from the dma-buf private.  Prime will do this automatically for drivers 
> that
> - * use the drm_gem_prime_{import,export} helpers.
> - *
> - * GEM struct _buf_ops symbols are now exported. They can be resued by
> - * drivers which implement GEM interface.
> +/**
> + * DOC: 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
> + * _driver.driver_features field, and implement the
> + * _driver.prime_handle_to_fd and _driver.prime_fd_to_handle 
> operations.
> + * GEM based drivers must use drm_gem_prime_handle_to_fd() and
> + * drm_gem_prime_fd_to_handle() to implement these. For GEM based drivers the
> + * actual driver interfaces is provided through the 
> _gem_object_funcs.export
> + * and _driver.gem_prime_import hooks.
> + *

[PULL] drm-intel-next

[Jani Nikula]

Hi Dave & Daniel, final i915 feature pull for v5.3.

While I'll follow up with i915 fixes leading to the v5.3 release, I'll
pass the drm-intel-next baton to Rodrigo who'll take care of v5.4.

BR,
Jani.

drm-intel-next-2019-06-19:
Features:
- HDR support (Uma, Ville)
- Add I2C symlink under HDMI connector similar to DP (Oleg)
- Add ICL multi-segmented gamma support (Shashank, Uma)
- Update register whitelist support for new hardware (Robert, John)
- GuC firmware update with updated ABI interface (Michal, Oscar)
- Add support for new DMC header versions (Lucas)
- In-kernel blitter client for selftest use (Matthew)
- Add Mule Creec Canyon (MCC) PCH support to go with EHL (Matt)
- EHL platform feature updates (Matt)
- Use Command Transport Buffers with GuC on all gens (Daniele)
- New i915.force_probe module parameter to replace i915.alpha_support (Jani)

Refactoring:
- Better runtime PM code abstraction/encapsulation (Daniele)
- VBT parsing cleanup and improvements (Jani)
- Move display code to its own subdirectory (Jani)
- Header cleanup (Jani, Daniele)
- Prep work for subsclice mask expansion (Stuart)
- Use uncore mmio register accessors more, remove unused macro wrappers (Tvrtko)
- Remove unused atomic property get/set stubs (Maarten)
- GTT cleanups and improvements (Mika)
- Pass intel_ types instead of drm_ types in plenty of display code (Ville)
- Engine reset, hangcheck, fault code cleanups and improvements (Tvrtko)
- Consider AML variants simply as either KBL or CFL ULX (Ville)
- State checker cleanups and improvements (Ville)
- GEM code reorganization to more files under gem subdirectory (Chris)
- Reducing dependency on a coarse struct_mutex (Chris)

Fixes:
- Fix use of uninitialized/incorrect error pointers (Colin, Dan)
- Fix DSI fastboot on some VLV/CHV platforms (Hans)
- Fix DSI error path (Hans)
- Add ICL port A combo PHY HW state check (Imre)
- Fix ICL AUX-B HW not done issue (Imre)
- Fix perf whitelist on gen10+ (Lionel)
- Fix PSR exit by forcing manual exit on older gens (José)
- Match voltage ranges instead of exact values (Lucas)
- Fix SDVO HDMI audio, with cleanups (Ville)
- Fix plane state dumps (Ville)
- Fix driver cleanup code to support driver hot unbind (Janusz)
- Add checks for ICL memory bandwidth requirements (Ville)
- Fix toggling between no C8 planes vs. at least one C8 plane (Ville)
- Improved checks on PLL usage conditions, refactoring (Ville)
- Avoid clobbering M/N values in fastset fuzzy checks (Ville)
- Take a runtime pm wakeref for atomic commits (Chris)
- Do not allow runtime pm autosuspend to remove userspace GGTT mmaps too 
quickly (Chris)
- Avoid refcount_inc on known zero count to avoid debug flagging (Chris)

BR,
Jani.

The following changes since commit 14ee642c2ab0a3d8a1ded11fade692d8b77172b9:

  Merge tag 'drm-intel-next-2019-05-24' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2019-05-28 09:26:52 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2019-06-19

for you to fetch changes up to 1ee008f240ad5401f683ec3b79a2e3b044a82a89:

  drm/i915: Update DRIVER_DATE to 20190619 (2019-06-19 15:32:25 +0300)


Features:
- HDR support (Uma, Ville)
- Add I2C symlink under HDMI connector similar to DP (Oleg)
- Add ICL multi-segmented gamma support (Shashank, Uma)
- Update register whitelist support for new hardware (Robert, John)
- GuC firmware update with updated ABI interface (Michal, Oscar)
- Add support for new DMC header versions (Lucas)
- In-kernel blitter client for selftest use (Matthew)
- Add Mule Creec Canyon (MCC) PCH support to go with EHL (Matt)
- EHL platform feature updates (Matt)
- Use Command Transport Buffers with GuC on all gens (Daniele)
- New i915.force_probe module parameter to replace i915.alpha_support (Jani)

Refactoring:
- Better runtime PM code abstraction/encapsulation (Daniele)
- VBT parsing cleanup and improvements (Jani)
- Move display code to its own subdirectory (Jani)
- Header cleanup (Jani, Daniele)
- Prep work for subsclice mask expansion (Stuart)
- Use uncore mmio register accessors more, remove unused macro wrappers (Tvrtko)
- Remove unused atomic property get/set stubs (Maarten)
- GTT cleanups and improvements (Mika)
- Pass intel_ types instead of drm_ types in plenty of display code (Ville)
- Engine reset, hangcheck, fault code cleanups and improvements (Tvrtko)
- Consider AML variants simply as either KBL or CFL ULX (Ville)
- State checker cleanups and improvements (Ville)
- GEM code reorganization to more files under gem subdirectory (Chris)
- Reducing dependency on a coarse struct_mutex (Chris)

Fixes:
- Fix use of uninitialized/incorrect error pointers (Colin, Dan)
- Fix DSI fastboot on some VLV/CHV platforms (Hans)
- Fix DSI error path (Hans)
- Add ICL port A combo PHY HW state check (Imre)
- Fix ICL AUX-B HW not done issue (Imre)
- Fix perf whitelist on gen10+ (Lionel)
- Fix PSR 

Re: [PATCH v2 1/2] dt-bindings: display: Add King Display KD035G6-54NT panel documentation

[Sam Ravnborg]

On Mon, Jun 03, 2019 at 05:25:54PM +0200, Paul Cercueil wrote:
> The KD035G6-54NT is a 3.5" 320x240 24-bit TFT LCD panel.
> 
> Signed-off-by: Paul Cercueil 
Reviewed-by: Sam Ravnborg 

Rob - ping for review.

Sam

> ---
> 
> Notes:
> v2: - Add an address to the panel node
>   - Add information about SPI properties
>   - Add information about the 'port' sub-node
> 
>  .../panel/kingdisplay,kd035g6-54nt.txt| 42 +++
>  1 file changed, 42 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt
>  
> b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt
> new file mode 100644
> index ..fa9596082e44
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt
> @@ -0,0 +1,42 @@
> +King Display KD035G6-54NT 3.5" (320x240 pixels) 24-bit TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "kingdisplay,kd035g6-54nt"
> +- power-supply: See panel-common.txt
> +- reset-gpios: See panel-common.txt
> +
> +Optional properties:
> +- backlight: see panel-common.txt
> +
> +The generic bindings for the SPI slaves documented in [1] also apply.
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in [2]. This
> +node should describe panel's video bus.
> +
> +[1]: Documentation/devicetree/bindings/spi/spi-bus.txt
> +[2]: Documentation/devicetree/bindings/graph.txt
> +
> +Example:
> +
> + {
> + panel@0 {
> + compatible = "kingdisplay,kd035g6-54nt";
> + reg = <0>;
> +
> + spi-max-frequency = <3125000>;
> + spi-3wire;
> + spi-cs-high;
> +
> + reset-gpios = < 2 GPIO_ACTIVE_LOW>;
> +
> + backlight = <>;
> + power-supply = <>;
> +
> + port {
> + panel_input: endpoint {
> + remote-endpoint = <_output>;
> + };
> + };
> + };
> +};
> -- 
> 2.21.0.593.g511ec345e18
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/2] DRM: Add KMS driver for the Ingenic JZ47xx SoCs

[Sam Ravnborg]

Hi Paul.

On Mon, Jun 03, 2019 at 05:23:31PM +0200, Paul Cercueil wrote:
> Add a KMS driver for the Ingenic JZ47xx family of SoCs.
> This driver is meant to replace the aging jz4740-fb driver.
> 
> This driver does not make use of the simple pipe helper, for the reason
> that it will soon be updated to support more advanced features like
> multiple planes, IPU integration for colorspace conversion and up/down
> scaling, support for DSI displays, and TV-out and HDMI outputs.
> 
> Signed-off-by: Paul Cercueil 
> Tested-by: Artur Rojek 
> ---
> 
> Notes:
> v2: - Remove custom handling of panel. The panel is now discovered using
> the standard API.
>   - Lots of small tweaks suggested by upstream
> 
> v3: - Use devm_drm_dev_init()
>   - Update compatible strings to -lcd instead of -drm
>   - Add destroy() callbacks to plane and crtc
>   - The ingenic,lcd-mode is now read from the bridge's DT node
> 
> v4: Remove ingenic,lcd-mode property completely. The various modes are now
>   deduced from the connector type, the pixel format or the bus flags.
> 
> v5: - Fix framebuffer size incorrectly calculated for 24bpp framebuffers
>   - Use 32bpp framebuffer instead of 16bpp, as it'll work with both
> 16-bit and 24-bit panel
>   - Get rid of drm_format_plane_cpp() which has been dropped upstream
>   - Avoid using drm_format_info->depth, which is deprecated.
In the drm world we include the revision notes in the changelog.
So I did this when I applied it to drm-misc-next.

Fixed a few trivial checkpatch warnings about indent too.
There was a few too-long-lines warnings that I ignored. Fixing them
would have hurt readability.

I assume you will maintain this driver onwards from now.
Please request drm-misc commit rights (see
https://www.freedesktop.org/wiki/AccountRequests/)
You will need a legacy SSH account.

And you should familiarize yourself with the maintainer-tools:
https://drm.pages.freedesktop.org/maintainer-tools/index.html

For my use I use "dim update-branches; dim apply; dim push
So only a small subset i needed for simple use.

Sam

Re: [PATCH v5 1/2] dt-bindings: Add doc for the Ingenic JZ47xx LCD controller driver

[Sam Ravnborg]

On Wed, Jun 12, 2019 at 10:49:52AM +0200, Paul Cercueil wrote:
> 
> 
> Le mar. 11 juin 2019 à 23:55, Rob Herring  a écrit :
> > On Mon,  3 Jun 2019 17:23:30 +0200, Paul Cercueil wrote:
> > >  Add documentation for the devicetree bindings of the LCD controller
> > > present in
> > >  the JZ47xx family of SoCs from Ingenic.
> > > 
> > >  Signed-off-by: Paul Cercueil 
> > >  Tested-by: Artur Rojek 
> > >  ---
> > > 
> > >  Notes:
> > >  v2: Remove ingenic,panel property.
> > > 
> > >  v3: - Rename compatible strings from ingenic,jz47XX-drm to
> > > ingenic,jz47XX-lcd
> > >  - The ingenic,lcd-mode property is now read from the panel
> > > node instead
> > > of from the driver node
> > > 
> > >  v4: Remove ingenic,lcd-mode property completely.
> > > 
> > >  v5: No change
> > > 
> > >   .../bindings/display/ingenic,lcd.txt  | 44
> > > +++
> > >   1 file changed, 44 insertions(+)
> > >   create mode 100644
> > > Documentation/devicetree/bindings/display/ingenic,lcd.txt
> > > 
> > 
> > Please add Acked-by/Reviewed-by tags when posting new versions. However,
> > there's no need to repost patches *only* to add the tags. The upstream
> > maintainer will do that for acks received on the version they apply.
> > 
> > If a tag was not added on purpose, please state why and what changed.
> 
> Sorry Rob, my mistake. I simply forgot that you ever reviewed that patch.
Added Rob's r-b and pushed to drm-misc-next

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

Re: [PATCH 1/2] drm/prime: Shuffle functions.

[Noralf Trønnes]

Den 18.06.2019 11.20, skrev Daniel Vetter:
> Reorder all the functions in drm_prime.[hc] into three groups: core,
> export helpers, import helpers.
> 
> Not other changes beyond moving the functions and their unchanged
> kerneldoc around in here.
> 
> Cc: Sam Ravnborg 
> Cc: Eric Anholt 
> Cc: Emil Velikov 
> Signed-off-by: Daniel Vetter 
> ---

Acked-by: Noralf Trønnes 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/imx: correct order of crtc disable

[Philipp Zabel]

On Wed, 2019-06-19 at 12:41 +0100, Robert Beckett wrote:
> Notify drm core before sending pending events during crtc disable.
> This fixes the first event after disable having an old stale timestamp
> by having drm_crtc_vblank_off update the timestamp to now.
> 
> This was seen while debugging weston log message:
> Warning: computed repaint delay is insane: -8212 msec
> 
> Also only send pending event if crtc is kept disabled, otherwise it will
> be sent on next vlblank.
>
> Fixes: a474478642d5 ("drm/imx: fix crtc vblank state regression")

Thank you, applied to imx-drm/fixes.

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

Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir

[Peter Zijlstra]

On Wed, Jun 19, 2019 at 01:45:51PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 19, 2019 at 01:43:56PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro Carvalho Chehab wrote:
> > 
> > >  .../{ => driver-api}/atomic_bitops.rst|  2 -
> > 
> > That's a .txt file, big fat NAK for making it an rst.
> 
> Also, how many bloody times do I have to keep telling this? It is
> starting to get _REALLY_ annoying.

Also, cross-posting to moderated lists is rude.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/7] video: add HDMI state notifier support

[Cheng-yi Chiang]

On Tue, Jun 18, 2019 at 8:12 PM Daniel Vetter  wrote:
>
> On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote:
> > On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter  wrote:
> > >
> > > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote:
> > > > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter  wrote:
> > > > >
> > > > > On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote:
> > > > > > On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote:
> > > > > > > > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote:
> > > > > > > > > From: Hans Verkuil 
> > > > > > > > >
> > > > > > > > > Add support for HDMI hotplug and EDID notifiers, which is 
> > > > > > > > > used to convey
> > > > > > > > > information from HDMI drivers to their CEC and audio 
> > > > > > > > > counterparts.
> > > > > > > > >
> > > > > > > > > Based on an earlier version from Russell King:
> > > > > > > > >
> > > > > > > > > https://patchwork.kernel.org/patch/9277043/
> > > > > > > > >
> > > > > > > > > The hdmi_notifier is a reference counted object containing 
> > > > > > > > > the HDMI state
> > > > > > > > > of an HDMI device.
> > > > > > > > >
> > > > > > > > > When a new notifier is registered the current state will be 
> > > > > > > > > reported to
> > > > > > > > > that notifier at registration time.
> > > > > > > > >
> > > > > > > > > Based on Hans Verkuil's patch:
> > > > > > > > >
> > > > > > > > > https://patchwork.kernel.org/patch/9472521/
> > > > > > > >
> > > > > > > > Erm, you are aware that this patch morphed into a CEC-specific 
> > > > > > > > notifier
> > > > > > > > found in drivers/media/cec/cec-notifier.c?
> > > > > > > >
> > > > > > > > I don't think it makes sense to have two notifier 
> > > > > > > > implementations in the kernel.
> > > > > > > > The original intention was to have the notifier deal with both 
> > > > > > > > CEC and ASoC
> > > > > > > > notifications, but there was not enough interest for the ASoC 
> > > > > > > > bits at the time
> > > > > > > > and it was dropped.
> > > > > > > >
> > > > > > > > I am planning changes to the cec-notifier API, I hope to work 
> > > > > > > > on that this
> > > > > > > > week. I'll CC you when I post those. Those might be a good 
> > > > > > > > starting point
> > > > > > > > to convert the cec-notifier to an hdmi-notifier as was 
> > > > > > > > originally intended.
> > > > > > > >
> > > > > > > > I've added your colleague Dariusz Marcinkiewicz to the CC list 
> > > > > > > > since he's been
> > > > > > > > working on some nice cec-notifier improvements as well.
> > > > > > >
> > > > > > > We also have some interfaces for drm/alsa interactions around hdmi
> > > > > > > already in drm/drm_audio_component.h, but it's not used by 
> > > > > > > anything
> > > > > > > outside of i915. Imo we should extend that, not reinvent a new 
> > > > > > > wheel.
> > > > > > >
> > > > > > Hi Daniel,
> > > > > > Thank you for the pointer. Looking at the ops, it seems that it is
> > > > > > specific to HDA.
> > > > > > I am not familiar with drm and HDA. I am not sure how applicable it
> > > > > > would be to report jack status to ASoC.
> > > > > > There is a use case in sound/soc/codecs/hdac_hdmi.c though so it
> > > > > > should be possible.
> > > > >
> > > > > Currently hda is the only user, but the idea was to make it more 
> > > > > generic.
> > > > > Jack status in alsa is what drm calls connector status btw.
> > > > >
> > > > > So if we can take that as a baseline and extend it (probably needs 
> > > > > some
> > > > > registration boilerplate and helpers to look up the right endpoint 
> > > > > using
> > > > > of/dt for soc systems, we use component.c in i915/hda for this), that
> > > > > would be great I think.
> > > > >
> > > > > > > Another note: notifiers considered evil, imo. Gets the job done 
> > > > > > > for one
> > > > > > > case, as soon as you have multiple devices and need to make sure 
> > > > > > > you get
> > > > > > > the update for the right one it all comes crashing down. Please 
> > > > > > > create an
> > > > > > > api which registers for updates from a specific device only, plus
> > > > > > > something that has real callbacks (like the drm_audio_component.h 
> > > > > > > thing we
> > > > > > > started already).
> > > > > >
> > > > > > To clarify a bit, this hdmi-notifier indeed supports updating from a
> > > > > > specific device only.
> > > > > > hdmi_notifier_get takes a device and return the notifier.
> > > > >
> > > > > Hm I missed that, I thought it's global, so one of my usual notifier
> > > > > concerns addressed.
> > > > >
> > > > > > It seems that a major difference between drm_audio_components and
> > > > > > hdmi-notifier is that
> > > > > > drm_audio_components defines all supported ops in 
> > > > > > drm_audio_component_audio_ops.
> > > > > > On the other hand, hdmi-notifier passes different events using an 
> > > > > > enum

Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir

[Peter Zijlstra]

On Wed, Jun 19, 2019 at 01:43:56PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro Carvalho Chehab wrote:
> 
> >  .../{ => driver-api}/atomic_bitops.rst|  2 -
> 
> That's a .txt file, big fat NAK for making it an rst.

Also, how many bloody times do I have to keep telling this? It is
starting to get _REALLY_ annoying.


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

[Bug 109456] KVM VFIO guest X hang with guest kernel > 4.15

[bugzilla-daemon]

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

--- Comment #6 from libgra...@gmail.com ---
Updated to QEMU 4.0.0 and re-tested - same result.

Let me know if you would like anything further info.

Thanks!

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

Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir

[Peter Zijlstra]

On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro Carvalho Chehab wrote:

>  .../{ => driver-api}/atomic_bitops.rst|  2 -

That's a .txt file, big fat NAK for making it an rst.

>  .../{ => driver-api}/futex-requeue-pi.rst |  2 -

>  .../{ => driver-api}/gcc-plugins.rst  |  2 -

>  Documentation/{ => driver-api}/kprobes.rst|  2 -
>  .../{ => driver-api}/percpu-rw-semaphore.rst  |  2 -

More NAK for rst conversion

>  Documentation/{ => driver-api}/pi-futex.rst   |  2 -
>  .../{ => driver-api}/preempt-locking.rst  |  2 -

>  Documentation/{ => driver-api}/rbtree.rst |  2 -

>  .../{ => driver-api}/robust-futex-ABI.rst |  2 -
>  .../{ => driver-api}/robust-futexes.rst   |  2 -

>  .../{ => driver-api}/speculation.rst  |  8 +--
>  .../{ => driver-api}/static-keys.rst  |  2 -

>  .../{ => driver-api}/this_cpu_ops.rst |  2 -

>  Documentation/locking/rt-mutex.rst|  2 +-

NAK. None of the above have anything to do with driver-api.

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

[PATCH v2] drm/imx: correct order of crtc disable

[Robert Beckett]

Notify drm core before sending pending events during crtc disable.
This fixes the first event after disable having an old stale timestamp
by having drm_crtc_vblank_off update the timestamp to now.

This was seen while debugging weston log message:
Warning: computed repaint delay is insane: -8212 msec

Also only send pending event if crtc is kept disabled, otherwise it will
be sent on next vlblank.

Fixes: a474478642d5 ("drm/imx: fix crtc vblank state regression")

Changes since v1:
Add details to commit message.

Signed-off-by: Robert Beckett 
Reviewed-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-crtc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 9cc1d678674f..c436a28d50e4 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -91,14 +91,14 @@ static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
ipu_dc_disable(ipu);
ipu_prg_disable(ipu);
 
+   drm_crtc_vblank_off(crtc);
+
spin_lock_irq(>dev->event_lock);
-   if (crtc->state->event) {
+   if (crtc->state->event && !crtc->state->active) {
drm_crtc_send_vblank_event(crtc, crtc->state->event);
crtc->state->event = NULL;
}
spin_unlock_irq(>dev->event_lock);
-
-   drm_crtc_vblank_off(crtc);
 }
 
 static void imx_drm_crtc_reset(struct drm_crtc *crtc)
-- 
2.18.0

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

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

[Daniel Vetter]

On Wed, Jun 19, 2019 at 1:21 PM Gerd Hoffmann  wrote:
>
>   Hi,
>
> > > > Second one is drm_driver->fops->mmap. That one we need to keep, but this
> > > > isn't mmap on a buffer, but mmap on the entire drm_device. The one which
> > > > should be replaced by drm_gem_object_funcs.vm_ops is
> > > > drm_driver->gem_vm_ops.
> > >
> > > Hmm, seems ttm hasn't something I can hook into drm_driver->gem_vm_ops ...
> >
> > ttm_bo_vm_ops seems to be the thing you want.
>
> Wouldn't work as-is, but when ttm bo are a subclass of gem bos should
> be possible to create something usable based on it.

You'd need to create driver-specific wrappers, but that's somewhat
defeating the point.

> Related question: why there is no drm_gem_object_funcs.mmap() callback?
> I think it would make sense to have a callback where the bo-specific
> setup can be done, i.e. what ttm_bo_mmap() or drm_gem_shmem_mmap() are
> doing, and have some generic function which basically does the lookup,
> then dispatches.

Maybe. Atm all we have around mmap is a sprawling number of different
solutions. Atm I'm not really sure which direction we really should
head into ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 01/12] drm: add gem array helpers

[Gerd Hoffmann]

> > +struct drm_gem_object_array*
> > +drm_gem_array_from_handles(struct drm_file *drm_file, u32 *handles, u32 
> > nents)
> > +{
> > +   struct drm_gem_object_array *objs;
> > +   u32 i;
> > +
> > +   objs = drm_gem_array_alloc(nents);
> > +   if (!objs)
> > +   return NULL;
> > +
> > +   for (i = 0; i < nents; i++) {
> > +   objs->objs[i] = drm_gem_object_lookup(drm_file, handles[i]);
> > +   if (!objs->objs[i]) {
> Missing object put for the 0..i-1 handles. Personally I would:

No. drm_gem_array_alloc initializes objs->nents and
drm_gem_array_put_free() loops over the whole array,
skipping NULL pointers.

> > +   drm_gem_array_put_free(objs);
> > +   return NULL;
> > +   }
> > +   }
> > +   return objs;
> > +}
> Missing EXPORT_SYMBOL?

Oops.  I had that fixed.  Possibly squashed into the wrong patch.

> Ditto?

Yes.

cheers,
  Gerd

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

[Gerd Hoffmann]

  Hi,

> > > Second one is drm_driver->fops->mmap. That one we need to keep, but this
> > > isn't mmap on a buffer, but mmap on the entire drm_device. The one which
> > > should be replaced by drm_gem_object_funcs.vm_ops is
> > > drm_driver->gem_vm_ops.
> >
> > Hmm, seems ttm hasn't something I can hook into drm_driver->gem_vm_ops ...
> 
> ttm_bo_vm_ops seems to be the thing you want.

Wouldn't work as-is, but when ttm bo are a subclass of gem bos should
be possible to create something usable based on it.

Related question: why there is no drm_gem_object_funcs.mmap() callback?
I think it would make sense to have a callback where the bo-specific
setup can be done, i.e. what ttm_bo_mmap() or drm_gem_shmem_mmap() are
doing, and have some generic function which basically does the lookup,
then dispatches.

cheers,
  Gerd

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

Re: [PATCH v3 08/12] drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing

[Daniel Vetter]

On Wed, Jun 19, 2019 at 11:04:16AM +0200, Gerd Hoffmann wrote:
> Use gem reservation helpers and direct reservation_object_* calls
> instead of ttm.
> 
> v3: Also attach the array of gem objects to the virtio command buffer,
> so we can drop the object references in the completion callback.  Needed
> because ttm fence helpers grab a reference for us, but gem helpers
> don't.
> 
> Signed-off-by: Gerd Hoffmann 

I think this looks reasonable now, but since it now touches virtio
lifetime management I'm not sure I can convince myself of its correctness.
I didn't spot anything fundamentally wrong with the remaining patches, so
on 8-12:

Acked-by: Daniel Vetter 

But I think you want someone with clue about virtio to double-check stuff
doesn't get leaked or the driver oopses somewhere. Specifically I'm not
sure whether you have some more traps lurking around buffer destruction,
since ttm keeps stuff on the lru for longer than just until all the fences
are signalled.

Also, I strongly recommend you do a very basic igt to exercise this, i.e.
allocate some buffers, submit them in a dummby op, then close the entire
drmfd. The old version should at least have tripped over kasan, maybe even
oopses somewhere.
-Daniel

> ---
>  drivers/gpu/drm/virtio/virtgpu_drv.h   |  6 ++-
>  drivers/gpu/drm/drm_gem_array_helper.c |  2 +
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c | 62 +++---
>  drivers/gpu/drm/virtio/virtgpu_vq.c| 16 ---
>  4 files changed, 43 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 77ac69a8e6cc..573173c35c48 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -33,6 +33,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -115,9 +116,9 @@ struct virtio_gpu_vbuffer {
>  
>   char *resp_buf;
>   int resp_size;
> -
>   virtio_gpu_resp_cb resp_cb;
>  
> + struct drm_gem_object_array *objs;
>   struct list_head list;
>  };
>  
> @@ -301,7 +302,8 @@ void virtio_gpu_cmd_context_detach_resource(struct 
> virtio_gpu_device *vgdev,
>   uint32_t resource_id);
>  void virtio_gpu_cmd_submit(struct virtio_gpu_device *vgdev,
>  void *data, uint32_t data_size,
> -uint32_t ctx_id, struct virtio_gpu_fence *fence);
> +uint32_t ctx_id, struct virtio_gpu_fence *fence,
> +struct drm_gem_object_array *objs);
>  void virtio_gpu_cmd_transfer_from_host_3d(struct virtio_gpu_device *vgdev,
> uint32_t resource_id, uint32_t ctx_id,
> uint64_t offset, uint32_t level,
> diff --git a/drivers/gpu/drm/drm_gem_array_helper.c 
> b/drivers/gpu/drm/drm_gem_array_helper.c
> index d35c77c4a02d..fde6c2e63253 100644
> --- a/drivers/gpu/drm/drm_gem_array_helper.c
> +++ b/drivers/gpu/drm/drm_gem_array_helper.c
> @@ -57,6 +57,7 @@ drm_gem_array_from_handles(struct drm_file *drm_file, u32 
> *handles, u32 nents)
>   }
>   return objs;
>  }
> +EXPORT_SYMBOL(drm_gem_array_from_handles);
>  
>  /**
>   * drm_gem_array_put_free -- put gem objects and free array.
> @@ -74,3 +75,4 @@ void drm_gem_array_put_free(struct drm_gem_object_array 
> *objs)
>   }
>   drm_gem_array_free(objs);
>  }
> +EXPORT_SYMBOL(drm_gem_array_put_free);
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index 5cffd2e54c04..21ebf5cdb8bc 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -105,14 +105,11 @@ static int virtio_gpu_execbuffer_ioctl(struct 
> drm_device *dev, void *data,
>   struct drm_virtgpu_execbuffer *exbuf = data;
>   struct virtio_gpu_device *vgdev = dev->dev_private;
>   struct virtio_gpu_fpriv *vfpriv = drm_file->driver_priv;
> - struct drm_gem_object *gobj;
>   struct virtio_gpu_fence *out_fence;
> - struct virtio_gpu_object *qobj;
>   int ret;
>   uint32_t *bo_handles = NULL;
>   void __user *user_bo_handles = NULL;
> - struct list_head validate_list;
> - struct ttm_validate_buffer *buflist = NULL;
> + struct drm_gem_object_array *buflist = NULL;
>   int i;
>   struct ww_acquire_ctx ticket;
>   struct sync_file *sync_file;
> @@ -155,15 +152,10 @@ static int virtio_gpu_execbuffer_ioctl(struct 
> drm_device *dev, void *data,
>   return out_fence_fd;
>   }
>  
> - INIT_LIST_HEAD(_list);
>   if (exbuf->num_bo_handles) {
> -
>   bo_handles = kvmalloc_array(exbuf->num_bo_handles,
> -sizeof(uint32_t), GFP_KERNEL);
> - buflist = kvmalloc_array(exbuf->num_bo_handles,
> -sizeof(struct ttm_validate_buffer),
> - 

Re: [PATCH 1/4] MAINTAINERS: Add entry for stable backlight sysfs ABI documentation

[Daniel Thompson]

On Thu, Jun 13, 2019 at 12:43:23PM -0700, Matthias Kaehlcke wrote:
> Add an entry for the stable backlight sysfs ABI to the MAINTAINERS
> file.
> 
> Signed-off-by: Matthias Kaehlcke 

Well spotted. Thanks!

Acked-by: Daniel Thompson 


Daniel.

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 57f496cff999..d51e74340870 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2857,6 +2857,7 @@ F:  drivers/video/backlight/
>  F:   include/linux/backlight.h
>  F:   include/linux/pwm_backlight.h
>  F:   Documentation/devicetree/bindings/leds/backlight
> +F:   Documentation/ABI/stable/sysfs-class-backlight
>  
>  BATMAN ADVANCED
>  M:   Marek Lindner 
> -- 
> 2.22.0.rc2.383.gf4fbbf30c2-goog
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 06/12] drm/virtio: drop no_wait argument from virtio_gpu_object_reserve

[Daniel Vetter]

On Wed, Jun 19, 2019 at 11:04:14AM +0200, Gerd Hoffmann wrote:
> All callers pass no_wait = false.
> 
> Signed-off-by: Gerd Hoffmann 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/virtio/virtgpu_drv.h   | 5 ++---
>  drivers/gpu/drm/virtio/virtgpu_gem.c   | 4 ++--
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 ++--
>  3 files changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 2cd96256ba37..06cc0e961df6 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -398,12 +398,11 @@ static inline u64 virtio_gpu_object_mmap_offset(struct 
> virtio_gpu_object *bo)
>   return drm_vma_node_offset_addr(>tbo.vma_node);
>  }
>  
> -static inline int virtio_gpu_object_reserve(struct virtio_gpu_object *bo,
> -  bool no_wait)
> +static inline int virtio_gpu_object_reserve(struct virtio_gpu_object *bo)
>  {
>   int r;
>  
> - r = ttm_bo_reserve(>tbo, true, no_wait, NULL);
> + r = ttm_bo_reserve(>tbo, true, false, NULL);
>   if (unlikely(r != 0)) {
>   if (r != -ERESTARTSYS) {
>   struct virtio_gpu_device *qdev =
> diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c 
> b/drivers/gpu/drm/virtio/virtgpu_gem.c
> index 1e49e08dd545..9c9ad3b14080 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_gem.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
> @@ -140,7 +140,7 @@ int virtio_gpu_gem_object_open(struct drm_gem_object *obj,
>   if (!vgdev->has_virgl_3d)
>   return 0;
>  
> - r = virtio_gpu_object_reserve(qobj, false);
> + r = virtio_gpu_object_reserve(qobj);
>   if (r)
>   return r;
>  
> @@ -161,7 +161,7 @@ void virtio_gpu_gem_object_close(struct drm_gem_object 
> *obj,
>   if (!vgdev->has_virgl_3d)
>   return;
>  
> - r = virtio_gpu_object_reserve(qobj, false);
> + r = virtio_gpu_object_reserve(qobj);
>   if (r)
>   return;
>  
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index 313c770ea2c5..5cffd2e54c04 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -375,7 +375,7 @@ static int virtio_gpu_transfer_from_host_ioctl(struct 
> drm_device *dev,
>  
>   qobj = gem_to_virtio_gpu_obj(gobj);
>  
> - ret = virtio_gpu_object_reserve(qobj, false);
> + ret = virtio_gpu_object_reserve(qobj);
>   if (ret)
>   goto out;
>  
> @@ -425,7 +425,7 @@ static int virtio_gpu_transfer_to_host_ioctl(struct 
> drm_device *dev, void *data,
>  
>   qobj = gem_to_virtio_gpu_obj(gobj);
>  
> - ret = virtio_gpu_object_reserve(qobj, false);
> + ret = virtio_gpu_object_reserve(qobj);
>   if (ret)
>   goto out;
>  
> -- 
> 2.18.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v3 01/12] drm: add gem array helpers

[Daniel Vetter]

On Wed, Jun 19, 2019 at 11:04:09AM +0200, Gerd Hoffmann wrote:
> Add struct and helper functions to manage an array of gem objects.
> See added kernel docs for details.
> 
> Signed-off-by: Gerd Hoffmann 

Hm, feels like jumping ahead here, I think there's too much still
in-flight:
- Christian is pondering some improved ww_mutex lock/unlock helpers.
  That'll probably change a lot of this code too.
- If we do more helpers, then I think we should have a consistent story
  across everything. These here don't really fit into the existing gem
  lock/unlock helpers.
- We probably want to design something coherent to replace all the ttm
  execbuf utils, i.e. bo lookup, locking, updating reservation objects,
  all that.
- I think this needs more than one driver to proof itself.

Maybe long-term we could have a drm_gem_eu_helper.c or so which contains
all that. But that's still some ways off.

I'd go back to the virtio-only conversion, and once we have more of this
stuff settled, we can look at how to properly design some nice
helpers.

Cheers, Daniel
> ---
>  include/drm/drm_gem_array_helper.h | 15 +
>  drivers/gpu/drm/drm_gem_array_helper.c | 76 ++
>  drivers/gpu/drm/Makefile   |  3 +-
>  3 files changed, 93 insertions(+), 1 deletion(-)
>  create mode 100644 include/drm/drm_gem_array_helper.h
>  create mode 100644 drivers/gpu/drm/drm_gem_array_helper.c
> 
> diff --git a/include/drm/drm_gem_array_helper.h 
> b/include/drm/drm_gem_array_helper.h
> new file mode 100644
> index ..adf7961247b3
> --- /dev/null
> +++ b/include/drm/drm_gem_array_helper.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __DRM_GEM_ARRAY_HELPER_H__
> +#define __DRM_GEM_ARRAY_HELPER_H__
> +
> +struct drm_gem_object_array {
> + u32 nents;
> + struct drm_gem_object *objs[];
> +};
> +
> +struct drm_gem_object_array *drm_gem_array_alloc(u32 nents);
> +struct drm_gem_object_array *
> +drm_gem_array_from_handles(struct drm_file *drm_file, u32 *handles, u32 
> nents);
> +void drm_gem_array_put_free(struct drm_gem_object_array *objs);
> +
> +#endif /* __DRM_GEM_ARRAY_HELPER_H__ */
> diff --git a/drivers/gpu/drm/drm_gem_array_helper.c 
> b/drivers/gpu/drm/drm_gem_array_helper.c
> new file mode 100644
> index ..d35c77c4a02d
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_gem_array_helper.c
> @@ -0,0 +1,76 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#include 
> +#include 
> +
> +/**
> + * drm_gem_array_alloc -- allocate gem object array of the given size.
> + *
> + * @nents: number of entries needed.
> + *
> + * Returns: An array of gem objects on success, NULL on failure.
> + */
> +struct drm_gem_object_array *drm_gem_array_alloc(u32 nents)
> +{
> + struct drm_gem_object_array *objs;
> + size_t size = sizeof(*objs) + sizeof(objs->objs[0]) * nents;
> +
> + objs = kzalloc(size, GFP_KERNEL);
> + if (!objs)
> + return NULL;
> +
> + objs->nents = nents;
> + return objs;
> +}
> +EXPORT_SYMBOL(drm_gem_array_alloc);
> +
> +static void drm_gem_array_free(struct drm_gem_object_array *objs)
> +{
> + kfree(objs);
> +}
> +
> +/**
> + * drm_gem_array_from_handles -- lookup an array of gem handles.
> + *
> + * @drm_file: drm file-private structure to use for the handle look up
> + * @handles: the array of handles to lookup.
> + * @nents: the numer of handles.
> + *
> + * Returns: An array of gem objects on success, NULL on failure.
> + */
> +struct drm_gem_object_array*
> +drm_gem_array_from_handles(struct drm_file *drm_file, u32 *handles, u32 
> nents)
> +{
> + struct drm_gem_object_array *objs;
> + u32 i;
> +
> + objs = drm_gem_array_alloc(nents);
> + if (!objs)
> + return NULL;
> +
> + for (i = 0; i < nents; i++) {
> + objs->objs[i] = drm_gem_object_lookup(drm_file, handles[i]);
> + if (!objs->objs[i]) {
> + drm_gem_array_put_free(objs);
> + return NULL;
> + }
> + }
> + return objs;
> +}
> +
> +/**
> + * drm_gem_array_put_free -- put gem objects and free array.
> + *
> + * @objs: the gem object array.
> + */
> +void drm_gem_array_put_free(struct drm_gem_object_array *objs)
> +{
> + u32 i;
> +
> + for (i = 0; i < objs->nents; i++) {
> + if (!objs->objs[i])
> + continue;
> + drm_gem_object_put_unlocked(objs->objs[i]);
> + }
> + drm_gem_array_free(objs);
> +}
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 9d630a28a788..d32e7de0937b 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -43,7 +43,8 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
> drm_dsc.o drm_probe_helper
>   drm_simple_kms_helper.o drm_modeset_helper.o \
>   drm_scdc_helper.o drm_gem_framebuffer_helper.o \
>   drm_atomic_state_helper.o drm_damage_helper.o \
> - 

Re: [PATCH 2/2] drm/prime: Update docs

[Emil Velikov]

On 2019/06/18, Daniel Vetter wrote:
> 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.
> 
> - Document all the hooks in _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.
> 
> v3:
> - Split out the function moving. This patch is now exclusively
>   documentation changes.
> - Typos and nits (Sam).
> 
> Cc: Sam Ravnborg 
> Cc: Eric Anholt 
> Cc: Emil Velikov 
> Signed-off-by: Daniel Vetter 
> ---
Had a quick read and it looks reasonable.
Acked-by: Emil Velikov 

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

Re: [PATCH 1/2] drm/prime: Shuffle functions.

[Emil Velikov]

On 2019/06/18, Daniel Vetter wrote:
> Reorder all the functions in drm_prime.[hc] into three groups: core,
> export helpers, import helpers.
> 
> Not other changes beyond moving the functions and their unchanged
> kerneldoc around in here.
> 
> Cc: Sam Ravnborg 
> Cc: Eric Anholt 
> Cc: Emil Velikov 
> Signed-off-by: Daniel Vetter 
> ---
Git's --color-moved=zebra detects nearly everything as moves. Couple of
return statements and a dma_buf_put() do not get flagged up, but I've
confirmed the reshuttle was OK.

Acked-by: Emil Velikov 

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

Re: [PATCH v1 12/22] docs: driver-api: add .rst files from the main dir

[Peter Zijlstra]

On Wed, Jun 19, 2019 at 07:22:18AM -0300, Mauro Carvalho Chehab wrote:
> Hi Daniel,
> 
> Em Wed, 19 Jun 2019 11:05:57 +0200
> Daniel Vetter  escreveu:
> 
> > On Tue, Jun 18, 2019 at 10:55 PM Mauro Carvalho Chehab
> >  wrote:
> > > diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> > > index fa30dfcfc3c8..b0f948d8733b 100644
> > > --- a/Documentation/gpu/drm-mm.rst
> > > +++ b/Documentation/gpu/drm-mm.rst
> > > @@ -320,7 +320,7 @@ struct :c:type:`struct file_operations 
> > > ` get_unmapped_area
> > >  field with a pointer on :c:func:`drm_gem_cma_get_unmapped_area`.
> > >
> > >  More detailed information about get_unmapped_area can be found in
> > > -Documentation/nommu-mmap.rst
> > > +Documentation/driver-api/nommu-mmap.rst  
> > 
> > Random drive-by comment: Could we convert these into hyperlinks within
> > sphinx somehow, without making them less useful as raw file references
> > (with vim I can just type 'gf' and it works, emacs probably the same).
> > -Daniel
> 
> Short answer: I don't know how vim/emacs would recognize Sphinx tags.

No, the other way around, Sphinx can recognize local files and treat
them special. That way we keep the text readable.

Same with that :c:func:'foo' crap, that needs to die, and Sphinx needs
to be taught about foo().
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel