- 19 May, 2020 28 commits
-
-
Emil Velikov authored
With earlier patch we removed the overhead so now we can lift the helper into the header effectively folding it with __drm_object_put. v2: drop struct_mutex references (Daniel) Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> (v1) Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200515095118.2743122-11-emil.l.velikov@gmail.com
-
Emil Velikov authored
No drivers set the callback, so remove it all together. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
-
Emil Velikov authored
No dev->struct_mutex anywhere to be seen. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Emil Velikov authored
The driver does not hold struct_mutex, thus using the locked version of the helper is incorrect. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: amd-gfx@lists.freedesktop.org Fixes: a3941471 ("drm/amdgpu: add independent DMA-buf import v9") Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
-
Emil Velikov authored
The comment that struct_mutex must be held is misleading. It is only required when .gem_free_object() is used. Since that one is going with the next patches, drop the reference. Signed-off-by:
-
Emil Velikov authored
The mutex should be used, only by legacy drivers. Add a big warning to deter people from using it. Suggested-by:
-
Emil Velikov authored
There's little point in providing partial and ancient information about the struct_mutex. Some drivers are using it, new ones should not. As-it this only provides for confusion. Signed-off-by:
-
Emil Velikov authored
The i915 driver uses the struct_mutex, eventhough it does not use the locked version of the drm_object_gem API. Signed-off-by:
-
Emil Velikov authored
Use the drm_gem_object_put_unlocked in the documentation for drm_gem_objects_lookup. The locked version of the helper should be used solely by people who know exactly what they are doing. Should prevent issues like ones adddressed with the next patch. Signed-off-by:
-
Emil Velikov authored
There's nothing GEM related in the file - the drm_gem.h include is not needed. Signed-off-by:
-
Thomas Zimmermann authored
The VRAM helpers managed the framebuffer memory for mgag200. This came with several problems, as some MGA device require the scanout address to be located at VRAM offset 0. It's incompatible with the page-flip semantics of DRM's atomic modesettting. With atomic modesetting, old and new framebuffers have to be located in VRAM at the same time. So at least one of them has to reside at a non-0 offset. This patch replaces VRAM helpers with SHMEM helpers. GEM SHMEM buffers reside in system memory, and are shadow-copied into VRAM during page flips. The shadow copy always starts at VRAM offset 0. v2: * revert dev->pdev changes Signed-off-by:
John Donnelly <John.p.donnelly@oracle.com> Acked-by:
-
Thomas Zimmermann authored
The mgag200 supports a single pipeline with only a primary plane. It can be converted to simple KMS helpers. This also adds support for atomic modesetting. Wayland compositors, which use pageflip ioctls, can now be used with mgag200. v2: * prepare encoder and CRTC in a separate patch * remove suspend/resume code in a separate patch * don't call set_format_regs() in pipe_update() Signed-off-by:
-
Thomas Zimmermann authored
The MGA CRTC data structure struct mga_crtc contains unused additional fields; so it can removed. The standard DRM CRTC and encoder structures are embedded now in struct drm_simple_display_pipe. Done in preparation of converting mgag200 to simple KMS helpers. v3: * remove now-unused define MGAG200FB_CONN_LIMIT * remove unused define MATROX_DPMS_CLEARED Signed-off-by:
-
Thomas Zimmermann authored
The suspend/resume helpers are unused. Also remove associated state from struct mga_device. Signed-off-by:
-
Thomas Zimmermann authored
Registers are initialized with constants. This is now done in mgag200_init_regs(), mgag200_set_dac_regs() and mgag200_set_pci_regs(). Later patches should move these calls from mode setting to device initialization. v2: * replace uint8_t with u8 Signed-off-by:
-
Thomas Zimmermann authored
The hiprivlvl settings are now updated in mgag200_g200se_set_hiprilvl() and mgag200_g200ev_set_hiprilvl(). v2: * replace uint8_t with u8 Signed-off-by:
-
Thomas Zimmermann authored
The TAGFIFO state is now reset in mgag200_g200er_reset_tagfifo(). v2: * define MGAREG_SEQ1_SCROFF Signed-off-by:
-
Thomas Zimmermann authored
The primary plane's format registers are now updated in a mgag200_set_format_regs(). v2: * get bpp shift from helper function * replace uint8_t with u8 Signed-off-by:
-
Thomas Zimmermann authored
The framebuffer's pitch is now set in mgag200_set_offset(). v2: * move offset and bpp-shift calculation into helper functions * use u8 instead of uint8_t * add MGAREG_CRTCEXT0_OFFSET_MASK Signed-off-by:
-
Thomas Zimmermann authored
Setting the plane registers first and the mode registers afterwards reproduces the sequence used by atomic helpers. Done in preparation of switching to simple KMS helpers. Signed-off-by:
-
Thomas Zimmermann authored
Set different fields in MISC in their rsp location in the code. This patch also fixes a bug in the original code where the mode's SYNC flags were never written into the MISC register. v2: * use u8 instead of uint8_t * define MGAREG_MISC_CLK_SEL_MASK Signed-off-by:
-
Thomas Zimmermann authored
The mode-setting code is now located in mgag200_set_mode_regs(), sans a few flags that will be moved in a later patch for clarity. v2: * replace uint8_t with u8 Signed-off-by:
-
Thomas Zimmermann authored
The function now only takes the device structure, and the old and new framebuffers. Signed-off-by:
-
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:
-
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 1 commit
-
-
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
-
