dri-devel May 2019

dri-devel@lists.freedesktop.org

299 participants
2118 discussions

[PATCH v1 0/3] drm/msm: Add dependencies for per-instance pagetables
by Jordan Crouse 09 May '19

09 May '19

These are a few support changes in advance of per-instance pagetables. These can be added to msm-next immediately since they don't require anything external support and they are mostly benign on their own without the more aggressive changes coming up later. Jordan Crouse (3): drm/msm/adreno: Enable 64 bit mode by default on a5xx and a6xx targets drm/msm: Print all 64 bits of the faulting IOMMU address drm/msm: Pass the MMU domain index in struct msm_file_private drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 14 ++++++++++++++ drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 ++++++++++++++ drivers/gpu/drm/msm/msm_drv.c | 2 ++ drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/msm/msm_gem.h | 1 + drivers/gpu/drm/msm/msm_gem_submit.c | 13 ++++++++----- drivers/gpu/drm/msm/msm_gpu.c | 5 ++--- drivers/gpu/drm/msm/msm_iommu.c | 2 +- 8 files changed, 43 insertions(+), 9 deletions(-) -- 2.7.4

2 4

[v1] drm/arm/mali-dp: Add a loop around the second set CVAL and try 5 times
by Wen He 09 May '19

09 May '19

This patch trying to fix monitor freeze issue caused by drm error 'flip_done timed out' on LS1028A platform. this set try is make a loop around the second setting CVAL and try like 5 times before giveing up. Signed-off-by: Liviu <liviu.Dudau(a)arm.com> Signed-off-by: Wen He <wen.he_1(a)nxp.com> --- drivers/gpu/drm/arm/malidp_drv.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index 21725c9b9f5e..18cb7f134f4e 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -192,6 +192,7 @@ static void malidp_atomic_commit_hw_done(struct drm_atomic_state *state) { struct drm_device *drm = state->dev; struct malidp_drm *malidp = drm->dev_private; + int loop = 5; malidp->event = malidp->crtc.state->event; malidp->crtc.state->event = NULL; @@ -206,8 +207,18 @@ static void malidp_atomic_commit_hw_done(struct drm_atomic_state *state) drm_crtc_vblank_get(&malidp->crtc); /* only set config_valid if the CRTC is enabled */ - if (malidp_set_and_wait_config_valid(drm) < 0) + if (malidp_set_and_wait_config_valid(drm) < 0) { + /* + * make a loop around the second CVAL setting and + * try 5 times before giving up. + */ + while (loop--) { + if (!malidp_set_and_wait_config_valid(drm)) + break; + } DRM_DEBUG_DRIVER("timed out waiting for updated configuration\n"); + } + } else if (malidp->event) { /* CRTC inactive means vblank IRQ is disabled, send event directly */ spin_lock_irq(&drm->event_lock); -- 2.17.1

2 1

[PATCH RFC 0/6] ARM: qcom: initial Nexus 5 display support
by Brian Masney 09 May '19

09 May '19

Here is a patch series that adds initial display support for the LG Nexus 5 (hammerhead) phone. The board boots into terminal mode, however there is a several second (or more) delay when writing to tty1 compared to when the changes are actually shown on the screen. The following errors are in dmesg: msm fd900000.mdss: pp done time out, lm=0 [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:49:crtc-0] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:32:plane-0] flip_done timed out mdp5_get_scanoutpos() and mdp5_get_vblank_counter() both return 0, which is causing this stack trace to be dumped into the system log several times: WARNING: CPU: 0 PID: 5 at drivers/gpu/drm/drm_atomic_helper.c:1430 drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290 [CRTC:49:crtc-0] vblank wait timed out Modules linked in: CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.1.0-rc6-next-20190426-00006-g35c0d32a96e1-dirty #191 Hardware name: Generic DT based system Workqueue: events deferred_probe_work_func [<c031229c>] (unwind_backtrace) from [<c030d5ac>] (show_stack+0x10/0x14) [<c030d5ac>] (show_stack) from [<c0ac134c>] (dump_stack+0x78/0x8c) [<c0ac134c>] (dump_stack) from [<c0321660>] (__warn.part.3+0xb8/0xd4) [<c0321660>] (__warn.part.3) from [<c03216e0>] (warn_slowpath_fmt+0x64/0x88) [<c03216e0>] (warn_slowpath_fmt) from [<c0761a0c>] (drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290) [<c0761a0c>] (drm_atomic_helper_wait_for_vblanks.part.1) from [<c07b0a98>] (mdp5_complete_commit+0x14/0x40) [<c07b0a98>] (mdp5_complete_commit) from [<c07ddb80>] (msm_atomic_commit_tail+0xa8/0x140) [<c07ddb80>] (msm_atomic_commit_tail) from [<c0763304>] (commit_tail+0x40/0x6c) [<c07633f4>] (drm_atomic_helper_commit) from [<c07667f0>] (restore_fbdev_mode_atomic+0x168/0x1d4) .... In mdp5_irq(), I see that a few vblank IRQ statuses (0x1000) come through when the board boots, drm_handle_vblank() is called, and the screen updates, however mdp5_get_scanoutpos() continues to return 0 after these operations complete. I don't see any ping-pong done IRQ statuses (0x100) come through in mdp5_irq(). I can get the text console to work with a 4.17 kernel with this patch https://patchwork.kernel.org/patch/10321845/ plus about a dozen or more other patches that have been mainlined since that release. The pp done and vblank messages still happen, however tty1 is updated when I write to it and Wayland works. The lg,acx467akm-7 panel listed below is currently handled by the simple panel driver since it is sufficient for 4.17 kernel, but that may need to change in the future for the power on commands. To be sure, I followed the instructions at https://github.com/freedreno/freedreno/wiki/DSI-Panel-Driver-Porting for porting the almost 400 panel on commands from the downstream kernel sources at https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/m…. The screen turns all white when the panel display is turned on and the panel exits sleep mode. Unfortunately, there are a lot of power on commands listed in the downstream device tree that aren't listed in mipi_display.h. Thanks in advance for any advice that you can provide. Brian Masney (6): drm/msm: fix null pointer dereference in msm_atomic_prepare_fb() drm/msm: add dirty framebuffer helper ARM: qcom_defconfig: add display-related options ARM: dts: msm8974: add display support ARM: dts: qcom: msm8974-hammerhead: add support for backlight ARM: dts: qcom: msm8974-hammerhead: add support for display .../qcom-msm8974-lge-nexus5-hammerhead.dts | 79 +++++++++++ arch/arm/boot/dts/qcom-msm8974.dtsi | 132 ++++++++++++++++++ arch/arm/configs/qcom_defconfig | 5 + drivers/gpu/drm/msm/msm_atomic.c | 8 +- drivers/gpu/drm/msm/msm_fb.c | 2 + 5 files changed, 223 insertions(+), 3 deletions(-) -- 2.20.1

4 19

[PATCH] drm/amd/display: Make some functions static
by Wang Hai 09 May '19

09 May '19

Fix the following sparse warnings: drivers/gpu/drm/amd/amdgpu/../display/dc/dce120/dce120_resource.c:483:21: warning: symbol 'dce120_clock_source_create' was not declared. Should it be static? drivers/gpu/drm/amd/amdgpu/../display/dc/dce120/dce120_resource.c:506:6: warning: symbol 'dce120_clock_source_destroy' was not declared. Should it be static? drivers/gpu/drm/amd/amdgpu/../display/dc/dce120/dce120_resource.c:513:6: warning: symbol 'dce120_hw_sequencer_create' was not declared. Should it be static? Fixes: b8fdfcc6a92c ("drm/amd/display: Add DCE12 core support") Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Wang Hai <wanghai26(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c index 312a0aebf91f..0948421219ef 100644 --- a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c @@ -458,7 +458,7 @@ static const struct dc_debug_options debug_defaults = { .disable_clock_gate = true, }; -struct clock_source *dce120_clock_source_create( +static struct clock_source *dce120_clock_source_create( struct dc_context *ctx, struct dc_bios *bios, enum clock_source_id id, @@ -481,14 +481,14 @@ struct clock_source *dce120_clock_source_create( return NULL; } -void dce120_clock_source_destroy(struct clock_source **clk_src) +static void dce120_clock_source_destroy(struct clock_source **clk_src) { kfree(TO_DCE110_CLK_SRC(*clk_src)); *clk_src = NULL; } -bool dce120_hw_sequencer_create(struct dc *dc) +static bool dce120_hw_sequencer_create(struct dc *dc) { /* All registers used by dce11.2 match those in dce11 in offset and * structure -- 2.17.1

2 1

Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
by Theodore Ts'o 09 May '19

09 May '19

On Thu, May 09, 2019 at 01:52:15PM +0200, Knut Omang wrote: > 1) Tests that exercises typically algorithmic or intricate, complex > code with relatively few outside dependencies, or where the dependencies > are considered worth mocking, such as the basics of container data > structures or page table code. If I get you right, Ted, the tests > you refer to in this thread are such tests. I believe covering this space > is the goal Brendan has in mind for KUnit. Yes, that's correct. I'd also add that one of the key differences is that it sounds like Frank and you are coming from the perspective of testing *device drivers* where in general there aren't a lot of complex code which is hardware independent. After all, the vast majority of device drivers are primarily interface code to hardware, with as much as possible abstracted away to common code. (Take, for example, the model of the SCSI layer; or all of the kobject code.) > 2) Tests that exercises interaction between a module under test and other > parts of the kernel, such as testing intricacies of the interaction of > a driver or file system with the rest of the kernel, and with hardware, > whether that is real hardware or a model/emulation. > Using your testing needs as example again, Ted, from my shallow understanding, > you have such needs within the context of xfstests (https://github.com/tytso/xfstests) Well, upstream is for xfstests is git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git The test framework where I can run 20 hours worth of xfstests (multiple file system features enabled, multiple mount options, etc.) in 3 hours of wall clock time using multiple cloud VM is something called gce-xfstests. I also have kvm-xfstests, which optimizes low test latency, where I want to run a one or a small number of tests with a minimum of overhead --- gce startup and shutdown is around 2 minutes, where as kvm startup and shutdown is about 7 seconds. As far as I'm concerned, 7 seconds is still too slow, but that's the best I've been able to do given all of the other things I want a test framework to do, including archiving test results, parsing the test results so it's easy to interpret, etc. Both kvm-xfstests and gce-xfstests are located at: git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git So if Frank's primary argument is "too many frameworks", it's already too late. The block layer has blktests has a seprate framework, called blktests --- and yeah, it's a bit painful to launch or learn how to set things up. That's why I added support to run blktests using gce-xfstests and kvm-xfstests, so that "gce-xfstests --blktests" or "kvm-xfstests --xfstests" will pluck a kernel from your build tree, and launch at test appliance VM using that kernel and run the block layer tests. The point is we *already* have multiple test frameworks, which are optimized for testing different parts of the kernel. And if you plan to do a lot of work in these parts of the kernel, you're going to have to learn how to use some other test framework other than kselftest. Sorry, that's just the way it goes. Of course, I'll accept trivial patches that haven't been tested using xfstests --- but that's because I can trivially run the smoke test for you. Of course, if I get a lot of patches from a contributor which cause test regressions, I'll treat them much like someone who contribute patches which fail to build. I'll apply pressure to the contributor to actually build test, or run a ten minute kvm-xfstests smoke test. Part of the reason why I feel comfortable to do this is it's really easy to run the smoke test. There are pre-compiled test appliances, and a lot of documentation: https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickst… This is why I have close to zero sympathy to Frank's complaint that extra test frameworks are a bad thing. To me, that's whining. I've done a huge amount of work to meet contributors more than half-way. The insistence that "There Must Be One", ala the Highlander movie, is IMHO so wrong that it's not even close. Is it really that hard to do a "git pull", download a test appliance, set up a config file to tell kvm-xfstests where to find your build tree, and then run "kvm-xfstests --smoke" or "gce-xfstests --smoke"? Cry me a river. There are already multiple test frameworks, and if you expect to do a lot of work in a particular subsystem, you'll be expected to use the Maintainer's choice of tests. Deal with it. We do this so we can scale to the number of contributors we have in our subsystem. > To 1) I agree with Frank in that the problem with using UML is that you still have to > relate to the complexity of a kernel run time system, while what you really want for these > types of tests is just to compile a couple of kernel source files in a normal user land > context, to allow the use of Valgrind and other user space tools on the code. "Just compiling a couple of kernel source files in a normal user land" is much harder than you think. It requires writing vast numbers of mocking functions --- for a file system I would have to simulate the block device layer, large portions of the VFS layer, the scheduler and the locking layer if I want to test locking bugs, etc., etc. In practice, UML itself is serving as mocking layer, by its mere existence. So when Frank says that KUnit doesn't provide any mocking functions, I don't at all agree. Using KUnit and UML makes testing internal interfaces *far* simpler, especially if the comparison is "just compile some kernel source files as part of a userspace test program". Perhaps your and Frank's experience is different --- perhaps that can be explained by your past experience and interest in testing device drivers as opposed to file systems. The other thing I'd add is that at least for me, a really important consideration is how quickly we can run tests. I consider minimization of developer friction (e.g., all you need to do is running "make ; kvm-xfstests --smoke" to run tests), and maximizing developer velocity to be high priority goals. Developer velocity is how quickly can you run the tests; ideally, less than 5-10 seconds. And that's the other reason why I consider unit tests to be a complement to integration tests. "gce-xfstests --smoke" takes 10-15 minutes. If I can have unit tests which takes 5-15 seconds for a smoke test of the specific part of ext4 that I am modifying (and often with much better coverage than integration tests from userspace), that's at really big deal. I can do this for e2fsprogs; but if I have to launch a VM, the VM overhead pretty much eats all or most of that time budget right there. >From looking at your documentation of KTF, you are targetting the use case of continuous testing. That's a different testing scenario than what I'm describing; with continuous testing, overhead measured in minutes or even tens of minutes is not a big deal. But if you are trying to do real-time testing as part of your development process --- *real* Test Driven Development, then test latency is a really big deal. I'll grant that for people who are working on device drivers where architecture dependencies are a big deal, building for an architecture where you can run in a virtual environment or using test hardware is going to be a better way to go. And Brendan has said he's willing to look at adapting KUnit so it can be built for use in a virtual environment to accomodate your requirements. As far as I'm concerned, however, I would *not* be interested in KTF unless you could demonstrate to me that launching at test VM, somehow getting the kernel modules copied into the VM, and running the tests as kernel modules, has zero overhead compared to using UML. Ultimately, I'm a pragmatist. If KTF serves your needs best, good for you. If other approaches are better for other parts of the kernel, let's not try to impose a strict "There Must Be Only One" religion. That's already not true today, and for good reason. There are many different kinds of kernel code, and many different types of test philosophies. Trying to force all kernel testing into a single Procrustean Bed is simply not productive. Regards, - Ted

1 0

[drm-intel:drm-intel-next-queued 4/6] drivers/gpu/drm/drm_hdcp.c:27:3: sparse: sparse: symbol 'srm_data' was not declared. Should it be static?
by kbuild test robot 09 May '19

09 May '19

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: c16fd9be70faf3c49a61700efd16018dd910e390 commit: 6498bf5800a302ef69e7f4914e727893f278bb2f [4/6] drm: revocation check at drm subsystem reproduce: # apt-get install sparse git checkout 6498bf5800a302ef69e7f4914e727893f278bb2f make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag Reported-by: kbuild test robot <lkp(a)intel.com> sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/drm_hdcp.c:27:3: sparse: sparse: symbol 'srm_data' was not declared. Should it be static? >> drivers/gpu/drm/drm_hdcp.c:235:6: sparse: sparse: symbol 'drm_hdcp_request_srm' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

1 1

[PATCH] i915: disable framebuffer compression on GeminiLake
by Jian-Hong Pan 09 May '19

09 May '19

From: Daniel Drake <drake(a)endlessm.com> On many (all?) the Gemini Lake systems we work with, there is frequent momentary graphical corruption at the top of the screen, and it seems that disabling framebuffer compression can avoid this. The ticket was reported 6 months ago and has already affected a multitude of users, without any real progress being made. So, lets disable framebuffer compression on GeminiLake until a solution is found. Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=108085 Signed-off-by: Daniel Drake <drake(a)endlessm.com> Signed-off-by: Jian-Hong Pan <jian-hong(a)endlessm.com> --- drivers/gpu/drm/i915/intel_fbc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c index 656e684e7c9a..fc018f3f53a1 100644 --- a/drivers/gpu/drm/i915/intel_fbc.c +++ b/drivers/gpu/drm/i915/intel_fbc.c @@ -1278,6 +1278,10 @@ static int intel_sanitize_fbc_option(struct drm_i915_private *dev_priv) if (!HAS_FBC(dev_priv)) return 0; + /* https://bugs.freedesktop.org/show_bug.cgi?id=108085 */ + if (IS_GEMINILAKE(dev_priv)) + return 0; + if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9) return 1; -- 2.21.0

5 4

[Bug 109294] [CI][SHARDS] igt@prime_vgem@basic-fence-flip - skip - Test requirement: (crtc_id = set_fb_on_crtc(i915, 0, &bo[0], fb_id[0])), SKIP
by bugzilla-daemon＠freedesktop.org 09 May '19

09 May '19

https://bugs.freedesktop.org/show_bug.cgi?id=109294 Tvrtko Ursulin <tvrtko.ursulin(a)linux.intel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Tvrtko Ursulin <tvrtko.ursulin(a)linux.intel.com> --- Pushed a test fix to probe the native display resolution. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PULL] drm-intel-next-fixes
by Joonas Lahtinen 09 May '19

09 May '19

Hi Dave & Daniel, Still rather quiet, most issues seem to have been fixed during CI testing. For i915, just two fixes to the request semaphore ordering code. For GVT a couple regression and static checker fixes. Best Regards, Joonas *** drm-intel-next-fixes-2019-05-09: - Two fixes for the freshly enabled semaphore ordering code - Includes gvt-next-fixes-2019-05-07 The following changes since commit 9628e15ca9d5f7595ba886173e98a139d0a56cd1: drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1 (2019-04-30 10:16:18 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-05-09 for you to fetch changes up to 23372cce8fe7ee98a6458fd3d035a55b87f0c6fe: Merge tag 'gvt-next-fixes-2019-05-07' of https://github.com/intel/gvt-linux into drm-intel-next-fixes (2019-05-07 15:29:15 +0300) ---------------------------------------------------------------- - Two fixes for the freshly enabled semaphore ordering code - Includes gvt-next-fixes-2019-05-07 ---------------------------------------------------------------- Aleksei Gimbitskii (4): drm/i915/gvt: Remove typedef and let the enumeration starts from zero drm/i915/gvt: Do not copy the uninitialized pointer from fb_info drm/i915/gvt: Use snprintf() to prevent possible buffer overflow. drm/i915/gvt: Check if get_next_pt_type() always returns a valid value Chris Wilson (2): drm/i915: Delay semaphore submission until the start of the signaler drm/i915: Disable semaphore busywaits on saturated systems Colin Xu (1): drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list Joonas Lahtinen (1): Merge tag 'gvt-next-fixes-2019-05-07' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Xiong Zhang (1): drm/i915/gvt: Change fb_info->size from pages to bytes Zhao Yakui (1): drm/i915/gvt: Revert "drm/i915/gvt: Refine the snapshort range of I915 MCHBAR to optimize gvt-g boot time" drivers/gpu/drm/i915/gvt/debugfs.c | 4 +- drivers/gpu/drm/i915/gvt/dmabuf.c | 19 ++++------ drivers/gpu/drm/i915/gvt/gtt.c | 15 +++++--- drivers/gpu/drm/i915/gvt/gtt.h | 16 ++++---- drivers/gpu/drm/i915/gvt/handlers.c | 4 +- drivers/gpu/drm/i915/gvt/mmio_context.c | 1 + drivers/gpu/drm/i915/gvt/reg.h | 3 -- drivers/gpu/drm/i915/gvt/scheduler.c | 2 +- drivers/gpu/drm/i915/i915_request.c | 59 +++++++++++++++++++++++++++++- drivers/gpu/drm/i915/intel_context.c | 1 + drivers/gpu/drm/i915/intel_context_types.h | 3 ++ 11 files changed, 93 insertions(+), 34 deletions(-)

1 0

[PATCH] drm/imx: ipuv3-plane: fix atomic update status query for non-plus i.MX6Q
by Philipp Zabel 09 May '19

09 May '19

The current buffer check halves the frame rate on non-plus i.MX6Q, as the IDMAC current buffer pointer is not yet updated when ipu_plane_atomic_update_pending is called from the EOF irq handler. Fixes: 70e8a0c71e9 ("drm/imx: ipuv3-plane: add function to query atomic update status") Tested-by: Marco Felsch <m.felsch(a)pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> --- drivers/gpu/drm/imx/ipuv3-plane.c | 13 ++++++++----- drivers/gpu/drm/imx/ipuv3-plane.h | 1 - 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c index d7a727a6e3d7..91edfe2498a6 100644 --- a/drivers/gpu/drm/imx/ipuv3-plane.c +++ b/drivers/gpu/drm/imx/ipuv3-plane.c @@ -605,7 +605,6 @@ static void ipu_plane_atomic_update(struct drm_plane *plane, active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch); ipu_cpmem_set_buffer(ipu_plane->ipu_ch, !active, eba); ipu_idmac_select_buffer(ipu_plane->ipu_ch, !active); - ipu_plane->next_buf = !active; if (ipu_plane_separate_alpha(ipu_plane)) { active = ipu_idmac_get_current_buffer(ipu_plane->alpha_ch); ipu_cpmem_set_buffer(ipu_plane->alpha_ch, !active, @@ -710,7 +709,6 @@ static void ipu_plane_atomic_update(struct drm_plane *plane, ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 1, eba); ipu_idmac_lock_enable(ipu_plane->ipu_ch, num_bursts); ipu_plane_enable(ipu_plane); - ipu_plane->next_buf = -1; } static const struct drm_plane_helper_funcs ipu_plane_helper_funcs = { @@ -732,10 +730,15 @@ bool ipu_plane_atomic_update_pending(struct drm_plane *plane) if (ipu_state->use_pre) return ipu_prg_channel_configure_pending(ipu_plane->ipu_ch); - else if (ipu_plane->next_buf >= 0) - return ipu_idmac_get_current_buffer(ipu_plane->ipu_ch) != - ipu_plane->next_buf; + /* + * Pretend no update is pending in the non-PRE/PRG case. For this to + * happen, an atomic update would have to be deferred until after the + * start of the next frame and simultaneously interrupt latency would + * have to be high enough to let the atomic update finish and issue an + * event before the previous end of frame interrupt handler can be + * executed. + */ return false; } int ipu_planes_assign_pre(struct drm_device *dev, diff --git a/drivers/gpu/drm/imx/ipuv3-plane.h b/drivers/gpu/drm/imx/ipuv3-plane.h index 15e85e15d35c..ffacbcdd2f98 100644 --- a/drivers/gpu/drm/imx/ipuv3-plane.h +++ b/drivers/gpu/drm/imx/ipuv3-plane.h @@ -27,7 +27,6 @@ struct ipu_plane { int dp_flow; bool disabling; - int next_buf; }; struct ipu_plane *ipu_plane_init(struct drm_device *dev, struct ipu_soc *ipu, -- 2.20.1

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2019