- 19 Jun, 2019 12 commits
-
-
Maxime Ripard authored
During the connector reset, if that connector has a TV property, it needs to be reset to the value provided on the command line. Provide a helper to do that. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/84a7b657f09303a2850e1cc79e68f623547f3fdd.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
Properly configuring the overscan properties might be needed for the initial setup of the framebuffer for display that still have overscan. Let's allow for more properties on the kernel command line to setup each margin. Reviewed-by:
-
Maxime Ripard authored
The TV margins has been defined as a structure inside the drm_connector_state structure so far. However, we will need it in other structures as well, so let's move that structure definition so that it can be reused. Reviewed-by:
-
Maxime Ripard authored
Rotations and reflections setup are needed in some scenarios to initialise properly the initial framebuffer. Some drivers already had a bunch of quirks to deal with this, such as either a private kernel command line parameter (omapdss) or on the device tree (various panels). In order to accomodate this, let's create a video mode parameter to deal with the rotation and reflexion. Reviewed-by:
-
Maxime Ripard authored
The drm subsystem also uses the video= kernel parameter, and in the documentation refers to the fbdev documentation for that parameter. However, that documentation also says that instead of giving the mode using its resolution we can also give a name. However, DRM doesn't handle that case at the moment. Even though in most case it shouldn't make any difference, it might be useful for analog modes, where different standards might have the same resolution, but still have a few different parameters that are not encoded in the modes (NTSC vs NTSC-J vs PAL-M for example). Reviewed-by:
-
Maxime Ripard authored
Rewrite the command line parser in order to get away from the state machine parsing the video mode lines. Hopefully, this will allow to extend it more easily to support named modes and / or properties set directly on the command line. Reviewed-by:
-
Maxime Ripard authored
The drm_client_panel_rotation function has been used so far to set the default rotation based on the panel orientation. However, we can have more sources of information to make that decision, starting with the command line that we will introduce later in this series. Change the name to remove the panel mention. Reviewed-by:
-
Maxime Ripard authored
The drm_client_rotation has a check on the rotation value, but the reflections are also stored in the same variable, and the check doesn't take this into account. Therefore, even though we might have a valid rotation, if we're also using a reflection parameter, the test will fail for no particular reason. Reviewed-by:
-
Maxime Ripard authored
The drm_client_modeset_commit_atomic function uses two times the plane_state variable in inner blocks of code, but the variable has a scope global to this function. This will lead to inadvertent devs to reuse the variable in the second block with the value left by the first, without any warning from the compiler since value would have been initialized. Fix this by moving the variable declaration to the proper scope. Reviewed-by:
-
Maxime Ripard authored
The struct drm_cmdline_mode holds the result of the command line parsers. However, it wasn't documented so far, so let's do that. Reviewed-by:
-
Oleg Vasilev authored
Other drivers are able to list crc sources when accessing /sys/kernel/debug/dri/.../crtc-0/crc/control Even though VKMS now supports only 'auto' mode, it is more consistent to have the list available to the userspace. Signed-off-by:
Oleg Vasilev <oleg.vasilev@intel.com> Reviewed-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by:
-
Daniel Vetter authored
No need to have them multiple times. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
-
- 18 Jun, 2019 6 commits
-
-
Serge Semin authored
Since commit 4b050ba7 ("MIPS: pgtable.h: Implement the pgprot_writecombine function for MIPS") and commit c4687b15 ("MIPS: Fix definition of pgprot_writecombine()") write-combine vma mapping is available to be used by kernel subsystems for MIPS. In particular the uncached accelerated attribute is requested to be set by ioremap_wc() method and by generic PCI memory pages/ranges mapping methods. The same is done by the drm_io_prot()/ttm_io_prot() functions in case if write-combine flag is set for vma's passed for mapping. But for some reason the pgprot_writecombine() method calling is ifdefed to be a platform-specific with MIPS system being marked as lacking of one. At the very least it doesn't reflect the current MIPS platform implementation. So in order to improve the DRM subsystem performance on MIPS with UCA mapping enabled, we need to have pgprot_writecombine() called for buffers, which need store operations being combined. In case if particular MIPS chip doesn't support the UCA attribute, the mapping will fall back to noncached. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@mips.com> Cc: James Hogan <jhogan@kernel.org> Acked-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Paul Burton <paul.burton@mips.com> Signed-off-by:
Vadim V. Vlasov <vadim.vlasov@t-platforms.ru> Signed-off-by:
Serge Semin <fancer.lancer@gmail.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190423123122.32573-1-fancer.lancer@gmail.com
-
Sean Paul authored
drm_atomic_get_crtc_state() returns an error pointer when it fails, so the null check is doing nothing here. Credit to 0-day/Dan Carpenter for reporting this. Fixes: 6f3b6278 ("drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state") Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Eric Anholt <eric@anholt.net> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [for rcar lvds] Cc: Sean Paul <seanpaul@chromium.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Lyude Paul <lyude@redhat.com> Cc: Karol Herbst <karolherbst@gmail.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Reported-by:
kbuild test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Boris Brezillon authored
Expose performance counters through 2 driver specific ioctls: one to enable/disable the perfcnt block, and one to dump the counter values. There are discussions to expose global performance monitors (those counters that can't be retrieved on a per-job basis) in a consistent way, but this is likely to take time to settle on something that works for various HW/users. The ioctls are marked unstable so we can get rid of them when the time comes. We initally went for a debugfs-based interface, but this was making the transition to per-FD address space more complicated (we need to specify the namespace the GPU has to use when dumping the perf counters), hence the decision to switch back to driver specific ioctls which are passed the FD they operate on and thus will have a dedicated address space attached to them. Other than that, the implementation is pretty simple: it basically dumps all counters and copy the values to a userspace buffer. The parsing is left to userspace which has to know the specific layout that's used by the GPU (layout differs on a per-revision basis). Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Acked-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190618081648.17297-5-boris.brezillon@collabora.com
-
Boris Brezillon authored
All models with an ID >= 0x1000 are Bifrost GPUs for now (might change with new gens). Suggested-by:
-
Boris Brezillon authored
We plan to expose performance counters through 2 driver specific ioctls until there's a solution to expose them in a generic way. In order to be able to deprecate those ioctls when this new infrastructure is in place we add an unsafe module parameter that will keep those ioctls hidden unless it's set to true (which also has the effect of tainting the kernel). All unstable ioctl handlers should use panfrost_unstable_ioctl_check() to check whether they're supposed to handle the request or reject it with ENOSYS. Suggested-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
-
Boris Brezillon authored
So they can be used from other files. Signed-off-by:
-
- 17 Jun, 2019 3 commits
-
-
Daniel Vetter authored
They're purely for internal use, not for drivers. Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Christian König <christian.koenig@amd.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Daniel Vetter authored
We're kinda going in the wrong direction. Spotted while typing better gem/prime docs. Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rob Herring <robh@kernel.org> Cc: Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Maarten Lankhorst authored
Pick up rc3 and rc4 and the merges from the other branches, we're a bit out of date. Signed-off-by:Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
- 16 Jun, 2019 2 commits
-
-
Douglas Anderson authored
In vop_crtc_mode_fixup() we fixup the mode to show what we actually will be able to achieve. However we should base our adjustments on any previous adjustments that were made. As an example, the dw_hdmi driver may wish to make some small adjustments to clock rates in its atomic_check() function. If it does, it will update the adjusted_mode. We shouldn't throw away those adjustments. NOTE: the version of the dw_hdmi driver upstream doesn't _actually_ make such adjustments, but downstream in Chrome OS it does. It is plausible that one day we'll figure out how to cleanly make that happen in an upstream-friendly way, so we should prepare by using the right mode. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190614224730.98622-2-dianders@chromium.org
-
Douglas Anderson authored
When fixing up the clock in vop_crtc_mode_fixup() we're not doing it quite correctly. Specifically if we've got the true clock 266666667 Hz, we'll perform this calculation: 266666667 / 1000 => 266666 Later when we try to set the clock we'll do clk_set_rate(266666 * 1000). The common clock framework won't actually pick the proper clock in this case since it always wants clocks <= the specified one. Let's solve this by using DIV_ROUND_UP. Fixes: b59b8de3 ("drm/rockchip: return a true clock rate to adjusted_mode") Signed-off-by:
Yakir Yang <ykk@rock-chips.com> Signed-off-by:
-
- 14 Jun, 2019 12 commits
-
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Ville Syrjälä authored
CH7511 eDP->LVDS bridge doesn't seem to set SINK_COUNT properly causing i915 to detect it as disconnected. Add a quirk to ignore SINK_COUNT on these devices. Cc: David S. <david@majinbuu.com> Cc: Peteris Rudzusiks <peteris.rudzusiks@gmail.com> Tested-by:
Peteris Rudzusiks <peteris.rudzusiks@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105406Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528140650.19230-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> #irc
-
Oleg Vasilev authored
Since we are logging all vblank counter updates 30 lines below, it is also good to have some details whether and how vblank count difference is calculated. Signed-off-by:
-
Rob Herring authored
In order to increase the chances of using 2MB pages, we need to align the GPU VA mapping to 2MB. Only do this if the object size is 2MB or more. Cc: Robin Murphy <robin.murphy@arm.com> Cc: Steven Price <steven.price@arm.com> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190610165806.24854-1-robh@kernel.org
-
Greg Kroah-Hartman authored
As stated before, there is no need to care if a debugfs function succeeds or not, and no code logic in the kernel should ever change based on a debugfs function return value, so make drm_debugfs_create_files() never fail. If it encounters an odd/rare/impossible error (i.e. out of memory, or a duplicate debugfs filename to be created), just keep on moving as if nothing improper had happened. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190614095110.3716-2-gregkh@linuxfoundation.org
-
Sandor Yu authored
The value stored in the rate field of struct drm_dp_link should be the actual link-rate and not the bw_code. Right now the driver stores the code and converts it to the rate. So fixup the driver to store the rate itself. Signed-off-by:
Sandor Yu <Sandor.yu@nxp.com> Signed-off-by:
-
Justin Swartz authored
Like the RK3328, RK322x SoCs offer a Synopsis DesignWare HDMI transmitter and an Innosilicon HDMI PHY. Add a new dw_hdmi_plat_data struct, rk3228_hdmi_drv_data. Assign a set of mostly generic rk3228_hdmi_phy_ops functions. Add dw_hdmi_rk3228_setup_hpd() to enable the HDMI HPD and DDC lines. Signed-off-by:
Justin Swartz <justin.swartz@risingedge.co.za> Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDaniel Vetter authored
drm-misc-next for v5.3: UAPI Changes: Cross-subsystem Changes: - Add code to signal all dma-fences when freed with pending signals. - Annotate reservation object access in CONFIG_DEBUG_MUTEXES Core Changes: - Assorted documentation fixes. - Use irqsave/restore spinlock to add crc entry. - Move code around to drm_client, for internal modeset clients. - Make drm_crtc.h and drm_debugfs.h self-contained. - Remove drm_fb_helper_connector. - Add bootsplash to todo. - Fix lock ordering in pan_display_legacy. - Support pinning buffers to current location in gem-vram. - Remove the now unused locking functions from gem-vram. - Remove the now unused kmap-object argument from vram helpers. - Stop checking return value of debugfs_create. - Add atomic encoder enable/disable helpers. - pass drm_atomic_state to atomic connector check. - Add atomic support for bridge enable/disable. - Add self refresh helpers to core. Driver Changes: - Add extra delay to make MTP SDM845 work. - Small fixes to virtio, vkms, sii902x, sii9234, ast, mcde, analogix, rockchip. - Add zpos and ?BGR8888 support to meson. - More removals of drm_os_linux and drmP headers for amd, radeon, sti, r128, r128, savage, sis. - Allow synopsis to unwedge the i2c hdmi bus. - Add orientation quirks for GPD panels. - Edid cleanups and fixing handling for edid < 1.2. - Add runtime pm to stm. - Handle s/r in dw-hdmi. - Add hooks for power on/off to dsi for stm. - Remove virtio dirty tracking code, done in drm core. - Rework BO handling in ast and mgag200. Tiny conflict in drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c, needed #include <linux/slab.h> to make it compile. Signed-off-by:
-
Greg Hackmann authored
The show_fdinfo handler exports the same information available through debugfs on a per-buffer basis. Signed-off-by:
Greg Hackmann <ghackmann@google.com> Signed-off-by:
Chenbo Feng <fengc@google.com> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190613223408.139221-4-fengc@google.com
-
Greg Hackmann authored
This patch adds complimentary DMA_BUF_SET_NAME ioctls, which lets userspace processes attach a free-form name to each buffer. This information can be extremely helpful for tracking and accounting shared buffers. For example, on Android, we know what each buffer will be used for at allocation time: GL, multimedia, camera, etc. The userspace allocator can use DMA_BUF_SET_NAME to associate that information with the buffer, so we can later give developers a breakdown of how much memory they're allocating for graphics, camera, etc. Signed-off-by:
-
Greg Hackmann authored
By traversing /proc/*/fd and /proc/*/map_files, processes with CAP_ADMIN can get a lot of fine-grained data about how shmem buffers are shared among processes. stat(2) on each entry gives the caller a unique ID (st_ino), the buffer's size (st_size), and even the number of pages currently charged to the buffer (st_blocks / 512). In contrast, all dma-bufs share the same anonymous inode. So while we can count how many dma-buf fds or mappings a process has, we can't get the size of the backing buffers or tell if two entries point to the same dma-buf. On systems with debugfs, we can get a per-buffer breakdown of size and reference count, but can't tell which processes are actually holding the references to each buffer. Replace the singleton inode with full-fledged inodes allocated by alloc_anon_inode(). This involves creating and mounting a mini-pseudo-filesystem for dma-buf, following the example in fs/aio.c. Signed-off-by:
-
Sean Paul authored
I missed amdgpu in my connnector_helper_funcs->atomic_check conversion, which is understandably causing compilation failures. Fixes: 6f3b6278 ("drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state") Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Eric Anholt <eric@anholt.net> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [for rcar lvds] Cc: Sean Paul <seanpaul@chromium.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Lyude Paul <lyude@redhat.com> Cc: Karol Herbst <karolherbst@gmail.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Reported-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 13 Jun, 2019 5 commits
-
-
Sean Paul authored
Fixes the following warning: ../drivers/gpu/drm/drm_connector.c:981: WARNING: Definition list ends without a blank line; unexpected unindent. Fixes: a09db883 ("drm: Fix docbook warnings in hdr metadata helper structures") Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Ville Syrjä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: "Ville Syrjä" <ville.syrjala@linux.intel.com> Cc: Hans Verkuil <hansverk@cisco.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Cc: Sean Paul <sean@poorly.run> (v1) Cc: Uma Shankar <uma.shankar@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Sean Paul authored
Instead of flushing all vops every time we get a dirtyfb call, use the damage helper to kick off an atomic commit. Even though we don't use damage clips, the helper commit will force us through the normal psr_inhibit_get/put sequence. Changes in v3: - Added to the set Changes in v4: - None Changes in v5: - None Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-7-sean@poorly.run Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-7-sean@poorly.runSuggested-by:
Daniel Vetter <daniel@ffwll.ch> Tested-by:
-
Sean Paul authored
This patch adds a new drm helper library to help drivers implement self refresh. Drivers choosing to use it will register crtcs and will receive callbacks when it's time to enter or exit self refresh mode. In its current form, it has a timer which will trigger after a driver-specified amount of inactivity. When the timer triggers, the helpers will submit a new atomic commit to shut the refreshing pipe off. On the next atomic commit, the drm core will revert the self refresh state and bring everything back up to be actively driven. From the driver's perspective, this works like a regular disable/enable cycle. The driver need only check the 'self_refresh_active' state in crtc_state. It should initiate self refresh mode on the panel and enter an off or low-power state. Changes in v2: - s/psr/self_refresh/ (Daniel) - integrated the psr exit into the commit that wakes it up (Jose/Daniel) - made the psr state per-crtc (Jose/Daniel) Changes in v3: - Remove the self_refresh_(active|changed) from connector state (Daniel) - Simplify loop in drm_self_refresh_helper_alter_state (Daniel) - Improve self_refresh_aware comment (Daniel) - s/self_refresh_state/self_refresh_data/ (Daniel) Changes in v4: - Move docbook location below panel (Daniel) - Improve docbook with references and more detailed explanation (Daniel) - Instead of register/unregister, use init/cleanup (Daniel) Changes in v5: - Resolved conflict in drm_atomic_helper.c #include block - Resolved conflict in rst with HDCP helper docs Changes in v6: - Fix include ordering, clean up forward declarations (Sam) Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-2-sean@poorly.run Link to v2: https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-1-sean@poorly.run Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-6-sean@poorly.run Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-6-sean@poorly.run Link to v5: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-6-sean@poorly.run Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jose Souza <jose.souza@intel.com> Cc: Zain Wang <wzz@rock-chips.com> Cc: Tomasz Figa <tfiga@chromium.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Tested-by:
-
Sean Paul authored
Everyone who implements connector_helper_funcs->atomic_check reaches into the connector state to get the atomic state. Instead of continuing this pattern, change the callback signature to just give atomic state and let the driver determine what it does and does not need from it. Eventually all atomic functions should do this, but that's just too much busy work for me. Changes in v3: - Added to the set Changes in v4: - None Changes in v5: - intel_digital_connector_atomic_check declaration moved to i915_atomic.h Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-5-sean@poorly.run Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-5-sean@poorly.run Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Eric Anholt <eric@anholt.net> Tested-by:
-
Sean Paul authored
This patch adds atomic variants for all of pre_enable/enable/disable/post_disable bridge functions. These will be called from the appropriate atomic helper functions. If the bridge driver doesn't implement the atomic version of the function, we will fall back to the vanilla implementation. Note that some drivers call drm_bridge_disable directly, and these cases are not covered. It's up to the driver to decide whether to implement both atomic_disable and disable, or if it's not necessary. Changes in v3: - Added to the patchset Changes in v4: - Fix up docbook references (Daniel) Changes in v5: - None Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-4-sean@poorly.run Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-4-sean@poorly.run Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
