- 04 Nov, 2021 11 commits
-
-
Maxime Ripard authored
Depending on a given HVS output (HVS to PixelValves) and input (planes attached to a channel) load, the HVS needs for the core clock to be raised above its boot time default. Failing to do so will result in a vblank timeout and a stalled display pipeline. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-11-maxime@cerno.tech
-
Maxime Ripard authored
If we have a state already and disconnect/reconnect the display, the SCDC messages won't be sent again since we didn't go through a disable / enable cycle. In order to fix this, let's call the vc4_hdmi_enable_scrambling function in the detect callback if there is a mode and it needs the scrambler to be enabled. Fixes: c85695a2 ("drm/vc4: hdmi: Enable the scrambler") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-10-maxime@cerno.tech
-
Maxime Ripard authored
Now that we have the infrastructure in place, we can raise the maximum pixel rate we can reach for HDMI0 on the BCM2711. HDMI1 is left untouched since its pixelvalve has a smaller FIFO and would need a clock faster than what we can provide to support the same modes. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20211025152903.1088803-9-maxime@cerno.tech
-
Maxime Ripard authored
The load tracker was initially designed to report and warn about a load too high for the HVS. To do so, it computes for each plane the impact it's going to have on the HVS, and will warn (if it's enabled) if we go over what the hardware can process. While the limits being used are a bit irrelevant to the BCM2711, the algorithm to compute the HVS load will be one component used in order to compute the core clock rate on the BCM2711. Let's remove the hooks to prevent the load tracker to do its computation, but since we don't have the same limits, don't check them against them, and prevent the debugfs file to enable it from being created. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-8-maxime@cerno.tech
-
Maxime Ripard authored
The encoder retrieval code has been a source of bugs and glitches in the past and the crtc <-> encoder association been wrong in a number of different ways. Add some logging to quickly spot issues if they occur. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-7-maxime@cerno.tech
-
Maxime Ripard authored
It turns out the encoder retrieval code, in addition to being unnecessarily complicated, has a bug when only the planes and crtcs are affected by a given atomic commit. Indeed, in such a case, either drm_atomic_get_old_connector_state or drm_atomic_get_new_connector_state will return NULL and thus our encoder retrieval code will not match on anything. We can however simplify the code by using drm_for_each_encoder_mask, the drm_crtc_state storing the encoders a given CRTC is connected to directly and without relying on any other state. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-6-maxime@cerno.tech
-
Maxime Ripard authored
vc4_crtc_config_pv() retrieves the encoder again, even though its only caller, vc4_crtc_atomic_enable(), already did. Pass the encoder pointer as an argument instead of going through all the connectors to retrieve it again. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-5-maxime@cerno.tech
-
Maxime Ripard authored
We'll need that function in vc4_kms to compute the core clock rate requirements. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-4-maxime@cerno.tech
-
Maxime Ripard authored
Prior to commit 6800234c ("drm/vc4: hdmi: Convert to gpiod"), in the detect hook, if we had an HPD GPIO we would only rely on it and return whatever state it was in. However, that commit changed that by mistake to only consider the case where we have a GPIO and it returns a logical high, and would fall back to the other methods otherwise. Since we can read the EDIDs when the HPD signal is low on some displays, we changed the detection status from disconnected to connected, and we would ignore an HPD pulse. Fixes: 6800234c ("drm/vc4: hdmi: Convert to gpiod") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-3-maxime@cerno.tech
-
Maxime Ripard authored
Commit 9d44abbb ("drm/vc4: Fall back to using an EDID probe in the absence of a GPIO.") added some code to read the EDID through DDC in the HDMI driver detect hook since the Pi3 had no HPD GPIO back then. However, commit b1b8f45b ("ARM: dts: bcm2837: Add missing GPIOs of Expander") changed that a couple of years later. This causes an issue though since some TV (like the LG 55C8) when it comes out of standy will deassert the HPD line, but the EDID will remain readable. It causes an issues nn platforms without an HPD GPIO, like the Pi4, where the DDC probing will be our primary mean to detect a display, and thus we will never detect the HPD pulse. This was fine before since the pulse was small enough that we would never detect it, and we also didn't have anything (like the scrambler) that needed to be set up in the display. However, now that we have both, the display during the HPD pulse will clear its scrambler status, and since we won't detect the disconnect/reconnect cycle we will never enable the scrambler back. As our main reason for that DDC probing is gone, let's just remove it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-2-maxime@cerno.tech
-
Christian König authored
Don't touch the exclusive fence manually here, but rather use the general dma_resv function. We did that for better hw reset handling but this doesn't necessary work correctly. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deuche <alexander.deucher@amd.com> Acked-by: Nirmoy Das <nirmoy.das@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211028132630.2330-6-christian.koenig@amd.com
-
- 03 Nov, 2021 1 commit
-
-
Christian König authored
Just grab all fences in one go. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211028132630.2330-3-christian.koenig@amd.com
-
- 02 Nov, 2021 6 commits
-
-
Simon Ser authored
When link-status changes, send a hotplug uevent which contains the connector ID. That way, user-space can more easily figure out that only this connector has been updated. Changes in v4: avoid sending two uevents (Ville) Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018084707.32253-7-contact@emersion.fr
-
Simon Ser authored
If an hotplug event only updates a single connector, use drm_kms_helper_connector_hotplug_event instead of drm_kms_helper_hotplug_event. Changes in v4: - Simplify loop logic (Ville, Sam) - Update drm_connector_helper_hpd_irq_event (Maxime) Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018084707.32253-6-contact@emersion.fr
-
Simon Ser authored
When updating a single connector, use drm_kms_helper_connector_hotplug_event instead of drm_kms_helper_hotplug_event. Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018084707.32253-5-contact@emersion.fr
-
Simon Ser authored
In drm_connector_register, use drm_sysfs_connector_hotplug_event instead of drm_sysfs_hotplug_event, because the hotplug event only updates a single connector. Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018084707.32253-4-contact@emersion.fr
-
Simon Ser authored
This function is the same as drm_kms_helper_hotplug_event, but takes a connector instead of a device. Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018084707.32253-3-contact@emersion.fr
-
Simon Ser authored
This function sends a hotplug uevent with a CONNECTOR property. Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018084707.32253-2-contact@emersion.fr
-
- 01 Nov, 2021 1 commit
-
-
Andrey Grodzovsky authored
Probelm: Singlaning one sched fence from within another's sched fence singal callback generates lockdep splat because the both have same lockdep class of their fence->lock Fix: Fix bellow stack by rescheduling to irq work of signaling and killing of jobs that left when entity is killed. [11176.741181] dump_stack+0x10/0x12 [11176.741186] __lock_acquire.cold+0x208/0x2df [11176.741197] lock_acquire+0xc6/0x2d0 [11176.741204] ? dma_fence_signal+0x28/0x80 [11176.741212] _raw_spin_lock_irqsave+0x4d/0x70 [11176.741219] ? dma_fence_signal+0x28/0x80 [11176.741225] dma_fence_signal+0x28/0x80 [11176.741230] drm_sched_fence_finished+0x12/0x20 [gpu_sched] [11176.741240] drm_sched_entity_kill_jobs_cb+0x1c/0x50 [gpu_sched] [11176.741248] dma_fence_signal_timestamp_locked+0xac/0x1a0 [11176.741254] dma_fence_signal+0x3b/0x80 [11176.741260] drm_sched_fence_finished+0x12/0x20 [gpu_sched] [11176.741268] drm_sched_job_done.isra.0+0x7f/0x1a0 [gpu_sched] [11176.741277] drm_sched_job_done_cb+0x12/0x20 [gpu_sched] [11176.741284] dma_fence_signal_timestamp_locked+0xac/0x1a0 [11176.741290] dma_fence_signal+0x3b/0x80 [11176.741296] amdgpu_fence_process+0xd1/0x140 [amdgpu] [11176.741504] sdma_v4_0_process_trap_irq+0x8c/0xb0 [amdgpu] [11176.741731] amdgpu_irq_dispatch+0xce/0x250 [amdgpu] [11176.741954] amdgpu_ih_process+0x81/0x100 [amdgpu] [11176.742174] amdgpu_irq_handler+0x26/0xa0 [amdgpu] [11176.742393] __handle_irq_event_percpu+0x4f/0x2c0 [11176.742402] handle_irq_event_percpu+0x33/0x80 [11176.742408] handle_irq_event+0x39/0x60 [11176.742414] handle_edge_irq+0x93/0x1d0 [11176.742419] __common_interrupt+0x50/0xe0 [11176.742426] common_interrupt+0x80/0x90 Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Suggested-by: Christian König <christian.koenig@amd.com> Tested-by: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://www.spinics.net/lists/dri-devel/msg321250.html
-
- 30 Oct, 2021 1 commit
-
-
Paul Cercueil authored
Commit 1bdb542d ("drm/ingenic: Simplify code by using hwdescs array") caused the dma_hwdesc_phys_f{0,1} variables to be used while uninitialized in a mmio register write, which most certainly broke the ingenic-drm driver. However, the very same patchset also submitted commit 60554662 ("drm/ingenic: Upload palette before frame"), which restored a correct behaviour by doing the register writes in a different place in the code. What's left of this, is just to remove the bogus register writes in the probe function. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reported-by: kernel test robot <lkp@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211030100032.42066-1-paul@crapouillou.netAcked-by: Sam Ravnborg <sam@ravnborg.org>
-
- 29 Oct, 2021 11 commits
-
-
Paul Cercueil authored
Attach a top-level bridge to each encoder, which will be used for negociating the bus format and flags. All the bridges are now attached with DRM_BRIDGE_ATTACH_NO_CONNECTOR. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20211026181240.213806-7-paul@crapouillou.netTested-by: Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Christophe Branchereau <cbranchereau@gmail.com>
-
Paul Cercueil authored
When using C8 color mode, make sure that the palette is always uploaded before a frame; otherwise the very first frame will have wrong colors. Do that by changing the link order of the DMA descriptors. v3: Fix ingenic_drm_get_new_priv_state() called instead of ingenic_drm_get_priv_state() Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20211026181240.213806-6-paul@crapouillou.netTested-by: Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Christophe Branchereau <cbranchereau@gmail.com>
-
Paul Cercueil authored
Setting the DMA descriptor chain register in the probe function has been fine until now, because we only ever had one descriptor per foreground. As the driver will soon have real descriptor chains, and the DMA descriptor chain register updates itself to point to the current descriptor being processed, this register needs to be reset after a full modeset to point to the first descriptor of the chain. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20211026181240.213806-5-paul@crapouillou.netTested-by: Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Christophe Branchereau <cbranchereau@gmail.com>
-
Paul Cercueil authored
The IPU scaling information is computed in the plane's ".atomic_check" callback, and used in the ".atomic_update" callback. As such, it is state-specific, and should be moved to a private state structure. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20211026181240.213806-4-paul@crapouillou.netTested-by: Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Christophe Branchereau <cbranchereau@gmail.com>
-
Paul Cercueil authored
Until now, the ingenic-drm as well as the ingenic-ipu drivers used to put state-specific information in their respective private structure. Add boilerplate code to support private objects in the two drivers, so that state-specific information can be put in the state-specific private structure. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20211026181240.213806-3-paul@crapouillou.netTested-by: Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Christophe Branchereau <cbranchereau@gmail.com>
-
Paul Cercueil authored
Instead of having one 'hwdesc' variable for the plane #0, one for the plane #1 and one for the palette, use a 'hwdesc[3]' array, where the DMA hardware descriptors are indexed by the plane's number. v2: dma_hwdesc_addr() extended to support palette hwdesc. The palette hwdesc is now hwdesc[3] to simplify things. Add ingenic_drm_configure_hwdesc*() functions to factorize code. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20211026181240.213806-2-paul@crapouillou.netTested-by: Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Christophe Branchereau <cbranchereau@gmail.com>
-
Marcel Ziswiler authored
Today's -next fails building arm64 defconfig as follows: ERROR: modpost: module drm_cma_helper uses symbol dma_buf_vunmap from namespace DMA_BUF, but does not import it. ERROR: modpost: module drm_cma_helper uses symbol dma_buf_vmap from namespace DMA_BUF, but does not import it. Fix this by importing DMA_BUF namespace into drm_cma_helper.ko. Also fix the problem with drm_shmem_helper.ko. Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Fixes: 4b2b5e14 ("drm: Move GEM memory managers into modules") Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211027212506.3418521-1-marcel@ziswiler.com
-
Christian König authored
Makes the handling a bit more complex, but avoids the use of dma_resv_get_excl_unlocked(). Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211005113742.1101-27-christian.koenig@amd.com
-
Colin Ian King authored
The left shift of unsigned int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then assigned to a signed 64 bit integer. In the case where value is 32 or more this can lead to an overflow (value can be in range 0..MAX_CAPSET_ID (63). Fix this by shifting the value 1ULL instead. Addresses-Coverity: ("Uninitentional integer overflow") Fixes: 4fb530e5 ("drm/virtio: implement context init: support init ioctl") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210930102748.16922-1-colin.king@canonical.comSigned-off-by: Gerd Hoffmann <kraxel@redhat.com>
-
Colin Ian King authored
The left shift of unsigned int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then assigned to a signed 64 bit integer. In the case where i is 32 or more this can lead to an overflow. Fix this by shifting the value 1ULL instead. Addresses-Coverity: ("Uninitentional integer overflow") Fixes: 8d6b006e ("drm/virtio: implement context init: handle VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210930101941.16546-1-colin.king@canonical.comSigned-off-by: Gerd Hoffmann <kraxel@redhat.com>
-
Chia-I Wu authored
Add Gurchetan Singh and me as reviewers for virtio-gpu. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Acked-by: Gurchetan Singh <gurchetansingh@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Daniel Stone <daniels@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20211028213446.955338-1-olvaffe@gmail.comSigned-off-by: Gerd Hoffmann <kraxel@redhat.com>
-
- 28 Oct, 2021 2 commits
-
-
Bjorn Andersson authored
When built without CONFIG_PWM there are no references to ti_sn65dsi86_read_u16(), avoid the W=1 build warning by marking the function as __maybe_unused. __maybe_unused is used insted of a #ifdef guard as it looks slighly cleaner and it avoids issues if in the future other permutations of the config options would use the function. Reported-by: kernel test robot <lkp@intel.com> Fixes: cea86c5b ("drm/bridge: ti-sn65dsi86: Implement the pwm_chip") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211028163548.273736-1-bjorn.andersson@linaro.orgSigned-off-by: Robert Foss <robert.foss@linaro.org>
-
Guangming Cao authored
In this patch(https://patchwork.freedesktop.org/patch/310349), it add a new IOCTL to support dma-buf user to set debug name. But it also added a limitation of this IOCTL, it needs the attachments of dmabuf should be empty, otherwise it will fail. For the original series, the idea was that allowing name change mid-use could confuse the users about the dma-buf. However, the rest of the series also makes sure each dma-buf have a unique inode(https://patchwork.freedesktop.org/patch/310387/), and any accounting should probably use that, without relying on the name as much. So, removing this restriction will let dma-buf userspace users to use it more comfortably and without any side effect. Signed-off-by: Guangming Cao <Guangming.Cao@mediatek.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211014102551.54983-1-guangming.cao@mediatek.comReviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
-
- 27 Oct, 2021 7 commits
-
-
Anitha Chrisanthus authored
Enable support for fbcon (framebuffer console). v2: added missing static clk_enable v3: removed module parameter, use fbdev_emulation instead. Use preferred depth of 24 for color depth. (Thomas Z.) Signed-off-by: Anitha Chrisanthus <anitha.chrisanthus@intel.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211019230719.789958-2-anitha.chrisanthus@intel.com
-
Rob Clark authored
Switch to the documented order dsi-host vs bridge probe. Tested-by: Amit Pundir <amit.pundir@linaro.org> Tested-by: Caleb Connolly <caleb.connolly@linaro.org> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-22-maxime@cerno.tech
-
Maxime Ripard authored
Without proper care and an agreement between how DSI hosts and devices drivers register their MIPI-DSI entities and potential components, we can end up in a situation where the drivers can never probe. Most drivers were taking evasive maneuvers to try to workaround this, but not all of them were following the same conventions, resulting in various incompatibilities between DSI hosts and devices. Now that we have a sequence agreed upon and documented, let's convert kirin to it. Acked-by: John Stultz <john.stultz@linaro.org> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-21-maxime@cerno.tech
-
Maxime Ripard authored
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-20-maxime@cerno.tech
-
Maxime Ripard authored
Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device when we detach the bridge. Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-19-maxime@cerno.tech
-
Maxime Ripard authored
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-18-maxime@cerno.tech
-
Maxime Ripard authored
Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device when we detach the bridge. Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-17-maxime@cerno.tech
-