- 22 Jun, 2020 2 commits
-
-
Thomas Zimmermann authored
The driver cannot suspend before it has loaded completely. So the test for device pointers is not required. Remove it. v3: * s/them/it/ in commit message Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200617080340.29584-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
The ast driver contains code paths for AST 1180 chips. The chip is not supported and the rsp code has never been tested. Simplify the driver by removing the AST 1180 code. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200617080340.29584-2-tzimmermann@suse.de
-
- 21 Jun, 2020 4 commits
-
-
Max Merchel authored
Add support for the Tianma Micro-electronics TM070JVHG33 7.0" WXGA display to panel-simple. Signed-off-by:
Max Merchel <Max.Merchel@tq-group.com> Signed-off-by:
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by:
-
Michael Krummsdorf authored
Add support for the CDTech Electronics displays S070PWS19HP-FC21 (7.0" WSVGA) and S070SWV29HG-DC44 (7.0" WVGA) to panel-simple. Signed-off-by:
Michael Krummsdorf <michael.krummsdorf@tq-group.com> Signed-off-by:
-
Matthias Schiffer authored
Add the Tianma Micro-electronics TM070JVHG33 7.0" WXGA display to the panel-simple compatible list. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Matthias Schiffer authored
Add the CDTech Electronics displays S070PWS19HP-FC21 (7.0" WSVGA) and S070SWV29HG-DC44 (7.0" WVGA) to the panel-simple compatible list. Signed-off-by:
-
- 20 Jun, 2020 6 commits
-
-
Ricardo Cañuelo authored
This fixes a bug in the calculation of the setup and hold times based on the deskew configuration. Signed-off-by:
Ricardo Cañuelo <ricardo.canuelo@collabora.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Ricardo Cañuelo authored
The tfp410 has a data de-skew feature that allows the user to compensate the skew between IDCK and the pixel data and control signals. In the driver, the setup and hold times are calculated from the de-skew value. This retrieves the deskew value from the DT using the proper datatype and range check as described by the binding (u32 from 0 to 7). This fix results from a change in the ti,tfp410 DT binding. Signed-off-by:
-
Ricardo Cañuelo authored
This changes how the 'ti,deskew' property is defined. It's now an unsigned value from 0 to 7 instead of a signed value from -4 to 3. Until the dtc carries the integer sign through to the yaml output it's easier to define signed types as unsigned. Signed-off-by:
-
Ricardo Cañuelo authored
Convert the DT binding documentation for the TI TFP410 DPI-to-DVI encoder to json-schema. Signed-off-by:
-
Dmitry Osipenko authored
The DRM panel bridge core requires connector type to be set up properly, otherwise it rejects the panel. The missing connector type problem popped up while I was trying to wrap CLAA070WP03XG panel into a DRM bridge in order to test whether panel's rotation property work properly using panel-simple driver on NVIDIA Tegra30 Nexus 7 tablet device, which uses CLAA070WP03XG display panel. The NVIDIA Tegra DRM driver recently gained DRM bridges support for the RGB output and now driver wraps directly-connected panels into DRM bridge. Hence all panels should have connector type set properly now, otherwise the panel's wrapping fails. This patch adds missing connector types for the LVDS panels that are found on NVIDIA Tegra devices: 1. AUO B101AW03 2. Chunghwa CLAA070WP03XG 3. Chunghwa CLAA101WA01A 4. Chunghwa CLAA101WB01 5. EDT ET057090DHU 6. Innolux N156BGE L21 7. Samsung LTN101NT05 Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
-
Wei Yongjun authored
It's not necessary to unregister backlight device which registered with devm_backlight_device_register(). Fixes: 12a6cbd4 ("drm/panel: otm8009a: Use new backlight API") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
- 19 Jun, 2020 7 commits
-
-
Manasi Navare authored
DP sink device sets the Ignore MSA bit in its DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to ignore the MSA video timing parameters and its ability to support seamless video timing change over a range of timing exposed by DisplayID and EDID. This is required for the sink to indicate that it is Adaptive sync capable. v3: * Fi the typo in commit message (Manasi) v2: * Rename to describe what the function does (Jani Nikula) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200619212356.19285-2-bhanuprakash.modem@intel.com
-
Colin Ian King authored
Shifting the integer value 1 is evaluated using 32-bit arithmetic and then used in an expression that expects a long value leads to a potential integer overflow. Fix this by using the BIT macro to perform the shift to avoid the overflow. Addresses-Coverity: ("Unintentional integer overflow") Fixes: ad49f860 ("drm/arm: Add support for Mali Display Processors") Signed-off-by:Colin Ian King <colin.king@canonical.com> Acked-by:
Liviu Dudau <liviu.dudau@arm.com> Signed-off-by:
-
Ben Davis authored
AFBC has a mode that guarantees use of AFBC with an uncompressed payloads, we add a new modifier to support this mode. V2: updated modifier comment Signed-off-by:
Ben Davis <ben.davis@arm.com> Acked-by:
-
Ben Davis authored
DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16 block-linear memory layouts (DRM_FORMAT_MOD_SAMSUNG_16_16_TILE). The format is similar to P010 with 4:2:0 sub-sampling but has no padding between components. Instead, luminance and chrominance samples are grouped into 4s so that each group is packed into an integer number of bytes: YYYY = UVUV = 4 * 10 bits = 40 bits = 5 bytes The '15' suffix refers to the optimum effective bits per pixel which is achieved when the total number of luminance samples is a multiple of 8. Q410 and Q401 are both 3 plane non-subsampled formats with 16 bits per component, but only 10 bits are used and 6 are padded. 'Q' is chosen as the first letter to denote 3 plane YUV444, (and is the next letter along from P which is usually 2 plane). V2: Updated block_w of NV15 to {4, 2, 0} V3: Updated commit message to include specific modifier name NV15: Tested-by:Jonas Karlman <jonas@kwiboo.se> Reviewed-by:
Brian Starkey <brian.starkey@arm.com> Signed-off-by:
-
Denis Efremov authored
Use kvfree() to free bo->sgts, because the memory is allocated with kvmalloc_array() in panfrost_mmu_map_fault_addr(). Fixes: 187d2929 ("drm/panfrost: Add support for GPU heap allocations") Cc: stable@vger.kernel.org Signed-off-by:
Denis Efremov <efremov@linux.com> Reviewed-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
Dinghao Liu authored
The caller expects panfrost_job_hw_submit() to increase runtime PM usage counter. The refcount decrement on the error branch of WARN_ON() will break the counter balance and needs to be removed. Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by:
-
Steven Price authored
The calls to panfrost_devfreq_record_busy() and panfrost_devfreq_record_idle() must be balanced to ensure that the devfreq utilisation is correctly reported. But there are two cases where this doesn't work correctly. In panfrost_job_hw_submit() if pm_runtime_get_sync() fails or the WARN_ON() fires then no call to panfrost_devfreq_record_busy() is made, but when the job times out the corresponding _record_idle() call is still made in panfrost_job_timedout(). Move the call up to ensure that it always happens. Secondly panfrost_job_timedout() only makes a single call to panfrost_devfreq_record_idle() even if it is cleaning up multiple jobs. Move the call inside the loop to ensure that the number of _record_idle() calls matches the number of _record_busy() calls. Fixes: 9e62b885 ("drm/panfrost: Simplify devfreq utilisation tracking") Acked-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by:
-
- 18 Jun, 2020 5 commits
-
-
Douglas Anderson authored
The ti_sn_bridge_gpio_set() got the return value of regmap_update_bits() but didn't check it. The function can't return an error value, but we should at least print a warning if it didn't work. This fixes a compiler warning about setting "ret" but not using it. Fixes: 27ed2b3f ("drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200612123003.v2.4.Ia4376fd88cdc6e8f8b43c65548458305f82f1d61@changeid
-
Douglas Anderson authored
This fixes a kernel doc warning due to a typo: warning: Function parameter or member 'ln_polrs' not described in 'ti_sn_bridge' Fixes: 5bebaead ("drm/bridge: ti-sn65dsi86: Implement lane reordering + polarity") Signed-off-by:
-
Douglas Anderson authored
When building we were getting an error: warning: cannot understand function prototype: 'const unsigned int ti_sn_bridge_dp_rate_lut[] = ' Arrays aren't supposed to be marked with "/**" kerneldoc comments. Fix. Fixes: a095f15c ("drm/bridge: add support for sn65dsi86 bridge driver") Signed-off-by: -
Douglas Anderson authored
The kernel test robot noted that if "OF" is defined (which is needed to select DRM_TI_SN65DSI86 at all) but not OF_GPIO that we'd get compile failures because some of the members that we access in "struct gpio_chip" are only defined "#if defined(CONFIG_OF_GPIO)". All the GPIO bits in the driver are all nicely separated out. We'll guard them with the same "#if defined" that the header has and add a little stub function if OF_GPIO is not defined. Fixes: 27ed2b3f ("drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Krzysztof Kozlowski authored
There is no point to print deferred probe (and its failures to get resources) as an error. Also there is no need to print regulator errors twice. In case of multiple probe tries this would pollute the dmesg. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by:
-
- 17 Jun, 2020 1 commit
-
-
Paul Kocialkowski authored
Compared to its predecessors, the PX30 VOP has a different register layout for enabling per-pixel alpha. Instead of src_alpha_ctl and dst_alpha_ctl, there is a single alpha control register. This register takes some fields from src_alpha_ctl, but with a different layout. Add support for the required fields to the PX30 VOP window descriptions, which makes per-pixel-alpha formats behave correctly. Signed-off-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200416140526.262533-1-paul.kocialkowski@bootlin.com
-
- 16 Jun, 2020 4 commits
-
-
Daniel Vetter authored
I broke that in my refactoring: commit 7d2cd72a Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri May 29 16:05:42 2020 +0200 drm/shmem-helpers: Simplify dma-buf importing I'm not entirely sure of the history here, but I suspect that in one of the rebases or when applying the patch I moved the hunk from drm_gem_shmem_prime_import_sg_table(), where it should be, to drm_gem_shmem_create_with_handle(), which is totally wrong. Remedy this. Thanks for Thomas for the crucial hint in debugging this. Tested-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616114723.2363268-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
I broke that in my refactoring: commit 7d2cd72a Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri May 29 16:05:42 2020 +0200 drm/shmem-helpers: Simplify dma-buf importing Tested-by:
-
Masanari Iida authored
This patch fix a spelling typo in test-drm_mm.c Signed-off-by:
Masanari Iida <standby24x7@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Allows us to remove a bit of cleanup code. Reviewed-by:
-
- 15 Jun, 2020 6 commits
-
-
Emil Velikov authored
Platform drivers now have the option to have the platform core create and remove any needed sysfs attribute files. So take advantage of that and do not register "by hand" a sysfs file. Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Emil Velikov authored
Add the COMPILE_TEST conditional, so that people can at least build test the drivers. Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Emil Velikov authored
Add some information about pre-atomic modeset properties alongside a list of suggestions how to handle the different instances. Signed-off-by:
-
Emil Velikov authored
Currently the ret handling is all over the place - with two redundant assignments and another one addressed earlier. Use the exact same flow in both functions. v2: straighten the code flow, instead of just removing the assignments Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Emil Velikov authored
The function always returns zero (success). Ideally we'll remove it all together - although that's requires a little more work. For now, we can drop the return type and simplify the drm core code surrounding it. v2: remove redundant assignment (Sam) Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Roland Scheidegger <sroland@vmware.com> Signed-off-by:
Roland Scheidegger <sroland@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200530124640.4176323-1-emil.l.velikov@gmail.com
-
Christian König authored
When the current entry is rejected as candidate for the search it does not mean that we can abort the subtree search. It is perfectly possible that only the alignment, but not the size is the reason for the rejection. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Nirmoy Das <nirmoy.das@amd.com> Link: https://patchwork.freedesktop.org/patch/369394/
-
- 11 Jun, 2020 5 commits
-
-
Imre Deak authored
Atm, a pending delayed destroy work during module removal will be canceled, leaving behind MST ports, mstbs. Fix this by using a dedicated workqueue which will be drained of requeued items as well when destroying it. v2: - Check if wq is NULL before calling destroy_workqueue(). Cc: Lyude Paul <lyude@redhat.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200610134704.25270-1-imre.deak@intel.com
-
Imre Deak authored
During the initial MST probing an MST port's I2C device will be registered using the kdev of the DRM device as a parent. Later after MST Connection Status Notifications this I2C device will be re-registered with the kdev of the port's connector. This will also move inconsistently the I2C device's sysfs entry from the DRM device's sysfs dir to the connector's dir. Fix the above by keeping the DRM kdev as the parent of the I2C device. Ideally the connector's kdev would be used as a parent, similarly to non-MST connectors, however that needs some more refactoring to ensure the connector's kdev is already available early enough. So keep the existing (initial) behavior for now. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Imre Deak authored
The WARN below triggers during the removal of an MST port. The problem is that the parent device's (the connector's kdev) sysfs directory is removed recursively when the connector is unregistered (even though the I2C device holds a reference on the parent device). To fix this set first the Peer Device Type to none which will remove the I2C device. Note that atm, inconsistently, the parent of the I2C device is initially set to the DRM kdev and after a Connection Status Notification the parent may be reset to be the connector's kdev. This problem is addressed by the next patch. [ 4462.989299] ------------[ cut here ]------------ [ 4463.014940] sysfs group 'power' not found for kobject 'i2c-24' [ 4463.034664] WARNING: CPU: 0 PID: 970 at fs/sysfs/group.c:281 sysfs_remove_group+0x71/0x80 [ 4463.044357] Modules linked in: snd_hda_intel i915 drm_kms_helper(O) drm netconsole snd_hda_codec_hdmi mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul snd_intel_dspcf g crc32_pclmul snd_hda_codec snd_hwdep ghash_clmulni_intel snd_hda_core asix usbnet kvm_intel mii i2c_algo_bit snd_pcm syscopyarea sysfillrect e1000e sysimgblt fb_sys_fops prim e_numbers ptp pps_core i2c_i801 r8169 mei_me realtek mei [last unloaded: drm] [ 4463.044399] CPU: 0 PID: 970 Comm: kworker/0:2 Tainted: G O 5.7.0+ #172 [ 4463.044402] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP [ 4463.044423] Workqueue: events drm_dp_delayed_destroy_work [drm_kms_helper] [ 4463.044428] RIP: 0010:sysfs_remove_group+0x71/0x80 [ 4463.044431] Code: 48 89 df 5b 5d 41 5c e9 cd b6 ff ff 48 89 df e8 95 b4 ff ff eb cb 49 8b 14 24 48 8b 75 00 48 c7 c7 20 0f 3f 82 e8 9f c5 d7 ff <0f> 0b 5b 5d 41 5c c3 0f 1f 84 00 00 00 00 00 48 85 f6 74 31 41 54 [ 4463.044433] RSP: 0018:ffffc900018bfbf0 EFLAGS: 00010282 [ 4463.044436] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001 [ 4463.044439] RDX: 0000000080000001 RSI: ffff88849e828f38 RDI: 00000000ffffffff [ 4463.052970] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:100:plane 2B] 00000000c2160caa state to 00000000d172564a [ 4463.070533] RBP: ffffffff820cea20 R08: ffff88847f4b8958 R09: 0000000000000000 [ 4463.070535] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848a725018 [ 4463.070537] R13: 0000000000000000 R14: ffffffff827090e0 R15: 0000000000000002 [ 4463.070539] FS: 0000000000000000(0000) GS:ffff88849e800000(0000) knlGS:0000000000000000 [ 4463.070541] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4463.070543] CR2: 00007fdf8a756538 CR3: 0000000489684001 CR4: 0000000000760ef0 [ 4463.070545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4463.070547] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4463.070549] PKRU: 55555554 [ 4463.070551] Call Trace: [ 4463.070560] device_del+0x84/0x400 [ 4463.070571] cdev_device_del+0x10/0x30 [ 4463.070578] put_i2c_dev+0x69/0x80 [ 4463.070584] i2cdev_detach_adapter+0x2e/0x60 [ 4463.070591] notifier_call_chain+0x34/0x90 [ 4463.070599] blocking_notifier_call_chain+0x3f/0x60 [ 4463.070606] device_del+0x7c/0x400 [ 4463.087817] ? lockdep_init_map_waits+0x57/0x210 [ 4463.087825] device_unregister+0x11/0x60 [ 4463.087829] i2c_del_adapter+0x249/0x310 [ 4463.087846] drm_dp_port_set_pdt+0x6b/0x2c0 [drm_kms_helper] [ 4463.087862] drm_dp_delayed_destroy_work+0x2af/0x350 [drm_kms_helper] [ 4463.087876] process_one_work+0x268/0x600 [ 4463.105438] ? __schedule+0x30c/0x920 [ 4463.105451] worker_thread+0x37/0x380 [ 4463.105457] ? process_one_work+0x600/0x600 [ 4463.105462] kthread+0x140/0x160 [ 4463.105466] ? kthread_park+0x80/0x80 [ 4463.105474] ret_from_fork+0x24/0x50 Cc: <stable@vger.kernel.org> Signed-off-by:
-
Imre Deak authored
Some TypeC -> native DP adapters, at least the Club 3D CAC-1557 adapter, incorrectly filter out HPD short pulses with a duration less than ~540 usec, leading to MST probe failures. According to the DP Standard 2.0 section 5.1.4: - DP sinks should generate short pulses in the 500 usec -> 1 msec range - DP sources should detect short pulses in the 250 usec -> 2 msec range According to the DP Alt Mode on TypeC Standard section 3.9.2, adapters should detect and forward short pulses according to how sources should detect them as specified in the DP Standard (250 usec -> 2 msec). Based on the above filtering out short pulses with a duration less than 540 usec is incorrect. To make such adapters work add support for a driver polling on MST inerrupt flags, and wire this up in the i915 driver. The sink can clear an interrupt it raised after 110 msec if the source doesn't respond, so use a 50 msec poll period to avoid missing an interrupt. Polling of the MST interrupt flags is explicitly allowed by the DP Standard. This fixes MST probe failures I saw using this adapter and a DELL U2515H monitor. v2: - Fix the wait event timeout for the no-poll case. v3 (Ville): - Fix the short pulse duration limits in the commit log prescribed by the DP Standard. - Add code comment explaining why/how polling is used. - Factor out a helper to schedule the port's hpd irq handler and move it to the rest of hotplug handlers. - Document the new MST callback. - s/update_hpd_irq_state/poll_hpd_irq/ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Make the locking look symmetric with the unlocking. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
