- 19 May, 2020 6 commits
-
-
Thomas Zimmermann authored
The function now only takes the device structure, and the old and new framebuffers. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Tested-by:
John Donnelly <John.p.donnelly@oracle.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Emil Velikov <emil.velikov@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-4-tzimmermann@suse.de
-
Thomas Zimmermann authored
All register names and fields are now named according to the MGA programming manuals. The function doesn't need the CRTC, so callers pass in the device structure directly. The logging now uses device-specific macros. The original implementation busy-waited for the VSYNC flag to go up, to synchronize the page flip with the display's vblank. This code has been moved to mga_crtc_mode_set_base(). It's still present in the non-atomic code paths, but won't be used in atomic commits. With atomic, we should use interrupts to synchronize with vblanks. v3: * clarify commit message wrt. vblank busy-waiting v2: * use to_mga_device() * use MiB instead of MB * replace empty while loop with do-while, fixes checkpatch warning * replace uint{8,32}_t with u{8,32} Signed-off-by: -
Thomas Zimmermann authored
The HW cursor of Matrox G200 cards only supports a 16-color palette format. Univeral planes require at least ARGB or a similar component- based format, so remove the HW cursor. Alternatively, the driver could dither a cursor image from ARGB to 16 colors. But this does not produce pleasent-looking results in general, so it's useless for modern compositors. Without HW support, compositors will use software rendering. Signed-off-by:
-
Tomi Valkeinen authored
struct platform_driver panel_driver is only used from tilcdc_panel.c, so it can be static. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429104234.18910-3-tomi.valkeinen@ti.comReviewed-by:
Jyri Sarha <jsarha@ti.com> Acked-by:
-
Tomi Valkeinen authored
tilcdc_plane_atomic_check() exits if state->fb == NULL, so no need to check it again later. Signed-off-by:
-
Tomi Valkeinen authored
If videomode_from_timings() returns true, the mode allocated with drm_mode_create will be leaked. Also, the return value of drm_mode_create() is never checked, and thus could cause NULL deref. Fix these two issues. Signed-off-by:
-
- 18 May, 2020 11 commits
-
-
Douglas Anderson authored
The ti-sn65dsi86 MIPI DSI to eDP bridge chip supports arbitrary remapping of eDP lanes and also polarity inversion. Both of these features have been described in the device tree bindings for the device since the beginning but were never implemented in the driver. Implement both of them. Part of this change also allows you to (via the same device tree bindings) specify to use fewer than the max number of DP lanes that the panel reports. This could be useful if your display supports more lanes but only a few are hooked up on your board. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Douglas Anderson authored
If the rate in our table is _equal_ to the rate we want then it's OK to pick it. It doesn't need to be greater than the one we want. Fixes: a095f15c ("drm/bridge: add support for sn65dsi86 bridge driver") Signed-off-by:
-
Douglas Anderson authored
The AUX channel transfer error bits in the status register are latched and need to be cleared. Clear them before doing our transfer so we don't see old bits and get confused. Without this patch having a single failure would mean that all future transfers would look like they failed. Fixes: b814ec6d ("drm/bridge: ti-sn65dsi86: Implement AUX channel") Signed-off-by:
-
Douglas Anderson authored
The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP because of excessive debouncing in hardware. Specifically there is no way to disable the debouncing and for eDP debouncing hurts you because HPD is just used for knowing when the panel is ready, not for detecting physical plug events. Currently the driver in Linux just assumes that nobody has HPD hooked up. It relies on folks setting the "no-hpd" property in the panel node to specify that HPD isn't hooked up and then the panel driver using this to add some worst case delays when turning on the panel. Apparently it's also useful to specify "no-hpd" in the bridge node so that the bridge driver can make sure it's doing the right thing without peeking into the panel [1]. This would be used if anyone ever found it useful to implement support for the HW HPD pin on the bridge. Let's add this property to the bindings. NOTES: - This is somewhat of a backward-incompatible change. All current known users of ti-sn65dsi86 didn't have "no-hpd" specified in the bridge node yet none of them had HPD hooked up. This worked because the current Linux driver just assumed that HPD was never hooked up. We could make it less incompatible by saying that for this bridge it's assumed HPD isn't hooked up _unless_ a property is defined, but "no-hpd" is much more standard and it's unlikely to matter unless someone quickly goes and implements HPD in the driver. - It is sensible to specify "no-hpd" at the bridge chip level and specify "hpd-gpios" at the panel level. That would mean HPD is hooked up to some other GPIO in the system, just not the hardware HPD pin on the bridge chip. [1] https://lore.kernel.org/r/20200417180819.GE5861@pendragon.ideasonboard.comSigned-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Douglas Anderson authored
This moves the bindings over, based a lot on toshiba,tc358768.yaml. Unless there's someone known to be better, I've set the maintainer in the yaml as the first person to submit bindings. Signed-off-by:
-
Douglas Anderson authored
The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can be used as GPIOs in a system. Each pin can be configured as input, output, or a special function for the bridge chip. These are: - GPIO1: SUSPEND Input - GPIO2: DSIA VSYNC - GPIO3: DSIA HSYNC or VSYNC - GPIO4: PWM Let's expose these pins as GPIOs. A few notes: - Access to ti-sn65dsi86 is via i2c so we set "can_sleep". - These pins can't be configured for IRQ. - There are no programmable pulls or other fancy features. - Keeping the bridge chip powered might be expensive. The driver is setup such that if all used GPIOs are only inputs we'll power the bridge chip on just long enough to read the GPIO and then power it off again. Setting a GPIO as output will keep the bridge powered. - If someone releases a GPIO we'll implicitly switch it to an input so we no longer need to keep the bridge powered for it. Because of all of the above limitations we just need to implement a bare-bones GPIO driver. The device tree bindings already account for this device being a GPIO controller so we only need the driver changes for it. NOTE: Despite the fact that these pins are nominally muxable I don't believe it makes sense to expose them through the pinctrl interface as well as the GPIO interface. The special functions are things that the bridge chip driver itself would care about and it can just configure the pins as needed. Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
-
Chris Wilson authored
drivers/gpu/drm/drm_dp_mst_topology.c:2898:6: warning: symbol 'drm_dp_send_clear_payload_id_table' was not declared. Should it be static? drivers/gpu/drm/drm_dp_mst_topology.c:5451:37: warning: missing braces around initializer drivers/gpu/drm/drm_dp_mst_topology.c:5451:37: warning: missing braces around initializer Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200516212330.13633-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
drivers/gpu/drm/drm_dp_helper.c:1598: warning: Function parameter or member 'dp_rev' not described in 'drm_dp_set_phy_test_pattern' Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/drm_client_modeset.c: In function ‘drm_client_firmware_config’: ./include/linux/bits.h:26:28: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] __builtin_constant_p((l) > (h)), (l) > (h), 0))) v2: Add a warning for passing connector_count==0 as this will hit an infinite loop, so document the invalid parameter. Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/drm_managed.c:61:6: warning: symbol 'drm_managed_release' was not declared. Should it be static? CC drivers/gpu/drm/drm_managed.o drivers/gpu/drm/drm_managed.c:61:6: warning: no previous prototype for ‘drm_managed_release’ [-Wmissing-prototypes] void drm_managed_release(struct drm_device *dev) Fixes: c6603c74 ("drm: add managed resources tied to drm_device") Signed-off-by:
-
Sam Ravnborg authored
Look up backlight device using devm_of_find_backlight(). This simplifies the code and prevents us from hardcoding the node name in the driver. v2: - Added Cc: Peter Ujfalusi Signed-off-by:
-
- 17 May, 2020 8 commits
-
-
Hans de Goede authored
drm_helper_probe_add_cmdline_mode() prefers using a probed mode matching a video= argument over calculating our own timings for the user specified mode using CVT or GTF. But userspace code which is auto-configuring the mode may want to know that the user has specified that mode on the kernel commandline so that it can pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED. This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just as we would do on the user-specified mode when no matching probed mode is found. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221173313.510235-2-hdegoede@redhat.com
-
Wolfram Sang authored
i2c_new_client() is deprecated, use the replacement i2c_new_client_device(). Also, we have a helper to check if a driver is bound. Use it to simplify the code. Note that this changes the errno for a failed device creation from ENOMEM to ENODEV. No callers currently interpret this errno, though, so we use this condensed error check. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
-
Wolfram Sang authored
module_put() balances try_module_get(), not request_module(). Fix the error path to match that. Fixes: 2066facc ("drm/kms: slave encoder interface.") Signed-off-by:
-
Michael Tretter authored
Using plain echo to set the "force" connector attribute fails with -EINVAL, because echo appends a newline to the output. Replace strcmp with sysfs_streq to also accept strings that end with a newline. v2: use sysfs_streq instead of stripping trailing whitespace Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Dan Carpenter authored
If the "handles" allocation or the copy_from_user() fails then we leak "objs". It's supposed to be freed in panfrost_job_cleanup(). Fixes: c117aa4d ("drm: Add a drm_gem_objects_lookup helper") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Emil Velikov authored
The function vop_cfg_done() is a simple VOP_REG_SET(). As such it should be done under a reg_lock. A quick look through the driver shows that all other instances (apart from driver init) have the lock. Do the same here Cc: Sandy Huang <hjc@rock-chips.com> Cc: Heiko Stübner <heiko@sntech.de> Signed-off-by:
Sandy Huang <hjc@rock-chips.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200505151613.2932456-1-emil.l.velikov@gmail.com
-
Sam Ravnborg authored
Look up backlight device using devm_of_find_backlight(). This simplifies the code and prevents us from hardcoding the node name in the driver. Signed-off-by:
-
Sam Ravnborg authored
Look up backlight device using devm_of_find_backlight(). This simplifies the code and prevents us from hardcoding the node name in the driver. Signed-off-by:
-
- 15 May, 2020 3 commits
-
-
Maxime Ripard authored
The main DRM device is actually a virtual device so it doesn't have the iommus property, which is instead on the DMA masters, in this case the mixers. Add a call to of_dma_configure with the mixers DT node but on the DRM virtual device to configure it in the same way than the mixers. Reviewed-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/9a4daf438dd3f2fe07afb23688bfb793a0613d7d.1589378833.git-series.maxime@cerno.tech
-
Maxime Ripard authored
The H6 mixer is attached to an IOMMU, so let's allow that property to be set in the bindings. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Imre Deak authored
This fixes the following use-after-free problem in case an MST down message times out, while waiting for the response for it: [ 449.022841] [drm:drm_dp_mst_wait_tx_reply.isra.26] timedout msg send 0000000080ba7fa2 2 0 [ 449.022898] ------------[ cut here ]------------ [ 449.022903] list_add corruption. prev->next should be next (ffff88847dae32c0), but was 6b6b6b6b6b6b6b6b. (prev=ffff88847db1c140). [ 449.022931] WARNING: CPU: 2 PID: 22 at lib/list_debug.c:28 __list_add_valid+0x4d/0x70 [ 449.022935] Modules linked in: asix usbnet mii snd_hda_codec_hdmi mei_hdcp i915 x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep e1000e snd_hda_core ptp snd_pcm pps_core mei_me mei intel_lpss_pci prime_numbers [ 449.022966] CPU: 2 PID: 22 Comm: kworker/2:0 Not tainted 5.7.0-rc3-CI-Patchwork_17536+ #1 [ 449.022970] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2457.A16.1912270059 12/27/2019 [ 449.022976] Workqueue: events_long drm_dp_mst_link_probe_work [ 449.022982] RIP: 0010:__list_add_valid+0x4d/0x70 [ 449.022987] Code: c3 48 89 d1 48 c7 c7 f0 e7 32 82 48 89 c2 e8 3a 49 b7 ff 0f 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 40 e8 32 82 e8 23 49 b7 ff <0f> 0b 31 c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 90 e8 32 82 e8 [ 449.022991] RSP: 0018:ffffc900001abcb0 EFLAGS: 00010286 [ 449.022995] RAX: 0000000000000000 RBX: ffff88847dae2d58 RCX: 0000000000000001 [ 449.022999] RDX: 0000000080000001 RSI: ffff88849d914978 RDI: 00000000ffffffff [ 449.023002] RBP: ffff88847dae32c0 R08: ffff88849d914978 R09: 0000000000000000 [ 449.023006] R10: ffffc900001abcb8 R11: 0000000000000000 R12: ffff888490d98400 [ 449.023009] R13: ffff88847dae3230 R14: ffff88847db1c140 R15: ffff888490d98540 [ 449.023013] FS: 0000000000000000(0000) GS:ffff88849ff00000(0000) knlGS:0000000000000000 [ 449.023017] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.023021] CR2: 00007fb96fafdc63 CR3: 0000000005610004 CR4: 0000000000760ee0 [ 449.023025] PKRU: 55555554 [ 449.023028] Call Trace: [ 449.023034] drm_dp_queue_down_tx+0x59/0x110 [ 449.023041] ? rcu_read_lock_sched_held+0x4d/0x80 [ 449.023050] ? kmem_cache_alloc_trace+0x2a6/0x2d0 [ 449.023060] drm_dp_send_link_address+0x74/0x870 [ 449.023065] ? __slab_free+0x3e1/0x5c0 [ 449.023071] ? lockdep_hardirqs_on+0xe0/0x1c0 [ 449.023078] ? lockdep_hardirqs_on+0xe0/0x1c0 [ 449.023097] drm_dp_check_and_send_link_address+0x9a/0xc0 [ 449.023106] drm_dp_mst_link_probe_work+0x9e/0x160 [ 449.023117] process_one_work+0x268/0x600 [ 449.023124] ? __schedule+0x307/0x8d0 [ 449.023139] worker_thread+0x37/0x380 [ 449.023149] ? process_one_work+0x600/0x600 [ 449.023153] kthread+0x140/0x160 [ 449.023159] ? kthread_park+0x80/0x80 [ 449.023169] ret_from_fork+0x24/0x50 Fixes: d308a881 ("drm/dp_mst: Kill the second sideband tx slot, save the world") Cc: Lyude Paul <lyude@redhat.com> Cc: Sean Paul <sean@poorly.run> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200513103155.12336-1-imre.deak@intel.com
-
- 14 May, 2020 1 commit
-
-
Wolfram Sang authored
The R-Car DU driver calls drm_vblank_init via some helper functions in probe(). From what I checked, most drivers do this as well. I have a config now where DU always stays in deferred_probe state because of a missing dependency. This means that every time I rebind another driver like MMC, the vblank init message is displayed again when the DU driver is retried. Because the message doesn't really carry a useful information, I suggest to simply drop it. Signed-off-by:
-
- 13 May, 2020 1 commit
-
-
Chris Wilson authored
Now that atomic64_fetch_add() exists we can use it to return the base context id, rather than the atomic64_add_return(N) - N concoction. Suggested-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
Maciej Patelczyk <maciej.patelczyk@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200513074809.18194-2-chris@chris-wilson.co.uk
-
- 12 May, 2020 1 commit
-
-
Wei Yongjun authored
The of_drm_find_bridge() function returns NULL on error, it doesn't return error pointers so this check doesn't work. Fixes: 5fc537bf ("drm/mcde: Add new driver for ST-Ericsson MCDE") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
- 11 May, 2020 6 commits
-
-
Thomas Zimmermann authored
Storing the connector instance in struct mga_device avoids some dynamic memory allocation. On errors, the connector's initializer function now destroys the i2c structure. Done in preparation of converting mgag200 to simple-KMS helpers. v2: * improved commit message (Michael) * fixed error message for mgag200_vga_connector_init() (Sam) Signed-off-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Acked-by:
-
Thomas Zimmermann authored
The fields mode_info, num_crtcs and mode in struct mga_device serve no purpose. Remove them. Signed-off-by:
-
Thomas Zimmermann authored
Mode configuration is now cleanued up automatically. While at it, move all mode-config code into mgag200_mode.c. Done in preparation of switching mgag200 to simple-KMS helpers. v2: * improve commit message (Sam) * rebased during cherry pick * also move bpp_shift initialization Signed-off-by:
-
Thomas Zimmermann authored
Done to simplify initialization code before embedding the DRM device instance in struct mga_device. Signed-off-by:
-
Thomas Zimmermann authored
Done in preparation of embedding the DRM device in struct mga_device. This patch makes the patch for embedding more readable. v2: * improved commit message (Daniel) Signed-off-by:
-
Thomas Zimmermann authored
Mgag200 uses dev_private to look up struct mga_device for instances of struct drm_device. Use of dev_private is deprecated, so hide it in the helper function to_mga_device(). v2: * make to_mga_device() a function (Sam) Signed-off-by:
-
- 09 May, 2020 3 commits
-
-
Jason Yan authored
No other functions use the return value of pxa168fb_init_mode() and the return value is always 0 now. Make it return void. This fixes the following coccicheck warning: drivers/video/fbdev/pxa168fb.c:565:5-8: Unneeded variable: "ret". Return "0" on line 597 Signed-off-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
-
Samuel Zou authored
Fix the following sparse warning: drivers/gpu/drm/i2c/tda998x_drv.c:1136:5: warning: symbol 'tda998x_audio_digital_mute' was not declared. Should it be static? Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Samuel Zou <zou_wei@huawei.com> Cc: Russell King <linux@armlinux.org.uk> Signed-off-by:
-
Douglas Anderson authored
People use panel-simple when they have panels that are builtin to their device. In these cases the HPD (Hot Plug Detect) signal isn't really used for hotplugging devices but instead is used for power sequencing. Panel timing diagrams (especially for eDP panels) usually have the HPD signal in them and it acts as an indicator that the panel is ready for us to talk to it. Sometimes the HPD signal is hooked up to a normal GPIO on a system. In this case we need to poll it in the correct place to know that the panel is ready for us. In some system designs the right place for this is panel-simple. When adding this support, we'll account for the case that there might be a circular dependency between panel-simple and the provider of the GPIO. The case this was designed for was for the "ti-sn65dsi86" bridge chip. If HPD is hooked up to one of the GPIOs provided by the bridge chip then in our probe function we'll always get back -EPROBE_DEFER. Let's handle this by allowing this GPIO to show up late if we saw -EPROBE_DEFER during probe. NOTE: since the gpio_get_optional() is used, if the "hpd-gpios" isn't there our variable will just be NULL and we won't do anything in prepare(). Signed-off-by:
-
