Re: [PATCH v2 04/17] kunit: test: add kunit_stream a std::stream like logger
On Thu, May 2, 2019 at 6:50 PM shuah wrote:
>
> On 5/1/19 5:01 PM, Brendan Higgins wrote:
< snip >
> > diff --git a/kunit/kunit-stream.c b/kunit/kunit-stream.c
> > new file mode 100644
> > index 0..93c14eec03844
> > --- /dev/null
> > +++ b/kunit/kunit-stream.c
> > @@ -0,0 +1,149 @@
< snip >
> > +static int kunit_stream_init(struct kunit_resource *res, void *context)
> > +{
> > + struct kunit *test = context;
> > + struct kunit_stream *stream;
> > +
> > + stream = kzalloc(sizeof(*stream), GFP_KERNEL);
> > + if (!stream)
> > + return -ENOMEM;
> > + res->allocation = stream;
> > + stream->test = test;
> > + spin_lock_init(>lock);
> > + stream->internal_stream = new_string_stream();
> > +
> > + if (!stream->internal_stream)
> > + return -ENOMEM;
>
> What happens to stream? Don't you want to free that?
Good catch. Will fix in next revision.
< snip >
Cheers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/17] kunit: tool: add Python wrappers for running KUnit tests
On Thu, May 2, 2019 at 6:45 PM Frank Rowand wrote: > > On 5/2/19 4:45 PM, Brendan Higgins wrote: > > On Thu, May 2, 2019 at 2:16 PM Frank Rowand wrote: > >> > >> On 5/2/19 11:07 AM, Brendan Higgins wrote: > >>> On Thu, May 2, 2019 at 4:02 AM Greg KH wrote: > > On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrote: > > From: Felix Guo > > > > The ultimate goal is to create minimal isolated test binaries; in the > > meantime we are using UML to provide the infrastructure to run tests, so > > define an abstract way to configure and run tests that allow us to > > change the context in which tests are built without affecting the user. > > This also makes pretty and dynamic error reporting, and a lot of other > > nice features easier. > > > > kunit_config.py: > > - parse .config and Kconfig files. > > > > kunit_kernel.py: provides helper functions to: > > - configure the kernel using kunitconfig. > > - build the kernel with the appropriate configuration. > > - provide function to invoke the kernel and stream the output back. > > > > Signed-off-by: Felix Guo > > Signed-off-by: Brendan Higgins > > Ah, here's probably my answer to my previous logging format question, > right? What's the chance that these wrappers output stuff in a standard > format that test-framework-tools can already parse? :) > > > > To be clear, the test-framework-tools format we are talking about is > > TAP13[1], correct? > > I'm not sure what the test community prefers for a format. I'll let them > jump in and debate that question. > > > > > > My understanding is that is what kselftest is being converted to use. > > > >>> > >>> It should be pretty easy to do. I had some patches that pack up the > >>> results into a serialized format for a presubmit service; it should be > >>> pretty straightforward to take the same logic and just change the > >>> output format. > >> > >> When examining and trying out the previous versions of the patch I found > >> the wrappers useful to provide information about how to control and use > >> the tests, but I had no interest in using the scripts as they do not > >> fit in with my personal environment and workflow. > >> > >> In the previous versions of the patch, these helper scripts are optional, > >> which is good for my use case. If the helper scripts are required to > > > > They are still optional. > > > >> get the data into the proper format then the scripts are not quite so > >> optional, they become the expected environment. I think the proper > >> format should exist without the helper scripts. > > > > That's a good point. A couple things, > > > > First off, supporting TAP13, either in the kernel or the wrapper > > script is not hard, but I don't think that is the real issue that you > > raise. > > > > If your only concern is that you will always be able to have human > > readable KUnit results printed to the kernel log, that is a guarantee > > I feel comfortable making. Beyond that, I think it is going to take a > > long while before I would feel comfortable guaranteeing anything about > > how will KUnit work, what kind of data it will want to expose, and how > > it will be organized. I think the wrapper script provides a nice > > facade that I can maintain, can mediate between the implementation > > details and the user, and can mediate between the implementation > > details and other pieces of software that might want to consume > > results. > > > > [1] https://testanything.org/tap-version-13-specification.html > > My concern is based on a focus on my little part of the world > (which in _previous_ versions of the patch series was the devicetree > unittest.c tests being converted to use the kunit infrastructure). > If I step back and think of the entire kernel globally I may end > up with a different conclusion - but I'm going to remain myopic > for this email. > > I want the test results to be usable by me and my fellow > developers. I prefer that the test results be easily accessible > (current printk() implementation means that kunit messages are > just as accessible as the current unittest.c printk() output). > If the printk() output needs to be filtered through a script > to generate the actual test results then that is sub-optimal > to me. It is one more step added to my workflow. And > potentially with an embedded target a major pain to get a > data file (the kernel log file) transferred from a target > to my development host. That's fair. If that is indeed your only concern, then I don't think the wrapper script will ever be an issue for you. You will always be able to execute a given test the old fashioned/manual way, and the wrapper script only summarizes results, it does not change the contents. > > I want a reported test failure to be easy to trace back to the > point in the source where the failure is reported. With printk() > the search is a simple
Re: [PATCH v2 07/17] kunit: test: add initial tests
On Thu, May 2, 2019 at 6:27 PM shuah wrote: > > On 5/1/19 5:01 PM, Brendan Higgins wrote: > > Add a test for string stream along with a simpler example. > > > > Signed-off-by: Brendan Higgins > > --- > > kunit/Kconfig | 12 ++ > > kunit/Makefile | 4 ++ > > kunit/example-test.c | 88 ++ > > kunit/string-stream-test.c | 61 ++ > > 4 files changed, 165 insertions(+) > > create mode 100644 kunit/example-test.c > > create mode 100644 kunit/string-stream-test.c > > > > diff --git a/kunit/Kconfig b/kunit/Kconfig > > index 64480092b2c24..5cb500355c873 100644 > > --- a/kunit/Kconfig > > +++ b/kunit/Kconfig > > @@ -13,4 +13,16 @@ config KUNIT > > special hardware. For more information, please see > > Documentation/kunit/ > > > > +config KUNIT_TEST > > + bool "KUnit test for KUnit" > > + depends on KUNIT > > + help > > + Enables KUnit test to test KUnit. > > + > > Please add a bit more information on what this config option > does. Why should user care to enable it? > > > +config KUNIT_EXAMPLE_TEST > > + bool "Example test for KUnit" > > + depends on KUNIT > > + help > > + Enables example KUnit test to demo features of KUnit. > > + > > Same here. Sounds reasonable. Will fix in the next revision. < snip > Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/17] kunit: test: add string_stream a std::stream like string builder
On Thu, May 2, 2019 at 6:26 PM shuah wrote:
>
> On 5/1/19 5:01 PM, Brendan Higgins wrote:
< snip >
> > diff --git a/kunit/Makefile b/kunit/Makefile
> > index 5efdc4dea2c08..275b565a0e81f 100644
> > --- a/kunit/Makefile
> > +++ b/kunit/Makefile
> > @@ -1 +1,2 @@
> > -obj-$(CONFIG_KUNIT) += test.o
> > +obj-$(CONFIG_KUNIT) += test.o \
> > + string-stream.o
> > diff --git a/kunit/string-stream.c b/kunit/string-stream.c
> > new file mode 100644
> > index 0..7018194ecf2fa
> > --- /dev/null
> > +++ b/kunit/string-stream.c
> > @@ -0,0 +1,144 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * C++ stream style string builder used in KUnit for building messages.
> > + *
> > + * Copyright (C) 2019, Google LLC.
> > + * Author: Brendan Higgins
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +int string_stream_vadd(struct string_stream *this,
> > +const char *fmt,
> > +va_list args)
> > +{
> > + struct string_stream_fragment *fragment;
>
> Since there is field with the same name, please use a different
> name. Using the same name for the struct which contains a field
> of the same name get very confusing and will hard to maintain
> the code.
>
> > + int len;
> > + va_list args_for_counting;
> > + unsigned long flags;
> > +
> > + /* Make a copy because `vsnprintf` could change it */
> > + va_copy(args_for_counting, args);
> > +
> > + /* Need space for null byte. */
> > + len = vsnprintf(NULL, 0, fmt, args_for_counting) + 1;
> > +
> > + va_end(args_for_counting);
> > +
> > + fragment = kmalloc(sizeof(*fragment), GFP_KERNEL);
> > + if (!fragment)
> > + return -ENOMEM;
> > +
> > + fragment->fragment = kmalloc(len, GFP_KERNEL);
>
> This is confusing. See above comment.
Good point. Will fix in the next revision.
< snip >
Thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108893] Slow redrawing of menu in Gothic 2 under wine
https://bugs.freedesktop.org/show_bug.cgi?id=108893 --- Comment #7 from Timothy Arceri --- The trace runs perfectly fast. What is the most recent version you have tested this with? If you are still using 18.2 I would recommend updating to at least 19.0. -- 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 110143] Doom 3: BFG Edition - Steam and GOG.com - white flickering screen
https://bugs.freedesktop.org/show_bug.cgi?id=110143 --- Comment #5 from Timothy Arceri --- I've remove the regression tag from the bug title as I don't think this ever worked on Mesa and have sent a patch [1] that should work around some game bugs in future Mesa releases. [1] https://patchwork.freedesktop.org/patch/303169/ -- 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 110143] Doom 3: BFG Edition - Steam and GOG.com - white flickering screen
https://bugs.freedesktop.org/show_bug.cgi?id=110143 Timothy Arceri changed: What|Removed |Added Summary|[Regression] Doom 3: BFG|Doom 3: BFG Edition - Steam |Edition - Steam and GOG.com |and GOG.com - white |- white flickering screen |flickering screen -- 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
[radeon-alex:drm-next-5.2-wip 47/78] drivers/gpu//drm/panfrost/panfrost_job.c:388:3: error: too few arguments to function 'drm_sched_stop'
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
head: ad636d2a1cb80ed84030892630a6159c0e34dd85
commit: d88e20633f0308bf17e954f4e71b44c16252e4f0 [47/78] drm/scheduler: rework
job destruction
config: riscv-allyesconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d88e20633f0308bf17e954f4e71b44c16252e4f0
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=riscv
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu//drm/panfrost/panfrost_job.c: In function
'panfrost_job_timedout':
>> drivers/gpu//drm/panfrost/panfrost_job.c:388:3: error: too few arguments to
>> function 'drm_sched_stop'
drm_sched_stop(>js->queue[i].sched);
^~
In file included from drivers/gpu//drm/panfrost/panfrost_job.c:10:
include/drm/gpu_scheduler.h:295:6: note: declared here
void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job
*bad);
^~
vim +/drm_sched_stop +388 drivers/gpu//drm/panfrost/panfrost_job.c
f3ba9122 Rob Herring 2018-09-10 365
f3ba9122 Rob Herring 2018-09-10 366 static void panfrost_job_timedout(struct
drm_sched_job *sched_job)
f3ba9122 Rob Herring 2018-09-10 367 {
f3ba9122 Rob Herring 2018-09-10 368struct panfrost_job *job =
to_panfrost_job(sched_job);
f3ba9122 Rob Herring 2018-09-10 369struct panfrost_device *pfdev =
job->pfdev;
f3ba9122 Rob Herring 2018-09-10 370int js = panfrost_job_get_slot(job);
f3ba9122 Rob Herring 2018-09-10 371int i;
f3ba9122 Rob Herring 2018-09-10 372
f3ba9122 Rob Herring 2018-09-10 373/*
f3ba9122 Rob Herring 2018-09-10 374 * If the GPU managed to complete this
jobs fence, the timeout is
f3ba9122 Rob Herring 2018-09-10 375 * spurious. Bail out.
f3ba9122 Rob Herring 2018-09-10 376 */
f3ba9122 Rob Herring 2018-09-10 377if
(dma_fence_is_signaled(job->done_fence))
f3ba9122 Rob Herring 2018-09-10 378return;
f3ba9122 Rob Herring 2018-09-10 379
f3ba9122 Rob Herring 2018-09-10 380dev_err(pfdev->dev, "gpu sched timeout,
js=%d, status=0x%x, head=0x%x, tail=0x%x, sched_job=%p",
f3ba9122 Rob Herring 2018-09-10 381js,
f3ba9122 Rob Herring 2018-09-10 382job_read(pfdev, JS_STATUS(js)),
f3ba9122 Rob Herring 2018-09-10 383job_read(pfdev, JS_HEAD_LO(js)),
f3ba9122 Rob Herring 2018-09-10 384job_read(pfdev, JS_TAIL_LO(js)),
f3ba9122 Rob Herring 2018-09-10 385sched_job);
f3ba9122 Rob Herring 2018-09-10 386
f3ba9122 Rob Herring 2018-09-10 387for (i = 0; i < NUM_JOB_SLOTS; i++)
f3ba9122 Rob Herring 2018-09-10 @388
drm_sched_stop(>js->queue[i].sched);
f3ba9122 Rob Herring 2018-09-10 389
f3ba9122 Rob Herring 2018-09-10 390if (sched_job)
f3ba9122 Rob Herring 2018-09-10 391
drm_sched_increase_karma(sched_job);
f3ba9122 Rob Herring 2018-09-10 392
f3ba9122 Rob Herring 2018-09-10 393/* panfrost_core_dump(pfdev); */
f3ba9122 Rob Herring 2018-09-10 394
f3ba9122 Rob Herring 2018-09-10 395
panfrost_devfreq_record_transition(pfdev, js);
f3ba9122 Rob Herring 2018-09-10 396panfrost_gpu_soft_reset(pfdev);
f3ba9122 Rob Herring 2018-09-10 397
f3ba9122 Rob Herring 2018-09-10 398/* TODO: Re-enable all other address
spaces */
f3ba9122 Rob Herring 2018-09-10 399panfrost_mmu_enable(pfdev, 0);
f3ba9122 Rob Herring 2018-09-10 400panfrost_gpu_power_on(pfdev);
f3ba9122 Rob Herring 2018-09-10 401panfrost_job_enable_interrupts(pfdev);
f3ba9122 Rob Herring 2018-09-10 402
f3ba9122 Rob Herring 2018-09-10 403for (i = 0; i < NUM_JOB_SLOTS; i++)
f3ba9122 Rob Herring 2018-09-10 404
drm_sched_resubmit_jobs(>js->queue[i].sched);
f3ba9122 Rob Herring 2018-09-10 405
f3ba9122 Rob Herring 2018-09-10 406/* restart scheduler after GPU is
usable again */
f3ba9122 Rob Herring 2018-09-10 407for (i = 0; i < NUM_JOB_SLOTS; i++)
f3ba9122 Rob Herring 2018-09-10 408
drm_sched_start(>js->queue[i].sched, true);
f3ba9122 Rob Herring 2018-09-10 409 }
f3ba9122 Rob Herring 2018-09-10 410
:: The code at line 388 was first introduced by commit
:: f3ba91228e8e917e5bd6c4b72bfe846933d17370 drm/panfrost: Add initial
panfrost driver
:: TO: Rob Herring
:: CC: Rob Herring
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-tip:drm-tip 4/9] htmldocs: drivers/gpu/drm/scheduler/sched_main.c:364: warning: Function parameter or member 'bad' not described in 'drm_sched_stop'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: 6f67b24f2fc7b90a94e4163ae4cd01bc2783fbfd commit: fb4f0930305e60c480c86c0e2ba9bc8683179bd9 [4/9] Merge remote-tracking branch 'origin/drm-misc-next' into drm-tip reproduce: make htmldocs If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) include/linux/generic-radix-tree.h:1: warning: no structured comments found kernel/rcu/tree_plugin.h:1: warning: no structured comments found kernel/rcu/tree_plugin.h:1: warning: no structured comments found include/linux/firmware/intel/stratix10-svc-client.h:1: warning: no structured comments found include/linux/gpio/driver.h:371: warning: Function parameter or member 'init_valid_mask' not described in 'gpio_chip' include/linux/i2c.h:343: warning: Function parameter or member 'init_irq' not described in 'i2c_client' include/linux/iio/hw-consumer.h:1: warning: no structured comments found include/linux/input/sparse-keymap.h:46: warning: Function parameter or member 'sw' not described in 'key_entry' include/linux/regulator/machine.h:199: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:228: warning: Function parameter or member 'resume' not described in 'regulator_ops' drivers/slimbus/stream.c:1: warning: no structured comments found include/linux/spi/spi.h:188: warning: Function parameter or member 'driver_override' not described in 'spi_device' drivers/target/target_core_device.c:1: warning: no structured comments found drivers/usb/typec/bus.c:1: warning: no structured comments found drivers/usb/typec/class.c:1: warning: no structured comments found include/linux/w1.h:281: warning: Function parameter or member 'of_match_table' not described in 'w1_family' fs/direct-io.c:257: warning: Excess function parameter 'offset' description in 'dio_complete' fs/file_table.c:1: warning: no structured comments found fs/libfs.c:477: warning: Excess function parameter 'available' description in 'simple_write_end' fs/posix_acl.c:646: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode' fs/posix_acl.c:646: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode' fs/posix_acl.c:646: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:294: warning: Excess function parameter 'mm' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:294: warning: Excess function parameter 'start' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:294: warning: Excess function parameter 'end' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:343: warning: Excess function parameter 'mm' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:343: warning: Excess function parameter 'start' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:343: warning: Excess function parameter 'end' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:183: warning: Function parameter or member 'blockable' not described in 'amdgpu_mn_read_lock' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:295: warning: Function parameter or member 'range' not described in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:295: warning: Excess function parameter 'mm' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:295: warning: Excess function parameter 'start' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:295: warning: Excess function parameter 'end' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:344: warning: Function parameter or member 'range' not described in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:344: warning: Excess function parameter 'mm' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:344: warning: Excess function parameter 'start' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:344: warning: Excess function parameter 'end' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:347: warning: cannot understand function prototype: 'struct amdgpu_vm_pt_cursor ' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:348: warning: cannot understand function prototype: 'struct amdgpu_vm_pt_cursor '
[Bug 104185] CS:GO randomly locks up the entire system requiring forced reboot
https://bugs.freedesktop.org/show_bug.cgi?id=104185 Timothy Arceri changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEEDINFO|RESOLVED --- Comment #7 from Timothy Arceri --- Closing as there have been no reports of this issue in over a year and the original reporter haven't responded to confirm the issue still exists. Please reopen if this is still an issues. -- 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 109124] [AMD][TAHITI XT] csgo new battle royal mode bad performance
https://bugs.freedesktop.org/show_bug.cgi?id=109124 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #4 from Timothy Arceri --- I suspect it could be your system showing its age. It seems common that users on Windows also reported FPS drops with Danger Zone. You could try some of the generic (non windows) suggestions found here [1] to reduce CPU use etc. Otherwise it might be upgrade time. [1] https://www.youtube.com/watch?v=FkP-MUL8Qg8 -- 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 110575] [R9 380X] Artifacts in CSGO
https://bugs.freedesktop.org/show_bug.cgi?id=110575 --- Comment #1 from Timothy Arceri --- Bit of a stab in the dark but if its related to bug #100239 You could try running steam from the command line with: R600_DEBUG=zerovram steam -- 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 04/17] kunit: test: add kunit_stream a std::stream like logger
On 5/1/19 5:01 PM, Brendan Higgins wrote:
A lot of the expectation and assertion infrastructure prints out fairly
complicated test failure messages, so add a C++ style log library for
for logging test results.
Signed-off-by: Brendan Higgins
---
include/kunit/kunit-stream.h | 85
include/kunit/test.h | 2 +
kunit/Makefile | 3 +-
kunit/kunit-stream.c | 149 +++
kunit/test.c | 8 ++
5 files changed, 246 insertions(+), 1 deletion(-)
create mode 100644 include/kunit/kunit-stream.h
create mode 100644 kunit/kunit-stream.c
diff --git a/include/kunit/kunit-stream.h b/include/kunit/kunit-stream.h
new file mode 100644
index 0..d457a54fe0100
--- /dev/null
+++ b/include/kunit/kunit-stream.h
@@ -0,0 +1,85 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * C++ stream style string formatter and printer used in KUnit for outputting
+ * KUnit messages.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins
+ */
+
+#ifndef _KUNIT_KUNIT_STREAM_H
+#define _KUNIT_KUNIT_STREAM_H
+
+#include
+#include
+
+struct kunit;
+
+/**
+ * struct kunit_stream - a std::stream style string builder.
+ *
+ * A std::stream style string builder. Allows messages to be built up and
+ * printed all at once.
+ */
+struct kunit_stream {
+ /* private: internal use only. */
+ struct kunit *test;
+ spinlock_t lock; /* Guards level. */
+ const char *level;
+ struct string_stream *internal_stream;
+};
+
+/**
+ * kunit_new_stream() - constructs a new kunit_stream.
+ * @test: The test context object.
+ *
+ * Constructs a new test managed kunit_stream.
+ */
+struct kunit_stream *kunit_new_stream(struct kunit *test);
+
+/**
+ * kunit_stream_set_level(): sets the level that string should be printed at.
+ * @this: the stream being operated on.
+ * @level: the print level the stream is set to output to.
+ *
+ * Sets the print level at which the stream outputs.
+ */
+void kunit_stream_set_level(struct kunit_stream *this, const char *level);
+
+/**
+ * kunit_stream_add(): adds the formatted input to the internal buffer.
+ * @this: the stream being operated on.
+ * @fmt: printf style format string to append to stream.
+ *
+ * Appends the formatted string, @fmt, to the internal buffer.
+ */
+void __printf(2, 3) kunit_stream_add(struct kunit_stream *this,
+const char *fmt, ...);
+
+/**
+ * kunit_stream_append(): appends the contents of @other to @this.
+ * @this: the stream to which @other is appended.
+ * @other: the stream whose contents are appended to @this.
+ *
+ * Appends the contents of @other to @this.
+ */
+void kunit_stream_append(struct kunit_stream *this, struct kunit_stream
*other);
+
+/**
+ * kunit_stream_commit(): prints out the internal buffer to the user.
+ * @this: the stream being operated on.
+ *
+ * Outputs the contents of the internal buffer as a kunit_printk formatted
+ * output.
+ */
+void kunit_stream_commit(struct kunit_stream *this);
+
+/**
+ * kunit_stream_clear(): clears the internal buffer.
+ * @this: the stream being operated on.
+ *
+ * Clears the contents of the internal buffer.
+ */
+void kunit_stream_clear(struct kunit_stream *this);
+
+#endif /* _KUNIT_KUNIT_STREAM_H */
diff --git a/include/kunit/test.h b/include/kunit/test.h
index 819edd8db4e81..4668e8a635954 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -11,6 +11,7 @@
#include
#include
+#include
struct kunit_resource;
@@ -171,6 +172,7 @@ struct kunit {
void (*vprintk)(const struct kunit *test,
const char *level,
struct va_format *vaf);
+ void (*fail)(struct kunit *test, struct kunit_stream *stream);
};
int kunit_init_test(struct kunit *test, const char *name);
diff --git a/kunit/Makefile b/kunit/Makefile
index 275b565a0e81f..6ddc622ee6b1c 100644
--- a/kunit/Makefile
+++ b/kunit/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_KUNIT) +=test.o \
- string-stream.o
+ string-stream.o \
+ kunit-stream.o
diff --git a/kunit/kunit-stream.c b/kunit/kunit-stream.c
new file mode 100644
index 0..93c14eec03844
--- /dev/null
+++ b/kunit/kunit-stream.c
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * C++ stream style string formatter and printer used in KUnit for outputting
+ * KUnit messages.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins
+ */
+
+#include
+#include
+#include
+
+const char *kunit_stream_get_level(struct kunit_stream *this)
+{
+ unsigned long flags;
+ const char *level;
+
+ spin_lock_irqsave(>lock, flags);
+ level = this->level;
+ spin_unlock_irqrestore(>lock, flags);
+
+ return level;
+}
+
+void kunit_stream_set_level(struct kunit_stream *this,
[Bug 108750] Glitchy Interface on Origin when using radeonsi and wined3d
https://bugs.freedesktop.org/show_bug.cgi?id=108750 Timothy Arceri changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #1 from Timothy Arceri --- wined3d DX11 support is known to be very buggy. Just use dxvk. -- 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 07/17] kunit: test: add initial tests
On 5/1/19 5:01 PM, Brendan Higgins wrote:
Add a test for string stream along with a simpler example.
Signed-off-by: Brendan Higgins
---
kunit/Kconfig | 12 ++
kunit/Makefile | 4 ++
kunit/example-test.c | 88 ++
kunit/string-stream-test.c | 61 ++
4 files changed, 165 insertions(+)
create mode 100644 kunit/example-test.c
create mode 100644 kunit/string-stream-test.c
diff --git a/kunit/Kconfig b/kunit/Kconfig
index 64480092b2c24..5cb500355c873 100644
--- a/kunit/Kconfig
+++ b/kunit/Kconfig
@@ -13,4 +13,16 @@ config KUNIT
special hardware. For more information, please see
Documentation/kunit/
+config KUNIT_TEST
+ bool "KUnit test for KUnit"
+ depends on KUNIT
+ help
+ Enables KUnit test to test KUnit.
+
Please add a bit more information on what this config option
does. Why should user care to enable it?
+config KUNIT_EXAMPLE_TEST
+ bool "Example test for KUnit"
+ depends on KUNIT
+ help
+ Enables example KUnit test to demo features of KUnit.
+
Same here.
endmenu
diff --git a/kunit/Makefile b/kunit/Makefile
index 6ddc622ee6b1c..60a9ea6cb4697 100644
--- a/kunit/Makefile
+++ b/kunit/Makefile
@@ -1,3 +1,7 @@
obj-$(CONFIG_KUNIT) +=test.o \
string-stream.o \
kunit-stream.o
+
+obj-$(CONFIG_KUNIT_TEST) +=string-stream-test.o
+
+obj-$(CONFIG_KUNIT_EXAMPLE_TEST) +=example-test.o
diff --git a/kunit/example-test.c b/kunit/example-test.c
new file mode 100644
index 0..3947dd7c8f922
--- /dev/null
+++ b/kunit/example-test.c
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Example KUnit test to show how to use KUnit.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins
+ */
+
+#include
+
+/*
+ * This is the most fundamental element of KUnit, the test case. A test case
+ * makes a set EXPECTATIONs and ASSERTIONs about the behavior of some code; if
+ * any expectations or assertions are not met, the test fails; otherwise, the
+ * test passes.
+ *
+ * In KUnit, a test case is just a function with the signature
+ * `void (*)(struct kunit *)`. `struct kunit` is a context object that stores
+ * information about the current test.
+ */
+static void example_simple_test(struct kunit *test)
+{
+ /*
+* This is an EXPECTATION; it is how KUnit tests things. When you want
+* to test a piece of code, you set some expectations about what the
+* code should do. KUnit then runs the test and verifies that the code's
+* behavior matched what was expected.
+*/
+ KUNIT_EXPECT_EQ(test, 1 + 1, 2);
+}
+
+/*
+ * This is run once before each test case, see the comment on
+ * example_test_module for more information.
+ */
+static int example_test_init(struct kunit *test)
+{
+ kunit_info(test, "initializing\n");
+
+ return 0;
+}
+
+/*
+ * Here we make a list of all the test cases we want to add to the test module
+ * below.
+ */
+static struct kunit_case example_test_cases[] = {
+ /*
+* This is a helper to create a test case object from a test case
+* function; its exact function is not important to understand how to
+* use KUnit, just know that this is how you associate test cases with a
+* test module.
+*/
+ KUNIT_CASE(example_simple_test),
+ {},
+};
+
+/*
+ * This defines a suite or grouping of tests.
+ *
+ * Test cases are defined as belonging to the suite by adding them to
+ * `kunit_cases`.
+ *
+ * Often it is desirable to run some function which will set up things which
+ * will be used by every test; this is accomplished with an `init` function
+ * which runs before each test case is invoked. Similarly, an `exit` function
+ * may be specified which runs after every test case and can be used to for
+ * cleanup. For clarity, running tests in a test module would behave as
follows:
+ *
+ * module.init(test);
+ * module.test_case[0](test);
+ * module.exit(test);
+ * module.init(test);
+ * module.test_case[1](test);
+ * module.exit(test);
+ * ...;
+ */
+static struct kunit_module example_test_module = {
+ .name = "example",
+ .init = example_test_init,
+ .test_cases = example_test_cases,
+};
+
+/*
+ * This registers the above test module telling KUnit that this is a suite of
+ * tests that need to be run.
+ */
+module_test(example_test_module);
diff --git a/kunit/string-stream-test.c b/kunit/string-stream-test.c
new file mode 100644
index 0..b2a98576797c9
--- /dev/null
+++ b/kunit/string-stream-test.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test for struct string_stream.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins
+ */
+
+#include
+#include
+#include
+
+static void
Re: [PATCH v2 03/17] kunit: test: add string_stream a std::stream like string builder
On 5/1/19 5:01 PM, Brendan Higgins wrote:
A number of test features need to do pretty complicated string printing
where it may not be possible to rely on a single preallocated string
with parameters.
So provide a library for constructing the string as you go similar to
C++'s std::string.
Signed-off-by: Brendan Higgins
---
include/kunit/string-stream.h | 51
kunit/Makefile| 3 +-
kunit/string-stream.c | 144 ++
3 files changed, 197 insertions(+), 1 deletion(-)
create mode 100644 include/kunit/string-stream.h
create mode 100644 kunit/string-stream.c
diff --git a/include/kunit/string-stream.h b/include/kunit/string-stream.h
new file mode 100644
index 0..567a4629406da
--- /dev/null
+++ b/include/kunit/string-stream.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * C++ stream style string builder used in KUnit for building messages.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins
+ */
+
+#ifndef _KUNIT_STRING_STREAM_H
+#define _KUNIT_STRING_STREAM_H
+
+#include
+#include
+#include
+#include
+
+struct string_stream_fragment {
+ struct list_head node;
+ char *fragment;
+};
+
+struct string_stream {
+ size_t length;
+ struct list_head fragments;
+
+ /* length and fragments are protected by this lock */
+ spinlock_t lock;
+ struct kref refcount;
+};
+
+struct string_stream *new_string_stream(void);
+
+void destroy_string_stream(struct string_stream *stream);
+
+void string_stream_get(struct string_stream *stream);
+
+int string_stream_put(struct string_stream *stream);
+
+int string_stream_add(struct string_stream *this, const char *fmt, ...);
+
+int string_stream_vadd(struct string_stream *this,
+ const char *fmt,
+ va_list args);
+
+char *string_stream_get_string(struct string_stream *this);
+
+void string_stream_clear(struct string_stream *this);
+
+bool string_stream_is_empty(struct string_stream *this);
+
+#endif /* _KUNIT_STRING_STREAM_H */
diff --git a/kunit/Makefile b/kunit/Makefile
index 5efdc4dea2c08..275b565a0e81f 100644
--- a/kunit/Makefile
+++ b/kunit/Makefile
@@ -1 +1,2 @@
-obj-$(CONFIG_KUNIT) += test.o
+obj-$(CONFIG_KUNIT) += test.o \
+ string-stream.o
diff --git a/kunit/string-stream.c b/kunit/string-stream.c
new file mode 100644
index 0..7018194ecf2fa
--- /dev/null
+++ b/kunit/string-stream.c
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * C++ stream style string builder used in KUnit for building messages.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins
+ */
+
+#include
+#include
+#include
+
+int string_stream_vadd(struct string_stream *this,
+ const char *fmt,
+ va_list args)
+{
+ struct string_stream_fragment *fragment;
Since there is field with the same name, please use a different
name. Using the same name for the struct which contains a field
of the same name get very confusing and will hard to maintain
the code.
+ int len;
+ va_list args_for_counting;
+ unsigned long flags;
+
+ /* Make a copy because `vsnprintf` could change it */
+ va_copy(args_for_counting, args);
+
+ /* Need space for null byte. */
+ len = vsnprintf(NULL, 0, fmt, args_for_counting) + 1;
+
+ va_end(args_for_counting);
+
+ fragment = kmalloc(sizeof(*fragment), GFP_KERNEL);
+ if (!fragment)
+ return -ENOMEM;
+
+ fragment->fragment = kmalloc(len, GFP_KERNEL);
This is confusing. See above comment.
+ if (!fragment->fragment) {
+ kfree(fragment);
+ return -ENOMEM;
+ }
+
+ len = vsnprintf(fragment->fragment, len, fmt, args);
+ spin_lock_irqsave(>lock, flags);
+ this->length += len;
+ list_add_tail(>node, >fragments);
+ spin_unlock_irqrestore(>lock, flags);
+ return 0;
+}
+
+int string_stream_add(struct string_stream *this, const char *fmt, ...)
+{
+ va_list args;
+ int result;
+
+ va_start(args, fmt);
+ result = string_stream_vadd(this, fmt, args);
+ va_end(args);
+ return result;
+}
+
+void string_stream_clear(struct string_stream *this)
+{
+ struct string_stream_fragment *fragment, *fragment_safe;
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ list_for_each_entry_safe(fragment,
+fragment_safe,
+>fragments,
+node) {
+ list_del(>node);
+ kfree(fragment->fragment);
+ kfree(fragment);
This is what git me down the road of checking the structure
name to begin with. :)
+ }
+ this->length = 0;
+ spin_unlock_irqrestore(>lock, flags);
+}
+
+char
[Bug 100239] Incorrect rendering in CS:GO
https://bugs.freedesktop.org/show_bug.cgi?id=100239 --- Comment #19 from Timothy Arceri --- If you run steam from the command line with: R600_DEBUG=zerovram steam Does that fix the issue for you? -- 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
[git pull] drm fixes for final
Hey Linus, Just a single qxl revert for rc8/final. Dave. drm-fixes-2019-05-03: drm one qxl revert The following changes since commit 37624b58542fb9f2d9a70e6ea006ef8a5f66c30b: Linux 5.1-rc7 (2019-04-28 17:04:13 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-05-03 for you to fetch changes up to 1daa0449d287a109b93c4516914eddeff4baff65: Merge tag 'drm-misc-fixes-2019-05-02' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2019-05-03 09:36:31 +1000) drm one qxl revert Dave Airlie (1): Merge tag 'drm-misc-fixes-2019-05-02' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Gerd Hoffmann (1): Revert "drm/qxl: drop prime import/export callbacks" drivers/gpu/drm/qxl/qxl_drv.c | 4 drivers/gpu/drm/qxl/qxl_prime.c | 12 2 files changed, 16 insertions(+) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On Thu, May 2, 2019 at 7:04 AM shuah wrote: > > On 5/2/19 4:50 AM, Greg KH wrote: > > On Wed, May 01, 2019 at 04:01:09PM -0700, Brendan Higgins wrote: > >> ## TLDR > >> > >> I rebased the last patchset on 5.1-rc7 in hopes that we can get this in > >> 5.2. > > > > That might be rushing it, normally trees are already closed now for > > 5.2-rc1 if 5.1-final comes out this Sunday. > > > >> Shuah, I think you, Greg KH, and myself talked off thread, and we agreed > >> we would merge through your tree when the time came? Am I remembering > >> correctly? > > > > No objection from me. > > > > Yes. I can take these through kselftest tree when the time comes. Awesome. > Agree with Greg that 5.2 might be rushing it. 5.3 would be a good > target. Whoops. I guess I should have sent this out a bit earlier. Oh well, as long as we are on our way! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On Thu, May 2, 2019 at 4:05 AM Greg KH wrote: > > On Thu, May 02, 2019 at 12:50:53PM +0200, Greg KH wrote: > > On Wed, May 01, 2019 at 04:01:09PM -0700, Brendan Higgins wrote: > > > ## TLDR > > > > > > I rebased the last patchset on 5.1-rc7 in hopes that we can get this in > > > 5.2. > > > > That might be rushing it, normally trees are already closed now for > > 5.2-rc1 if 5.1-final comes out this Sunday. > > > > > Shuah, I think you, Greg KH, and myself talked off thread, and we agreed > > > we would merge through your tree when the time came? Am I remembering > > > correctly? > > > > No objection from me. > > > > Let me go review the latest round of patches now. > > Overall, looks good to me, and provides a framework we can build on. > I'm a bit annoyed at the reliance on uml at the moment, but we can work > on that in the future :) Eh, I mostly fixed that. I removed the KUnit framework's reliance on UML i.e. the actual tests now run on any architecture. The only UML dependent bit is the KUnit wrapper scripts, which could be made to work to support other architectures pretty trivially. The only limitation here is that it would be dependent on the actual workflow you are using. In anycase, if you are comfortable reading the results in the kernel logs, then there is no dependence on UML. (I should probably provide some documentation on that...) > > Thanks for sticking with this, now the real work begins... I don't doubt it. > > Reviewed-by: Greg Kroah-Hartman Does this cover all the patches in this set? Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] 2nd pull for malidp-next
On Thu, 2 May 2019 at 20:45, Liviu Dudau wrote: > > Hi DRM maintainers, > > This is the 2nd pull request for the malidp-next. The new patches add > additional support for Arm Mali D71 so that it can now be enabled > correctly and brought up on any SoC that contains the IP. From now on > we will start focusing on adding writeback, scaling and other useful > features to bring the driver to the same level of maturity as mali-dp. > > Please pull, > Liviu > > > > The following changes since commit 7c13e5cc2391950541f41fc9ab0336aae77c7f63: > > Merge tag 'drm-intel-next-fixes-2019-04-25' of > git://anongit.freedesktop.org/drm/drm-intel into drm-next (2019-04-26 > 11:35:59 +1000) > > are available in the Git repository at: > > git://linux-arm.org/linux-ld.git for-upstream/mali-dp This branch contains: commit 04c8a1ec395b22f060b836b72d2d4480e7e859f8 Author: Liviu Dudau Date: Tue Mar 26 10:23:40 2019 + MAINTAINERS: Fix pattern for Documentation path for Arm Mali Komeda as it's head, did you forget to push? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/17] kunit: tool: add Python wrappers for running KUnit tests
On Thu, May 2, 2019 at 2:16 PM Frank Rowand wrote: > > On 5/2/19 11:07 AM, Brendan Higgins wrote: > > On Thu, May 2, 2019 at 4:02 AM Greg KH wrote: > >> > >> On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrote: > >>> From: Felix Guo > >>> > >>> The ultimate goal is to create minimal isolated test binaries; in the > >>> meantime we are using UML to provide the infrastructure to run tests, so > >>> define an abstract way to configure and run tests that allow us to > >>> change the context in which tests are built without affecting the user. > >>> This also makes pretty and dynamic error reporting, and a lot of other > >>> nice features easier. > >>> > >>> kunit_config.py: > >>> - parse .config and Kconfig files. > >>> > >>> kunit_kernel.py: provides helper functions to: > >>> - configure the kernel using kunitconfig. > >>> - build the kernel with the appropriate configuration. > >>> - provide function to invoke the kernel and stream the output back. > >>> > >>> Signed-off-by: Felix Guo > >>> Signed-off-by: Brendan Higgins > >> > >> Ah, here's probably my answer to my previous logging format question, > >> right? What's the chance that these wrappers output stuff in a standard > >> format that test-framework-tools can already parse? :) To be clear, the test-framework-tools format we are talking about is TAP13[1], correct? My understanding is that is what kselftest is being converted to use. > > > > It should be pretty easy to do. I had some patches that pack up the > > results into a serialized format for a presubmit service; it should be > > pretty straightforward to take the same logic and just change the > > output format. > > When examining and trying out the previous versions of the patch I found > the wrappers useful to provide information about how to control and use > the tests, but I had no interest in using the scripts as they do not > fit in with my personal environment and workflow. > > In the previous versions of the patch, these helper scripts are optional, > which is good for my use case. If the helper scripts are required to They are still optional. > get the data into the proper format then the scripts are not quite so > optional, they become the expected environment. I think the proper > format should exist without the helper scripts. That's a good point. A couple things, First off, supporting TAP13, either in the kernel or the wrapper script is not hard, but I don't think that is the real issue that you raise. If your only concern is that you will always be able to have human readable KUnit results printed to the kernel log, that is a guarantee I feel comfortable making. Beyond that, I think it is going to take a long while before I would feel comfortable guaranteeing anything about how will KUnit work, what kind of data it will want to expose, and how it will be organized. I think the wrapper script provides a nice facade that I can maintain, can mediate between the implementation details and the user, and can mediate between the implementation details and other pieces of software that might want to consume results. [1] https://testanything.org/tap-version-13-specification.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/bridge/synopsys: dw-hdmi: Add "unwedge" for ddc bus
See the PhD thesis in the comments in this patch for details, but to
summarize this adds a hacky "unwedge" feature to the dw_hdmi i2c bus to
workaround what appears to be a hardware errata. This relies on a
pinctrl entry to help change around muxing to perform the unwedge.
NOTE that the specific TV this was tested on was the "Samsung
UN40HU6950FXZA" and the specific port was the "STB" port.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 116 +++---
1 file changed, 100 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index db761329a1e3..c66587e33813 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -169,6 +170,10 @@ struct dw_hdmi {
bool sink_is_hdmi;
bool sink_has_audio;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *default_state;
+ struct pinctrl_state *unwedge_state;
+
struct mutex mutex; /* for state below and previous_mode */
enum drm_connector_force force; /* mutex-protected force state */
bool disabled; /* DRM has disabled our bridge */
@@ -247,11 +252,82 @@ static void dw_hdmi_i2c_init(struct dw_hdmi *hdmi)
HDMI_IH_MUTE_I2CM_STAT0);
}
+static bool dw_hdmi_i2c_unwedge(struct dw_hdmi *hdmi)
+{
+ /* If no unwedge state then give up */
+ if (IS_ERR(hdmi->unwedge_state))
+ return false;
+
+ dev_info(hdmi->dev, "Attempting to unwedge stuck i2c bus\n");
+
+ /*
+* This is a huge hack to workaround a problem where the dw_hdmi i2c
+* bus could sometimes get wedged. Once wedged there doesn't appear
+* to be any way to unwedge it (including the HDMI_I2CM_SOFTRSTZ)
+* other than pulsing the SDA line.
+*
+* We appear to be able to pulse the SDA line (in the eyes of dw_hdmi)
+* by:
+* 1. Remux the pin as a GPIO output, driven low.
+* 2. Wait a little while. 1 ms seems to work, but we'll do 10.
+* 3. Immediately jump to remux the pin as dw_hdmi i2c again.
+*
+* At the moment of remuxing, the line will still be low due to its
+* recent stint as an output, but then it will be pulled high by the
+* (presumed) external pullup. dw_hdmi seems to see this as a rising
+* edge and that seems to get it out of its jam.
+*
+* This wedging was only ever seen on one TV, and only on one of
+* its HDMI ports. It happened when the TV was powered on while the
+* device was plugged in. A scope trace shows the TV bringing both SDA
+* and SCL low, then bringing them both back up at roughly the same
+* time. Presumably this confuses dw_hdmi because it saw activity but
+* no real STOP (maybe it thinks there's another master on the bus?).
+* Giving it a clean rising edge of SDA while SCL is already high
+* presumably makes dw_hdmi see a STOP which seems to bring dw_hdmi out
+* of its stupor.
+*
+* Note that after coming back alive, transfers seem to immediately
+* resume, so if we unwedge due to a timeout we should wait a little
+* longer for our transfer to finish, since it might have just started
+* now.
+*/
+ pinctrl_select_state(hdmi->pinctrl, hdmi->unwedge_state);
+ msleep(10);
+ pinctrl_select_state(hdmi->pinctrl, hdmi->default_state);
+
+ return true;
+}
+
+static int dw_hdmi_i2c_wait(struct dw_hdmi *hdmi)
+{
+ struct dw_hdmi_i2c *i2c = hdmi->i2c;
+ int stat;
+
+ stat = wait_for_completion_timeout(>cmp, HZ / 10);
+ if (!stat) {
+ /* If we can't unwedge, return timeout */
+ if (!dw_hdmi_i2c_unwedge(hdmi))
+ return -EAGAIN;
+
+ /* We tried to unwedge; give it another chance */
+ stat = wait_for_completion_timeout(>cmp, HZ / 10);
+ if (!stat)
+ return -EAGAIN;
+ }
+
+ /* Check for error condition on the bus */
+ if (i2c->stat & HDMI_IH_I2CM_STAT0_ERROR)
+ return -EIO;
+
+ return 0;
+}
+
static int dw_hdmi_i2c_read(struct dw_hdmi *hdmi,
unsigned char *buf, unsigned int length)
{
struct dw_hdmi_i2c *i2c = hdmi->i2c;
- int stat;
+ int ret;
if (!i2c->is_regaddr) {
dev_dbg(hdmi->dev, "set read register address to 0\n");
@@ -270,13 +346,9 @@ static int dw_hdmi_i2c_read(struct dw_hdmi *hdmi,
hdmi_writeb(hdmi, HDMI_I2CM_OPERATION_READ,
HDMI_I2CM_OPERATION);
- stat = wait_for_completion_timeout(>cmp, HZ / 10);
-
[PATCH 1/5] dt-bindings: drm/bridge/synopsys: dw-hdmi: Add "unwedge" for ddc bus
In certain situations it was seen that we could wedge up the DDC bus
on the HDMI adapter on rk3288. The only way to unwedge was to mux one
of the pins over to GPIO output-driven-low temporarily and then
quickly mux back. Full details can be found in the patch
("drm/bridge/synopsys: dw-hdmi: Add "unwedge" for ddc bus").
Since unwedge requires remuxing the pins, we first need to add to the
bindings so that we can specify what state the pins should be in for
unwedging.
Signed-off-by: Douglas Anderson
---
.../bindings/display/rockchip/dw_hdmi-rockchip.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index 39143424a474..8346bac81f1c 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -38,6 +38,13 @@ Optional properties
- phys: from general PHY binding: the phandle for the PHY device.
- phy-names: Should be "hdmi" if phys references an external phy.
+Optional pinctrl entry:
+- If you have both a "unwedge" and "default" pinctrl entry, dw_hdmi
+ will switch to the unwedge pinctrl state for 10ms if it ever gets an
+ i2c timeout. It's intended that this unwedge pinctrl entry will
+ cause the SDA line to be driven low to work around a hardware
+ errata.
+
Example:
hdmi: hdmi@ff98 {
--
2.21.0.1020.gf2820cf01a-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/5] cgroup support for GPU devices
> Count us (Mellanox) too, our RDMA devices are exposing special and > limited in size device memory to the users and we would like to provide > an option to use cgroup to control its exposure. Doesn't RDMA already has a separate cgroup? Why not implement it there? > > and with future work, we could extend to: > > * track and control share of GPU time (reuse of cpu/cpuacct) > > * apply mask of allowed execution engines (reuse of cpusets) > > > > Instead of introducing a new cgroup subsystem for GPU devices, a new > > framework is proposed to allow devices to register with existing cgroup > > controllers, which creates per-device cgroup_subsys_state within the > > cgroup. This gives device drivers their own private cgroup controls > > (such as memory limits or other parameters) to be applied to device > > resources instead of host system resources. > > Device drivers (GPU or other) are then able to reuse the existing cgroup > > controls, instead of inventing similar ones. > > > > Per-device controls would be exposed in cgroup filesystem as: > > mount//.devices// > > such as (for example): > > mount//memory.devices//memory.max > > mount//memory.devices//memory.current > > mount//cpu.devices//cpu.stat > > mount//cpu.devices//cpu.weight > > > > The drm/i915 patch in this series is based on top of other RFC work [1] > > for i915 device memory support. > > > > AMD [2] and Intel [3] have proposed related work in this area within the > > last few years, listed below as reference. This new RFC reuses existing > > cgroup controllers and takes a different approach than prior work. > > > > Finally, some potential discussion points for this series: > > * merge proposed .devices into a single devices directory? > > * allow devices to have multiple registrations for subsets of resources? > > * document a 'common charging policy' for device drivers to follow? > > > > [1] https://patchwork.freedesktop.org/series/56683/ > > [2] > > https://lists.freedesktop.org/archives/dri-devel/2018-November/197106.html > > [3] > > https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html > > > > > > Brian Welty (5): > > cgroup: Add cgroup_subsys per-device registration framework > > cgroup: Change kernfs_node for directories to store > > cgroup_subsys_state > > memcg: Add per-device support to memory cgroup subsystem > > drm: Add memory cgroup registration and DRIVER_CGROUPS feature bit > > drm/i915: Use memory cgroup for enforcing device memory limit > > > > drivers/gpu/drm/drm_drv.c | 12 + > > drivers/gpu/drm/drm_gem.c | 7 + > > drivers/gpu/drm/i915/i915_drv.c| 2 +- > > drivers/gpu/drm/i915/intel_memory_region.c | 24 +- > > include/drm/drm_device.h | 3 + > > include/drm/drm_drv.h | 8 + > > include/drm/drm_gem.h | 11 + > > include/linux/cgroup-defs.h| 28 ++ > > include/linux/cgroup.h | 3 + > > include/linux/memcontrol.h | 10 + > > kernel/cgroup/cgroup-v1.c | 10 +- > > kernel/cgroup/cgroup.c | 310 ++--- > > mm/memcontrol.c| 183 +++- > > 13 files changed, 552 insertions(+), 59 deletions(-) > > > > -- > > 2.21.0 > > > ___ > 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
[Bug 110443] vaapi/vpp: wrong output for non 64-bytes align width (ex: 1200)
https://bugs.freedesktop.org/show_bug.cgi?id=110443 --- Comment #11 from Julien Isorce --- https://gitlab.freedesktop.org/mesa/mesa/merge_requests/796 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/rockchip: dw_hdmi: Handle suspend/resume
On Rockchip rk3288-based Chromebooks when you do a suspend/resume
cycle:
1. You lose the ability to detect an HDMI device being plugged in.
2. If you're using the i2c bus built in to dw_hdmi then it stops
working.
Let's call the core dw-hdmi's suspend/resume functions to restore
things.
NOTE: in downstream Chrome OS (based on kernel 3.14) we used the
"late/early" versions of suspend/resume because we found that the VOP
was sometimes resuming before dw_hdmi and then calling into us before
we were fully resumed. For now I have gone back to the normal
suspend/resume because I can't reproduce the problems.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 4cdc9f86c2e5..deb0e8c30c03 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -542,11 +542,31 @@ static int dw_hdmi_rockchip_remove(struct platform_device
*pdev)
return 0;
}
+static int __maybe_unused dw_hdmi_rockchip_suspend(struct device *dev)
+{
+ struct rockchip_hdmi *hdmi = dev_get_drvdata(dev);
+
+ return dw_hdmi_suspend(hdmi->hdmi);
+}
+
+static int __maybe_unused dw_hdmi_rockchip_resume(struct device *dev)
+{
+ struct rockchip_hdmi *hdmi = dev_get_drvdata(dev);
+
+ return dw_hdmi_resume(hdmi->hdmi);
+}
+
+const struct dev_pm_ops dw_hdmi_rockchip_pm = {
+ SET_SYSTEM_SLEEP_PM_OPS(dw_hdmi_rockchip_suspend,
+ dw_hdmi_rockchip_resume)
+};
+
struct platform_driver dw_hdmi_rockchip_pltfm_driver = {
.probe = dw_hdmi_rockchip_probe,
.remove = dw_hdmi_rockchip_remove,
.driver = {
.name = "dwhdmi-rockchip",
+ .pm = _hdmi_rockchip_pm,
.of_match_table = dw_hdmi_rockchip_dt_ids,
},
};
--
2.21.0.1020.gf2820cf01a-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: bridge: dw-hdmi: Add hooks for suspend/resume
On Rockchip rk3288-based Chromebooks when you do a suspend/resume
cycle:
1. You lose the ability to detect an HDMI device being plugged in.
2. If you're using the i2c bus built in to dw_hdmi then it stops
working.
Let's add a hook to the core dw-hdmi driver so that we can call it in
dw_hdmi-rockchip in the next commit.
NOTE: the exact set of steps I've done here in resume come from
looking at the normal dw_hdmi init sequence in upstream Linux plus the
sequence that we did in downstream Chrome OS 3.14. Testing show that
it seems to work, but if an extra step is needed or something here is
not needed we could improve it.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 21 +
include/drm/bridge/dw_hdmi.h | 3 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index db761329a1e3..4b38bfd43e59 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2780,6 +2780,27 @@ void dw_hdmi_unbind(struct dw_hdmi *hdmi)
}
EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
+int dw_hdmi_suspend(struct dw_hdmi *hdmi)
+{
+ return 0;
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_suspend);
+
+int dw_hdmi_resume(struct dw_hdmi *hdmi)
+{
+ initialize_hdmi_ih_mutes(hdmi);
+
+ dw_hdmi_setup_i2c(hdmi);
+ if (hdmi->i2c)
+ dw_hdmi_i2c_init(hdmi);
+
+ if (hdmi->phy.ops->setup_hpd)
+ hdmi->phy.ops->setup_hpd(hdmi, hdmi->phy.data);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_resume);
+
MODULE_AUTHOR("Sascha Hauer ");
MODULE_AUTHOR("Andy Yan ");
MODULE_AUTHOR("Yakir Yang ");
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 66e70770cce5..c4132e9a5ae3 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -154,6 +154,9 @@ struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
struct drm_encoder *encoder,
const struct dw_hdmi_plat_data *plat_data);
+int dw_hdmi_suspend(struct dw_hdmi *hdmi);
+int dw_hdmi_resume(struct dw_hdmi *hdmi);
+
void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense);
void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);
--
2.21.0.1020.gf2820cf01a-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109345] drm-next-2018-12-14 -Linux PPC
https://bugs.freedesktop.org/show_bug.cgi?id=109345 --- Comment #26 from Christian Zigotzky --- (In reply to Michel Dänzer from comment #25) > (In reply to Christian Zigotzky from comment #24) > > With which good and bad commit should I start bisecting? > > Good: c76cd634eb5bfd497617ea224a54a03b545c8c4d > Bad: 4971f090aa7f6ce5daa094ce4334f6618f93a7eb Hi Michel, Thanks a lot for your help! :-) I started bisecting today. git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git drm_test cd drm_test git bisect start git bisect good c76cd634eb5bfd497617ea224a54a03b545c8c4d git bisect bad 4971f090aa7f6ce5daa094ce4334f6618f93a7eb Output: Bisecting: 653 revisions left to test after this (roughly 10 steps) [2ac5e38ea4203852d6e99edd3cf11f044b0a409f] Merge drm/drm-next into drm-intel-next-queued --- cp ../linux-image-5.1-rc7-X1000_X5000/X5000_and_QEMU_e5500/src/cyrus-5.1-rc7.config .config make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage Download: http://www.xenosoft.de/uImage-drm1 @Allan (acefnq/ace) Please test this kernel with the two installed graphics cards. Thanks, Christian -- 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 1/2] drm/panel: simple: Add FriendlyELEC HD702E 800x1280 LCD panel
On Wed, 1 May 2019 17:44:47 +0530, Jagan Teki wrote: > HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280 > resolution. It has built in Goodix, GT9271 captive touchscreen > with backlight adjustable via PWM. > > Add support for it. > > Cc: Thierry Reding > Cc: Sam Ravnborg > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Jagan Teki > --- > .../display/panel/friendlyarm,hd702e.txt | 29 +++ > drivers/gpu/drm/panel/panel-simple.c | 26 + > 2 files changed, 55 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108892] kernel BUG at kernel/time/timer.c:1137 in drm_sched_job_finish [gpu_sched]
https://bugs.freedesktop.org/show_bug.cgi?id=108892 --- Comment #8 from Sami Farin --- Created attachment 144130 --> https://bugs.freedesktop.org/attachment.cgi?id=144130=edit dmesg 4.19.37 has this bug also. Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Lexa PRO [Radeon RX 550/550X] driver: amdgpu v: kernel Display: server: Fedora Project X.org 1.20.4 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa resolution: 3840x2160~60Hz OpenGL: renderer: Radeon 550 Series (POLARIS12 DRM 3.27.0 4.19.38+ LLVM 7.0.1) v: 4.5 Mesa 19.0.3 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 0/3] mesa: Initial build fixups for AOSP/master
On Thu, May 2, 2019 at 1:20 PM Greg Hartman wrote: > > + dwillem...@google.com background on the build changes. > > Thanks for doing this. It will be helpful to have fixes to make this build > again. > We're still a bit out from getting master to build w/ the current AOSP tree. We need solutions for the xgettext and the python-mako usage. The current AOSP tree checks in prebuilt-intermediates that are hand generated (which is messy to re-create), so I'm thinking we should externalize the intermediate source generation into something like a script, which the build system can call in the normal case, or that we can run independently on a host to generate prebuilt intermediate source files that can be checked into the AOSP tree. But I wanted to get these basic fixes in so its easier to have working before and after trees to compare any such build changes. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 0/3] mesa: Initial build fixups for AOSP/master
On Thu, May 2, 2019 at 1:31 PM Rob Clark wrote: > > fyi, John pushed a MR w/ the same patches: > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/795 > > (I'm not really an expert on android build system, but if it works, > then ack-by from me) > So there's one new issue that cropped up when I re-based, but I'll have a fix for that here in a second and will update the MR. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201273] Fatal error during GPU init amdgpu RX560
https://bugzilla.kernel.org/show_bug.cgi?id=201273 --- Comment #50 from quirin.blae...@freenet.de --- Bug is still alive. v5.0.10 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/17] kunit: test: add initial tests
On Thu, May 2, 2019 at 3:58 AM Greg KH wrote: > > On Wed, May 01, 2019 at 04:01:16PM -0700, Brendan Higgins wrote: > > Add a test for string stream along with a simpler example. > > > > Signed-off-by: Brendan Higgins > > --- > > kunit/Kconfig | 12 ++ > > kunit/Makefile | 4 ++ > > kunit/example-test.c | 88 ++ > > kunit/string-stream-test.c | 61 ++ > > 4 files changed, 165 insertions(+) > > create mode 100644 kunit/example-test.c > > create mode 100644 kunit/string-stream-test.c > > > > diff --git a/kunit/Kconfig b/kunit/Kconfig > > index 64480092b2c24..5cb500355c873 100644 > > --- a/kunit/Kconfig > > +++ b/kunit/Kconfig > > @@ -13,4 +13,16 @@ config KUNIT > > special hardware. For more information, please see > > Documentation/kunit/ > > > > +config KUNIT_TEST > > + bool "KUnit test for KUnit" > > + depends on KUNIT > > + help > > + Enables KUnit test to test KUnit. > > + > > +config KUNIT_EXAMPLE_TEST > > + bool "Example test for KUnit" > > + depends on KUNIT > > + help > > + Enables example KUnit test to demo features of KUnit. > > Can't these tests be module? At this time, no. KUnit doesn't support loading tests as kernel modules; it is something we could add in in the future, but I would rather not open that can of worms right now. There are some other things I would like to do that would probably be easier to do before adding support for tests as loadable modules. > > Or am I mis-reading the previous logic? > > Anyway, just a question, nothing objecting to this as-is for now. Cool Cheers! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/17] kunit: test: add kunit_stream a std::stream like logger
On Thu, May 2, 2019 at 4:00 AM Greg KH wrote: > > On Wed, May 01, 2019 at 04:01:13PM -0700, Brendan Higgins wrote: > > A lot of the expectation and assertion infrastructure prints out fairly > > complicated test failure messages, so add a C++ style log library for > > for logging test results. > > Ideally we would always use a standard logging format, like the > kselftest tests all are aiming to do. That way the output can be easily > parsed by tools to see if the tests succeed/fail easily. > > Any chance of having this logging framework enforcing that format as > well? I agree with your comment on the later patch that we should handle this at the wrapper script layer (KUnit tool). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/doc: Document the writeback prepare/cleanup jobs
From: Sean Paul
These functions were missing documentation.
Fixes the warning:
../include/drm/drm_modeset_helper_vtables.h:1000: warning: Function parameter
or member 'prepare_writeback_job' not described in 'drm_connector_helper_funcs'
../include/drm/drm_modeset_helper_vtables.h:1000: warning: Function parameter
or member 'cleanup_writeback_job' not described in 'drm_connector_helper_funcs'
Fixes: 9d2230dc1351 ("drm: writeback: Add job prepare and cleanup operations")
Cc: Laurent Pinchart
Cc: Liviu Dudau
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_writeback.c | 20
include/drm/drm_modeset_helper_vtables.h | 20
2 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index 79ac014701c8..ef6f85966546 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -258,6 +258,15 @@ int drm_writeback_set_fb(struct drm_connector_state
*conn_state,
return 0;
}
+/**
+ * drm_writeback_prepare_job - Gives driver a chance to prepare for writeback
+ * @job: The writeback job to be prepared
+ *
+ * This function is called from _atomic_helper_prepare_planes(), and allows
+ * the driver to setup the upcoming writeback job. The job will be
+ * destroyed/cleaned up in _writeback_cleanup_job when the connector state
+ * is destroyed.
+ */
int drm_writeback_prepare_job(struct drm_writeback_job *job)
{
struct drm_writeback_connector *connector = job->connector;
@@ -310,6 +319,17 @@ void drm_writeback_queue_job(struct
drm_writeback_connector *wb_connector,
}
EXPORT_SYMBOL(drm_writeback_queue_job);
+/**
+ * drm_writeback_cleanup_job - Gives driver a chance to cleanup a writeback job
+ * @job: The writeback job to be cleaned up
+ *
+ * This function is called from _helper_connector_destroy_state() and
+ * allows the driver to clean up the now finished writeback job.
+ *
+ * Notice the asymmetry from prepare, this is called on destroy to
+ * ensure the job is not destroyed before than the writeback operation
+ * has completed.
+ */
void drm_writeback_cleanup_job(struct drm_writeback_job *job)
{
struct drm_writeback_connector *connector = job->connector;
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index 8f3602811eb5..a0017f37ef55 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -992,8 +992,28 @@ struct drm_connector_helper_funcs {
void (*atomic_commit)(struct drm_connector *connector,
struct drm_connector_state *state);
+ /**
+* @prepare_writeback_job:
+*
+* Called from _atomic_helper_prepare_planes(), provides the driver
+* a chance to setup things in preparation for a writeback job.
+*
+* This hook is optional.
+*/
int (*prepare_writeback_job)(struct drm_writeback_connector *connector,
struct drm_writeback_job *job);
+
+ /**
+* @cleanup_writeback_job:
+*
+* Called from _atomic_helper_connector_destroy_state(), and
+* provides the driver an opportunity to cleanup the writeback job.
+* Notice the asymmetry from prepare, this is called on destroy to
+* ensure the job is not destroyed before than the writeback operation
+* has completed.
+*
+* This hook is optional.
+*/
void (*cleanup_writeback_job)(struct drm_writeback_connector *connector,
struct drm_writeback_job *job);
};
--
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 1/2] drm/doc: Remove atomic_state_helper.h from drm-kms-helpers.rst
From: Sean Paul
There are no structured comments in the file, so it generates this
warning on compilation:
include/drm/drm_atomic_state_helper.h:1: warning: no structured comments found
Fixes: 9ef8a9dc4b21 ("drm: Extract drm_atomic_state_helper.[hc]")
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sean Paul
---
Documentation/gpu/drm-kms-helpers.rst | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 14102ae035dc..e7804a9eef9f 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -77,9 +77,6 @@ Atomic State Reset and Initialization
Atomic State Helper Reference
-
-.. kernel-doc:: include/drm/drm_atomic_state_helper.h
- :internal:
-
.. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c
:export:
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110443] vaapi/vpp: wrong output for non 64-bytes align width (ex: 1200)
https://bugs.freedesktop.org/show_bug.cgi?id=110443 --- Comment #10 from Viktor Jägersküpper --- I tried to investigate a bit further, and I think video acceleration does not really work on my RV770, neither with VA-API nor with VDPAU. However, even if I deactivate hardware video decoding in VLC, it crashes when I want to play a video. So I think you're right, it should just fall back to whatever "worked" before the change. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 10/10] drm/rockchip: Use drm_atomic_helper_commit_tail_rpm
From: Sean Paul
Now that we use the drm psr helpers, we no longer need to hand-roll our
atomic_commit_tail implementation. So use the helper
Changes in v2:
- None
Changes in v3:
- None
Link to v1:
https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-6-s...@poorly.run
Link to v2:
https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-5-s...@poorly.run
Cc: Zain Wang
Cc: Tomasz Figa
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 214064d599ee..1c63d9e833bc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -117,27 +117,8 @@ rockchip_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
return ERR_PTR(ret);
}
-static void
-rockchip_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state)
-{
- struct drm_device *dev = old_state->dev;
-
- drm_atomic_helper_commit_modeset_disables(dev, old_state);
-
- drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
- drm_atomic_helper_commit_planes(dev, old_state,
- DRM_PLANE_COMMIT_ACTIVE_ONLY);
-
- drm_atomic_helper_commit_hw_done(old_state);
-
- drm_atomic_helper_wait_for_vblanks(dev, old_state);
-
- drm_atomic_helper_cleanup_planes(dev, old_state);
-}
-
static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers
= {
- .atomic_commit_tail = rockchip_atomic_helper_commit_tail_rpm,
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
};
static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
--
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 v3 00/10] drm: Add self refresh helpers
From: Sean Paul Hey all, Back from my break from this. v3 isn't a whole lot different from v2, aside from the new helpers that I've added. These allowed me to remove some redundant state from connector and rely solely on crtc_state. Please take a look, Sean Sean Paul (10): drm: Add atomic variants of enable/disable to encoder helper funcs drm: Add drm_atomic_crtc_state_for_encoder helper drm: Add atomic variants for bridge enable/disable drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state drm: Add helpers to kick off self refresh mode in drivers drm/rockchip: Use dirtyfb helper drm/rockchip: Check for fast link training before enabling psr drm/rockchip: Use the helpers for PSR drm/rockchip: Don't fully disable vop on self refresh drm/rockchip: Use drm_atomic_helper_commit_tail_rpm Documentation/gpu/drm-kms-helpers.rst | 9 + drivers/gpu/drm/Makefile | 2 +- .../drm/bridge/analogix/analogix_dp_core.c| 266 +++- .../drm/bridge/analogix/analogix_dp_core.h| 2 +- drivers/gpu/drm/drm_atomic.c | 2 + drivers/gpu/drm/drm_atomic_helper.c | 101 +- drivers/gpu/drm/drm_atomic_state_helper.c | 4 + drivers/gpu/drm/drm_atomic_uapi.c | 7 +- drivers/gpu/drm/drm_bridge.c | 110 +++ drivers/gpu/drm/drm_self_refresh_helper.c | 205 + drivers/gpu/drm/i915/intel_atomic.c | 8 +- drivers/gpu/drm/i915/intel_dp_mst.c | 7 +- drivers/gpu/drm/i915/intel_drv.h | 2 +- drivers/gpu/drm/i915/intel_sdvo.c | 9 +- drivers/gpu/drm/i915/intel_tv.c | 8 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +- drivers/gpu/drm/rcar-du/rcar_lvds.c | 12 +- drivers/gpu/drm/rockchip/Makefile | 3 +- .../gpu/drm/rockchip/analogix_dp-rockchip.c | 86 +++--- drivers/gpu/drm/rockchip/rockchip_drm_fb.c| 39 +-- drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 290 -- drivers/gpu/drm/rockchip/rockchip_drm_psr.h | 30 -- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 71 - drivers/gpu/drm/vc4/vc4_txp.c | 7 +- include/drm/bridge/analogix_dp.h | 4 - include/drm/drm_atomic.h | 15 + include/drm/drm_atomic_helper.h | 6 + include/drm/drm_bridge.h | 114 +++ include/drm/drm_connector.h | 14 + include/drm/drm_crtc.h| 19 ++ include/drm/drm_modeset_helper_vtables.h | 47 ++- include/drm/drm_self_refresh_helper.h | 22 ++ 32 files changed, 983 insertions(+), 543 deletions(-) create mode 100644 drivers/gpu/drm/drm_self_refresh_helper.c delete mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c delete mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h create mode 100644 include/drm/drm_self_refresh_helper.h -- 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 v3 09/10] drm/rockchip: Don't fully disable vop on self refresh
From: Sean Paul
Instead of fully disabling and re-enabling the vop on self refresh
transitions, only disable the active windows. This will speed up
self refresh exits substantially and is still a power-savings win.
This patch integrates portions of Zain's patch from here:
https://patchwork.kernel.org/patch/9615063/
Changes in v2:
- None
Changes in v3:
- None
Link to v1:
https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-5-s...@poorly.run
Link to v2:
https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-4-s...@poorly.run
Cc: Zain Wang
Cc: Tomasz Figa
Cc: Kristian H. Kristensen
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 38 +
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 45a38a332827..d171d90418c8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -134,6 +134,7 @@ struct vop {
bool is_enabled;
struct completion dsp_hold_completion;
+ unsigned int win_enabled;
/* protected by dev->event_lock */
struct drm_pending_vblank_event *event;
@@ -594,6 +595,7 @@ static int vop_enable(struct drm_crtc *crtc, struct
drm_crtc_state *old_state)
const struct vop_win_data *win = vop_win->data;
VOP_WIN_SET(vop, win, enable, 0);
+ vop->win_enabled &= ~BIT(i);
}
}
spin_unlock(>reg_lock);
@@ -624,6 +626,25 @@ static int vop_enable(struct drm_crtc *crtc, struct
drm_crtc_state *old_state)
return ret;
}
+static void rockchip_drm_set_win_enabled(struct drm_crtc *crtc, bool enabled)
+{
+struct vop *vop = to_vop(crtc);
+int i;
+
+spin_lock(>reg_lock);
+
+for (i = 0; i < vop->data->win_size; i++) {
+struct vop_win *vop_win = >win[i];
+const struct vop_win_data *win = vop_win->data;
+
+VOP_WIN_SET(vop, win, enable,
+enabled && (vop->win_enabled & BIT(i)));
+}
+vop_cfg_done(vop);
+
+spin_unlock(>reg_lock);
+}
+
static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
@@ -631,9 +652,15 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
WARN_ON(vop->event);
+ if (crtc->state->self_refresh_active)
+ rockchip_drm_set_win_enabled(crtc, false);
+
mutex_lock(>vop_lock);
drm_crtc_vblank_off(crtc);
+ if (crtc->state->self_refresh_active)
+ goto out;
+
/*
* Vop standby will take effect at end of current frame,
* if dsp hold valid irq happen, it means standby complete.
@@ -664,6 +691,8 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
clk_disable(vop->dclk);
vop_core_clks_disable(vop);
pm_runtime_put(vop->dev);
+
+out:
mutex_unlock(>vop_lock);
if (crtc->state->event && !crtc->state->active) {
@@ -744,6 +773,7 @@ static void vop_plane_atomic_disable(struct drm_plane
*plane,
spin_lock(>reg_lock);
VOP_WIN_SET(vop, win, enable, 0);
+ vop->win_enabled &= ~BIT(VOP_WIN_TO_INDEX(vop_win));
spin_unlock(>reg_lock);
}
@@ -882,6 +912,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
}
VOP_WIN_SET(vop, win, enable, 1);
+ vop->win_enabled |= BIT(win_index);
spin_unlock(>reg_lock);
}
@@ -1038,6 +1069,12 @@ static void vop_crtc_atomic_enable(struct drm_crtc *crtc,
int dither_bpc = s->output_bpc ? s->output_bpc : 10;
int ret;
+ if (old_state && old_state->self_refresh_active) {
+ drm_crtc_vblank_on(crtc);
+ rockchip_drm_set_win_enabled(crtc, true);
+ return;
+ }
+
mutex_lock(>vop_lock);
WARN_ON(vop->event);
@@ -1648,6 +1685,7 @@ static int vop_initial(struct vop *vop)
VOP_WIN_SET(vop, win, channel, (channel + 1) << 4 | channel);
VOP_WIN_SET(vop, win, enable, 0);
VOP_WIN_SET(vop, win, gate, 1);
+ vop->win_enabled &= ~BIT(i);
}
vop_cfg_done(vop);
--
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 v3 06/10] drm/rockchip: Use dirtyfb helper
From: Sean Paul
Instead of flushing all vops every time we get a dirtyfb call, use the
damage helper to kick off an atomic commit. Even though we don't use
damage clips, the helper commit will force us through the normal
psr_inhibit_get/put sequence.
Changes in v3:
- Added to the set
Suggested-by: Daniel Vetter
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 97438bbbe389..02e81ca2d933 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -25,20 +26,10 @@
#include "rockchip_drm_gem.h"
#include "rockchip_drm_psr.h"
-static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
-struct drm_file *file,
-unsigned int flags, unsigned int color,
-struct drm_clip_rect *clips,
-unsigned int num_clips)
-{
- rockchip_drm_psr_flush_all(fb->dev);
- return 0;
-}
-
static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
- .dirty = rockchip_drm_fb_dirty,
+ .dirty = drm_atomic_helper_dirtyfb,
};
static struct drm_framebuffer *
--
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 v3 07/10] drm/rockchip: Check for fast link training before enabling psr
From: Sean Paul
Once we start shutting off the link during PSR, we're going to want fast
training to work. If the display doesn't support fast training, don't
enable psr.
Changes in v2:
- None
Changes in v3:
- None
Link to v1:
https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-3-s...@poorly.run
Link to v2:
https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-2-s...@poorly.run
Cc: Zain Wang
Cc: Tomasz Figa
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 225f5e5dd69b..af34554a5a02 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1040,16 +1040,17 @@ static int analogix_dp_commit(struct analogix_dp_device
*dp)
if (ret)
return ret;
+ /* Check whether panel supports fast training */
+ ret = analogix_dp_fast_link_train_detection(dp);
+ if (ret)
+ dp->psr_enable = false;
+
if (dp->psr_enable) {
ret = analogix_dp_enable_sink_psr(dp);
if (ret)
return ret;
}
- /* Check whether panel supports fast training */
- ret = analogix_dp_fast_link_train_detection(dp);
- if (ret)
- dp->psr_enable = false;
return ret;
}
--
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 v3 08/10] drm/rockchip: Use the helpers for PSR
From: Sean Paul
Instead of rolling our own implementation for tracking when PSR should
be [in]active, use the new self refresh helpers to do the heavy lifting.
Changes in v2:
- updated to reflect changes made in the helpers
Changes in v3:
- use the new atomic hooks to inspect crtc state instead of needing conn state
(Daniel)
Link to v1:
https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-4-s...@poorly.run
Link to v2:
https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-3-s...@poorly.run
Cc: Zain Wang
Cc: Tomasz Figa
Signed-off-by: Sean Paul
---
.../drm/bridge/analogix/analogix_dp_core.c| 265 +++-
.../drm/bridge/analogix/analogix_dp_core.h| 2 +-
drivers/gpu/drm/rockchip/Makefile | 3 +-
.../gpu/drm/rockchip/analogix_dp-rockchip.c | 86 +++---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c| 5 -
drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 290 --
drivers/gpu/drm/rockchip/rockchip_drm_psr.h | 30 --
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 33 +-
include/drm/bridge/analogix_dp.h | 4 -
9 files changed, 243 insertions(+), 475 deletions(-)
delete mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c
delete mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index af34554a5a02..e66c105c3b68 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -24,6 +24,7 @@
#include
#include
+#include
#include
#include
#include
@@ -106,63 +107,7 @@ static int analogix_dp_detect_hpd(struct
analogix_dp_device *dp)
return 0;
}
-int analogix_dp_psr_enabled(struct analogix_dp_device *dp)
-{
-
- return dp->psr_enable;
-}
-EXPORT_SYMBOL_GPL(analogix_dp_psr_enabled);
-
-int analogix_dp_enable_psr(struct analogix_dp_device *dp)
-{
- struct edp_vsc_psr psr_vsc;
-
- if (!dp->psr_enable)
- return 0;
-
- /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
- memset(_vsc, 0, sizeof(psr_vsc));
- psr_vsc.sdp_header.HB0 = 0;
- psr_vsc.sdp_header.HB1 = 0x7;
- psr_vsc.sdp_header.HB2 = 0x2;
- psr_vsc.sdp_header.HB3 = 0x8;
-
- psr_vsc.DB0 = 0;
- psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
-
- return analogix_dp_send_psr_spd(dp, _vsc, true);
-}
-EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
-
-int analogix_dp_disable_psr(struct analogix_dp_device *dp)
-{
- struct edp_vsc_psr psr_vsc;
- int ret;
-
- if (!dp->psr_enable)
- return 0;
-
- /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
- memset(_vsc, 0, sizeof(psr_vsc));
- psr_vsc.sdp_header.HB0 = 0;
- psr_vsc.sdp_header.HB1 = 0x7;
- psr_vsc.sdp_header.HB2 = 0x2;
- psr_vsc.sdp_header.HB3 = 0x8;
-
- psr_vsc.DB0 = 0;
- psr_vsc.DB1 = 0;
-
- ret = drm_dp_dpcd_writeb(>aux, DP_SET_POWER, DP_SET_POWER_D0);
- if (ret != 1) {
- dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
- return ret;
- }
-
- return analogix_dp_send_psr_spd(dp, _vsc, false);
-}
-EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
-
-static int analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
+static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
{
unsigned char psr_version;
int ret;
@@ -170,14 +115,11 @@ static int analogix_dp_detect_sink_psr(struct
analogix_dp_device *dp)
ret = drm_dp_dpcd_readb(>aux, DP_PSR_SUPPORT, _version);
if (ret != 1) {
dev_err(dp->dev, "failed to get PSR version, disable it\n");
- return ret;
+ return false;
}
dev_dbg(dp->dev, "Panel PSR version : %x\n", psr_version);
-
- dp->psr_enable = (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
-
- return 0;
+ return psr_version & DP_PSR_IS_SUPPORTED;
}
static int analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
@@ -200,7 +142,7 @@ static int analogix_dp_enable_sink_psr(struct
analogix_dp_device *dp)
}
/* Main-Link transmitter remains active during PSR active states */
- psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
+ psr_en = DP_PSR_CRC_VERIFICATION;
ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
if (ret != 1) {
dev_err(dp->dev, "failed to set panel psr\n");
@@ -208,8 +150,7 @@ static int analogix_dp_enable_sink_psr(struct
analogix_dp_device *dp)
}
/* Enable psr function */
- psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
-DP_PSR_CRC_VERIFICATION;
+ psr_en = DP_PSR_ENABLE | DP_PSR_CRC_VERIFICATION;
ret = drm_dp_dpcd_writeb(>aux, DP_PSR_EN_CFG, psr_en);
if (ret != 1) {
[PATCH v3 04/10] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
From: Sean Paul
Everyone who implements connector_helper_funcs->atomic_check reaches
into the connector state to get the atomic state. Instead of continuing
this pattern, change the callback signature to just give atomic state
and let the driver determine what it does and does not need from it.
Eventually all atomic functions should do this, but that's just too much
busy work for me.
Changes in v3:
- Added to the set
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Ben Skeggs
Cc: Laurent Pinchart
Cc: Kieran Bingham
Cc: Eric Anholt
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
drivers/gpu/drm/i915/intel_atomic.c | 8 +---
drivers/gpu/drm/i915/intel_dp_mst.c | 7 ---
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_sdvo.c| 9 +
drivers/gpu/drm/i915/intel_tv.c | 8 +---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +++--
drivers/gpu/drm/rcar-du/rcar_lvds.c | 12 +++-
drivers/gpu/drm/vc4/vc4_txp.c| 7 ---
include/drm/drm_modeset_helper_vtables.h | 2 +-
10 files changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9d9e47276839..fa5a367507c1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -683,7 +683,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
}
if (funcs->atomic_check)
- ret = funcs->atomic_check(connector,
new_connector_state);
+ ret = funcs->atomic_check(connector, state);
if (ret)
return ret;
@@ -725,7 +725,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
continue;
if (funcs->atomic_check)
- ret = funcs->atomic_check(connector,
new_connector_state);
+ ret = funcs->atomic_check(connector, state);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index b844e8840c6f..e8a5b82e9242 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -103,12 +103,14 @@ int intel_digital_connector_atomic_set_property(struct
drm_connector *connector,
}
int intel_digital_connector_atomic_check(struct drm_connector *conn,
-struct drm_connector_state *new_state)
+struct drm_atomic_state *state)
{
+ struct drm_connector_state *new_state =
+ drm_atomic_get_new_connector_state(state, conn);
struct intel_digital_connector_state *new_conn_state =
to_intel_digital_connector_state(new_state);
struct drm_connector_state *old_state =
- drm_atomic_get_old_connector_state(new_state->state, conn);
+ drm_atomic_get_old_connector_state(state, conn);
struct intel_digital_connector_state *old_conn_state =
to_intel_digital_connector_state(old_state);
struct drm_crtc_state *crtc_state;
@@ -118,7 +120,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
if (!new_state->crtc)
return 0;
- crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
new_state->crtc);
+ crtc_state = drm_atomic_get_new_crtc_state(state, new_state->crtc);
/*
* These properties are handled by fastset, and might not end
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 19d81cef2ab6..89cfec128ba0 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -143,9 +143,10 @@ static int intel_dp_mst_compute_config(struct
intel_encoder *encoder,
static int
intel_dp_mst_atomic_check(struct drm_connector *connector,
- struct drm_connector_state *new_conn_state)
+ struct drm_atomic_state *state)
{
- struct drm_atomic_state *state = new_conn_state->state;
+ struct drm_connector_state *new_conn_state =
+ drm_atomic_get_new_connector_state(state, connector);
struct drm_connector_state *old_conn_state =
drm_atomic_get_old_connector_state(state, connector);
struct intel_connector *intel_connector =
@@ -155,7 +156,7 @@ intel_dp_mst_atomic_check(struct drm_connector *connector,
struct drm_dp_mst_topology_mgr *mgr;
int ret;
- ret = intel_digital_connector_atomic_check(connector, new_conn_state);
+ ret = intel_digital_connector_atomic_check(connector, state);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index
[PATCH v3 01/10] drm: Add atomic variants of enable/disable to encoder helper funcs
From: Sean Paul
This patch adds atomic_enable and atomic_disable callbacks to the
encoder helpers. This will allow encoders to make informed decisions in
their start-up/shutdown based on the committed state.
Aside from the new hooks, this patch also introduces the new signature
for .atomic_* functions going forward. Instead of passing object state
(well, encoders don't have atomic state, but let's ignore that), we pass
the entire atomic state so the driver can inspect more than what's
happening locally.
This is particularly important for the upcoming self refresh helpers.
Changes in v3:
- Added patch to the set
Cc: Daniel Vetter
Cc: Ville Syrjälä
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_atomic_helper.c | 6 +++-
include/drm/drm_modeset_helper_vtables.h | 45
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 553415fe8ede..71cc7d6b0644 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1001,6 +1001,8 @@ disable_outputs(struct drm_device *dev, struct
drm_atomic_state *old_state)
if (funcs) {
if (new_conn_state->crtc && funcs->prepare)
funcs->prepare(encoder);
+ else if (funcs->atomic_disable)
+ funcs->atomic_disable(encoder, old_state);
else if (funcs->disable)
funcs->disable(encoder);
else if (funcs->dpms)
@@ -1309,7 +1311,9 @@ void drm_atomic_helper_commit_modeset_enables(struct
drm_device *dev,
drm_bridge_pre_enable(encoder->bridge);
if (funcs) {
- if (funcs->enable)
+ if (funcs->atomic_enable)
+ funcs->atomic_enable(encoder, old_state);
+ else if (funcs->enable)
funcs->enable(encoder);
else if (funcs->commit)
funcs->commit(encoder);
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index 8f3602811eb5..de57fb40cb6e 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -675,6 +675,51 @@ struct drm_encoder_helper_funcs {
enum drm_connector_status (*detect)(struct drm_encoder *encoder,
struct drm_connector *connector);
+ /**
+* @atomic_disable:
+*
+* This callback should be used to disable the encoder. With the atomic
+* drivers it is called before this encoder's CRTC has been shut off
+* using their own _crtc_helper_funcs.atomic_disable hook. If that
+* sequence is too simple drivers can just add their own driver private
+* encoder hooks and call them from CRTC's callback by looping over all
+* encoders connected to it using for_each_encoder_on_crtc().
+*
+* This callback is a variant of @disable that provides the atomic state
+* to the driver. It takes priority over @disable during atomic commits.
+*
+* This hook is used only by atomic helpers. Atomic drivers don't need
+* to implement it if there's no need to disable anything at the encoder
+* level. To ensure that runtime PM handling (using either DPMS or the
+* new "ACTIVE" property) works @atomic_disable must be the inverse of
+* @atomic_enable.
+*/
+ void (*atomic_disable)(struct drm_encoder *encoder,
+ struct drm_atomic_state *state);
+
+ /**
+* @atomic_enable:
+*
+* This callback should be used to enable the encoder. It is called
+* after this encoder's CRTC has been enabled using their own
+* _crtc_helper_funcs.atomic_enable hook. If that sequence is
+* too simple drivers can just add their own driver private encoder
+* hooks and call them from CRTC's callback by looping over all encoders
+* connected to it using for_each_encoder_on_crtc().
+*
+* This callback is a variant of @enable that provides the atomic state
+* to the driver. It is called in place of @enable during atomic
+* commits.
+*
+* This hook is used only by atomic helpers, for symmetry with @disable.
+* Atomic drivers don't need to implement it if there's no need to
+* enable anything at the encoder level. To ensure that runtime PM
+* handling (using either DPMS or the new "ACTIVE" property) works
+* @enable must be the inverse of @disable for atomic drivers.
+*/
+ void (*atomic_enable)(struct drm_encoder *encoder,
+ struct drm_atomic_state *state);
+
/**
[PATCH v3 03/10] drm: Add atomic variants for bridge enable/disable
From: Sean Paul
This patch adds atomic variants for all of
pre_enable/enable/disable/post_disable bridge functions. These will be
called from the appropriate atomic helper functions. If the bridge
driver doesn't implement the atomic version of the function, we will
fall back to the vanilla implementation.
Note that some drivers call drm_bridge_disable directly, and these cases
are not covered. It's up to the driver to decide whether to implement
both atomic_disable and disable, or if it's not necessary.
Changes in v3:
- Added to the patchset
Cc: Daniel Vetter
Cc: Ville Syrjälä
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_atomic_helper.c | 8 +-
drivers/gpu/drm/drm_bridge.c| 110 +++
include/drm/drm_bridge.h| 114
3 files changed, 228 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 1f81ca8daad7..9d9e47276839 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -995,7 +995,7 @@ disable_outputs(struct drm_device *dev, struct
drm_atomic_state *old_state)
* Each encoder has at most one connector (since we always steal
* it away), so we won't call disable hooks twice.
*/
- drm_bridge_disable(encoder->bridge);
+ drm_atomic_bridge_disable(encoder->bridge, old_state);
/* Right function depends upon target state. */
if (funcs) {
@@ -1009,7 +1009,7 @@ disable_outputs(struct drm_device *dev, struct
drm_atomic_state *old_state)
funcs->dpms(encoder, DRM_MODE_DPMS_OFF);
}
- drm_bridge_post_disable(encoder->bridge);
+ drm_atomic_bridge_post_disable(encoder->bridge, old_state);
}
for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
new_crtc_state, i) {
@@ -1308,7 +1308,7 @@ void drm_atomic_helper_commit_modeset_enables(struct
drm_device *dev,
* Each encoder has at most one connector (since we always steal
* it away), so we won't call enable hooks twice.
*/
- drm_bridge_pre_enable(encoder->bridge);
+ drm_atomic_bridge_pre_enable(encoder->bridge, old_state);
if (funcs) {
if (funcs->atomic_enable)
@@ -1319,7 +1319,7 @@ void drm_atomic_helper_commit_modeset_enables(struct
drm_device *dev,
funcs->commit(encoder);
}
- drm_bridge_enable(encoder->bridge);
+ drm_atomic_bridge_enable(encoder->bridge, old_state);
}
drm_atomic_helper_commit_writebacks(dev, old_state);
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 138b2711d389..ab586adf 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -352,6 +352,116 @@ void drm_bridge_enable(struct drm_bridge *bridge)
}
EXPORT_SYMBOL(drm_bridge_enable);
+/**
+ * drm_atomic_bridge_disable - disables all bridges in the encoder chain
+ * @bridge: bridge control structure
+ * @state: atomic state being committed
+ *
+ * Calls _bridge_funcs.atomic_disable (falls back on
+ * _bridge_funcs.disable) op for all the bridges in the encoder chain,
+ * starting from the last bridge to the first. These are called before calling
+ * the encoder's prepare op.
+ *
+ * Note: the bridge passed should be the one closest to the encoder
+ */
+void drm_atomic_bridge_disable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state)
+{
+ if (!bridge)
+ return;
+
+ drm_atomic_bridge_disable(bridge->next, state);
+
+ if (bridge->funcs->atomic_disable)
+ bridge->funcs->atomic_disable(bridge, state);
+ else if (bridge->funcs->disable)
+ bridge->funcs->disable(bridge);
+}
+EXPORT_SYMBOL(drm_atomic_bridge_disable);
+
+/**
+ * drm_atomic_bridge_post_disable - cleans up after disabling all bridges in
the
+ * encoder chain
+ * @bridge: bridge control structure
+ * @state: atomic state being committed
+ *
+ * Calls _bridge_funcs.atomic_post_disable (falls back on
+ * _bridge_funcs.post_disable) op for all the bridges in the encoder chain,
+ * starting from the first bridge to the last. These are called after
completing
+ * the encoder's prepare op.
+ *
+ * Note: the bridge passed should be the one closest to the encoder
+ */
+void drm_atomic_bridge_post_disable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state)
+{
+ if (!bridge)
+ return;
+
+ if (bridge->funcs->atomic_post_disable)
+ bridge->funcs->atomic_post_disable(bridge, state);
+ else if (bridge->funcs->post_disable)
+
[PATCH v3 02/10] drm: Add drm_atomic_crtc_state_for_encoder helper
From: Sean Paul
This patch adds a helper to tease out the currently connected crtc for
an encoder, along with its state. This follows the same pattern as the
drm_atomic_crtc_*_for_* macros in the atomic helpers. Since the
relationship of crtc:encoder is 1:n, we don't need a loop since there is
only one crtc per encoder.
Instead of splitting this into 3 functions which all do the same thing,
this is presented as one function. Perhaps that's too ugly and it should
be split to:
struct drm_crtc *drm_atomic_crtc_for_encoder(state, encoder);
struct drm_crtc_state *drm_atomic_new_crtc_state_for_encoder(state, encoder);
struct drm_crtc_state *drm_atomic_old_crtc_state_for_encoder(state, encoder);
Suggestions welcome.
Changes in v3:
- Added to the set
Cc: Daniel Vetter
Cc: Ville Syrjälä
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_atomic_helper.c | 48 +
include/drm/drm_atomic_helper.h | 6
2 files changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 71cc7d6b0644..1f81ca8daad7 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3591,3 +3591,51 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
*crtc,
return ret;
}
EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
+
+/**
+ * drm_atomic_crtc_state_for_encoder - Get crtc and new/old state for an
encoder
+ * @state: Atomic state
+ * @encoder: The encoder to fetch the crtc information for
+ * @crtc: If not NULL, receives the currently connected crtc
+ * @old_crtc_state: If not NULL, receives the crtc's old state
+ * @new_crtc_state: If not NULL, receives the crtc's new state
+ *
+ * This function finds the crtc which is currently connected to @encoder and
+ * returns it as well as its old and new state. If there is no crtc currently
+ * connected, the function will clear @crtc, @old_crtc_state, @new_crtc_state.
+ *
+ * All of @crtc, @old_crtc_state, and @new_crtc_state are optional.
+ */
+void drm_atomic_crtc_state_for_encoder(struct drm_atomic_state *state,
+ struct drm_encoder *encoder,
+ struct drm_crtc **crtc,
+ struct drm_crtc_state **old_crtc_state,
+ struct drm_crtc_state **new_crtc_state)
+{
+ struct drm_crtc *tmp_crtc;
+ struct drm_crtc_state *tmp_new_crtc_state, *tmp_old_crtc_state;
+ u32 enc_mask = drm_encoder_mask(encoder);
+ int i;
+
+ for_each_oldnew_crtc_in_state(state, tmp_crtc, tmp_old_crtc_state,
+ tmp_new_crtc_state, i) {
+ if (!(tmp_new_crtc_state->encoder_mask & enc_mask))
+ continue;
+
+ if (new_crtc_state)
+ *new_crtc_state = tmp_new_crtc_state;
+ if (old_crtc_state)
+ *old_crtc_state = tmp_old_crtc_state;
+ if (crtc)
+ *crtc = tmp_crtc;
+ return;
+ }
+
+ if (new_crtc_state)
+ *new_crtc_state = NULL;
+ if (old_crtc_state)
+ *old_crtc_state = NULL;
+ if (crtc)
+ *crtc = NULL;
+}
+EXPORT_SYMBOL(drm_atomic_crtc_state_for_encoder);
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 58214be3bf3d..2383550a0cc8 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -153,6 +153,12 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
*crtc,
uint32_t size,
struct drm_modeset_acquire_ctx *ctx);
+void drm_atomic_crtc_state_for_encoder(struct drm_atomic_state *state,
+ struct drm_encoder *encoder,
+ struct drm_crtc **crtc,
+ struct drm_crtc_state **old_crtc_state,
+ struct drm_crtc_state **new_crtc_state);
+
/**
* drm_atomic_crtc_for_each_plane - iterate over planes currently attached to
CRTC
* @plane: the loop cursor
--
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 v3 05/10] drm: Add helpers to kick off self refresh mode in drivers
From: Sean Paul This patch adds a new drm helper library to help drivers implement self refresh. Drivers choosing to use it will register crtcs and will receive callbacks when it's time to enter or exit self refresh mode. In its current form, it has a timer which will trigger after a driver-specified amount of inactivity. When the timer triggers, the helpers will submit a new atomic commit to shut the refreshing pipe off. On the next atomic commit, the drm core will revert the self refresh state and bring everything back up to be actively driven. From the driver's perspective, this works like a regular disable/enable cycle. The driver need only check the 'self_refresh_active' state in crtc_state. It should initiate self refresh mode on the panel and enter an off or low-power state. Changes in v2: - s/psr/self_refresh/ (Daniel) - integrated the psr exit into the commit that wakes it up (Jose/Daniel) - made the psr state per-crtc (Jose/Daniel) Changes in v3: - Remove the self_refresh_(active|changed) from connector state (Daniel) - Simplify loop in drm_self_refresh_helper_alter_state (Daniel) - Improve self_refresh_aware comment (Daniel) - s/self_refresh_state/self_refresh_data/ (Daniel) Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-2-s...@poorly.run Link to v2: https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-1-s...@poorly.run Cc: Daniel Vetter Cc: Jose Souza Cc: Zain Wang Cc: Tomasz Figa Cc: Ville Syrjälä Signed-off-by: Sean Paul --- Documentation/gpu/drm-kms-helpers.rst | 9 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic.c | 2 + drivers/gpu/drm/drm_atomic_helper.c | 35 +++- drivers/gpu/drm/drm_atomic_state_helper.c | 4 + drivers/gpu/drm/drm_atomic_uapi.c | 7 +- drivers/gpu/drm/drm_self_refresh_helper.c | 205 ++ include/drm/drm_atomic.h | 15 ++ include/drm/drm_connector.h | 14 ++ include/drm/drm_crtc.h| 19 ++ include/drm/drm_self_refresh_helper.h | 22 +++ 11 files changed, 329 insertions(+), 5 deletions(-) create mode 100644 drivers/gpu/drm/drm_self_refresh_helper.c create mode 100644 include/drm/drm_self_refresh_helper.h diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 14102ae035dc..d8a13c6b4db3 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -113,6 +113,15 @@ format Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_format_helper.c :export: +Panel Self Refresh Helper Reference +=== + +.. kernel-doc:: drivers/gpu/drm/drm_self_refresh_helper.c + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/drm_self_refresh_helper.c + :export: + Framebuffer CMA Helper Functions Reference == diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 3d0c75cd687c..c4852604fc1d 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -39,7 +39,7 @@ 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 \ - drm_format_helper.o + drm_format_helper.o drm_self_refresh_helper.o drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 5eb40130fafb..4449956241f2 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -379,6 +379,7 @@ static void drm_atomic_crtc_print_state(struct drm_printer *p, drm_printf(p, "crtc[%u]: %s\n", crtc->base.id, crtc->name); drm_printf(p, "\tenable=%d\n", state->enable); drm_printf(p, "\tactive=%d\n", state->active); + drm_printf(p, "\tself_refresh_active=%d\n", state->self_refresh_active); drm_printf(p, "\tplanes_changed=%d\n", state->planes_changed); drm_printf(p, "\tmode_changed=%d\n", state->mode_changed); drm_printf(p, "\tactive_changed=%d\n", state->active_changed); @@ -881,6 +882,7 @@ static void drm_atomic_connector_print_state(struct drm_printer *p, drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector->name); drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : "(null)"); + drm_printf(p, "\tself_refresh_aware=%d\n", state->self_refresh_aware); if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK) if (state->writeback_job && state->writeback_job->fb) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index fa5a367507c1..3c26f04cd6b8 100644 ---
[PATCH] drm: add non-desktop quirk for Valve HMDs
Add vendor/product pairs for the Valve Index HMDs.
Signed-off-by: Andres Rodriguez
Cc: Dave Airlie
Cc: # v4.15
---
drivers/gpu/drm/drm_edid.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2c22ea446075..649cfd8b4200 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -162,6 +162,25 @@ static const struct edid_quirk {
/* Rotel RSX-1058 forwards sink's EDID but only does HDMI 1.1*/
{ "ETR", 13896, EDID_QUIRK_FORCE_8BPC },
+ /* Valve Index Headset */
+ { "VLV", 0x91a8, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b0, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b1, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b2, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b3, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b4, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b5, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b6, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b7, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b8, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91b9, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91ba, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91bb, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91bc, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91bd, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91be, EDID_QUIRK_NON_DESKTOP },
+ { "VLV", 0x91bf, EDID_QUIRK_NON_DESKTOP },
+
/* HTC Vive and Vive Pro VR Headsets */
{ "HVR", 0xaa01, EDID_QUIRK_NON_DESKTOP },
{ "HVR", 0xaa02, EDID_QUIRK_NON_DESKTOP },
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-next-5.2
Hi Dave, Daniel, Fixes for 5.2: - SR-IOV fixes - Raven flickering fix - Misc spelling fixes - Vega20 power fixes - Freesync improvements - DC fixes The following changes since commit f55be0be5b7296e73f1634e2839a1953dc12d11e: drm/amd/display: Add profiling tools for bandwidth validation (2019-04-15 00:22:19 -0500) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-5.2 for you to fetch changes up to b0fc850fd95f8ecceb601bbb40624da0a8c220a0: drm/amdgpu: power down the Vega20 VCE engine on request (2019-04-29 14:59:58 -0500) Amber Lin (1): drm/amdgpu: get_fw_version isn't ASIC specific Andrey Grodzovsky (2): drm/amdgpu: Change VRAM lost print from ERR to INF drm/amd/display: Use a reasonable timeout for framebuffer fence waits Anthony Koo (3): drm/amd/display: Allow system to enter stutter on init drm/amd/display: Send DMCU messages only if FW loaded drm/amd/display: Fix eDP Black screen after S4 resume Aric Cyr (1): drm/amd/display: 3.2.27 Charlene Liu (1): drm/amd/display: Add hubp_init entry to hubp vtable Chengming Gui (2): drm/amd/powerplay: add set/get_power_profile_mode for Raven (v2) drm/amd/powerplay: enable UMDPSTATE support on raven2 (v2) Christian König (1): drm/amd/display: wait for fence without holding reservation lock Colin Ian King (3): drm/amdgpu: fix spelling mistake "gateing" -> "gating" drm/amd/amdgpu: fix spelling mistake "recieve" -> "receive" drm/amd/display: fix incorrect null check on pointer Eric Bernstein (1): drm/amd/display: Allow cursor position when plane_res.ipp is NULL Eric Yang (1): drm/amd/display: remove deprecated pplib interface Evan Quan (4): drm/amdgpu: enable Vega20 BACO reset support drm/amdgpu: update Vega20 sdma golden settings drm/amdgpu: expose VCE 4.0 powergate interface drm/amdgpu: power down the Vega20 VCE engine on request John Barberiz (1): drm/amd/display: Refactor dp vendor parsing logic to a function Jun Lei (1): drm/amd/display: add explicit handshake between x86 and DMCU Leo Li (3): drm/amd/include: Add USB_C_TYPE to atom_encoder_cap_defs drm/amd/include: Add HUBPREQ_DEBUG register offsets drm/amdgpu: Check if SW SMU is supported before accessing funcs Likun Gao (1): drm/amdgpu: enable MGCG for PCO Mario Kleiner (2): drm/amd/display: Fix and simplify apply_below_the_range() drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v3) Nicholas Kazlauskas (8): drm/amd/display: Expose support for DRM_FORMAT_RGB565 drm/amd/display: Refactor CRTC interrupt toggling logic drm/amd/display: Disable cursors before disabling planes drm/amd/display: Fix CRC vblank refs when changing interrupts drm/amd/display: Split enabling CRTC interrupts into two passes drm/amd/display: Allow commits with no planes active drm/amd/display: Do VRR transition before enable_crc_interrupts drm/amd/display: Expose DRM_FORMAT_RGB565 on overlay planes Thomas Lim (1): drm/amd/display: Add power down display on boot flag Wenjing Liu (1): drm/amd/display: Add function to copy DC streams Wentao Lou (1): drm/amdgpu: value of amdgpu_sriov_vf cannot be set into F32_POLL_ENABLE Yintian Tao (1): drm/amdgpu: disable DRIVER_ATOMIC under SRIOV Yongqiang Sun (1): drm/amd/display: Refactor watermark programming hersen wu (1): drm/amd/powerplay: raven 4k@60hz dp monitor always flicking shaoyunl (1): drm/powerplay : send SMC message to set XGMI pstate wentalou (1): drm/amdgpu: amdgpu_device_recover_vram got NULL of shadow->parent drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 37 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 14 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 61 - drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 61 - drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 54 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 1 + drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 6 +- drivers/gpu/drm/amd/amdgpu/soc15.c | 9 +- drivers/gpu/drm/amd/amdgpu/vce_v2_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 15 +- drivers/gpu/drm/amd/amdkfd/kfd_device.c| 4 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 302 - drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 3 + drivers/gpu/drm/amd/display/dc/core/dc_link.c | 71 +++-- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c |
Re: [PATCH v2 16/17] kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec()
On Thu, May 2, 2019 at 11:15 AM wrote: > > > > > -Original Message- > > From: Greg KH > > > > On Wed, May 01, 2019 at 04:01:25PM -0700, Brendan Higgins wrote: > > > From: Iurii Zaikin > > > > > > KUnit tests for initialized data behavior of proc_dointvec that is > > > explicitly checked in the code. Includes basic parsing tests including > > > int min/max overflow. > > > > > > Signed-off-by: Iurii Zaikin > > > Signed-off-by: Brendan Higgins > > > --- > > > kernel/Makefile | 2 + > > > kernel/sysctl-test.c | 292 > > +++ > > > lib/Kconfig.debug| 6 + > > > 3 files changed, 300 insertions(+) > > > create mode 100644 kernel/sysctl-test.c > > > > > > diff --git a/kernel/Makefile b/kernel/Makefile > > > index 6c57e78817dad..c81a8976b6a4b 100644 > > > --- a/kernel/Makefile > > > +++ b/kernel/Makefile > > > @@ -112,6 +112,8 @@ obj-$(CONFIG_HAS_IOMEM) += iomem.o > > > obj-$(CONFIG_ZONE_DEVICE) += memremap.o > > > obj-$(CONFIG_RSEQ) += rseq.o > > > > > > +obj-$(CONFIG_SYSCTL_KUNIT_TEST) += sysctl-test.o > > > > You are going to have to have a "standard" naming scheme for test > > modules, are you going to recommend "foo-test" over "test-foo"? If so, > > that's fine, we should just be consistant and document it somewhere. > > > > Personally, I'd prefer "test-foo", but that's just me, naming is hard... > > My preference would be "test-foo" as well. Just my 2 cents. I definitely agree we should be consistent. My personal bias (unsurprisingly) is "foo-test," but this is just because that is the convention I am used to in other projects I have worked on. On an unbiased note, we are currently almost evenly split between the two conventions with *slight* preference for "foo-test": I ran the two following grep commands on v5.1-rc7: grep -Hrn --exclude-dir="build" -e "config [a-zA-Z_0-9]\+_TEST$" | wc -l grep -Hrn --exclude-dir="build" -e "config TEST_[a-zA-Z_0-9]\+" | wc -l "foo-test" has 36 occurrences. "test-foo" has 33 occurrences. The things I am more concerned about is how this would affect file naming. If we have a unit test for foo.c, I think foo_test.c is more consistent with our namespacing conventions. The other thing, is if we already have a Kconfig symbol called FOO_TEST (or TEST_FOO) what should we name the KUnit test in this case? FOO_UNIT_TEST? FOO_KUNIT_TEST, like I did above? Cheers ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 4/4] drm/vc4: Allocate binner bo when starting to use the V3D
Paul Kocialkowski writes:
> Hi,
>
> On Thu, 2019-04-25 at 10:42 -0700, Eric Anholt wrote:
>> Paul Kocialkowski writes:
>>
>> > The binner BO is not required until the V3D is in use, so avoid
>> > allocating it at probe and do it on the first non-dumb BO allocation.
>> >
>> > Keep track of which clients are using the V3D and liberate the buffer
>> > when there is none left, using a kref. Protect the logic with a
>> > mutex to avoid race conditions.
>> >
>> > The binner BO is created at the time of the first render ioctl and is
>> > destroyed when there is no client and no exec job using it left.
>> >
>> > The Out-Of-Memory (OOM) interrupt also gets some tweaking, to avoid
>> > enabling it before having allocated a binner bo.
>> >
>> > We also want to keep the BO alive during runtime suspend/resume to avoid
>> > failing to allocate it at resume. This happens when the CMA pool is
>> > full at that point and results in a hard crash.
>> >
>> > Signed-off-by: Paul Kocialkowski
>> > ---
>> > drivers/gpu/drm/vc4/vc4_bo.c | 33 +++-
>> > drivers/gpu/drm/vc4/vc4_drv.c | 6
>> > drivers/gpu/drm/vc4/vc4_drv.h | 14 +
>> > drivers/gpu/drm/vc4/vc4_gem.c | 13
>> > drivers/gpu/drm/vc4/vc4_irq.c | 21 +
>> > drivers/gpu/drm/vc4/vc4_v3d.c | 58 +++
>> > 6 files changed, 125 insertions(+), 20 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
>> > index 88ebd681d7eb..2b3ec5926fe2 100644
>> > --- a/drivers/gpu/drm/vc4/vc4_bo.c
>> > +++ b/drivers/gpu/drm/vc4/vc4_bo.c
>> > @@ -799,13 +799,38 @@ vc4_prime_import_sg_table(struct drm_device *dev,
>> >return obj;
>> > }
>> >
>> > +static int vc4_grab_bin_bo(struct vc4_dev *vc4, struct vc4_file *vc4file)
>> > +{
>> > + int ret;
>> > +
>> > + if (!vc4->v3d)
>> > + return -ENODEV;
>> > +
>> > + if (vc4file->bin_bo_used)
>> > + return 0;
>> > +
>> > + ret = vc4_v3d_bin_bo_get(vc4);
>> > + if (ret)
>> > + return ret;
>> > +
>> > + vc4file->bin_bo_used = true;
>>
>> I think I found one last race. Multiple threads could be in an ioctl
>> trying to grab the bin BO at the same time (while this is only during
>> app startup, since the fd only needs to get the ref once, it's
>> particularly plausible given that allocating the bin BO is slow). I
>> think if you replace this line with:
>>
>> mutex_lock(>bin_bo_lock);
>> if (vc4file->bin_bo_used) {
>> mutex_unlock(>bin_bo_lock);
>> vc4_v3d_bin_bo_put(vc4);
>> } else {
>> vc4file->bin_bo_used = true;
>> mutex_unlock(>bin_bo_lock);
>> }
>
> Huh, very good catch once again, thanks! It took me some time to grasp
> this one, but as far as I understand, the risk is that we could ref our
> bin bo twice (although it would only be allocated once) since
> bin_bo_used is not protected.
>
> I'd like to suggest another solution, which would avoid re-locking and
> doing an extra put if we got an extra ref: adding a "bool *used"
> argument to vc4_v3d_bin_bo_get and, which only gets dereferenced with
> the bin_bo lock held. Then we can skip obtaining a new reference if
> (used && *used) in vc4_v3d_bin_bo_get.
>
> So we could pass a pointer to vc4file->bin_bo_used for vc4_grab_bin_bo
> and exec->bin_bo_used for the exec case (where there is no such issue
> since we'll only ever try to _get the bin bo once there anyway).
>
> What do you think?
I like it!
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/17] kunit: tool: add Python wrappers for running KUnit tests
On Thu, May 2, 2019 at 4:02 AM Greg KH wrote: > > On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrote: > > From: Felix Guo > > > > The ultimate goal is to create minimal isolated test binaries; in the > > meantime we are using UML to provide the infrastructure to run tests, so > > define an abstract way to configure and run tests that allow us to > > change the context in which tests are built without affecting the user. > > This also makes pretty and dynamic error reporting, and a lot of other > > nice features easier. > > > > kunit_config.py: > > - parse .config and Kconfig files. > > > > kunit_kernel.py: provides helper functions to: > > - configure the kernel using kunitconfig. > > - build the kernel with the appropriate configuration. > > - provide function to invoke the kernel and stream the output back. > > > > Signed-off-by: Felix Guo > > Signed-off-by: Brendan Higgins > > Ah, here's probably my answer to my previous logging format question, > right? What's the chance that these wrappers output stuff in a standard > format that test-framework-tools can already parse? :) It should be pretty easy to do. I had some patches that pack up the results into a serialized format for a presubmit service; it should be pretty straightforward to take the same logic and just change the output format. Cheers ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] mesa: android: freedreno: Fix build failure due to path change
The ir3_nir_trig.py file was moved in a previous commit, aa0fed10d3574 (freedreno: move ir3 to common location), so update the Android.gen.mk file to match. Cc: Rob Clark Cc: Emil Velikov Cc: Amit Pundir Cc: Sumit Semwal Cc: Alistair Strachan Cc: Greg Hartman Cc: Tapani Pälli Cc: Jason Ekstrand Signed-off-by: John Stultz --- src/gallium/drivers/freedreno/Android.gen.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/freedreno/Android.gen.mk b/src/gallium/drivers/freedreno/Android.gen.mk index 17b6fbe1b7e..d29ba159d5c 100644 --- a/src/gallium/drivers/freedreno/Android.gen.mk +++ b/src/gallium/drivers/freedreno/Android.gen.mk @@ -25,7 +25,7 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES endif ir3_nir_trig_deps := \ - $(LOCAL_PATH)/ir3/ir3_nir_trig.py \ + $(MESA_TOP)/src/freedreno/ir3/ir3_nir_trig.py \ $(MESA_TOP)/src/compiler/nir/nir_algebraic.py intermediates := $(call local-generated-sources-dir) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 1/3] mesa: android: Remove unnecessary dependency tracking rules
From: Alistair Strachan The current AOSP master build system breaks building mesa due to the following error: external/mesa3d/src/compiler/Android.glsl.gen.mk:94: error: writing to readonly directory: "external/mesa3d/src/compiler/glsl/ir.h" This error is bogus -- nothing "writes" to ir.h -- but the rule is unnecessary because the generated header that is a dependency of the non-generated header should be added to LOCAL_GENERATED_SOURCES and this will track if the dependency needs to be regenerated. (This change fixes a similar problem affecting nir.h too.) Cc: Rob Clark Cc: Emil Velikov Cc: Amit Pundir Cc: Sumit Semwal Cc: Alistair Strachan Cc: Greg Hartman Cc: Tapani Pälli Cc: Jason Ekstrand Signed-off-by: Alistair Strachan [jstultz: Forward ported and tweaked commit subject] Signed-off-by: John Stultz --- src/compiler/Android.glsl.gen.mk | 2 -- src/compiler/Android.nir.gen.mk | 2 -- 2 files changed, 4 deletions(-) diff --git a/src/compiler/Android.glsl.gen.mk b/src/compiler/Android.glsl.gen.mk index 3b94ea7bd2f..1308de2db97 100644 --- a/src/compiler/Android.glsl.gen.mk +++ b/src/compiler/Android.glsl.gen.mk @@ -90,8 +90,6 @@ $(intermediates)/glsl/glcpp/glcpp-lex.c: $(LOCAL_PATH)/glsl/glcpp/glcpp-lex.l $(intermediates)/glsl/glcpp/glcpp-parse.c: $(LOCAL_PATH)/glsl/glcpp/glcpp-parse.y $(call glsl_local-y-to-c-and-h) -$(LOCAL_PATH)/glsl/ir.h: $(intermediates)/glsl/ir_expression_operation.h - $(intermediates)/glsl/ir_expression_operation.h: $(LOCAL_PATH)/glsl/ir_expression_operation.py @mkdir -p $(dir $@) $(hide) $(MESA_PYTHON2) $< enum > $@ diff --git a/src/compiler/Android.nir.gen.mk b/src/compiler/Android.nir.gen.mk index 894fb12c4be..26115f446a3 100644 --- a/src/compiler/Android.nir.gen.mk +++ b/src/compiler/Android.nir.gen.mk @@ -76,8 +76,6 @@ $(intermediates)/nir/nir_opcodes.h: $(nir_opcodes_h_deps) @mkdir -p $(dir $@) $(hide) $(MESA_PYTHON2) $(nir_opcodes_h_gen) $< > $@ -$(LOCAL_PATH)/nir/nir.h: $(intermediates)/nir/nir_opcodes.h - nir_opcodes_c_gen := $(LOCAL_PATH)/nir/nir_opcodes_c.py nir_opcodes_c_deps := \ $(LOCAL_PATH)/nir/nir_opcodes.py \ -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 2/3] mesa: android: freedreno: build libfreedreno_{drm, ir3} static libs
From: Amit Pundir Add libfreedreno_drm/ir3 to the build Cc: Rob Clark Cc: Emil Velikov Cc: Amit Pundir Cc: Sumit Semwal Cc: Alistair Strachan Cc: Greg Hartman Cc: Tapani Pälli Cc: Jason Ekstrand Signed-off-by: Amit Pundir [jstultz: Tweaked to add extra ir3 files from master] Signed-off-by: John Stultz --- Android.mk | 1 + src/freedreno/Android.drm.mk | 41 +++ src/freedreno/Android.ir3.mk | 51 src/freedreno/Android.mk | 30 ++ src/freedreno/Makefile.sources | 2 + src/gallium/Android.common.mk| 5 ++- src/gallium/drivers/freedreno/Android.mk | 2 +- src/gallium/targets/dri/Android.mk | 4 ++ 8 files changed, 134 insertions(+), 2 deletions(-) create mode 100644 src/freedreno/Android.drm.mk create mode 100644 src/freedreno/Android.ir3.mk create mode 100644 src/freedreno/Android.mk diff --git a/Android.mk b/Android.mk index d2b12ea4473..5fe028c6d19 100644 --- a/Android.mk +++ b/Android.mk @@ -110,6 +110,7 @@ endef # add subdirectories SUBDIRS := \ + src/freedreno \ src/gbm \ src/loader \ src/mapi \ diff --git a/src/freedreno/Android.drm.mk b/src/freedreno/Android.drm.mk new file mode 100644 index 000..dfa9bed7d2e --- /dev/null +++ b/src/freedreno/Android.drm.mk @@ -0,0 +1,41 @@ +# Mesa 3-D graphics library +# +# Copyright (C) +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the "Software"), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice shall be included +# in all copies or substantial portions of the Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +# DEALINGS IN THE SOFTWARE. + +# Android.mk for libfreedreno_drm.a + +# --- +# Build libfreedreno_drm +# --- + +include $(CLEAR_VARS) + +LOCAL_SRC_FILES := \ + $(drm_SOURCES) + +LOCAL_C_INCLUDES := \ + $(MESA_TOP)/src/gallium/include \ + $(MESA_TOP)/src/gallium/auxiliary + +LOCAL_MODULE := libfreedreno_drm + +include $(MESA_COMMON_MK) +include $(BUILD_STATIC_LIBRARY) diff --git a/src/freedreno/Android.ir3.mk b/src/freedreno/Android.ir3.mk new file mode 100644 index 000..c6a9d3288d7 --- /dev/null +++ b/src/freedreno/Android.ir3.mk @@ -0,0 +1,51 @@ +# Mesa 3-D graphics library +# +# Copyright (C) +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the "Software"), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice shall be included +# in all copies or substantial portions of the Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +# DEALINGS IN THE SOFTWARE. + +# Android.mk for libfreedreno_ir3.a + +# --- +# Build libfreedreno_ir3 +# --- + +include $(CLEAR_VARS) + +LOCAL_SRC_FILES := \ + $(ir3_SOURCES) + +LOCAL_C_INCLUDES := \ + $(MESA_TOP)/src/compiler/nir \ + $(MESA_TOP)/src/gallium/include \ + $(MESA_TOP)/src/gallium/auxiliary \ + $(MESA_TOP)/prebuilt-intermediates/nir \ + +# We need libmesa_nir to get NIR's generated include directories. +LOCAL_STATIC_LIBRARIES := \ + libmesa_nir + +LOCAL_MODULE := libfreedreno_ir3 + +LOCAL_GENERATED_SOURCES := \ + $(MESA_GEN_GLSL_H) \ + $(MESA_GEN_NIR_H) + +include $(MESA_COMMON_MK) +include
[RFC][PATCH 0/3] mesa: Initial build fixups for AOSP/master
Somewhat recent changes in the AOSP build system has been made
which fairly severely restricts the build environment. This has
made it difficult to test mesa/master w/ AOSP/master.
I'm working with others to try to remedy this, but as a first
step I used some hacks to temporarily remove the build environment
restrictions, and unsuprizingly found mesa/master has a few
build issues when trying to build w/ freedreno.
So this patch set provides only some very basic build fixes
that are needed to get mesa/master building w/ AOSP/master
(minus the build restrictions on external tools).
Feedback would be greatly appreciated!
thanks
-john
Cc: Rob Clark
Cc: Emil Velikov
Cc: Amit Pundir
Cc: Sumit Semwal
Cc: Alistair Strachan
Cc: Greg Hartman
Cc: Tapani Pälli
Cc: Jason Ekstrand
Alistair Strachan (1):
mesa: android: Remove unnecessary dependency tracking rules
Amit Pundir (1):
mesa: android: freedreno: build libfreedreno_{drm,ir3} static libs
John Stultz (1):
mesa: android: freedreno: Fix build failure due to path change
Android.mk | 1 +
src/compiler/Android.glsl.gen.mk | 2 -
src/compiler/Android.nir.gen.mk | 2 -
src/freedreno/Android.drm.mk | 41
src/freedreno/Android.ir3.mk | 51
src/freedreno/Android.mk | 30
src/freedreno/Makefile.sources | 2 +
src/gallium/Android.common.mk| 5 +-
src/gallium/drivers/freedreno/Android.gen.mk | 2 +-
src/gallium/drivers/freedreno/Android.mk | 2 +-
src/gallium/targets/dri/Android.mk | 4 ++
11 files changed, 135 insertions(+), 7 deletions(-)
create mode 100644 src/freedreno/Android.drm.mk
create mode 100644 src/freedreno/Android.ir3.mk
create mode 100644 src/freedreno/Android.mk
--
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/virtio: set seqno for dma-fence
(Add missing CCs)
On Mon, Apr 29, 2019 at 3:08 PM Chia-I Wu wrote:
>
> This is motivated by having meaningful ftrace events, but it also
> fixes use cases where dma_fence_is_later is called, such as in
> sync_file_merge.
>
> In other drivers, fence creation and cmdbuf submission normally
> happen atomically,
>
> mutex_lock();
> fence = dma_fence_create(..., ++timeline->seqno);
> submit_cmdbuf();
> mutex_unlock();
>
> and have no such issue. But in our driver, because most ioctls
> queue commands into ctrlq, we do not want to grab a lock. Instead,
> we set seqno to 0 when a fence is created, and update it when the
> command is finally queued and the seqno is known.
>
> Signed-off-by: Chia-I Wu
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 -
> drivers/gpu/drm/virtio/virtgpu_fence.c | 17 ++---
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 491dec0712b3..90461feeafdb 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -102,7 +102,6 @@ struct virtio_gpu_fence {
> struct dma_fence f;
> struct virtio_gpu_fence_driver *drv;
> struct list_head node;
> - uint64_t seq;
> };
> #define to_virtio_fence(x) \
> container_of(x, struct virtio_gpu_fence, f)
> diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
> b/drivers/gpu/drm/virtio/virtgpu_fence.c
> index 87d1966192f4..72b4f7561432 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_fence.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
> @@ -40,16 +40,14 @@ bool virtio_fence_signaled(struct dma_fence *f)
> {
> struct virtio_gpu_fence *fence = to_virtio_fence(f);
>
> - if (atomic64_read(>drv->last_seq) >= fence->seq)
> + if (atomic64_read(>drv->last_seq) >= fence->f.seqno)
> return true;
> return false;
> }
>
> static void virtio_fence_value_str(struct dma_fence *f, char *str, int size)
> {
> - struct virtio_gpu_fence *fence = to_virtio_fence(f);
> -
> - snprintf(str, size, "%llu", fence->seq);
> + snprintf(str, size, "%llu", f->seqno);
> }
>
> static void virtio_timeline_value_str(struct dma_fence *f, char *str, int
> size)
> @@ -76,6 +74,11 @@ struct virtio_gpu_fence *virtio_gpu_fence_alloc(struct
> virtio_gpu_device *vgdev)
> return fence;
>
> fence->drv = drv;
> +
> + /* This only partially initializes the fence because the seqno is
> +* unknown yet. The fence must not be used outside of the driver
> +* until virtio_gpu_fence_emit is called.
> +*/
> dma_fence_init(>f, _fence_ops, >lock,
> drv->context, 0);
>
> return fence;
> @@ -89,13 +92,13 @@ int virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
> unsigned long irq_flags;
>
> spin_lock_irqsave(>lock, irq_flags);
> - fence->seq = ++drv->sync_seq;
> + fence->f.seqno = ++drv->sync_seq;
> dma_fence_get(>f);
> list_add_tail(>node, >fences);
> spin_unlock_irqrestore(>lock, irq_flags);
>
> cmd_hdr->flags |= cpu_to_le32(VIRTIO_GPU_FLAG_FENCE);
> - cmd_hdr->fence_id = cpu_to_le64(fence->seq);
> + cmd_hdr->fence_id = cpu_to_le64(fence->f.seqno);
> return 0;
> }
>
> @@ -109,7 +112,7 @@ void virtio_gpu_fence_event_process(struct
> virtio_gpu_device *vgdev,
> spin_lock_irqsave(>lock, irq_flags);
> atomic64_set(>fence_drv.last_seq, last_seq);
> list_for_each_entry_safe(fence, tmp, >fences, node) {
> - if (last_seq < fence->seq)
> + if (last_seq < fence->f.seqno)
> continue;
> dma_fence_signal_locked(>f);
> list_del(>node);
> --
> 2.21.0.593.g511ec345e18-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm/malidp: Enable writeback scaling
On Thu, May 02, 2019 at 05:10:10PM +0100, Ben Davis wrote:
> The phase setting part of malidp_crtc_atomic_check_scaling is refactored
> to allow use in writeback scaling.
>
> Also the enable_memwrite function prototype is simplified by directly
> passing mw_state.
>
> Signed-off-by: Ben Davis
Reviewed-by: Liviu Dudau
I will pull this series the mali-dp tree after more people had a chance
to review it. I think the next thing to do would be to come up with a
test in igt for these properties.
Thanks,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_crtc.c | 47 ---
> drivers/gpu/drm/arm/malidp_drv.c | 10 +++-
> drivers/gpu/drm/arm/malidp_drv.h | 2 +
> drivers/gpu/drm/arm/malidp_hw.c | 45 ++-
> drivers/gpu/drm/arm/malidp_hw.h | 19 ++-
> drivers/gpu/drm/arm/malidp_mw.c | 117
> ++
> drivers/gpu/drm/arm/malidp_regs.h | 1 +
> 7 files changed, 176 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> b/drivers/gpu/drm/arm/malidp_crtc.c
> index 3f65996..6548859 100644
> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -265,6 +265,29 @@ static int malidp_crtc_atomic_check_ctm(struct drm_crtc
> *crtc,
> return 0;
> }
>
> +void malidp_set_se_config_phase(struct malidp_se_config *s)
> +{
> +#define SE_N_PHASE 4
> +#define SE_SHIFT_N_PHASE 12
> + u32 phase;
> +
> + /* Calculate initial_phase and delta_phase for horizontal. */
> + phase = s->input_w;
> + s->h_init_phase = ((phase << SE_N_PHASE) / s->output_w + 1) / 2;
> +
> + phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
> + s->h_delta_phase = phase / s->output_w;
> +
> + /* Same for vertical. */
> + phase = s->input_h;
> + s->v_init_phase = ((phase << SE_N_PHASE) / s->output_h + 1) / 2;
> +
> + phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
> + s->v_delta_phase = phase / s->output_h;
> +#undef SE_N_PHASE
> +#undef SE_SHIFT_N_PHASE
> +}
> +
> static int malidp_crtc_atomic_check_scaling(struct drm_crtc *crtc,
> struct drm_crtc_state *state)
> {
> @@ -291,7 +314,6 @@ static int malidp_crtc_atomic_check_scaling(struct
> drm_crtc *crtc,
>
> drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
> struct malidp_plane *mp = to_malidp_plane(plane);
> - u32 phase;
>
> if (!(mp->layer->id & scaling))
> continue;
> @@ -319,27 +341,8 @@ static int malidp_crtc_atomic_check_scaling(struct
> drm_crtc *crtc,
> s->output_w = pstate->crtc_w;
> s->output_h = pstate->crtc_h;
>
> -#define SE_N_PHASE 4
> -#define SE_SHIFT_N_PHASE 12
> - /* Calculate initial_phase and delta_phase for horizontal. */
> - phase = s->input_w;
> - s->h_init_phase =
> - ((phase << SE_N_PHASE) / s->output_w + 1) / 2;
> -
> - phase = s->input_w;
> - phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
> - s->h_delta_phase = phase / s->output_w;
> -
> - /* Same for vertical. */
> - phase = s->input_h;
> - s->v_init_phase =
> - ((phase << SE_N_PHASE) / s->output_h + 1) / 2;
> -
> - phase = s->input_h;
> - phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
> - s->v_delta_phase = phase / s->output_h;
> -#undef SE_N_PHASE
> -#undef SE_SHIFT_N_PHASE
> +
> + malidp_set_se_config_phase(s);
> s->plane_src_id = mp->layer->id;
> }
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index d37ff9d..e2465e9 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -138,7 +138,7 @@ static void malidp_atomic_commit_se_config(struct
> drm_crtc *crtc,
> u32 val;
>
> /* Set SE_CONTROL */
> - if (!s->scale_enable) {
> + if (!s->scale_enable && !s->wb_scale_enable) {
> val = malidp_hw_read(hwdev, se_control);
> val &= ~MALIDP_SE_SCALING_EN;
> malidp_hw_write(hwdev, val, se_control);
> @@ -147,12 +147,16 @@ static void malidp_atomic_commit_se_config(struct
> drm_crtc *crtc,
>
> hwdev->hw->se_set_scaling_coeffs(hwdev, s, old_s);
> val = malidp_hw_read(hwdev, se_control);
> - val |= MALIDP_SE_SCALING_EN | MALIDP_SE_ALPHA_EN;
> + val |= MALIDP_SE_SCALING_EN;
>
> val &= ~MALIDP_SE_ENH(MALIDP_SE_ENH_MASK);
> val |= s->enhancer_enable ? MALIDP_SE_ENH(3) : 0;
>
> - val |= MALIDP_SE_RGBO_IF_EN;
> + if (s->scale_enable)
> + val |= (MALIDP_SE_RGBO_IF_EN | MALIDP_SE_ALPHA_EN);
> + else
> + val &= ~((MALIDP_SE_RGBO_IF_EN | MALIDP_SE_ALPHA_EN));
> +
> malidp_hw_write(hwdev, val, se_control);
>
> /* Set IN_SIZE & OUT_SIZE. */
> diff --git
Re: [PATCH v4 1/2] drm: Add writeback_dest_x,y,w,h properties
On Thu, May 02, 2019 at 05:10:09PM +0100, Ben Davis wrote:
> Add new properties to specify x,y coordinates and
> width and height for writeback.
>
> These are reset to 0 on duplicating state to provide
> robustness against accidental scaling.
>
> Signed-off-by: Ben Davis
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 6 +++
> drivers/gpu/drm/drm_atomic_uapi.c | 17
> drivers/gpu/drm/drm_writeback.c | 66
> +++
> include/drm/drm_connector.h | 23 +++
> include/drm/drm_mode_config.h | 20 ++
> 5 files changed, 132 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 25a95b9..5973ca3 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -382,6 +382,12 @@ __drm_atomic_helper_connector_duplicate_state(struct
> drm_connector *connector,
>
> /* Don't copy over a writeback job, they are used only once */
> state->writeback_job = NULL;
> +
> + /* Auto clear writeback coordinates, should only be used once */
> + state->writeback_dest_x = 0;
> + state->writeback_dest_y = 0;
> + state->writeback_dest_w = 0;
> + state->writeback_dest_h = 0;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_connector_duplicate_state);
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d520a04..7d3fb7f 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -765,6 +765,14 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> return -EINVAL;
> }
> state->content_protection = val;
> + } else if (property == config->prop_writeback_dest_x) {
> + state->writeback_dest_x = val;
> + } else if (property == config->prop_writeback_dest_y) {
> + state->writeback_dest_y = val;
> + } else if (property == config->prop_writeback_dest_w) {
> + state->writeback_dest_w = val;
> + } else if (property == config->prop_writeback_dest_h) {
> + state->writeback_dest_h = val;
> } else if (property == config->writeback_fb_id_property) {
> struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
> val);
> int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
> @@ -837,6 +845,15 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = state->scaling_mode;
> } else if (property == connector->content_protection_property) {
> *val = state->content_protection;
> + } else if (property == config->prop_writeback_dest_x) {
> + /* Auto clear wb co-ordinates to prevent accidental scaling */
> + *val = 0;
> + } else if (property == config->prop_writeback_dest_y) {
> + *val = 0;
> + } else if (property == config->prop_writeback_dest_w) {
> + *val = 0;
> + } else if (property == config->prop_writeback_dest_h) {
> + *val = 0;
> } else if (property == config->writeback_fb_id_property) {
> /* Writeback framebuffer is one-shot, write and forget */
> *val = 0;
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index c20e6fe..7c53abd 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -74,6 +74,30 @@
> * applications making use of writeback connectors *always* retrieve an
> * out-fence for the commit and use it appropriately.
> * From userspace, this property will always read as zero.
> + *
> + * "WRITEBACK_DEST_X":
> + * The x-coordinate to write back onto the output writeback framebuffer.
> + * 0 acts as default. If non-zero the composition will be translated
> + * horizontally in the buffer by the amount specified. This is the case
> + * even if not scaling on writeback.
> + *
> + * "WRITEBACK_DEST_Y":
> + * The y-coordinate to write back onto the output writeback framebuffer.
> + * 0 acts as default. If non-zero the composition will be translated
> + * vertically in the buffer by the amount specified. This is the case even
> + * if not scaling on writeback.
> + *
> + * "WRITEBACK_DEST_W":
> + * The width of the composition to write back. 0 acts as default. If
> + * non-zero the composition will be scaled to match the given width.
> + * If scaling both WRITEBACK_DEST_W and WRITEBACK_DEST_H should be
> + * set as non-zero.
> + *
> + * "WRITEBACK_DEST_H":
> + * The height of the composition to write back. 0 acts as default. If
> + * non-zero the composition will be scaled to match the given height.
> + * If scaling both WRITEBACK_DEST_W and WRITEBACK_DEST_H should be
> + * set as non-zero.
> */
>
>
[PATCH v4 1/2] drm: Add writeback_dest_x,y,w,h properties
Add new properties to specify x,y coordinates and
width and height for writeback.
These are reset to 0 on duplicating state to provide
robustness against accidental scaling.
Signed-off-by: Ben Davis
---
drivers/gpu/drm/drm_atomic_state_helper.c | 6 +++
drivers/gpu/drm/drm_atomic_uapi.c | 17
drivers/gpu/drm/drm_writeback.c | 66 +++
include/drm/drm_connector.h | 23 +++
include/drm/drm_mode_config.h | 20 ++
5 files changed, 132 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 25a95b9..5973ca3 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -382,6 +382,12 @@ __drm_atomic_helper_connector_duplicate_state(struct
drm_connector *connector,
/* Don't copy over a writeback job, they are used only once */
state->writeback_job = NULL;
+
+ /* Auto clear writeback coordinates, should only be used once */
+ state->writeback_dest_x = 0;
+ state->writeback_dest_y = 0;
+ state->writeback_dest_w = 0;
+ state->writeback_dest_h = 0;
}
EXPORT_SYMBOL(__drm_atomic_helper_connector_duplicate_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d520a04..7d3fb7f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -765,6 +765,14 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == config->prop_writeback_dest_x) {
+ state->writeback_dest_x = val;
+ } else if (property == config->prop_writeback_dest_y) {
+ state->writeback_dest_y = val;
+ } else if (property == config->prop_writeback_dest_w) {
+ state->writeback_dest_w = val;
+ } else if (property == config->prop_writeback_dest_h) {
+ state->writeback_dest_h = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -837,6 +845,15 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
*val = state->content_protection;
+ } else if (property == config->prop_writeback_dest_x) {
+ /* Auto clear wb co-ordinates to prevent accidental scaling */
+ *val = 0;
+ } else if (property == config->prop_writeback_dest_y) {
+ *val = 0;
+ } else if (property == config->prop_writeback_dest_w) {
+ *val = 0;
+ } else if (property == config->prop_writeback_dest_h) {
+ *val = 0;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index c20e6fe..7c53abd 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -74,6 +74,30 @@
* applications making use of writeback connectors *always* retrieve an
* out-fence for the commit and use it appropriately.
* From userspace, this property will always read as zero.
+ *
+ * "WRITEBACK_DEST_X":
+ * The x-coordinate to write back onto the output writeback framebuffer.
+ * 0 acts as default. If non-zero the composition will be translated
+ * horizontally in the buffer by the amount specified. This is the case
+ * even if not scaling on writeback.
+ *
+ * "WRITEBACK_DEST_Y":
+ * The y-coordinate to write back onto the output writeback framebuffer.
+ * 0 acts as default. If non-zero the composition will be translated
+ * vertically in the buffer by the amount specified. This is the case even
+ * if not scaling on writeback.
+ *
+ * "WRITEBACK_DEST_W":
+ * The width of the composition to write back. 0 acts as default. If
+ * non-zero the composition will be scaled to match the given width.
+ * If scaling both WRITEBACK_DEST_W and WRITEBACK_DEST_H should be
+ * set as non-zero.
+ *
+ * "WRITEBACK_DEST_H":
+ * The height of the composition to write back. 0 acts as default. If
+ * non-zero the composition will be scaled to match the given height.
+ * If scaling both WRITEBACK_DEST_W and WRITEBACK_DEST_H should be
+ * set as non-zero.
*/
#define fence_to_wb_connector(x) container_of(x->lock, \
@@ -141,6 +165,38 @@ static int create_writeback_properties(struct drm_device
*dev)
dev->mode_config.writeback_out_fence_ptr_property = prop;
[PATCH v4 2/2] drm/malidp: Enable writeback scaling
The phase setting part of malidp_crtc_atomic_check_scaling is refactored
to allow use in writeback scaling.
Also the enable_memwrite function prototype is simplified by directly
passing mw_state.
Signed-off-by: Ben Davis
---
drivers/gpu/drm/arm/malidp_crtc.c | 47 ---
drivers/gpu/drm/arm/malidp_drv.c | 10 +++-
drivers/gpu/drm/arm/malidp_drv.h | 2 +
drivers/gpu/drm/arm/malidp_hw.c | 45 ++-
drivers/gpu/drm/arm/malidp_hw.h | 19 ++-
drivers/gpu/drm/arm/malidp_mw.c | 117 ++
drivers/gpu/drm/arm/malidp_regs.h | 1 +
7 files changed, 176 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index 3f65996..6548859 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -265,6 +265,29 @@ static int malidp_crtc_atomic_check_ctm(struct drm_crtc
*crtc,
return 0;
}
+void malidp_set_se_config_phase(struct malidp_se_config *s)
+{
+#define SE_N_PHASE 4
+#define SE_SHIFT_N_PHASE 12
+ u32 phase;
+
+ /* Calculate initial_phase and delta_phase for horizontal. */
+ phase = s->input_w;
+ s->h_init_phase = ((phase << SE_N_PHASE) / s->output_w + 1) / 2;
+
+ phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
+ s->h_delta_phase = phase / s->output_w;
+
+ /* Same for vertical. */
+ phase = s->input_h;
+ s->v_init_phase = ((phase << SE_N_PHASE) / s->output_h + 1) / 2;
+
+ phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
+ s->v_delta_phase = phase / s->output_h;
+#undef SE_N_PHASE
+#undef SE_SHIFT_N_PHASE
+}
+
static int malidp_crtc_atomic_check_scaling(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
@@ -291,7 +314,6 @@ static int malidp_crtc_atomic_check_scaling(struct drm_crtc
*crtc,
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
struct malidp_plane *mp = to_malidp_plane(plane);
- u32 phase;
if (!(mp->layer->id & scaling))
continue;
@@ -319,27 +341,8 @@ static int malidp_crtc_atomic_check_scaling(struct
drm_crtc *crtc,
s->output_w = pstate->crtc_w;
s->output_h = pstate->crtc_h;
-#define SE_N_PHASE 4
-#define SE_SHIFT_N_PHASE 12
- /* Calculate initial_phase and delta_phase for horizontal. */
- phase = s->input_w;
- s->h_init_phase =
- ((phase << SE_N_PHASE) / s->output_w + 1) / 2;
-
- phase = s->input_w;
- phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
- s->h_delta_phase = phase / s->output_w;
-
- /* Same for vertical. */
- phase = s->input_h;
- s->v_init_phase =
- ((phase << SE_N_PHASE) / s->output_h + 1) / 2;
-
- phase = s->input_h;
- phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
- s->v_delta_phase = phase / s->output_h;
-#undef SE_N_PHASE
-#undef SE_SHIFT_N_PHASE
+
+ malidp_set_se_config_phase(s);
s->plane_src_id = mp->layer->id;
}
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index d37ff9d..e2465e9 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -138,7 +138,7 @@ static void malidp_atomic_commit_se_config(struct drm_crtc
*crtc,
u32 val;
/* Set SE_CONTROL */
- if (!s->scale_enable) {
+ if (!s->scale_enable && !s->wb_scale_enable) {
val = malidp_hw_read(hwdev, se_control);
val &= ~MALIDP_SE_SCALING_EN;
malidp_hw_write(hwdev, val, se_control);
@@ -147,12 +147,16 @@ static void malidp_atomic_commit_se_config(struct
drm_crtc *crtc,
hwdev->hw->se_set_scaling_coeffs(hwdev, s, old_s);
val = malidp_hw_read(hwdev, se_control);
- val |= MALIDP_SE_SCALING_EN | MALIDP_SE_ALPHA_EN;
+ val |= MALIDP_SE_SCALING_EN;
val &= ~MALIDP_SE_ENH(MALIDP_SE_ENH_MASK);
val |= s->enhancer_enable ? MALIDP_SE_ENH(3) : 0;
- val |= MALIDP_SE_RGBO_IF_EN;
+ if (s->scale_enable)
+ val |= (MALIDP_SE_RGBO_IF_EN | MALIDP_SE_ALPHA_EN);
+ else
+ val &= ~((MALIDP_SE_RGBO_IF_EN | MALIDP_SE_ALPHA_EN));
+
malidp_hw_write(hwdev, val, se_control);
/* Set IN_SIZE & OUT_SIZE. */
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index 391d6ff..924f831 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -104,6 +104,8 @@ struct malidp_crtc_state {
int malidp_de_planes_init(struct drm_device *drm);
int malidp_crtc_init(struct drm_device *drm);
+void malidp_set_se_config_phase(struct malidp_se_config *s);
+
bool malidp_hw_format_is_linear_only(u32 format);
bool
[PATCH v4 0/2] Add writeback scaling
Add support for scaling on writeback. To do this add writeback_dest_x,y,w,h writeback connector properties to specify the desired output dimensions. Then implement downscaling on writeback for Malidp-550 and Malidp-650 (upscaling on writeback is not supported on these devices). v2: Use 0 as default for writeback_w,h and so update range to use 1 as minimum. v3: Rename properties to specify they are destination width/height. Make sure the values from the properties are passed to enable_memwrite rather than the framebuffer dimensions. v4: Add writeback_dest_x,y properties as well for consistency with plane properties. Writing to arbitrary x,y on writeback is not supported on the hardware so we simulate this in the driver. Clear the properties on duplicate state for robustness. Use 0 as minimum for all added properties. Also actually make sure the values from the properties are passed to enable_memwrite as intended in v3 and some other clean up. Ben Davis (2): drm: Add writeback_dest_x,y,w,h properties drm/malidp: Enable writeback scaling drivers/gpu/drm/arm/malidp_crtc.c | 47 ++-- drivers/gpu/drm/arm/malidp_drv.c | 10 ++- drivers/gpu/drm/arm/malidp_drv.h | 2 + drivers/gpu/drm/arm/malidp_hw.c | 45 drivers/gpu/drm/arm/malidp_hw.h | 19 - drivers/gpu/drm/arm/malidp_mw.c | 117 -- drivers/gpu/drm/arm/malidp_regs.h | 1 + drivers/gpu/drm/drm_atomic_state_helper.c | 6 ++ drivers/gpu/drm/drm_atomic_uapi.c | 17 + drivers/gpu/drm/drm_writeback.c | 66 + include/drm/drm_connector.h | 23 ++ include/drm/drm_mode_config.h | 20 + 12 files changed, 308 insertions(+), 65 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs
Hi,
On Tue, Apr 30, 2019 at 10:31:08PM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> Took a look at this, but feedback is trivial as
> I have no experience with PHYs so use only
> the feedback you consider relevant.
They all made sense so I've incorporated them for v10.
>
> Sam
>
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > new file mode 100644
> > index ..d6b5af0b3380
> > --- /dev/null
> > +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > @@ -0,0 +1,506 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2017,2018 NXP
> > + * Copyright 2019 Purism SPC
> > + */
> > +
> > +
> > +/* DPHY registers */
> > +#define DPHY_PD_DPHY 0x00
> > +#define DPHY_M_PRG_HS_PREPARE 0x04
> > +#define DPHY_MC_PRG_HS_PREPARE 0x08
> > +#define DPHY_M_PRG_HS_ZERO 0x0c
> > +#define DPHY_MC_PRG_HS_ZERO0x10
> > +#define DPHY_M_PRG_HS_TRAIL0x14
> > +#define DPHY_MC_PRG_HS_TRAIL 0x18
> > +#define DPHY_PD_PLL0x1c
> > +#define DPHY_TST 0x20
> > +#define DPHY_CN0x24
> > +#define DPHY_CM0x28
> > +#define DPHY_CO0x2c
> > +#define DPHY_LOCK 0x30
> > +#define DPHY_LOCK_BYP 0x34
> > +#define DPHY_REG_BYPASS_PLL0x4C
> > +
> > +#define MBPS(x) ((x) * 100)
> > +
> > +#define DATA_RATE_MAX_SPEED MBPS(1500)
> > +#define DATA_RATE_MIN_SPEED MBPS(80)
> > +
> > +#define PLL_LOCK_SLEEP 10
> > +#define PLL_LOCK_TIMEOUT 1000
> > +
> > +#define CN_BUF 0xcb7a89c0
> > +#define CO_BUF 0x63
> > +#define CM(x) ( \
> > + ((x) < 32)?0xe0|((x)-16) : \
> > + ((x) < 64)?0xc0|((x)-32) : \
> > + ((x) < 128)?0x80|((x)-64) : \
> > + ((x) - 128))
> > +#define CN(x) (((x) == 1)?0x1f : (((CN_BUF)>>((x)-1))&0x1f))
> > +#define CO(x) ((CO_BUF)>>(8-(x))&0x3)
> > +
> > +/* PHY power on is active low */
> > +#define PWR_ON 0
> > +#define PWR_OFF1
> > +
> > +enum mixel_dphy_devtype {
> > + MIXEL_IMX8MQ,
> > +};
> > +
> > +struct mixel_dphy_devdata {
> > + u8 reg_tx_rcal;
> > + u8 reg_auto_pd_en;
> > + u8 reg_rxlprp;
> > + u8 reg_rxcdrp;
> > + u8 reg_rxhs_settle;
> > +};
> > +
> > +static const struct mixel_dphy_devdata mixel_dphy_devdata[] = {
> > + [MIXEL_IMX8MQ] = {
> > + .reg_tx_rcal = 0x38,
> > + .reg_auto_pd_en = 0x3c,
> > + .reg_rxlprp = 0x40,
> > + .reg_rxcdrp = 0x44,
> > + .reg_rxhs_settle = 0x48,
> > + },
> > +};
> > +
> > +struct mixel_dphy_cfg {
> > + /* DPHY PLL parameters */
> > + u32 cm;
> > + u32 cn;
> > + u32 co;
> > + /* DPHY register values */
> > + u8 mc_prg_hs_prepare;
> > + u8 m_prg_hs_prepare;
> > + u8 mc_prg_hs_zero;
> > + u8 m_prg_hs_zero;
> > + u8 mc_prg_hs_trail;
> > + u8 m_prg_hs_trail;
> > + u8 rxhs_settle;
> > +};
> > +
> > +struct mixel_dphy_priv {
> > + struct mixel_dphy_cfg cfg;
> > + struct regmap *regs;
> It is a little confusing that the regmap is named regs.
> As regs in many other cases is used as name for the variable
> with pointer to registers.
> See for example call to devm_regmap_init_mmio()
Changed to regmap and base.
>
> > + struct clk *phy_ref_clk;
> > + const struct mixel_dphy_devdata *devdata;
> > +};
> > +
> > +static const struct regmap_config mixel_dphy_regmap_config = {
> > + .reg_bits = 8,
> > + .val_bits = 32,
> > + .reg_stride = 4,
> > + .max_register = DPHY_REG_BYPASS_PLL,
> > + .name = "mipi-dphy",
> > +};
> > +
> > +static int phy_write(struct phy *phy, u32 value, unsigned int reg)
> > +{
> > + struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> > + int ret;
> > +
> > + ret = regmap_write(priv->regs, reg, value);
> > + if (ret < 0)
> > + dev_err(>dev, "Failed to write DPHY reg %d: %d", reg, ret);
> > + return ret;
> > +}
> > +
> > +/*
> > + * Find a ratio close to the desired one using continued fraction
> > + * approximation ending either at exact match or maximum allowed
> > + * nominator, denominator.
> > + */
> > +static void get_best_ratio(u32 *pnum, u32 *pdenom, unsigned int max_n,
> > + unsigned int max_d)
> > +{
> Maybe use u32 for all parameters?
> That would also match usage below.
Less confusing, done.
>
> > + u32 a = *pnum;
> > + u32 b = *pdenom;
> > + u32 c;
> > + u32 n[] = {0, 1};
> > + u32 d[] = {1, 0};
> > + u32 whole;
> > + unsigned int i = 1;
> > +
> > + while (b) {
> > + i ^= 1;
> > + whole = a / b;
> > + n[i] += (n[i ^ 1] * whole);
> > + d[i] += (d[i ^ 1] * whole);
> > + if ((n[i] > max_n) || (d[i] > max_d)) {
> > + i ^= 1;
> > +
[PATCH] RFC: console: hack up console_trylock more
console_trylock, called from within printk, can be called from pretty
much anywhere. Including try_to_wake_up. Note that this isn't common,
usually the box is in pretty bad shape at that point already. But it
really doesn't help when then lockdep jumps in and spams the logs,
potentially obscuring the real backtrace we're really interested in.
One case I've seen (slightly simplified backtrace):
Call Trace:
console_trylock+0xe/0x60
vprintk_emit+0xf1/0x320
printk+0x4d/0x69
__warn_printk+0x46/0x90
native_smp_send_reschedule+0x2f/0x40
check_preempt_curr+0x81/0xa0
ttwu_do_wakeup+0x14/0x220
try_to_wake_up+0x218/0x5f0
pollwake+0x6f/0x90
credit_entropy_bits+0x204/0x310
add_interrupt_randomness+0x18f/0x210
handle_irq+0x67/0x160
do_IRQ+0x5e/0x130
common_interrupt+0xf/0xf
This alone isn't a problem, but the spinlock in the semaphore is also
still held while waking up waiters (up() -> __up() -> try_to_wake_up()
callchain), which then closes the runqueue vs. semaphore.lock loop,
and upsets lockdep, which issues a circular locking splat to dmesg.
Worse it upsets developers, since we don't want to spam dmesg with
clutter when the machine is dying already.
Fix this by creating a __down_trylock which only trylocks the
semaphore.lock. This isn't correct in full generality, but good enough
for console_lock:
- there's only ever one console_lock holder, we won't fail spuriously
because someone is doing a down() or up() while there's still room
(unlike other semaphores with count > 1).
- console_unlock() has one massive retry loop, which will catch anyone
who races the trylock against the up(). This makes sure that no
printk lines will get lost. Making the trylock more racy therefore
has no further impact.
Also cc'ing John Ogness since perhaps his printk rework fixes this all
properly.
Signed-off-by: Daniel Vetter
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Cc: Daniel Vetter
Cc: John Ogness
Cc: linux-ker...@vger.kernel.org
---
include/linux/semaphore.h | 1 +
kernel/locking/semaphore.c | 33 +
kernel/printk/printk.c | 2 +-
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/include/linux/semaphore.h b/include/linux/semaphore.h
index 11c86fbfeb98..82f6db6121c3 100644
--- a/include/linux/semaphore.h
+++ b/include/linux/semaphore.h
@@ -40,6 +40,7 @@ extern void down(struct semaphore *sem);
extern int __must_check down_interruptible(struct semaphore *sem);
extern int __must_check down_killable(struct semaphore *sem);
extern int __must_check down_trylock(struct semaphore *sem);
+extern int __must_check __down_trylock(struct semaphore *sem);
extern int __must_check down_timeout(struct semaphore *sem, long jiffies);
extern void up(struct semaphore *sem);
diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index 561acdd39960..345123336019 100644
--- a/kernel/locking/semaphore.c
+++ b/kernel/locking/semaphore.c
@@ -143,6 +143,39 @@ int down_trylock(struct semaphore *sem)
}
EXPORT_SYMBOL(down_trylock);
+/**
+ * __down_trylock - try to acquire the semaphore, without any locking
+ * @sem: the semaphore to be acquired
+ *
+ * Try to acquire the semaphore atomically. Returns 0 if the semaphore has
+ * been acquired successfully or 1 if it it cannot be acquired.
+ *
+ * NOTE: This return value is inverted from both spin_trylock and
+ * mutex_trylock! Be careful about this when converting code.
+ *
+ * Unlike mutex_trylock, this function can be used from interrupt context,
+ * and the semaphore can be released by any task or interrupt.
+ *
+ * WARNING: Unlike down_trylock this function doesn't guarantee that that the
+ * semaphore will be acquired if it could, it's best effort only. Use for
+ * down_trylock_console_sem only.
+ */
+int __down_trylock(struct semaphore *sem)
+{
+ unsigned long flags;
+ int count;
+
+ if (!raw_spin_trylock_irqsave(>lock, flags))
+ return 1;
+ count = sem->count - 1;
+ if (likely(count >= 0))
+ sem->count = count;
+ raw_spin_unlock_irqrestore(>lock, flags);
+
+ return (count < 0);
+}
+EXPORT_SYMBOL(__down_trylock);
+
/**
* down_timeout - acquire the semaphore within a specified time
* @sem: the semaphore to be acquired
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 02ca827b8fac..5293803eec1f 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -217,7 +217,7 @@ static int __down_trylock_console_sem(unsigned long ip)
* deadlock in printk()->down_trylock_console_sem() otherwise.
*/
printk_safe_enter_irqsave(flags);
- lock_failed = down_trylock(_sem);
+ lock_failed = __down_trylock(_sem);
printk_safe_exit_irqrestore(flags);
if (lock_failed)
--
2.20.1
___
dri-devel mailing list
Re: [PATCH] drm: Some ocd in drm_file.c
Quoting Daniel Vetter (2019-05-02 14:56:03) > Move the open helper around to avoid the forward decl, and give > drm_setup a drm_legacy_ prefix since it's all legacy stuff in there. > > v2: Move drm_legacy_setup into drm_legacy_misc.c (Chris). The > counterpart in the form of drm_legacy_dev_reinit is there already too, > plus it fits perfectly into Dave's work of making DRIVER_LEGACY code > compile-time optional. > > Cc: Chris Wilson > Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On 5/2/19 4:50 AM, Greg KH wrote: On Wed, May 01, 2019 at 04:01:09PM -0700, Brendan Higgins wrote: ## TLDR I rebased the last patchset on 5.1-rc7 in hopes that we can get this in 5.2. That might be rushing it, normally trees are already closed now for 5.2-rc1 if 5.1-final comes out this Sunday. Shuah, I think you, Greg KH, and myself talked off thread, and we agreed we would merge through your tree when the time came? Am I remembering correctly? No objection from me. Yes. I can take these through kselftest tree when the time comes. Agree with Greg that 5.2 might be rushing it. 5.3 would be a good target. thanks, -- Shuah ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, A quick fix to unbreak media driver, worthy inclusion before the merge window. Best Regards, Joonas *** drm-intel-next-fixes-2019-05-02: - Whitelist a register to avoid media driver from hanging The following changes since commit 879a4e70f96a26a9368a3caed2f552aa67105852: drm/i915: Fix ICL output CSC programming (2019-04-29 09:49:21 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-05-02 for you to fetch changes up to 9628e15ca9d5f7595ba886173e98a139d0a56cd1: drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1 (2019-04-30 10:16:18 +0300) - Whitelist a register to avoid media driver from hanging Tvrtko Ursulin (1): drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1 drivers/gpu/drm/i915/intel_workarounds.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/10] HDCP2.2 Phase II
On 2019-05-02 at 18:52:53 +0530, Ramalingam C wrote: > This series adds the content type capability for HDCP through a > drm connetor proeprty "HDCP Content Type". By default this property will > be "Type 0". And this property is exposed by the drivers which has the > HDCP2.2 capability to enable the userspace to configure for "Type 1". > > HDCP Content Type: > This property is used to indicate the content type > classification of a stream. Which indicate the HDCP version required > for the rendering of that streams. This conten type is one of the > parameter in the HDCP2.2 authentication flow, as even downstream > repeaters will mandate the HDCP version requirement. > > Two values possible for content type of a stream: > Type 0: Stream can be rendered only on HDCP encrypted link no > restriction on HDCP versions. > Type 1: Stream can be rendered only on HDCP2.2 encrypted link. > > And also this series adds a uevent for a change in the property state > change of a connector. This helps the userspace to monitor the uevent > for a proeprty state change than the trivial polling. > > Userspace consumer for above "HDCP Content Type" property and uevent is > almost at the last phase of review at #wayland community. So Patches 6, > 7, 8, 9 and 10 can be merged only when patches in #wayland community > receives the ACK. > > HDCP SRM is implemented through request_firmware() interface. Hence > userspace is expected to write the signature validated latest available > SRM table into /lib/firmware/ as "display_hdcp_srm.bin". On every HDCP > authentication kernel will read the SRM from above mentioned file and > do the revocation check. > > And also this series gathers all HDCP related DRM code into drm_hdcp.c > > Thanks Daniel Vetter for all the reviews. Daniel, Could you please review https://patchwork.freedesktop.org/patch/303048/?series=57232=8 And for all other patches I have imcorporated all your suggestions and added your Rbed-by. Please have a look. Thanks and Regards, -Ram > > Series can be cloned from github > https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_p2_v6 > > Test-with: <20190502131625.27551-2-ramalinga...@intel.com> > > Ramalingam C (10): > drm: move content protection property to mode_config > drm/i915: debugfs: HDCP2.2 capability read > drm: revocation check at drm subsystem > drm/i915: SRM revocation check for HDCP1.4 and 2.2 > drm/hdcp: gathering hdcp related code into drm_hdcp.c > drm: Add Content protection type property > drm/i915: Attach content type property > drm: uevent for connector status change > drm/hdcp: update content protection property with uevent > drm/i915: update the hdcp state with uevent > > Documentation/gpu/drm-kms-helpers.rst | 6 + > drivers/gpu/drm/Makefile | 2 +- > drivers/gpu/drm/drm_atomic_uapi.c | 8 +- > drivers/gpu/drm/drm_connector.c | 61 +--- > drivers/gpu/drm/drm_hdcp.c| 455 ++ > drivers/gpu/drm/drm_internal.h| 4 + > drivers/gpu/drm/drm_sysfs.c | 37 +++ > drivers/gpu/drm/i915/i915_debugfs.c | 13 +- > drivers/gpu/drm/i915/intel_ddi.c | 37 ++- > drivers/gpu/drm/i915/intel_hdcp.c | 100 -- > drivers/gpu/drm/i915/intel_hdcp.h | 3 +- > include/drm/drm_connector.h | 15 +- > include/drm/drm_hdcp.h| 29 ++ > include/drm/drm_mode_config.h | 12 + > include/drm/drm_sysfs.h | 5 +- > include/uapi/drm/drm_mode.h | 4 + > 16 files changed, 699 insertions(+), 92 deletions(-) > create mode 100644 drivers/gpu/drm/drm_hdcp.c > > -- > 2.19.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 09/10] drm/hdcp: update content protection property with uevent
drm function is defined and exported to update a connector's
content protection property state and to generate a uevent along
with it.
Need ACK for the uevent from userspace consumer.
v2:
Update only when state is different from old one.
v3:
KDoc is added [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_hdcp.c | 32
include/drm/drm_hdcp.h | 2 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index fc9083db833d..75ae4cd90c53 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -381,6 +381,10 @@ DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
*
* The content protection will be set to
_connector_state.content_protection
*
+ * When kernel triggered content protection state change like DESIRED->ENABLED
+ * and ENABLED->DESIRED, will use drm_hdcp_update_content_protection() to
update
+ * the content protection state of a connector.
+ *
* Returns:
* Zero on success, negative errno on failure.
*/
@@ -421,3 +425,31 @@ int drm_connector_attach_content_protection_property(
return 0;
}
EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
+
+/**
+ * drm_hdcp_update_content_protection - Updates the content protection state
+ * of a connector
+ *
+ * @connector: drm_connector on which content protection state needs an update
+ * @val: New state of the content protection property
+ *
+ * This function can be used by display drivers, to update the kernel triggered
+ * content protection state change of a drm_connector. This function update the
+ * new state of the property into the connector's state and generate an uevent
+ * to notify the userspace.
+ */
+void drm_hdcp_update_content_protection(struct drm_connector *connector,
+ u64 val)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_connector_state *state = connector->state;
+
+ WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
+ if (state->content_protection == val)
+ return;
+
+ state->content_protection = val;
+ drm_sysfs_connector_status_event(connector,
+dev->mode_config.content_protection_property);
+}
+EXPORT_SYMBOL(drm_hdcp_update_content_protection);
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index c9dd973f43df..e49fe40f767f 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -292,4 +292,6 @@ bool drm_hdcp_check_ksvs_revoked(struct drm_device *dev,
u8 *ksvs, u32 ksv_count);
int drm_connector_attach_content_protection_property(
struct drm_connector *connector, bool hdcp_content_type);
+void drm_hdcp_update_content_protection(struct drm_connector *connector,
+ u64 val);
#endif
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 08/10] drm: uevent for connector status change
DRM API for generating uevent for a status changes of connector's
property.
This uevent will have following details related to the status change:
HOTPLUG=1, CONNECTOR= and PROPERTY=
Need ACK from this uevent from userspace consumer.
v2:
Minor fixes at KDoc comments [Daniel]
v3:
Check the property is really attached with connector [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_sysfs.c | 35 +++
include/drm/drm_sysfs.h | 5 -
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 18b1ac442997..63fa951a20db 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -21,6 +21,7 @@
#include
#include
#include "drm_internal.h"
+#include "drm_crtc_internal.h"
#define to_drm_minor(d) dev_get_drvdata(d)
#define to_drm_connector(d) dev_get_drvdata(d)
@@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
* Send a uevent for the DRM device specified by @dev. Currently we only
* set HOTPLUG=1 in the uevent environment, but this could be expanded to
* deal with other types of events.
+ *
+ * Any new uapi should be using the drm_sysfs_connector_status_event()
+ * for uevents on connector status change.
*/
void drm_sysfs_hotplug_event(struct drm_device *dev)
{
@@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_sysfs_hotplug_event);
+/**
+ * drm_sysfs_connector_status_event - generate a DRM uevent for connector
+ * property status change
+ * @connector: connector on which property status changed
+ * @property: connector property whoes status changed.
+ *
+ * Send a uevent for the DRM device specified by @dev. Currently we
+ * set HOTPLUG=1 and connector id along with the attached property id
+ * related to the status change.
+ */
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+ struct drm_property *property)
+{
+ struct drm_device *dev = connector->dev;
+ char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
+ char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
+
+ WARN_ON(!drm_mode_obj_find_prop_id(>base,
+ property->base.id));
+
+ snprintf(conn_id, ARRAY_SIZE(conn_id),
+"CONNECTOR=%u", connector->base.id);
+ snprintf(prop_id, ARRAY_SIZE(prop_id),
+"PROPERTY=%u", property->base.id);
+
+ DRM_DEBUG("generating connector status event\n");
+
+ kobject_uevent_env(>primary->kdev->kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(drm_sysfs_connector_status_event);
+
static void drm_sysfs_release(struct device *dev)
{
kfree(dev);
diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
index 4f311e836cdc..d454ef617b2c 100644
--- a/include/drm/drm_sysfs.h
+++ b/include/drm/drm_sysfs.h
@@ -4,10 +4,13 @@
struct drm_device;
struct device;
+struct drm_connector;
+struct drm_property;
int drm_class_device_register(struct device *dev);
void drm_class_device_unregister(struct device *dev);
void drm_sysfs_hotplug_event(struct drm_device *dev);
-
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+ struct drm_property *property);
#endif
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 06/10] drm: Add Content protection type property
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.
So when a userspace sets this property to Type 1 and starts the HDCP
enable, kernel will honour it only if HDCP2.2 authentication is through
for type 1. Else HDCP enable will be failed.
Need ACK for this new conenctor property from userspace consumer.
v2:
cp_content_type is replaced with content_protection_type [daniel]
check at atomic_set_property is removed [Maarten]
v3:
%s/content_protection_type/hdcp_content_type [Pekka]
v4:
property is created for the first requested connector and then reused.
[Danvet]
v5:
kernel doc nits addressed [Daniel]
Rebased as part of patch reordering.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_connector.c | 18
drivers/gpu/drm/drm_hdcp.c| 36 ++-
drivers/gpu/drm/i915/intel_hdcp.c | 4 +++-
include/drm/drm_connector.h | 7 ++
include/drm/drm_hdcp.h| 2 +-
include/drm/drm_mode_config.h | 6 ++
include/uapi/drm/drm_mode.h | 4
8 files changed, 78 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 4131e669785a..a85f3ccfe699 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -738,6 +738,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == config->hdcp_content_type_property) {
+ state->hdcp_content_type = val;
} else if (property == connector->colorspace_property) {
state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
@@ -816,6 +818,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->scaling_mode;
} else if (property == config->content_protection_property) {
*val = state->content_protection;
+ } else if (property == config->hdcp_content_type_property) {
+ *val = state->hdcp_content_type;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 764c7903edf6..de9e06583e8c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -955,6 +955,24 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
* the value transitions from ENABLED to DESIRED. This signifies the link
* is no longer protected and userspace should take appropriate action
* (whatever that might be).
+ * HDCP Content Type:
+ * This property is used by the userspace to configure the kernel with
+ * to be displayed stream's content type. Content Type of a stream is
+ * decided by the owner of the stream, as HDCP Type0 or HDCP Type1.
+ *
+ * The value of the property can be one the below:
+ * - DRM_MODE_HDCP_CONTENT_TYPE0 = 0
+ * HDCP Type0 streams can be transmitted on a link which is
+ * encrypted with HDCP 1.4 or HDCP 2.2.
+ * - DRM_MODE_HDCP_CONTENT_TYPE1 = 1
+ * HDCP Type1 streams can be transmitted on a link which is
+ * encrypted only with HDCP 2.2.
+ *
+ * Note that the HDCP Content Type property is specific to HDCP 2.2, and
+ * defaults to type 0. It is only exposed by drivers supporting HDCP 2.2
+ * If content type is changed when content_protection is not UNDESIRED,
+ * then kernel will disable the HDCP and re-enable with new type in the
+ * same atomic commit
*
* max bpc:
* This range property is used by userspace to limit the bit depth. When
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index ff3fb2326b46..fc9083db833d 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -351,23 +351,41 @@ static struct drm_prop_enum_list drm_cp_enum_list[] = {
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+static struct drm_prop_enum_list drm_hdcp_content_type_enum_list[] = {
+ { DRM_MODE_HDCP_CONTENT_TYPE0, "HDCP Type0" },
+ { DRM_MODE_HDCP_CONTENT_TYPE1, "HDCP Type1" },
+};
+DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
+drm_hdcp_content_type_enum_list)
+
/**
* drm_connector_attach_content_protection_property - attach content protection
*
[PATCH v6 10/10] drm/i915: update the hdcp state with uevent
drm function to update the content protection property state and to
generate a uevent is invoked from the intel hdcp property work.
Hence whenever kernel changes the property state, userspace will be
updated with a uevent.
Need a ACK for uevent generating uAPI from userspace.
v2:
state update is moved into drm function [daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hdcp.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 2e159ffd17e6..f5c5ea921e8a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -865,7 +865,6 @@ static void intel_hdcp_prop_work(struct work_struct *work)
prop_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
struct drm_device *dev = connector->base.dev;
- struct drm_connector_state *state;
drm_modeset_lock(>mode_config.connection_mutex, NULL);
mutex_lock(>mutex);
@@ -875,10 +874,9 @@ static void intel_hdcp_prop_work(struct work_struct *work)
* those to UNDESIRED is handled by core. If value == UNDESIRED,
* we're running just after hdcp has been disabled, so just exit
*/
- if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- state = connector->base.state;
- state->content_protection = hdcp->value;
- }
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ drm_hdcp_update_content_protection(>base,
+ hdcp->value);
mutex_unlock(>mutex);
drm_modeset_unlock(>mode_config.connection_mutex);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 07/10] drm/i915: Attach content type property
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
Need ACK for content type property from userspace consumer.
v2:
s/cp_content_type/content_protection_type [daniel]
disable at hdcp_atomic_check to avoid check at atomic_set_property
[Maarten]
v3:
s/content_protection_type/hdcp_content_type [Pekka]
v4:
hdcp disable incase of type change is moved into commit [daniel].
v5:
Simplified the Type change procedure. [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c | 37 +-
drivers/gpu/drm/i915/intel_hdcp.c | 43 ---
drivers/gpu/drm/i915/intel_hdcp.h | 2 +-
3 files changed, 60 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f181c26f62fd..9c7caf39964a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3474,7 +3474,8 @@ static void intel_enable_ddi(struct intel_encoder
*encoder,
/* Enable hdcp if it's desired */
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector));
+ intel_hdcp_enable(to_intel_connector(conn_state->connector),
+ (u8)conn_state->hdcp_content_type);
}
static void intel_disable_ddi_dp(struct intel_encoder *encoder,
@@ -3543,15 +3544,39 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
+ struct intel_connector *connector =
+ to_intel_connector(conn_state->connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ bool content_protection_type_changed =
+ conn_state->hdcp_content_type != hdcp->content_type;
+
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
+ /*
+* During the HDCP encryption session if Type change is requested,
+* disable the HDCP and reenable it with new TYPE value.
+*/
if (conn_state->content_protection ==
- DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector));
- else if (conn_state->content_protection ==
-DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
- intel_hdcp_disable(to_intel_connector(conn_state->connector));
+ DRM_MODE_CONTENT_PROTECTION_UNDESIRED ||
+ content_protection_type_changed)
+ intel_hdcp_disable(connector);
+
+ /*
+* Mark the hdcp state as DESIRED after the hdcp disable of type
+* change procedure.
+*/
+ if (content_protection_type_changed) {
+ mutex_lock(>mutex);
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(>prop_work);
+ mutex_unlock(>mutex);
+ }
+
+ if (conn_state->content_protection ==
+ DRM_MODE_CONTENT_PROTECTION_DESIRED ||
+ content_protection_type_changed)
+ intel_hdcp_enable(connector, (u8)conn_state->hdcp_content_type);
}
static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index be36d594129d..2e159ffd17e6 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1747,14 +1747,15 @@ static const struct component_ops
i915_hdcp_component_ops = {
.unbind = i915_hdcp_component_unbind,
};
-static inline int initialize_hdcp_port_data(struct intel_connector *connector)
+static inline int initialize_hdcp_port_data(struct intel_connector *connector,
+ const struct intel_hdcp_shim *shim)
{
struct intel_hdcp *hdcp = >hdcp;
struct hdcp_port_data *data = >port_data;
data->port = connector->encoder->port;
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
- data->protocol = (u8)hdcp->shim->protocol;
+ data->protocol = (u8)shim->protocol;
data->k = 1;
if (!data->streams)
@@ -1804,12 +1805,13 @@ void intel_hdcp_component_init(struct drm_i915_private
*dev_priv)
}
}
-static void intel_hdcp2_init(struct intel_connector *connector)
+static void intel_hdcp2_init(struct intel_connector *connector,
+const struct intel_hdcp_shim *shim)
{
struct intel_hdcp *hdcp = >hdcp;
int ret;
- ret = initialize_hdcp_port_data(connector);
+ ret = initialize_hdcp_port_data(connector, shim);
[PATCH v6 00/10] HDCP2.2 Phase II
This series adds the content type capability for HDCP through a drm connetor proeprty "HDCP Content Type". By default this property will be "Type 0". And this property is exposed by the drivers which has the HDCP2.2 capability to enable the userspace to configure for "Type 1". HDCP Content Type: This property is used to indicate the content type classification of a stream. Which indicate the HDCP version required for the rendering of that streams. This conten type is one of the parameter in the HDCP2.2 authentication flow, as even downstream repeaters will mandate the HDCP version requirement. Two values possible for content type of a stream: Type 0: Stream can be rendered only on HDCP encrypted link no restriction on HDCP versions. Type 1: Stream can be rendered only on HDCP2.2 encrypted link. And also this series adds a uevent for a change in the property state change of a connector. This helps the userspace to monitor the uevent for a proeprty state change than the trivial polling. Userspace consumer for above "HDCP Content Type" property and uevent is almost at the last phase of review at #wayland community. So Patches 6, 7, 8, 9 and 10 can be merged only when patches in #wayland community receives the ACK. HDCP SRM is implemented through request_firmware() interface. Hence userspace is expected to write the signature validated latest available SRM table into /lib/firmware/ as "display_hdcp_srm.bin". On every HDCP authentication kernel will read the SRM from above mentioned file and do the revocation check. And also this series gathers all HDCP related DRM code into drm_hdcp.c Thanks Daniel Vetter for all the reviews. Series can be cloned from github https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_p2_v6 Test-with: <20190502131625.27551-2-ramalinga...@intel.com> Ramalingam C (10): drm: move content protection property to mode_config drm/i915: debugfs: HDCP2.2 capability read drm: revocation check at drm subsystem drm/i915: SRM revocation check for HDCP1.4 and 2.2 drm/hdcp: gathering hdcp related code into drm_hdcp.c drm: Add Content protection type property drm/i915: Attach content type property drm: uevent for connector status change drm/hdcp: update content protection property with uevent drm/i915: update the hdcp state with uevent Documentation/gpu/drm-kms-helpers.rst | 6 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic_uapi.c | 8 +- drivers/gpu/drm/drm_connector.c | 61 +--- drivers/gpu/drm/drm_hdcp.c| 455 ++ drivers/gpu/drm/drm_internal.h| 4 + drivers/gpu/drm/drm_sysfs.c | 37 +++ drivers/gpu/drm/i915/i915_debugfs.c | 13 +- drivers/gpu/drm/i915/intel_ddi.c | 37 ++- drivers/gpu/drm/i915/intel_hdcp.c | 100 -- drivers/gpu/drm/i915/intel_hdcp.h | 3 +- include/drm/drm_connector.h | 15 +- include/drm/drm_hdcp.h| 29 ++ include/drm/drm_mode_config.h | 12 + include/drm/drm_sysfs.h | 5 +- include/uapi/drm/drm_mode.h | 4 + 16 files changed, 699 insertions(+), 92 deletions(-) create mode 100644 drivers/gpu/drm/drm_hdcp.c -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 02/10] drm/i915: debugfs: HDCP2.2 capability read
Adding the HDCP2.2 capability of HDCP src and sink info into debugfs
entry "i915_hdcp_sink_capability"
This helps the userspace tests to skip the HDCP2.2 test on non HDCP2.2
sinks.
v2:
Rebased.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
drivers/gpu/drm/i915/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/intel_hdcp.h | 1 +
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ffbf5d920429..969985095170 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4750,6 +4750,7 @@ static int i915_hdcp_sink_capability_show(struct seq_file
*m, void *data)
{
struct drm_connector *connector = m->private;
struct intel_connector *intel_connector = to_intel_connector(connector);
+ bool hdcp_cap, hdcp2_cap;
if (connector->status != connector_status_connected)
return -ENODEV;
@@ -4760,8 +4761,16 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
seq_printf(m, "%s:%d HDCP version: ", connector->name,
connector->base.id);
- seq_printf(m, "%s ", !intel_hdcp_capable(intel_connector) ?
- "None" : "HDCP1.4");
+ hdcp_cap = intel_hdcp_capable(intel_connector);
+ hdcp2_cap = intel_hdcp2_capable(intel_connector);
+
+ if (hdcp_cap)
+ seq_puts(m, "HDCP1.4 ");
+ if (hdcp2_cap)
+ seq_puts(m, "HDCP2.2 ");
+
+ if (!hdcp_cap && !hdcp2_cap)
+ seq_puts(m, "None");
seq_puts(m, "\n");
return 0;
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index ca5982e45e3e..b8c8d6d1a33d 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -79,7 +79,7 @@ bool intel_hdcp_capable(struct intel_connector *connector)
}
/* Is HDCP2.2 capable on Platform and Sink */
-static bool intel_hdcp2_capable(struct intel_connector *connector)
+bool intel_hdcp2_capable(struct intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.h
b/drivers/gpu/drm/i915/intel_hdcp.h
index a75f25f09d39..be8da85c866a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/intel_hdcp.h
@@ -25,6 +25,7 @@ int intel_hdcp_enable(struct intel_connector *connector);
int intel_hdcp_disable(struct intel_connector *connector);
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
bool intel_hdcp_capable(struct intel_connector *connector);
+bool intel_hdcp2_capable(struct intel_connector *connector);
void intel_hdcp_component_init(struct drm_i915_private *dev_priv);
void intel_hdcp_component_fini(struct drm_i915_private *dev_priv);
void intel_hdcp_cleanup(struct intel_connector *connector);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 05/10] drm/hdcp: gathering hdcp related code into drm_hdcp.c
Considering the significant size of hdcp related code in drm, all
hdcp related codes are moved into separate file called drm_hdcp.c.
v2:
Rebased.
v2:
Rebased.
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_connector.c | 44 --
drivers/gpu/drm/drm_hdcp.c | 47 +
include/drm/drm_connector.h | 2 --
include/drm/drm_hdcp.h | 3 +++
4 files changed, 50 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7c0eda9cca60..764c7903edf6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -823,13 +823,6 @@ static const struct drm_prop_enum_list
drm_tv_subconnector_enum_list[] = {
DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
drm_tv_subconnector_enum_list)
-static struct drm_prop_enum_list drm_cp_enum_list[] = {
- { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
- { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
- { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
-};
-DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
-
static const struct drm_prop_enum_list hdmi_colorspaces[] = {
/* For Default case, driver will set the colorspace */
{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
@@ -1515,43 +1508,6 @@ int drm_connector_attach_scaling_mode_property(struct
drm_connector *connector,
}
EXPORT_SYMBOL(drm_connector_attach_scaling_mode_property);
-/**
- * drm_connector_attach_content_protection_property - attach content protection
- * property
- *
- * @connector: connector to attach CP property on.
- *
- * This is used to add support for content protection on select connectors.
- * Content Protection is intentionally vague to allow for different underlying
- * technologies, however it is most implemented by HDCP.
- *
- * The content protection will be set to
_connector_state.content_protection
- *
- * Returns:
- * Zero on success, negative errno on failure.
- */
-int drm_connector_attach_content_protection_property(
- struct drm_connector *connector)
-{
- struct drm_device *dev = connector->dev;
- struct drm_property *prop =
- dev->mode_config.content_protection_property;
-
- if (!prop)
- prop = drm_property_create_enum(dev, 0, "Content Protection",
- drm_cp_enum_list,
- ARRAY_SIZE(drm_cp_enum_list));
- if (!prop)
- return -ENOMEM;
-
- drm_object_attach_property(>base, prop,
- DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
- dev->mode_config.content_protection_property = prop;
-
- return 0;
-}
-EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
-
/**
* drm_mode_create_aspect_ratio_property - create aspect ratio property
* @dev: DRM device
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index dc0e13409221..ff3fb2326b46 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -17,6 +17,9 @@
#include
#include
#include
+#include
+#include
+#include
struct hdcp_srm {
u8 *srm_buf;
@@ -340,3 +343,47 @@ void drm_teardown_hdcp_srm(struct class *drm_class)
kfree(srm_data);
}
}
+
+static struct drm_prop_enum_list drm_cp_enum_list[] = {
+ { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
+ { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
+ { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
+};
+DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+
+/**
+ * drm_connector_attach_content_protection_property - attach content protection
+ * property
+ *
+ * @connector: connector to attach CP property on.
+ *
+ * This is used to add support for content protection on select connectors.
+ * Content Protection is intentionally vague to allow for different underlying
+ * technologies, however it is most implemented by HDCP.
+ *
+ * The content protection will be set to
_connector_state.content_protection
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_content_protection_property(
+ struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop =
+ dev->mode_config.content_protection_property;
+
+ if (!prop)
+ prop = drm_property_create_enum(dev, 0, "Content Protection",
+ drm_cp_enum_list,
+ ARRAY_SIZE(drm_cp_enum_list));
+ if (!prop)
+ return -ENOMEM;
+
+ drm_object_attach_property(>base, prop,
+ DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
+
[PATCH v6 01/10] drm: move content protection property to mode_config
Content protection property is created once and stored in
drm_mode_config. And attached to all HDCP capable connectors.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
drivers/gpu/drm/drm_connector.c | 13 +++--
include/drm/drm_connector.h | 6 --
include/drm/drm_mode_config.h | 6 ++
4 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 428d82662dc4..4131e669785a 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -732,7 +732,7 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->content_type = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
- } else if (property == connector->content_protection_property) {
+ } else if (property == config->content_protection_property) {
if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
return -EINVAL;
@@ -814,7 +814,7 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
- } else if (property == connector->content_protection_property) {
+ } else if (property == config->content_protection_property) {
*val = state->content_protection;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2355124849db..7c0eda9cca60 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1534,18 +1534,19 @@ int drm_connector_attach_content_protection_property(
struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
- struct drm_property *prop;
+ struct drm_property *prop =
+ dev->mode_config.content_protection_property;
- prop = drm_property_create_enum(dev, 0, "Content Protection",
- drm_cp_enum_list,
- ARRAY_SIZE(drm_cp_enum_list));
+ if (!prop)
+ prop = drm_property_create_enum(dev, 0, "Content Protection",
+ drm_cp_enum_list,
+ ARRAY_SIZE(drm_cp_enum_list));
if (!prop)
return -ENOMEM;
drm_object_attach_property(>base, prop,
DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
-
- connector->content_protection_property = prop;
+ dev->mode_config.content_protection_property = prop;
return 0;
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 02a131202add..5e41942e5679 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1061,12 +1061,6 @@ struct drm_connector {
*/
struct drm_property *vrr_capable_property;
- /**
-* @content_protection_property: DRM ENUM property for content
-* protection. See drm_connector_attach_content_protection_property().
-*/
- struct drm_property *content_protection_property;
-
/**
* @colorspace_property: Connector property to set the suitable
* colorspace supported by the sink.
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 7f60e8eb269a..5764ee3c7453 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -836,6 +836,12 @@ struct drm_mode_config {
*/
struct drm_property *writeback_out_fence_ptr_property;
+ /**
+* @content_protection_property: DRM ENUM property for content
+* protection. See drm_connector_attach_content_protection_property().
+*/
+ struct drm_property *content_protection_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 04/10] drm/i915: SRM revocation check for HDCP1.4 and 2.2
DRM HDCP SRM revocation check services are used from I915 for HDCP1.4
and 2.2 revocation check during the respective authentication flow.
v2:
Rebased.
v3:
%s/*_ksvs_revocated/*_check_ksvs_revoked [Daniel]
unwanted noise is removed.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hdcp.c | 45 ++-
1 file changed, 38 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index b8c8d6d1a33d..8eb3bbb3fa7f 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -491,9 +491,11 @@ int intel_hdcp_validate_v_prime(struct intel_digital_port
*intel_dig_port,
/* Implements Part 2 of the HDCP authorization procedure */
static
-int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
- const struct intel_hdcp_shim *shim)
+int intel_hdcp_auth_downstream(struct intel_connector *connector)
{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ const struct intel_hdcp_shim *shim = connector->hdcp.shim;
+ struct drm_device *dev = connector->base.dev;
u8 bstatus[2], num_downstream, *ksv_fifo;
int ret, i, tries = 3;
@@ -532,6 +534,11 @@ int intel_hdcp_auth_downstream(struct intel_digital_port
*intel_dig_port,
if (ret)
goto err;
+ if (drm_hdcp_check_ksvs_revoked(dev, ksv_fifo, num_downstream)) {
+ DRM_ERROR("Revoked Ksv(s) in ksv_fifo\n");
+ return -EPERM;
+ }
+
/*
* When V prime mismatches, DP Spec mandates re-read of
* V prime atleast twice.
@@ -558,9 +565,12 @@ int intel_hdcp_auth_downstream(struct intel_digital_port
*intel_dig_port,
}
/* Implements Part 1 of the HDCP authorization procedure */
-static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
- const struct intel_hdcp_shim *shim)
+static int intel_hdcp_auth(struct intel_connector *connector)
{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ struct drm_device *dev = connector->base.dev;
+ const struct intel_hdcp_shim *shim = hdcp->shim;
struct drm_i915_private *dev_priv;
enum port port;
unsigned long r0_prime_gen_start;
@@ -626,6 +636,11 @@ static int intel_hdcp_auth(struct intel_digital_port
*intel_dig_port,
if (ret < 0)
return ret;
+ if (drm_hdcp_check_ksvs_revoked(dev, bksv.shim, 1)) {
+ DRM_ERROR("BKSV is revoked\n");
+ return -EPERM;
+ }
+
I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
@@ -699,7 +714,7 @@ static int intel_hdcp_auth(struct intel_digital_port
*intel_dig_port,
*/
if (repeater_present)
- return intel_hdcp_auth_downstream(intel_dig_port, shim);
+ return intel_hdcp_auth_downstream(connector);
DRM_DEBUG_KMS("HDCP is enabled (no repeater present)\n");
return 0;
@@ -762,7 +777,7 @@ static int _intel_hdcp_enable(struct intel_connector
*connector)
/* Incase of authentication failures, HDCP spec expects reauth. */
for (i = 0; i < tries; i++) {
- ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim);
+ ret = intel_hdcp_auth(connector);
if (!ret) {
hdcp->hdcp_encrypted = true;
return 0;
@@ -1161,6 +1176,7 @@ static int hdcp2_authentication_key_exchange(struct
intel_connector *connector)
{
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct intel_hdcp *hdcp = >hdcp;
+ struct drm_device *dev = connector->base.dev;
union {
struct hdcp2_ake_init ake_init;
struct hdcp2_ake_send_cert send_cert;
@@ -1195,6 +1211,12 @@ static int hdcp2_authentication_key_exchange(struct
intel_connector *connector)
hdcp->is_repeater = HDCP_2_2_RX_REPEATER(msgs.send_cert.rx_caps[2]);
+ if (drm_hdcp_check_ksvs_revoked(dev, msgs.send_cert.cert_rx.receiver_id,
+ 1)) {
+ DRM_ERROR("Receiver ID is revoked\n");
+ return -EPERM;
+ }
+
/*
* Here msgs.no_stored_km will hold msgs corresponding to the km
* stored also.
@@ -1347,13 +1369,14 @@ int hdcp2_authenticate_repeater_topology(struct
intel_connector *connector)
{
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct intel_hdcp *hdcp = >hdcp;
+ struct drm_device *dev = connector->base.dev;
union {
struct hdcp2_rep_send_receiverid_list recvid_list;
struct hdcp2_rep_send_ack rep_ack;
} msgs;
const
[PATCH v6 03/10] drm: revocation check at drm subsystem
On every hdcp revocation check request SRM is read from fw file
/lib/firmware/display_hdcp_srm.bin
SRM table is parsed and stored at drm_hdcp.c, with functions exported
for the services for revocation check from drivers (which
implements the HDCP authentication)
This patch handles the HDCP1.4 and 2.2 versions of SRM table.
v2:
moved the uAPI to request_firmware_direct() [Daniel]
v3:
kdoc added. [Daniel]
srm_header unified and bit field definitions are removed. [Daniel]
locking improved. [Daniel]
vrl length violation is fixed. [Daniel]
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 6 +
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_hdcp.c| 342 ++
drivers/gpu/drm/drm_internal.h| 4 +
drivers/gpu/drm/drm_sysfs.c | 2 +
include/drm/drm_hdcp.h| 24 ++
6 files changed, 379 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_hdcp.c
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 14102ae035dc..0fe726a6ee67 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -181,6 +181,12 @@ Panel Helper Reference
.. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
:export:
+HDCP Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
+ :export:
+
Display Port Helper Functions Reference
===
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 72f5036d9bfa..dd02e9dec810 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -17,7 +17,7 @@ drm-y :=drm_auth.o drm_cache.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
- drm_atomic_uapi.o
+ drm_atomic_uapi.o drm_hdcp.o
drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o
drm_dma.o drm_scatter.o drm_lock.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
new file mode 100644
index ..dc0e13409221
--- /dev/null
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -0,0 +1,342 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation.
+ *
+ * Authors:
+ * Ramalingam C
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+struct hdcp_srm {
+ u8 *srm_buf;
+ size_t received_srm_sz;
+ u32 revoked_ksv_cnt;
+ u8 *revoked_ksv_list;
+
+ /* Mutex to protect above struct member */
+ struct mutex mutex;
+} *srm_data;
+
+static inline void drm_hdcp_print_ksv(const u8 *ksv)
+{
+ DRM_DEBUG("\t%#02x, %#02x, %#02x, %#02x, %#02x\n",
+ ksv[0], ksv[1], ksv[2], ksv[3], ksv[4]);
+}
+
+static u32 drm_hdcp_get_revoked_ksv_count(const u8 *buf, u32 vrls_length)
+{
+ u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
+
+ while (parsed_bytes < vrls_length) {
+ vrl_ksv_cnt = *buf;
+ ksv_count += vrl_ksv_cnt;
+
+ vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
+ buf += vrl_sz;
+ parsed_bytes += vrl_sz;
+ }
+
+ /*
+* When vrls are not valid, ksvs are not considered.
+* Hence SRM will be discarded.
+*/
+ if (parsed_bytes != vrls_length)
+ ksv_count = 0;
+
+ return ksv_count;
+}
+
+static u32 drm_hdcp_get_revoked_ksvs(const u8 *buf, u8 *revoked_ksv_list,
+u32 vrls_length)
+{
+ u32 parsed_bytes = 0, ksv_count = 0;
+ u32 vrl_ksv_cnt, vrl_ksv_sz, vrl_idx = 0;
+
+ do {
+ vrl_ksv_cnt = *buf;
+ vrl_ksv_sz = vrl_ksv_cnt * DRM_HDCP_KSV_LEN;
+
+ buf++;
+
+ DRM_DEBUG("vrl: %d, Revoked KSVs: %d\n", vrl_idx++,
+ vrl_ksv_cnt);
+ memcpy(revoked_ksv_list, buf, vrl_ksv_sz);
+
+ ksv_count += vrl_ksv_cnt;
+ revoked_ksv_list += vrl_ksv_sz;
+ buf += vrl_ksv_sz;
+
+ parsed_bytes += (vrl_ksv_sz + 1);
+ } while (parsed_bytes < vrls_length);
+
+ return ksv_count;
+}
+
+static inline u32 get_vrl_length(const u8 *buf)
+{
+ return (u32)(buf[0] << 16 | buf[1] << 8 | buf[2]);
+}
+
+static int drm_hdcp_parse_hdcp1_srm(const u8 *buf, size_t count)
+{
+ struct hdcp_srm_header *header;
+ u32 vrl_length, ksv_count;
+
+ if (count < (sizeof(struct hdcp_srm_header) +
+ DRM_HDCP_1_4_VRL_LENGTH_SIZE + DRM_HDCP_1_4_DCP_SIG_SIZE)) {
+ DRM_ERROR("Invalid blob length\n");
+ return -EINVAL;
+
[Bug 203471] Tearing on Raven Ridge and RX560X PRIME setup even with Vsync enabled
https://bugzilla.kernel.org/show_bug.cgi?id=203471 --- Comment #6 from Haxk20 (haxk...@gmail.com) --- Created attachment 282589 --> https://bugzilla.kernel.org/attachment.cgi?id=282589=edit glxinfo Here is Xorg log, glxinfo with DRI_PRIME=1 and glxinfo without PRIME. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203471] Tearing on Raven Ridge and RX560X PRIME setup even with Vsync enabled
https://bugzilla.kernel.org/show_bug.cgi?id=203471 --- Comment #5 from Haxk20 (haxk...@gmail.com) --- Created attachment 282587 --> https://bugzilla.kernel.org/attachment.cgi?id=282587=edit DRI_PRIME=1 glxinfo -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203471] Tearing on Raven Ridge and RX560X PRIME setup even with Vsync enabled
https://bugzilla.kernel.org/show_bug.cgi?id=203471 --- Comment #4 from Haxk20 (haxk...@gmail.com) --- Created attachment 282585 --> https://bugzilla.kernel.org/attachment.cgi?id=282585=edit Xorg log -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Dave, Daniel, Here is a drm-misc fixes PR for 5.1. Thanks! Maxime drm-misc-fixes-2019-05-02: - One revert for QXL for a DRI3 breakage The following changes since commit c4cba44eeecab9d5ccd3dd2d5520a7d1e5be544f: drm/bridge: dw-hdmi: fix SCDC configuration for ddc-i2c-bus (2019-04-25 10:38:21 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-05-02 for you to fetch changes up to ab042b824c11502bd39abfdfd4c7f285347d483a: Revert "drm/qxl: drop prime import/export callbacks" (2019-04-30 14:08:48 +0200) - One revert for QXL for a DRI3 breakage Gerd Hoffmann (1): Revert "drm/qxl: drop prime import/export callbacks" drivers/gpu/drm/qxl/qxl_drv.c | 4 drivers/gpu/drm/qxl/qxl_prime.c | 12 2 files changed, 16 insertions(+) -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: rave-sp: don't touch initial state and register with correct device
Hi Daniel, Am Donnerstag, den 02.05.2019, 11:33 +0100 schrieb Daniel Thompson: > On 29/04/2019 16:29, Lucas Stach wrote: > > This way the backlight can be referenced through its device node and > > enabling/disabling can be managed through the panel driver. > > Is it possible to implement something similar to > pwm_backlight_initial_power_state() to handle this? I'm not aware of any protocol to the RAVE-SP that would allow to read back the backlight state. AFAICS the backlight is implemented as a unidirectional protocol. Regards, Lucas > backlight drivers already suffer from too much diversity so I prefer > things like this to align behaviour with the (fairly heavilyly used) PWM > driver if possible. > > > Daniel. > > > > > > Signed-off-by: Lucas Stach > > --- > > drivers/video/backlight/rave-sp-backlight.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/drivers/video/backlight/rave-sp-backlight.c > > b/drivers/video/backlight/rave-sp-backlight.c > > index 462f14a1b19d..d296bfcf4396 100644 > > --- a/drivers/video/backlight/rave-sp-backlight.c > > +++ b/drivers/video/backlight/rave-sp-backlight.c > > @@ -48,15 +48,13 @@ static int rave_sp_backlight_probe(struct > > platform_device *pdev) > > > > struct device *dev = >dev; > > > > struct backlight_device *bd; > > > > > > - bd = devm_backlight_device_register(dev, pdev->name, > > > > dev->parent, > > > > + bd = devm_backlight_device_register(dev, pdev->name, dev, > > > > > > > > dev_get_drvdata(dev->parent), > > > > _sp_backlight_ops, > > > > _sp_backlight_props); > > > > if (IS_ERR(bd)) > > > > return PTR_ERR(bd); > > > > > > - backlight_update_status(bd); > > - > > > > return 0; > > } > > > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 4/4] drm/vc4: Allocate binner bo when starting to use the V3D
Hi,
On Thu, 2019-04-25 at 10:42 -0700, Eric Anholt wrote:
> Paul Kocialkowski writes:
>
> > The binner BO is not required until the V3D is in use, so avoid
> > allocating it at probe and do it on the first non-dumb BO allocation.
> >
> > Keep track of which clients are using the V3D and liberate the buffer
> > when there is none left, using a kref. Protect the logic with a
> > mutex to avoid race conditions.
> >
> > The binner BO is created at the time of the first render ioctl and is
> > destroyed when there is no client and no exec job using it left.
> >
> > The Out-Of-Memory (OOM) interrupt also gets some tweaking, to avoid
> > enabling it before having allocated a binner bo.
> >
> > We also want to keep the BO alive during runtime suspend/resume to avoid
> > failing to allocate it at resume. This happens when the CMA pool is
> > full at that point and results in a hard crash.
> >
> > Signed-off-by: Paul Kocialkowski
> > ---
> > drivers/gpu/drm/vc4/vc4_bo.c | 33 +++-
> > drivers/gpu/drm/vc4/vc4_drv.c | 6
> > drivers/gpu/drm/vc4/vc4_drv.h | 14 +
> > drivers/gpu/drm/vc4/vc4_gem.c | 13
> > drivers/gpu/drm/vc4/vc4_irq.c | 21 +
> > drivers/gpu/drm/vc4/vc4_v3d.c | 58 +++
> > 6 files changed, 125 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> > index 88ebd681d7eb..2b3ec5926fe2 100644
> > --- a/drivers/gpu/drm/vc4/vc4_bo.c
> > +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> > @@ -799,13 +799,38 @@ vc4_prime_import_sg_table(struct drm_device *dev,
> > return obj;
> > }
> >
> > +static int vc4_grab_bin_bo(struct vc4_dev *vc4, struct vc4_file *vc4file)
> > +{
> > + int ret;
> > +
> > + if (!vc4->v3d)
> > + return -ENODEV;
> > +
> > + if (vc4file->bin_bo_used)
> > + return 0;
> > +
> > + ret = vc4_v3d_bin_bo_get(vc4);
> > + if (ret)
> > + return ret;
> > +
> > + vc4file->bin_bo_used = true;
>
> I think I found one last race. Multiple threads could be in an ioctl
> trying to grab the bin BO at the same time (while this is only during
> app startup, since the fd only needs to get the ref once, it's
> particularly plausible given that allocating the bin BO is slow). I
> think if you replace this line with:
>
> mutex_lock(>bin_bo_lock);
> if (vc4file->bin_bo_used) {
> mutex_unlock(>bin_bo_lock);
> vc4_v3d_bin_bo_put(vc4);
> } else {
> vc4file->bin_bo_used = true;
> mutex_unlock(>bin_bo_lock);
> }
Huh, very good catch once again, thanks! It took me some time to grasp
this one, but as far as I understand, the risk is that we could ref our
bin bo twice (although it would only be allocated once) since
bin_bo_used is not protected.
I'd like to suggest another solution, which would avoid re-locking and
doing an extra put if we got an extra ref: adding a "bool *used"
argument to vc4_v3d_bin_bo_get and, which only gets dereferenced with
the bin_bo lock held. Then we can skip obtaining a new reference if
(used && *used) in vc4_v3d_bin_bo_get.
So we could pass a pointer to vc4file->bin_bo_used for vc4_grab_bin_bo
and exec->bin_bo_used for the exec case (where there is no such issue
since we'll only ever try to _get the bin bo once there anyway).
What do you think?
Cheers,
Paul
> that will be the last change we need. If you agree with this, feel free
> to squash it in and apply the series with:
>
> Reviewed-by: Eric Anholt
>
> > +
> > + return 0;
> > +}
> > +
> > int vc4_create_bo_ioctl(struct drm_device *dev, void *data,
> > struct drm_file *file_priv)
> > {
> > struct drm_vc4_create_bo *args = data;
> > + struct vc4_file *vc4file = file_priv->driver_priv;
> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
> > struct vc4_bo *bo = NULL;
> > int ret;
> >
> > + ret = vc4_grab_bin_bo(vc4, vc4file);
> > + if (ret)
> > + return ret;
> > +
> > /*
> > * We can't allocate from the BO cache, because the BOs don't
> > * get zeroed, and that might leak data between users.
> > @@ -846,6 +871,8 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void
> > *data,
> >struct drm_file *file_priv)
> > {
> > struct drm_vc4_create_shader_bo *args = data;
> > + struct vc4_file *vc4file = file_priv->driver_priv;
> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
> > struct vc4_bo *bo = NULL;
> > int ret;
> >
> > @@ -865,6 +892,10 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev,
> > void *data,
> > return -EINVAL;
> > }
> >
> > + ret = vc4_grab_bin_bo(vc4, vc4file);
> > + if (ret)
> > + return ret;
> > +
> > bo = vc4_bo_create(dev, args->size, true, VC4_BO_TYPE_V3D_SHADER);
> > if (IS_ERR(bo))
> > return PTR_ERR(bo);
> > @@ -894,7 +925,7 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev,
Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On Thu, May 02, 2019 at 12:50:53PM +0200, Greg KH wrote: > On Wed, May 01, 2019 at 04:01:09PM -0700, Brendan Higgins wrote: > > ## TLDR > > > > I rebased the last patchset on 5.1-rc7 in hopes that we can get this in > > 5.2. > > That might be rushing it, normally trees are already closed now for > 5.2-rc1 if 5.1-final comes out this Sunday. > > > Shuah, I think you, Greg KH, and myself talked off thread, and we agreed > > we would merge through your tree when the time came? Am I remembering > > correctly? > > No objection from me. > > Let me go review the latest round of patches now. Overall, looks good to me, and provides a framework we can build on. I'm a bit annoyed at the reliance on uml at the moment, but we can work on that in the future :) Thanks for sticking with this, now the real work begins... Reviewed-by: Greg Kroah-Hartman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 16/17] kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec()
On Wed, May 01, 2019 at 04:01:25PM -0700, Brendan Higgins wrote: > From: Iurii Zaikin > > KUnit tests for initialized data behavior of proc_dointvec that is > explicitly checked in the code. Includes basic parsing tests including > int min/max overflow. > > Signed-off-by: Iurii Zaikin > Signed-off-by: Brendan Higgins > --- > kernel/Makefile | 2 + > kernel/sysctl-test.c | 292 +++ > lib/Kconfig.debug| 6 + > 3 files changed, 300 insertions(+) > create mode 100644 kernel/sysctl-test.c > > diff --git a/kernel/Makefile b/kernel/Makefile > index 6c57e78817dad..c81a8976b6a4b 100644 > --- a/kernel/Makefile > +++ b/kernel/Makefile > @@ -112,6 +112,8 @@ obj-$(CONFIG_HAS_IOMEM) += iomem.o > obj-$(CONFIG_ZONE_DEVICE) += memremap.o > obj-$(CONFIG_RSEQ) += rseq.o > > +obj-$(CONFIG_SYSCTL_KUNIT_TEST) += sysctl-test.o You are going to have to have a "standard" naming scheme for test modules, are you going to recommend "foo-test" over "test-foo"? If so, that's fine, we should just be consistant and document it somewhere. Personally, I'd prefer "test-foo", but that's just me, naming is hard... thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/17] kunit: tool: add Python wrappers for running KUnit tests
On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrote: > From: Felix Guo > > The ultimate goal is to create minimal isolated test binaries; in the > meantime we are using UML to provide the infrastructure to run tests, so > define an abstract way to configure and run tests that allow us to > change the context in which tests are built without affecting the user. > This also makes pretty and dynamic error reporting, and a lot of other > nice features easier. > > kunit_config.py: > - parse .config and Kconfig files. > > kunit_kernel.py: provides helper functions to: > - configure the kernel using kunitconfig. > - build the kernel with the appropriate configuration. > - provide function to invoke the kernel and stream the output back. > > Signed-off-by: Felix Guo > Signed-off-by: Brendan Higgins Ah, here's probably my answer to my previous logging format question, right? What's the chance that these wrappers output stuff in a standard format that test-framework-tools can already parse? :) thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/17] kunit: test: add kunit_stream a std::stream like logger
On Wed, May 01, 2019 at 04:01:13PM -0700, Brendan Higgins wrote: > A lot of the expectation and assertion infrastructure prints out fairly > complicated test failure messages, so add a C++ style log library for > for logging test results. Ideally we would always use a standard logging format, like the kselftest tests all are aiming to do. That way the output can be easily parsed by tools to see if the tests succeed/fail easily. Any chance of having this logging framework enforcing that format as well? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/17] kunit: test: add initial tests
On Wed, May 01, 2019 at 04:01:16PM -0700, Brendan Higgins wrote: > Add a test for string stream along with a simpler example. > > Signed-off-by: Brendan Higgins > --- > kunit/Kconfig | 12 ++ > kunit/Makefile | 4 ++ > kunit/example-test.c | 88 ++ > kunit/string-stream-test.c | 61 ++ > 4 files changed, 165 insertions(+) > create mode 100644 kunit/example-test.c > create mode 100644 kunit/string-stream-test.c > > diff --git a/kunit/Kconfig b/kunit/Kconfig > index 64480092b2c24..5cb500355c873 100644 > --- a/kunit/Kconfig > +++ b/kunit/Kconfig > @@ -13,4 +13,16 @@ config KUNIT > special hardware. For more information, please see > Documentation/kunit/ > > +config KUNIT_TEST > + bool "KUnit test for KUnit" > + depends on KUNIT > + help > + Enables KUnit test to test KUnit. > + > +config KUNIT_EXAMPLE_TEST > + bool "Example test for KUnit" > + depends on KUNIT > + help > + Enables example KUnit test to demo features of KUnit. Can't these tests be module? Or am I mis-reading the previous logic? Anyway, just a question, nothing objecting to this as-is for now. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On Wed, May 01, 2019 at 04:01:09PM -0700, Brendan Higgins wrote: > ## TLDR > > I rebased the last patchset on 5.1-rc7 in hopes that we can get this in > 5.2. That might be rushing it, normally trees are already closed now for 5.2-rc1 if 5.1-final comes out this Sunday. > Shuah, I think you, Greg KH, and myself talked off thread, and we agreed > we would merge through your tree when the time came? Am I remembering > correctly? No objection from me. Let me go review the latest round of patches now. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/3] backlight: lm3630a: return 0 on success in update_status functions
On Thu, May 02, 2019 at 06:42:39AM -0400, Brian Masney wrote:
> On Thu, May 02, 2019 at 11:07:51AM +0100, Daniel Thompson wrote:
> > On 24/04/2019 10:25, Brian Masney wrote:
> > > lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
> > > both return the brightness value if the brightness was successfully
> > > updated. Writing to these attributes via sysfs would cause a 'Bad
> > > address' error to be returned. These functions should return 0 on
> > > success, so let's change it to correct that error.
> > >
> > > Signed-off-by: Brian Masney
> > > Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
> > > Acked-by: Pavel Machek
> >
> > Hi Brian, sorry for the delay. For some reason your mails are being dumped
> > before they reach me so I only discovered these patches when I paid proper
> > attention to the replies and fetched them from patchwork.
> >
> > Hi Lee, is the same thing happening for you? ;-)
>
> Huh, that's odd. I haven't ran into that issue when working with people
> from Linaro in other subsystems.
>
> As a sanity check, I used 'git send-email' to send this patch to
> check-a...@verifier.port25.com and it verified that I still have SPF,
> DKIM, reverse DNS, etc. all setup properly on this domain.
>
> hotmail.com addresses are the only ones I've had issues with in the
> past, but I doubt you're forwarding your email there. :)
No... and strangely enough your recent e-mail sailed through just fine.
Let's wait and see what is happening for Lee (which I suspect may not be
until well into next week).
Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] 2nd pull for malidp-next
Hi DRM maintainers, This is the 2nd pull request for the malidp-next. The new patches add additional support for Arm Mali D71 so that it can now be enabled correctly and brought up on any SoC that contains the IP. From now on we will start focusing on adding writeback, scaling and other useful features to bring the driver to the same level of maturity as mali-dp. Please pull, Liviu The following changes since commit 7c13e5cc2391950541f41fc9ab0336aae77c7f63: Merge tag 'drm-intel-next-fixes-2019-04-25' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2019-04-26 11:35:59 +1000) are available in the Git repository at: git://linux-arm.org/linux-ld.git for-upstream/mali-dp for you to fetch changes up to 96f9574666861e7c5902d412474d3ff28123c7d1: drm/komeda: remove set but not used variable 'kcrtc' (2019-04-29 14:51:11 +0100) Nathan Chancellor (1): drm/komeda: Use memset to initialize config_id YueHaibing (1): drm/komeda: remove set but not used variable 'kcrtc' james qian wang (Arm Technology China) (18): drm: Add drm_atomic_get_old/new_private_obj_state drm/komeda: Add komeda_pipeline/component_get_state_and_set_user drm/komeda: Initialize komeda component as drm private object drm/komeda: Add komeda_build_layer_data_flow drm/komeda: Add komeda_plane/plane_helper_funcs drm/komeda: Add komeda_build_display_data_flow drm/komeda: Add komeda_release_unclaimed_resources drm/komeda: Add komeda_crtc_atomic_flush drm/komeda: Add komeda_crtc_mode_valid/fixup drm/komeda: Add komeda_crtc_prepare/unprepare drm/komeda: Add komeda_crtc_atomic_enable/disable drm/komeda: Add komeda_crtc_vblank_enable/disable drm/komeda: Add komeda_crtc_funcs drm/komeda: Add komeda_kms_check drm/komeda: Add sysfs attribute: core_id and config_id drm/komeda: Expose bus_width to Komeda-CORE drm/komeda: Fixed warning: Function parameter or member not described drm/komeda: Mark the local functions as static .../gpu/drm/arm/display/include/malidp_product.h | 12 + drivers/gpu/drm/arm/display/komeda/Makefile| 1 + .../gpu/drm/arm/display/komeda/d71/d71_component.c | 9 +- drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 54 ++ drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 395 - drivers/gpu/drm/arm/display/komeda/komeda_dev.c| 52 ++ drivers/gpu/drm/arm/display/komeda/komeda_dev.h| 44 +- drivers/gpu/drm/arm/display/komeda/komeda_drv.c| 9 +- .../drm/arm/display/komeda/komeda_framebuffer.h| 9 +- drivers/gpu/drm/arm/display/komeda/komeda_kms.c| 39 +- drivers/gpu/drm/arm/display/komeda/komeda_kms.h| 21 +- .../gpu/drm/arm/display/komeda/komeda_pipeline.c | 2 +- .../gpu/drm/arm/display/komeda/komeda_pipeline.h | 81 ++- .../drm/arm/display/komeda/komeda_pipeline_state.c | 610 + drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 137 + .../drm/arm/display/komeda/komeda_private_obj.c| 220 +++- drivers/gpu/drm/drm_atomic.c | 45 +- include/drm/drm_atomic.h | 6 + 18 files changed, 1698 insertions(+), 48 deletions(-) create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: rave-sp: don't touch initial state and register with correct device
On 29/04/2019 16:29, Lucas Stach wrote: This way the backlight can be referenced through its device node and enabling/disabling can be managed through the panel driver. Is it possible to implement something similar to pwm_backlight_initial_power_state() to handle this? backlight drivers already suffer from too much diversity so I prefer things like this to align behaviour with the (fairly heavilyly used) PWM driver if possible. Daniel. Signed-off-by: Lucas Stach --- drivers/video/backlight/rave-sp-backlight.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/video/backlight/rave-sp-backlight.c b/drivers/video/backlight/rave-sp-backlight.c index 462f14a1b19d..d296bfcf4396 100644 --- a/drivers/video/backlight/rave-sp-backlight.c +++ b/drivers/video/backlight/rave-sp-backlight.c @@ -48,15 +48,13 @@ static int rave_sp_backlight_probe(struct platform_device *pdev) struct device *dev = >dev; struct backlight_device *bd; - bd = devm_backlight_device_register(dev, pdev->name, dev->parent, + bd = devm_backlight_device_register(dev, pdev->name, dev, dev_get_drvdata(dev->parent), _sp_backlight_ops, _sp_backlight_props); if (IS_ERR(bd)) return PTR_ERR(bd); - backlight_update_status(bd); - return 0; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/3] backlight: lm3630a: add firmware node support
On 24/04/2019 10:25, Brian Masney wrote:
Add fwnode support to the lm3630a driver and optionally allow
configuring the label, default brightness level, and maximum brightness
level. The two outputs can be controlled by bank A and B independently
or bank A can control both outputs.
If the platform data was not configured, then the driver defaults to
enabling both banks. This patch changes the default value to disable
both banks before parsing the firmware node so that just a single bank
can be enabled if desired. There are no in-tree users of this driver.
In that case given I'd certainly entertain patches that move the config
structures out of include/linux/platform_data and say the driver
requires a proper entry in the hardware description! Not a requirement
though.
Driver was tested on a LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
Reviewed-by: Dan Murphy
Acked-by: Pavel Machek
Acked-by: Daniel Thompson
---
Changes since v5
- None
Changes since v4
- Added new function lm3630a_parse_bank()
- Renamed seen variable to seen_led_sources
- Use the bitmask returned from lm3630a_parse_led_sources() to compare
against the seen_led_sources rather than just the control bank. This
eliminated another if statement that was previously present that
checked to see if control bank A should control both sinks.
- #define LM3630A_BANK_0, LM3630A_BANK_1, LM3630A_SINK_0,
LM3630A_SINK_1, and LM3630A_NUM_SINKS and use where appropriate.
- Changed all occurances of
'if (bank == 0) { BANK_A_WORK } else { BANK_B_WORK }' to
'if (bank) { BANK_B_WORK } else { BANK_A_WORK }'
- Dropped unnecessary 'ret = 0' from lm3630a_parse_led_sources().
- Changed 'if (ret < 0)' to 'if (ret)' in lm3630a_parse_node().
- Dropped kerneldoc from lm3630a_parse_led_sources().
Changes since v3
- Add support for label
- Changed lm3630a_parse_node() to return -ENODEV if no nodes were found
- Remove LM3630A_LED{A,B}_DISABLE
- Add two additional newlines for code readability
- Remove extra newline
Changes since v2
- Separated out control banks and outputs via the reg and led-sources
properties.
- Use fwnode instead of of API
- Disable both banks by default before calling lm3630a_parse_node()
- Add lots of error handling
- Check for duplicate source / bank definitions
- Remove extra ;
- Make probe() method fail if fwnode parsing fails.
drivers/video/backlight/lm3630a_bl.c | 149 ++-
include/linux/platform_data/lm3630a_bl.h | 4 +
2 files changed, 148 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index ef2553f452ca..75d996490cf0 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -35,6 +35,14 @@
#define REG_MAX 0x50
#define INT_DEBOUNCE_MSEC 10
+
+#define LM3630A_BANK_0 0
+#define LM3630A_BANK_1 1
+
+#define LM3630A_NUM_SINKS 2
+#define LM3630A_SINK_0 0
+#define LM3630A_SINK_1 1
+
struct lm3630a_chip {
struct device *dev;
struct delayed_work work;
@@ -329,15 +337,17 @@ static const struct backlight_ops lm3630a_bank_b_ops = {
static int lm3630a_backlight_register(struct lm3630a_chip *pchip)
{
- struct backlight_properties props;
struct lm3630a_platform_data *pdata = pchip->pdata;
+ struct backlight_properties props;
+ const char *label;
props.type = BACKLIGHT_RAW;
if (pdata->leda_ctrl != LM3630A_LEDA_DISABLE) {
props.brightness = pdata->leda_init_brt;
props.max_brightness = pdata->leda_max_brt;
+ label = pdata->leda_label ? pdata->leda_label : "lm3630a_leda";
pchip->bleda =
- devm_backlight_device_register(pchip->dev, "lm3630a_leda",
+ devm_backlight_device_register(pchip->dev, label,
pchip->dev, pchip,
_bank_a_ops, );
if (IS_ERR(pchip->bleda))
@@ -348,8 +358,9 @@ static int lm3630a_backlight_register(struct lm3630a_chip
*pchip)
(pdata->ledb_ctrl != LM3630A_LEDB_ON_A)) {
props.brightness = pdata->ledb_init_brt;
props.max_brightness = pdata->ledb_max_brt;
+ label = pdata->ledb_label ? pdata->ledb_label : "lm3630a_ledb";
pchip->bledb =
- devm_backlight_device_register(pchip->dev, "lm3630a_ledb",
+ devm_backlight_device_register(pchip->dev, label,
pchip->dev, pchip,
_bank_b_ops, );
if (IS_ERR(pchip->bledb))
@@ -364,6 +375,123 @@ static const struct regmap_config lm3630a_regmap = {
.max_register = REG_MAX,
};
+static int lm3630a_parse_led_sources(struct fwnode_handle *node,
+
Re: [PATCH v6 2/3] dt-bindings: backlight: add lm3630a bindings
On 24/04/2019 10:25, Brian Masney wrote:
Add new backlight bindings for the TI LM3630A dual-string white LED.
Signed-off-by: Brian Masney
Reviewed-by: Rob Herring
Acked-by: Pavel Machek
Acked-by: Daniel Thompson
---
Changes since v5:
- Change 'lm3630a_bl@38' in examples to 'led-controller@38'
Changes since v4:
- Drop $ref from led-sources
- Drop description from reg of i2c address
- Expand description of reg for the control bank
- Drop status from examples
Changes since v3:
- Add label. I didn't add a description for it since that'll come from
the common properties once its converted.
Changes since v2:
- Update description of max-brightness
- Add description for reg
- Correct typo: s/tranisiton/transition
- add reg to control banks
- add additionalProperties
.../leds/backlight/lm3630a-backlight.yaml | 129 ++
1 file changed, 129 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
diff --git
a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
new file mode 100644
index ..4d61fe0a98a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/lm3630a-backlight.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI LM3630A High-Efficiency Dual-String White LED
+
+maintainers:
+ - Lee Jones
+ - Daniel Thompson
+ - Jingoo Han
+
+description: |
+ The LM3630A is a current-mode boost converter which supplies the power and
+ controls the current in up to two strings of 10 LEDs per string.
+ https://www.ti.com/product/LM3630A
+
+properties:
+ compatible:
+const: ti,lm3630a
+
+ reg:
+maxItems: 1
+
+ ti,linear-mapping-mode:
+description: |
+ Enable linear mapping mode. If disabled, then it will use exponential
+ mapping mode in which the ramp up/down appears to have a more uniform
+ transition to the human eye.
+type: boolean
+
+required:
+ - compatible
+ - reg
+
+patternProperties:
+ "^led@[01]$":
+type: object
+description: |
+ Properties for a string of connected LEDs.
+
+properties:
+ reg:
+description: |
+ The control bank that is used to program the two current sinks. The
+ LM3630A has two control banks (A and B) and are represented as 0 or 1
+ in this property. The two current sinks can be controlled
+ independently with both banks, or bank A can be configured to control
+ both sinks with the led-sources property.
+maxItems: 1
+minimum: 0
+maximum: 1
+
+ label:
+maxItems: 1
+
+ led-sources:
+allOf:
+ - minItems: 1
+maxItems: 2
+items:
+ minimum: 0
+ maximum: 1
+
+ default-brightness:
+description: Default brightness level on boot.
+minimum: 0
+maximum: 255
+
+ max-brightness:
+description: Maximum brightness that is allowed during runtime.
+minimum: 0
+maximum: 255
+
+required:
+ - reg
+
+additionalProperties: false
+
+additionalProperties: false
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+led-controller@38 {
+compatible = "ti,lm3630a";
+reg = <0x38>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+led@0 {
+reg = <0>;
+led-sources = <0 1>;
+label = "lcd-backlight";
+default-brightness = <200>;
+max-brightness = <255>;
+};
+};
+};
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+led-controller@38 {
+compatible = "ti,lm3630a";
+reg = <0x38>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+led@0 {
+reg = <0>;
+default-brightness = <150>;
+ti,linear-mapping-mode;
+};
+
+led@1 {
+reg = <1>;
+default-brightness = <225>;
+ti,linear-mapping-mode;
+};
+};
+};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/3] backlight: lm3630a: return 0 on success in update_status functions
On 24/04/2019 10:25, Brian Masney wrote:
lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
both return the brightness value if the brightness was successfully
updated. Writing to these attributes via sysfs would cause a 'Bad
address' error to be returned. These functions should return 0 on
success, so let's change it to correct that error.
Signed-off-by: Brian Masney
Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
Acked-by: Pavel Machek
Hi Brian, sorry for the delay. For some reason your mails are being
dumped before they reach me so I only discovered these patches when I
paid proper attention to the replies and fetched them from patchwork.
Hi Lee, is the same thing happening for you? ;-)
Acked-by: Daniel Thompson
---
No changes since v2 when this patch was originally introduced.
drivers/video/backlight/lm3630a_bl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index 2030a6b77a09..ef2553f452ca 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -201,7 +201,7 @@ static int lm3630a_bank_a_update_status(struct
backlight_device *bl)
LM3630A_LEDA_ENABLE, LM3630A_LEDA_ENABLE);
if (ret < 0)
goto out_i2c_err;
- return bl->props.brightness;
+ return 0;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access\n");
@@ -278,7 +278,7 @@ static int lm3630a_bank_b_update_status(struct
backlight_device *bl)
LM3630A_LEDB_ENABLE, LM3630A_LEDB_ENABLE);
if (ret < 0)
goto out_i2c_err;
- return bl->props.brightness;
+ return 0;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access REG_CTRL\n");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
