- 09 Jan, 2020 15 commits
-
-
Ville Syrjälä authored
When moving the pipe disable & co. function calls from haswell_crtc_disable() into the encoder .post_disable() hooks I neglected to account for the MST vs. DDI interactions properly. This now leads us to call these functions two times for the last MST stream (once from the MST code and a second time from the DDI code). The calls from the DDI code should only be done for SST and not MST. Add the proper check for that. This results in an MCE on ICL. My vague theory is that we turn off the transcoder clock from the MST code and then we proceed to touch something in the DDI code which still depends on that clock causing the hardware to become upset. Though I can't really explain why Stan's hack of omitting the pipe disable in the MST code would avoid the MCE since we should still be turning off the transcoder clock. But maybe there's something magic in the hw that keeps the clock on as long as the pipe is on. Or maybe the clock isn't the problem and we now touch something in the DDI disable code that really does need the pipe to be still enabled. v2: Rebase to latest drm-tip Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Reported-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/901 Fixes: 773b4b54 ("drm/i915: Move stuff from haswell_crtc_disable() into encoder .post_disable()") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108144550.29280-1-ville.syrjala@linux.intel.comReviewed-by:
José Roberto de Souza <jose.souza@intel.com>
-
Jani Nikula authored
Sync with drm-next to get the new logging macros, among other things. Signed-off-by:Jani Nikula <jani.nikula@intel.com>
-
Ma Feng authored
Fixes coccicheck warning: drivers/gpu/drm/i915/display/intel_crt.c:1066:1-28: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/display/intel_crt.c:928:2-29: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/display/intel_crt.c:443:2-29: WARNING: Assignment of 0/1 to bool variable Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Ma Feng <mafeng.ma@huawei.com> Signed-off-by:
-
Ma Feng authored
Fixes coccicheck warning: drivers/gpu/drm/i915/display/intel_dp.c:4950:1-33: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/display/intel_dp.c:4906:1-33: WARNING: Assignment of 0/1 to bool variable Reported-by:
-
Ma Feng authored
Fixes coccicheck warning: drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to bool variable Reported-by:
-
Chris Wilson authored
Now that we have moved the runtime-pm management out of intel_context_acctive_acquire, and that itself out of ce->ops->pin(), no explicit runtime pm wakeref is required in intel_context_pin(). Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200109085717.873326-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
While this is encroaching on midlayer territory, having already made the state allocation a previous step in pinning, we can now pull the common intel_context_active_acquire() into intel_context_pin() itself. This is a prelude to make the activation a separate step inside pinning, outside of the ce->pin_mutex Signed-off-by:
-
Chris Wilson authored
Allow for knowledgeable users to preallocate the context state, and to separate the allocation step from the pinning step during intel_context_pin() Signed-off-by:
-
Chris Wilson authored
Since we now allow the intel_context_unpin() to run unserialised, we risk our operations under the intel_context_lock_pinned() being run as the context is unpinned (and thus invalidating our state). We can atomically acquire the pin, testing to see if it is pinned in the process, thus ensuring that the state remains consistent during the course of the whole operation. Fixes: 84135022 ("drm/i915/gt: Drop mutex serialisation between context pin/unpin") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200109085142.871563-1-chris@chris-wilson.co.uk
-
Tvrtko Ursulin authored
This reverts commit 08fff7ae. For some yet unexplained reason not having this improves stability of some media workloads. Promise is that the media hang will be root caused properly and in the meantime absence of this workaround is unlikely to cause problems. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Sudeep Dutt <sudeep.dutt@intel.com> Cc: Francesco Balestrieri <francesco.balestrieri@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tony Ye <tony.ye@intel.com> Acked-by:
-
Chris Wilson authored
Access through the GGTT (iomap) into the vma does require the device to be awake. However, we often take the i915_vma_pin_iomap() as an early preparatory step that is long before we use the iomap. Asserting that the device is awake at pin time does not protect us, and is merely a nuisance. Signed-off-by:
-
Chris Wilson authored
If we have no fence and desire no fence on the vma, return before we try and take the vm->mutex. Signed-off-by:
-
Chris Wilson authored
intel_timeline_enter() has been decoupled from intel_timeline_pin() and both enter/exit & pin/unpin are allowed [read expected] to run concurrently with one another. The assertion that they had better not is stale. Closes: https://gitlab.freedesktop.org/drm/intel/issues/940 References: a6edbca7 ("drm/i915/gt: Close race between engine_park and intel_gt_retire_requests") Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for v5.6: UAPI Changes: - Allow overriding number of bootup penguins in fbcon using fbcon=logo-count:n. Cross-subsystem Changes: - fbdev fixes for mmp, and make it work with CONFIG_COMPILE_TEST. - Use devm_platform_ioremap_resource in fbdev drivers. - Various small fbdev fixes. Core Changes: - Support scanline alignment for dumb buffers. - Add atomic_check() hook to bridge ops, to support bus format negotiation. - Add gem_create_object() to vram helpers. Driver Changes: - Rockchip: Add support for PX30. - Use generic fbdev code and dumb helpers in hisilicon/hibmc. - Add support for Leadtek LTK500HD1829 panel, and xinpeng XPP055C272. - Clock fixes for atmel-hlcdc. - Various smaller fixes to all drivers. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8eff1e3f-ef0a-2dd9-9a14-6273b1d6f963@linux.intel.com
-
Laurent Pinchart authored
The new helper drm_of_lvds_get_dual_link_pixel_order() introduced in commit 65290075 has a fallback stub when CONFIG_OF is not set, but the stub is declared in drm_of.h without a static inline. This causes multiple definitions of the function to be linked when the CONFIG_OF option isn't set. Fix it by making the stub static inline. Fixes: 65290075 ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order") Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
-
- 08 Jan, 2020 3 commits
-
-
José Roberto de Souza authored
Capturing the restrictions of the BSpec pages bellow: SKL and CNL do not support MST in DDI E, DDI E only support 2 lanes and it is mostly used to support a 4 lanes eDP panel together with DDI A. ICL's DDI E support MST just like other ports but DDI A is still eDP and MIPI only. TGL supports MST in any DDI, including DDI A but TGL has it's own ddi_pre_enable_dp function already without any warning. [ 215.579791] ------------[ cut here ]------------ [ 215.579794] WARN_ON(is_mst && (port == PORT_A || port == PORT_E)) [ 215.579875] WARNING: CPU: 0 PID: 268 at drivers/gpu/drm/i915/display/intel_ddi.c:3576 intel_ddi_pre_enable+0x124/0xea0 [i915] [ 215.579878] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 btusb btrtl btbcm btintel bluetooth prime_numbers snd_hda_intel snd_intel_dspcfg snd_hda_codec e1000e snd_hwdep snd_hda_core asix mei_hdcp cdc_ether x86_pkg_temp_thermal mei_me snd_pcm r8152 coretemp usbnet mei crct10dif_pclmul mii ptp ecdh_generic crc32_pclmul i2c_i801 ecc pps_core ghash_clmulni_intel thunderbolt [ 215.579905] CPU: 0 PID: 268 Comm: kworker/0:2 Tainted: G W 5.4.0-rc8-zeh+ #1307 [ 215.579907] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3201.A00.1905140358 05/14/2019 [ 215.579912] Workqueue: events_long drm_dp_mst_link_probe_work [ 215.579975] RIP: 0010:intel_ddi_pre_enable+0x124/0xea0 [i915] [ 215.579978] Code: ff 8b 7c 24 10 89 44 24 30 85 ff 74 1f f7 44 24 18 fb ff ff ff 75 15 48 c7 c6 98 fa 48 a0 48 c7 c7 d3 df 4a a0 e8 cf d5 d0 e0 <0f> 0b 0f b6 4c 24 2c 41 8b b5 04 06 00 00 4c 89 e7 41 0f b6 95 0c [ 215.579980] RSP: 0018:ffffc90001a5f990 EFLAGS: 00010286 [ 215.579984] RAX: 0000000000000000 RBX: ffff88848356a000 RCX: 0000000000000000 [ 215.579986] RDX: 0000000000001df1 RSI: ffff88849340c998 RDI: ffffffff821489c5 [ 215.579989] RBP: ffff88848356a000 R08: 00000000c021a419 R09: 0000000000000000 [ 215.579991] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848356a118 [ 215.579994] R13: ffff88847f39c000 R14: ffff88847fe70000 R15: ffff88848356a000 [ 215.579996] FS: 0000000000000000(0000) GS:ffff88849f800000(0000) knlGS:0000000000000000 [ 215.579999] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 215.580001] CR2: 000055d3d5a26bc0 CR3: 0000000480ba6005 CR4: 0000000000760ef0 [ 215.580004] PKRU: 55555554 [ 215.580006] Call Trace: [ 215.580014] ? drm_dp_mst_topology_put_port+0x6f/0x130 [ 215.580072] intel_mst_pre_enable_dp+0x14b/0x170 [i915] [ 215.580129] intel_encoders_pre_enable+0x76/0x90 [i915] [ 215.580191] haswell_crtc_enable+0x84/0x880 [i915] [ 215.580266] intel_update_crtc+0x1e4/0x200 [i915] [ 215.580333] skl_commit_modeset_enables+0x287/0x420 [i915] [ 215.580405] intel_atomic_commit_tail+0x332/0x14e0 [i915] [ 215.580410] ? queue_work_on+0x41/0x70 [ 215.580489] intel_atomic_commit+0x31e/0x350 [i915] [ 215.580500] drm_client_modeset_commit_atomic+0x18b/0x220 [ 215.580523] drm_client_modeset_commit_force+0x4d/0x180 [ 215.580531] drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0 [ 215.580538] drm_fb_helper_set_par+0x27/0x50 [ 215.580543] drm_fb_helper_hotplug_event.part.0+0xa7/0xc0 [ 215.580549] drm_kms_helper_hotplug_event+0x21/0x30 [ 215.580553] process_one_work+0x25b/0x5b0 [ 215.580566] worker_thread+0x4b/0x3b0 [ 215.580578] kthread+0x100/0x140 [ 215.580581] ? process_one_work+0x5b0/0x5b0 [ 215.580585] ? kthread_park+0x80/0x80 [ 215.580591] ret_from_fork+0x24/0x50 [ 215.580603] irq event stamp: 1393930 [ 215.580606] hardirqs last enabled at (1393929): [<ffffffff8112a013>] vprintk_emit+0x143/0x330 [ 215.580609] hardirqs last disabled at (1393930): [<ffffffff81001cfa>] trace_hardirqs_off_thunk+0x1a/0x20 [ 215.580613] softirqs last enabled at (1393434): [<ffffffff81c00389>] __do_softirq+0x389/0x47f [ 215.580618] softirqs last disabled at (1393423): [<ffffffff810b7199>] irq_exit+0xa9/0xc0 [ 215.580621] ---[ end trace afd44ea9caa6373e ]--- BSpec: 4217 BSpec: 14004 BSpec: 20584 BSpec: 50583 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
José Roberto de Souza authored
Talked with HW team and this is a left over, driver should not program clockgating, mg or dekel firmware is reponsible for any clockgating programing. Also removing the register and bits definition related to clockgating. v2: Added WARN_ON v3: Only calling icl_phy_set_clock_gating() on intel_ddi_pre_enable_hdmi for GEN11 v4: ICL should also not program clockgating (thanks Matt for catching this) BSpec issue: 20885 BSpec: 49292 BSpec: 21735 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
José Roberto de Souza authored
Recent improvements in the state tracking in i915 caused PSR to not be enabled when reusing firmware/BIOS modeset, this is due to all initial commits returning ealier in intel_atomic_check() as needs_modeset() is always false. To fix that here forcing the state compute phase in CRTC that is driving the eDP that supports PSR once. Enable or disable PSR do not require a fullmodeset, so user will still experience glitch free boot process plus the power savings that PSR brings. It was tried to set mode_changed in intel_initial_commit() but at this point the connectors are not registered causing a crash when computing encoder state. v2: - removed function return - change arguments to match intel_hdcp_atomic_check v3: - replaced drm includes in intel_psr.h by forward declaration(Jani) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112253 Reported-by: <s.zharkoff@gmail.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200106152128.195171-1-jose.souza@intel.com
-
- 07 Jan, 2020 21 commits
-
-
Chris Wilson authored
It is highly unlikely, but still conceivable, that we submit a context with the same GGTT address as last active on the HW. In this case, with a matching LRCA, the HW would not restore the new context image causing a potential violation of our context isolation. Signed-off-by:
-
Matthew Auld authored
Attempt to split i915_gem_gtt.[ch] into more manageable chunks. Suggested-by:
Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Chris Wilson authored
In order to avoid a double cleanup on error, take ownership of engine->release past the point of no [error] return. Reported-by:
-
José Roberto de Souza authored
This loop was added directly to intel_atomic_check() to be used by all other features that have external pipe dependencies, so using it and removing intel_atomic_check_synced_crtcs(). After this changes is_trans_port_sync_master() it not used anywhere, so removing it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200106142823.145260-1-jose.souza@intel.com
-
Dan Carpenter authored
There is a cut and paste bug so we return the wrong error code. Fixes: a603f5bd ("drm/i915/dp: Make sure all tiled connectors get added to the state with full modeset") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
YueHaibing authored
Fix build error: ./drivers/gpu/drm/i915/selftests/i915_random.h: In function i915_prandom_u32_max_state: ./drivers/gpu/drm/i915/selftests/i915_random.h:48:23: error: implicit declaration of function mul_u32_u32; did you mean mul_u64_u32_div? [-Werror=implicit-function-declaration] return upper_32_bits(mul_u32_u32(prandom_u32_state(state), ep_ro)); Reported-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
-
Dhinakaran Pandiyan authored
Detect the modifier corresponding to media compression to enable display decompression for YUV and xRGB packed formats. A new modifier is added so that the driver can distinguish between media and render compressed buffers. Unlike render decompression, plane 6 and plane 7 do not support media decompression. v2: Fix checkpatch warnings on code style (Lucas) From DK: Separate modifier array for planes that cannot decompress media (Ville) v3: Support planar formats v4: Switch plane order v5: - Use format block descriptors to get CCS subsampling calculation right everywhere. - Extend the plane state normal view array to accommodate 4 color planes. - Use helpers to convert between main and CCS planes. v6: Add missing packed YUV formats to the MC format list. (Yang) v7: Align UV planes to tile-row size. Cc: Nanley G Chery <nanley.g.chery@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Yang A Shi <yang.a.shi@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191231233756.18753-8-imre.deak@intel.com
-
Dhinakaran Pandiyan authored
addfb() uAPI has supported four planes for a while now, make format_info compatible with that. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191231233756.18753-7-imre.deak@intel.com
-
Dhinakaran Pandiyan authored
Gen-12 display can decompress surfaces compressed by the media engine, add a new modifier as the driver needs to know the surface was compressed by the media or render engine. v2: Update code comment describing the color plane order for YUV semiplanar formats. Cc: Nanley G Chery <nanley.g.chery@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: -
Imre Deak authored
As intel_fb_plane_get_subsampling() returns the subsampling factor wrt. its main plane, for a CCS plane we need to apply both the main and the CCS plane's subsampling factor on the FB's dimensions to get the CCS plane's dimensions. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Imre Deak authored
Print a debug message if the FB plane[0] offset is not 0 as expected, to help understainding an add FB IOCTL fail. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Imre Deak authored
Currently the GGTT offset of a UV plane in a semiplanar YUV FB is tile size (4kB) aligned. I noticed, that enforcing only this alignment leads oddly to random memory corruptions on TGL while scanning out Y-tiled FBs. This issue can be easily reproduced with a UV plane offset that is not aligned to the plane's tile row size. Some experiments showed the correct alignment to be tile row size indeed. This also makes sense, since the de-tiling fence created for the object - with its own stride and so "left" and "right" edge - applies to all the planes in the FB, so each tile row of all planes should be tile row aligned. In fact BSpec requires this alignment since SKL. On SKL we may enforce this due to the AUX plane x,y coords check, but on ICL and TGL we don't. For now enforce this only on TGL; I can follow up with any necessary change for ICL after more tests. BSpec requires a stricter alignment for linear UV planes too (kind of a tile row alignment), but it's unclear whether that's really needed (couldn't be explained with the de-tiling fence as above) and enforcing that could break existing user space; so avoid that too for now until more tests. v2: - Clarify the commit log wrt. the address space the alignment applies to. (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
At least one framebuffer plane on TGL - the UV plane of YUV semiplanar FBs - requires a non-power-of-2 alignment, so add support for this. This new alignment restriction applies only to an offset within an FB, so the GEM buffer itself containing the FB must still be power-of-2 aligned. Add a check for this (in practice plane 0, since the plane 0 offset must be 0). v2: - Fix WARN check for alignment=0. v3: - Return error for alignment programming bugs. (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Thomas Zimmermann authored
For hardware that does not interpret the startadd field correctly, add the module parameter 'hw_bug_no_startadd', which enables the workaround. v3: * style and typo fixes v2: * ask user for feedback if the option is active Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: John Donnelly <john.p.donnelly@oracle.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191126101950.11989-1-tzimmermann@suse.de
-
Thomas Zimmermann authored
Drivers that what to allocate VRAM GEM objects with additional fields can now do this by implementing struct drm_driver.gem_create_object. v3: * separately check allocation failure in if/else branches before upcast to gbo v2: * only cast to gbo within if branch; set gbo directly in else branch Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200106125745.13797-9-tzimmermann@suse.de
-
Thomas Zimmermann authored
TTM is an implementation detail of the VRAM helpers and therefore shouldn't be exposed to the callers. There's only one correct value for the BO device anyway, which is the one stored in the DRM device. So remove struct ttm_bo_device from the VRAM-helper interface and use the device's VRAM manager unconditionally. The GEM initializer function fails if the VRAM manager has not been initialized. Signed-off-by:
-
Thomas Zimmermann authored
The flag 'interruptible', which is passed to various functions, is always set to be false. Remove it and hard-code the value. Signed-off-by:
Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
-
Boris Brezillon authored
drm_bridge_state is extended to describe the input and output bus configurations. These bus configurations are exposed through the drm_bus_cfg struct which encodes the configuration of a physical bus between two components in an output pipeline, usually between two bridges, an encoder and a bridge, or a bridge and a connector. The bus configuration is stored in drm_bridge_state separately for the input and output buses, as seen from the point of view of each bridge. The bus configuration of a bridge output is usually identical to the configuration of the next bridge's input, but may differ if the signals are modified between the two bridges, for instance by an inverter on the board. The input and output configurations of a bridge may differ if the bridge modifies the signals internally, for instance by performing format conversion, or*modifying signals polarities. Bus format negotiation is automated by the core, drivers just have to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they want to take part to this negotiation. Negotiation happens in reverse order, starting from the last element of the chain (the one directly connected to the display) up to the first element of the chain (the one connected to the encoder). During this negotiation all supported formats are tested until we find one that works, meaning that the formats array should be in decreasing preference order (assuming the driver has a preference order). Note that the bus format negotiation works even if some elements in the chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks. In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets the previous bridge element decide what to do (most of the time, bridge drivers will pick a default bus format or extract this piece of information from somewhere else, like a FW property). Signed-off-by:Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed by: Jernej Skrabec <jernej.skrabec@siol.net> Tested-by:
Jonas Karlman <jonas@kwiboo.se> [narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format] Link: https://patchwork.freedesktop.org/patch/msgid/20200106143409.32321-5-narmstrong@baylibre.com
-
Boris Brezillon authored
So that bridge drivers have a way to check/reject an atomic operation. The drm_atomic_bridge_chain_check() (which is just a wrapper around the ->atomic_check() hook) is called in place of drm_bridge_chain_mode_fixup() (when ->atomic_check() is not implemented, the core falls back on ->mode_fixup(), so the behavior should stay the same for existing bridge drivers). Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Boris Brezillon authored
This way the drm_bridge_funcs interface is consistent with the rest of the subsystem. The only driver implementing those hooks (analogix DP) is patched too. Signed-off-by:
-
Boris Brezillon authored
One of the last remaining objects to not have its atomic state. This is being motivated by our attempt to support runtime bus-format negotiation between elements of the bridge chain. This patch just paves the road for such a feature by adding a new drm_bridge_state object inheriting from drm_private_obj so we can re-use some of the existing state initialization/tracking logic. Signed-off-by:
-
- 06 Jan, 2020 1 commit
-
-
Claudiu Beznea authored
This reverts commit d2c755e66617620b729041c625a6396c81d1231c ("drm: atmel-hlcdc: enable sys_clk during initalization."). With commit "drm: atmel-hlcdc: enable clock before configuring timing engine" there is no need for this patch. Code is also simpler. Cc: Sandeep Sheriker Mallikarjun <sandeepsheriker.mallikarjun@microchip.com> Signed-off-by:Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by:
-
