- 10 Aug, 2017 10 commits
-
-
Chris Wilson authored
Another case where we need to call sysfs_attr_init() to setup the internal lockdep class prior to use: [ 9.325229] BUG: key ffff880168bc7bb0 not in .data! [ 9.325240] DEBUG_LOCKS_WARN_ON(1) [ 9.325250] ------------[ cut here ]------------ [ 9.325280] WARNING: CPU: 1 PID: 275 at kernel/locking/lockdep.c:3156 lockdep_init_map+0x1b2/0x1c0 [ 9.325301] Modules linked in: intel_powerclamp(+) coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel i915(+) snd_hda_intel snd_hda_codec snd_hwdep r8169 mii snd_hda_core snd_pcm prime_numbers i2c_hid pinctrl_geminilake pinctrl_intel [ 9.325375] CPU: 1 PID: 275 Comm: modprobe Not tainted 4.13.0-rc4-CI-Trybot_1040+ #1 [ 9.325395] Hardware name: Intel Corp. Geminilake/GLK RVP2 LP4SD (07), BIOS GELKRVPA.X64.0045.B51.1704281422 04/28/2017 [ 9.325422] task: ffff8801721a4ec0 task.stack: ffffc900001dc000 [ 9.325440] RIP: 0010:lockdep_init_map+0x1b2/0x1c0 [ 9.325456] RSP: 0018:ffffc900001dfa10 EFLAGS: 00010282 [ 9.325473] RAX: 0000000000000016 RBX: ffff880168d54b80 RCX: 0000000000000000 [ 9.325488] RDX: 0000000080000001 RSI: 0000000000000001 RDI: ffffffff810f0800 [ 9.325505] RBP: ffffc900001dfa30 R08: 0000000000000001 R09: 0000000000000000 [ 9.325521] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880168bc7bb0 [ 9.325537] R13: 0000000000000000 R14: ffff880168bc7b98 R15: ffffffff81a263a0 [ 9.325554] FS: 00007fb60c3fd700(0000) GS:ffff88017fc80000(0000) knlGS:0000000000000000 [ 9.325574] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9.325588] CR2: 0000006582777d80 CR3: 000000016d818000 CR4: 00000000003406e0 [ 9.325604] Call Trace: [ 9.325618] __kernfs_create_file+0x76/0xe0 [ 9.325632] sysfs_add_file_mode_ns+0x8a/0x1a0 [ 9.325646] internal_create_group+0xea/0x2c0 [ 9.325660] sysfs_create_group+0x13/0x20 [ 9.325737] i915_perf_register+0xde/0x220 [i915] [ 9.325800] i915_driver_load+0xa77/0x16c0 [i915] [ 9.325863] i915_pci_probe+0x37/0x90 [i915] [ 9.325880] pci_device_probe+0xa8/0x130 [ 9.325894] driver_probe_device+0x29c/0x450 [ 9.325908] __driver_attach+0xe3/0xf0 [ 9.325922] ? driver_probe_device+0x450/0x450 [ 9.325935] bus_for_each_dev+0x62/0xa0 [ 9.325948] driver_attach+0x1e/0x20 [ 9.325960] bus_add_driver+0x173/0x270 [ 9.325974] driver_register+0x60/0xe0 [ 9.325986] __pci_register_driver+0x60/0x70 [ 9.326044] i915_init+0x6f/0x78 [i915] [ 9.326066] ? 0xffffffffa024e000 [ 9.326079] do_one_initcall+0x43/0x170 [ 9.326094] ? rcu_read_lock_sched_held+0x7a/0x90 [ 9.326109] ? kmem_cache_alloc_trace+0x261/0x2d0 [ 9.326124] do_init_module+0x5f/0x206 [ 9.326137] load_module+0x2561/0x2da0 [ 9.326150] ? show_coresize+0x30/0x30 [ 9.326165] ? kernel_read_file+0x105/0x190 [ 9.326180] SyS_finit_module+0xc1/0x100 [ 9.326192] ? SyS_finit_module+0xc1/0x100 [ 9.326210] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 9.326223] RIP: 0033:0x7fb60bf359f9 [ 9.326234] RSP: 002b:00007fff92b47c48 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 9.326255] RAX: ffffffffffffffda RBX: ffffffff814898a3 RCX: 00007fb60bf359f9 [ 9.326271] RDX: 0000000000000000 RSI: 00000028a9ceef8b RDI: 0000000000000000 [ 9.326287] RBP: ffffc900001dff88 R08: 0000000000000000 R09: 0000000000000000 [ 9.326303] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000040000 [ 9.326319] R13: 00000028aaef2a70 R14: 0000000000000000 R15: 00000028aaeee5d0 [ 9.326339] ? __this_cpu_preempt_check+0x13/0x20 [ 9.326353] Code: f1 39 00 85 c0 0f 84 38 ff ff ff 83 3d 9f 44 ce 01 00 0f 85 2b ff ff ff 48 c7 c6 b2 a2 c7 81 48 c7 c7 53 40 c5 81 e8 3f 82 01 00 <0f> ff e9 11 ff ff ff 0f 1f 80 00 00 00 00 55 31 c9 31 d2 31 f6 Fixes: 701f8231 ("drm/i915/perf: prune OA configs") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170810175743.25401-1-chris@chris-wilson.co.ukReviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
Jani Nikula authored
This is not to try to force a new style; this is my interpretation of what the most common existing style is. With hopes I don't need to answer so many questions about style going forward. Start a new style section in the i915 document to bolt the register style guide into. v2: vertical alignment, incorporate to kernel-doc, and more Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9de4a5b1bea4e76461c70a1dd66751581de0124f.1502368010.git.jani.nikula@intel.com
-
Jani Nikula authored
Revert to a normal comment, as the enum isn't properly documented anyway. Signed-off-by:
-
Jani Nikula authored
Remove old warning about docproc directive that's not supported in the Sphinx toolchain. Signed-off-by:
-
Ben Widawsky authored
This was based on a patch originally by Kristian. It has been modified pretty heavily to use the new callbacks from the previous patch. v2: - Add LINEAR and Yf modifiers to list (Ville) - Combine i8xx and i965 into one list of formats (Ville) - Allow 1010102 formats for Y/Yf tiled (Ville) v3: - Handle cursor formats (Ville) - Put handling for LINEAR in the mod_support functions (Ville) v4: - List each modifier explicitly in supported modifiers (Ville) - Handle the CURSOR plane (Ville) v5: - Split out cursor and sprite handling (Ville) v6: - Actually use the sprite funcs (Emil) - Use unreachable (Emil) v7: - Only allow Intel modifiers and LINEAR (Ben) v8 - Fix spite assert introduced in v6 (Daniel) v9 - Change vendor check logic to avoid magic 56 (Emil) - Reorder skl_mod_support (Ville) - make intel_plane_funcs static, could be done as of v5 (Ville) - rename local variable intel_format_modifiers to modifiers (Ville) - actually use sprite modifiers - split out modifier/formats by platform (Ville) v10: - Undo vendor check from v9 v11: - Squash CCS advertisement into this patch (daniels) - Don't advertise CCS on higher sprite planes (daniels) v12: - Don't advertise Y-tiled or CCS on any sprite planes, since we don't allocate enough DDB space for it to work. (daniels) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v8) Signed-off-by:Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Daniel Stone <daniels@collabora.com>
-
Ville Syrjälä authored
SKL+ display engine can scan out certain kinds of compressed surfaces produced by the render engine. This involved telling the display engine the location of the color control surfae (CCS) which describes which parts of the main surface are compressed and which are not. The location of CCS is provided by userspace as just another plane with its own offset. Add the required stuff to validate the user provided AUX plane metadata and convert the user provided linear offset into something the hardware can consume. Due to hardware limitations we require that the main surface and the AUX surface (CCS) be part of the same bo. The hardware also makes life hard by not allowing you to provide separate x/y offsets for the main and AUX surfaces (excpet with NV12), so finding suitable offsets for both requires a bit of work. Assuming we still want keep playing tricks with the offsets. I've just gone with a dumb "search backward for suitable offsets" approach, which is far from optimal, but it works. Also not all planes will be capable of scanning out compressed surfaces, and eg. 90/270 degree rotation is not supported in combination with decompression either. This patch may contain work from at least the following people: * Vandana Kannan <vandana.kannan@intel.com> * Daniel Vetter <daniel@ffwll.ch> * Ben Widawsky <ben@bwidawsk.net> v2: Deal with display workarounds 0390, 0531, 1125 (Paulo) v3: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason) Put the AUX register defines to the correct place Fix up the slightly bogus rotation check v4: Use I915_WRITE_FW() due to plane update locking changes s/return -EINVAL/goto err/ in intel_framebuffer_init() Eliminate a bunch hardcoded numbers in CCS code v5: (By Ben) conflict resolution + - res_blocks += fixed_16_16_to_u32_round_up(y_tile_minimum); + res_blocks += fixed16_to_u32_round_up(y_tile_minimum); v6: (daniels) Fix botched commit message. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Signed-off-by:Ville Syrjä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1) Reviewed-by:
-
Ville Syrjälä authored
SKL+ display engine can scan out certain kinds of compressed surfaces produced by the render engine. This involved telling the display engine the location of the color control surfae (CCS) which describes which parts of the main surface are compressed and which are not. The location of CCS is provided by userspace as just another plane with its own offset. By providing our own format information for the CCS formats, we should be able to make framebuffer_check() do the right thing for the CCS surface as well. Note that we'll return the same format info for both Y and Yf tiled format as that's what happens with the non-CCS Y vs. Yf as well. If desired, we could potentially return a unique pointer for each pixel_format+tiling+ccs combination, in which case we immediately be able to tell if any of that stuff changed by just comparing the pointers. But that does sound a bit wasteful space wise. v2: Drop the 'dev' argument from the hook v3: Include the description of the CCS surface layout v4: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason) v5: Re-drop 'dev', fix commit message, add missing drm_fourcc.h description of CCS layout. (daniels) Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Acked-by:Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v3) Reviewed-by:
-
Daniel Vetter authored
Ben Widawsky/Daniel Stone need the extended modifier support from drm-misc to be able to merge CCS support for i915.ko Signed-off-by: -
Chris Wilson authored
In the original selftest, we didn't care what the engine->id was, just that it could uniquely identify it. Later though, we started tracking the mock engines in the fixed size arrays around the drm_i915_private and so we now require their indices to be correct. This becomes an issue when using the standalone harness which runs all available tests at module load, and so we quickly assign an out-of-bounds index to an engine as we reallocate the mock GEM device between tests. It doesn't show up in igt/drv_selftest as that runs each subtest individually. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102045Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com>
-
git://anongit.freedesktop.org/git/drm-miscDave Airlie authored
UAPI Changes: - vc4: Add ioctl to allow attaching a label to a bo (Eric) - Add new format/modifier blob plane property (Ben) - armada: Use __u32/__u64 instead of uint32_t/uint64_t (Mikko) - [kinda uapi] fb_helper: Expose display_info size via fb_info (David) Core Changes: - Default gem_dumb_[map_offset|destroy] as mmap/destroy implementations (Noralf) - Simplify atomic properties by removing the helpers and handling in core (Daniel) Driver Changes: - stm: Add STM32 DSI controller driver (Phillipe) - vc4: Add HDMI CEC support (Hans) - rockchip: Refactor register init & soc version handling (Mark) - misc: Remove .load_lut, .gamma_set, .gamma_get dead code (Peter) - dw-hdmi: Add HDMI CEC support (Russell) Cc: Philippe CORNU <philippe.cornu@st.com> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: Eric Anholt <eric@anholt.net> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Mark yao <mark.yao@rock-chips.com> Cc: Peter Rosin <peda@axentia.se> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Mikko Rapeli <mikko.rapeli@iki.fi> Cc: David Lechner <david@lechnology.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> * tag 'drm-misc-next-2017-08-08' of git://anongit.freedesktop.org/git/drm-misc: (107 commits) drm: Nuke drm_atomic_legacy_backoff drm: Nuke drm_atomic_helper_connector_dpms drm: Nuke drm_atomic_helper_connector_set_property drm: Nuke drm_atomic_helper_plane_set_property drm: Nuke drm_atomic_helper_crtc_set_property drm: Handle properties in the core for atomic drivers drm: Don't update property values for atomic drivers drm/omap: Rework the rotation-on-crtc hack drm/radeon: Use the drm_driver.dumb_destroy default drm/i915: Use the drm_driver.dumb_destroy default drm/sti: Use .dumb_map_offset and .dumb_destroy defaults drm: bridge: synopsys/dw-hdmi: Provide default configuration function for HDMI 2.0 PHY drm/fb-helper: pass physical dimensions to fbdev uapi drm/armada_drm.h: use __u32 and __u64 instead of uint32_t and uint64_t drm/bridge: dw-hdmi: remove CEC engine register definitions drm/bridge: dw-hdmi: add cec driver drm/bridge: dw-hdmi: add missing cec_notifier_put drm: remove unused and redundant callbacks staging: vboxvideo: remove dead gamma lut code drm: dw-hdmi-i2s: add missing company name on Copyright ...
-
- 09 Aug, 2017 1 commit
-
-
Jim Bride authored
Bit 29 of SRD_CTL needs to have its value preserved according to the B-Spec, so right before we write out the register we go ahead and read the register and preserve the value of that bit before we write out the configured register value. v2: Spaces => tabs, minor name change, and commit message wording (Rodrigo) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Jim Bride <jim.bride@linux.intel.com> Reviewed-by:
-
- 08 Aug, 2017 14 commits
-
-
Rodrigo Vivi authored
DDI_E is not supported on CNL-U and CNL-Y When adding the initial support we noticed DDI_E wasn't supported and removed it on v4 and v5 of that patch. However for some reason I missed or put back these 2 chunks. Time to clean it up to avoid later confusion. Fixes: 8bcd3dd4 ("drm/i915/cnl: Add power wells for CNL") Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170808193237.17410-1-rodrigo.vivi@intel.com
-
Chris Wilson authored
As we may have just bound the renderstate into the GGTT for execution, we need to ensure that the GTT TLB are also flushed. On snb-gt2, this would cause a random GPU hang at the start of a new context (e.g. boot) and on snb-gt1, it was causing the renderstate batch to take ~10s. It was the GPU hang that revealed the truth, as the CS gleefully executed beyond the end of the golden renderstate batch, a good indicator for a GTT TLB miss. Fixes: 20fe17aa ("drm/i915: Remove redundant TLB invalidate on switching contexts") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.12-rc1+
-
Daniel Vetter authored
Finally all users are gone! Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
It's dead code, the core handles all this directly now. The only special case is nouveau and tda988x which used one function for both legacy modeset code and -nv50 atomic world instead of 2 vtables. But amounts to exactly the same. v2: Rebase over the panel/brideg refactorings in stm/ltdc. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Peter Senna Tschudin <peter.senna@collabora.com> Cc: Martin Donnelly <martin.donnelly@ge.com> Cc: Martyn Welch <martyn.welch@collabora.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Stefan Agner <stefan@agner.ch> Cc: Alison Wang <alison.wang@freescale.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: CK Hu <ck.hu@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Marek Vasut <marex@denx.de> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Eric Anholt <eric@anholt.net> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Yannick Fertre <yannick.fertre@st.com> Cc: Philippe Cornu <philippe.cornu@st.com> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Jeffy Chen <jeffy.chen@rock-chips.com> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Yakir Yang <kuankuan.y@gmail.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Romain Perier <romain.perier@collabora.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Hai Li <hali@codeaurora.org> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-mediatek@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: nouveau@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Cc: linux-tegra@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Cc: zain wang <wzz@rock-chips.com> Cc: Baoyou Xie <baoyou.xie@linaro.org> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Acked-by:
Archit Taneja <architt@codeaurora.org> Tested-by: Philippe Cornu <philippe.cornu@st.com> (on stm) Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Shawn Guo <shawnguo@kernel.org> Acked-by:
Noralf Trønnes <noralf@tronnes.org> Acked-by:
Vincent Abriou <vincent.abriou@st.com>
-
Daniel Vetter authored
It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_helper_connector_set_property. The only special case is nouveau which used one function for both pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2 vtables. But amounts to exactly the same. What is rather strange here is how few drivers set this up, I suspect the earlier patch to handle properties in the core did end up fixing a pile of possible issues. Signed-off-by:
-
Daniel Vetter authored
It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_plane_set_property. Signed-off-by:
Philippe Cornu <philippe.cornu@st.com> Tested-by:
Liviu Dudau <Liviu.Dudau@arm.com> Acked-by:
-
Daniel Vetter authored
It's dead code because this is now handled in the core. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com>
-
Daniel Vetter authored
The reason behind the original indirection through the helper functions was to allow existing drivers to overwrite how they handle properties. For example when a vendor-specific userspace had expectations that didn't match atomic. That seemed likely, since atomic is standardizing a _lot_ more of the behaviour of a kms driver. But 20 drivers later there's no such need at all. Worse, this forces all drivers to hook up the default behaviour, breaking userspace if they forget to do that. And it forces us to export a bunch of core function just for those helpers. And finally, these helpers are the last places using drm_atomic_legacy_backoff() and the implicit acquire_ctx. This patch here just implements the new behaviour and updates the docs. Follow-up patches will garbage-collect all the dead code. v2: Fixup docs even better! v3: Make it actually work ... v4: Drop the uses_atomic_modeset() checks from the previous patch again, since they're now moved up in the callchain. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> (v3) Reviewed-by:
-
Daniel Vetter authored
Atomic drivers only use the property value store for immutable (i.e. can't be set by userspace, but the kernel can still adjust it) properties. The only tricky part is the removal of the update in drm_atomic_helper_update_legacy_modeset_state(). This was added in commit 8c10342c (tag: topic/drm-misc-2015-07-28) Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Mon Jul 27 13:24:29 2015 +0200 drm/atomic: Update legacy DPMS state during modesets, v3. by copying it from the i915 code, where it was originally added in commit 68d34720 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Sep 6 22:08:35 2012 +0200 drm/i915: update dpms property in set_mode for the legacy modeset code. The reason we needed this hack was that i915 didn't yet set DRIVER_ATOMIC, and we checked for that instead of the newer-ish drm_drv_uses_atomic_modeset(), which avoids such troubles. With the correct feature checks this isn't needed anymore at all. Also make sure that drivers don't accidentally get this wrong by making the exported version of drm_object_property_get_value() only work for legacy drivers. Only gma500 uses it anyway. v2: Fixup the uses_atomic_modeset() checks (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Maarten Lankhorst authored
I want/need to rework the core property handling, and this hack is getting in the way. But since it's a non-standard propety only used by legacy userspace we know that this will only every be called from ioctl code. And never on some other free-standing state struct, where this old hack wouldn't work either. v2: don't forget zorder and get_property! v3: Shadow the legacy state to avoid locking issues in get_property (Maarten). v4: Review from Laurent - Move struct omap_crtc_state into omap_crtc.c - Clean up comments. - Don't forget to copy the shadowed state over on duplicate. v5: Don't forget to update the reset handler (Maarten). v6: Update omap_crtc_state shadow values in omap_crtc_atomic_check (Maarten). v7: - Fix get_property to return 0 and set value in *val (Maarten). - Update comment in set_property for changes in v6 (Maarten). Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (v4) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (v4) Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Noralf Trønnes authored
drm_gem_dumb_destroy() is the drm_driver.dumb_destroy default, so no need to set it. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1502034068-51384-16-git-send-email-noralf@tronnes.org
-
Noralf Trønnes authored
drm_gem_dumb_destroy() is the drm_driver.dumb_destroy default, so no need to set it. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Noralf Trønnes authored
This driver can use the drm_driver.dumb_destroy and drm_driver.dumb_map_offset defaults, so no need to set them. Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Signed-off-by:
-
Jose Abreu authored
Currently HDMI 2.0 PHYs do not have a default configuration function. As *some* of the HDMI 2.0 PHYs have the same register layout as the 3D PHYs we can provide the same default configuration function for both and still let user overwrite this with custom configuration function if needed. If, for some reason, the PHY is custom or has a register different register layout then custom configuration function *must* be provided in order for the system to work correctly. As we prefer the pdata provided configuration function over the internal one this change will not make any impact in custom platforms. Signed-off-by:
Jose Abreu <joabreu@synopsys.com> Tested-by:
Mark Yao <mark.yao@rock-chips.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Carlos Palminha <palminha@synopsys.com> Cc: Heiko Stübner <heiko@sntech.de> Reviewed-by:
-
- 07 Aug, 2017 9 commits
-
-
Lionel Landwerlin authored
This function is not part of the driver anymore. Signed-off-by:
-
David Lechner authored
The fbdev subsystem has a place for physical dimensions (width and height in mm) that is readable by userspace. Since DRM also knows these dimensions, pass this information to the fbdev device. This has to be done in drm_setup_crtcs_fb() instead of drm_setup_crtcs() because fb_helper->fbdev may be NULL in drm_setup_crtcs(). Signed-off-by:
David Lechner <david@lechnology.com> Signed-off-by:
-
Mikko Rapeli authored
These are defined in linux/types.h or drm/drm.h. Fixes user space compilation errors like: drm/armada_drm.h:26:2: error: unknown type name ‘uint32_t’ uint32_t handle; ^~~~~~~~ Signed-off-by:
Mikko Rapeli <mikko.rapeli@iki.fi> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Gabriel Laskar <gabriel@lse.epita.fr> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Russell King authored
We don't need the CEC engine register definitions, so let's remove them. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Tested-by:
-
Russell King authored
Add a CEC driver for the dw-hdmi hardware. Reviewed-by:
-
Hans Verkuil authored
The __dw_hdmi_remove() function was missing a call to cec_notifier_put to balance the cec_notifier_get in the probe function. Signed-off-by:
-
Peter Rosin authored
Drivers no longer have any need for these callbacks, and there are no users. Zap. Zap-zap-zzzap-p-pp-p. Acked-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
-
Peter Rosin authored
The redundant fb helpers .load_lut, .gamma_set and .gamma_get are no longer used. Remove the dead code that was not doing anything sensible anyway. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Kuninori Morimoto authored
This driver's Copyright is under Renesas Solutions Corp. This patch updates the year, because this driver was moved into synopsys folder in 2017. Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
- 04 Aug, 2017 6 commits
-
-
Chris Wilson authored
The purpose of the test was to check per-engine resets would fallback to the global reset when required, but first we actually need a test for a basic i915_handle_error()! Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170728112110.6464-1-chris@chris-wilson.co.uk
-
Russell King authored
The video setup path aways sets the clock disable register to a specific value, which has the effect of disabling the CEC engine. When we add the CEC driver, this becomes a problem. Fix this by only setting/clearing the bits that the video path needs to. Reviewed-by:
-
Russell King authored
Add CEC notifier support to the HDMI bridge driver, so that the CEC part of the IP can receive its physical address. Signed-off-by:
-
David Lechner authored
This removes the call to mipi_dbi_init() from mipi_dbi_spi_init() so that drivers can have a driver-specific implementation if needed. Suggested-by:
-
Noralf Trønnes authored
This driver can use the drm_driver.dumb_destroy and drm_driver.dumb_map_offset defaults, so no need to set them. Cc: Stefan Agner <stefan@agner.ch> Cc: Alison Wang <alison.wang@freescale.com> Signed-off-by:
Stefan Agner <stefan@agner.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1500837417-40580-8-git-send-email-noralf@tronnes.org
-
Jani Nikula authored
When we started following the backlight minimum brightness in 6dda730e ("drm/i915: respect the VBT minimum backlight brightness") we overlooked the brightness invert quirk. Even if we invert the brightness, we need to take the min limit into account. We probably missed this because the invert has only been required on gen4 for proper operation. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101127 Fixes: 6dda730e ("drm/i915: respect the VBT minimum backlight brightness") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
