#
a20f1b02 |
|
17-Jan-2024 |
Douglas Anderson <dianders@chromium.org> |
drm/bridge: parade-ps8640: Make sure we drop the AUX mutex in the error case After commit 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge is suspended in .post_disable()"), if we hit the error case in ps8640_aux_transfer() then we return without dropping the mutex. Fix this oversight. Fixes: 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge is suspended in .post_disable()") Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240117103502.1.Ib726a0184913925efc7e99c4d4fc801982e1bc24@changeid
|
#
26db46bc |
|
09-Jan-2024 |
Pin-yen Lin <treapking@chromium.org> |
drm/bridge: parade-ps8640: Ensure bridge is suspended in .post_disable() The ps8640 bridge seems to expect everything to be power cycled at the disable process, but sometimes ps8640_aux_transfer() holds the runtime PM reference and prevents the bridge from suspend. Prevent that by introducing a mutex lock between ps8640_aux_transfer() and .post_disable() to make sure the bridge is really powered off. Fixes: 826cff3f7ebb ("drm/bridge: parade-ps8640: Enable runtime power management") Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240109120528.1292601-1-treapking@chromium.org
|
#
024b32db |
|
21-Dec-2023 |
Douglas Anderson <dianders@chromium.org> |
drm/bridge: parade-ps8640: Wait for HPD when doing an AUX transfer Unlike what is claimed in commit f5aa7d46b0ee ("drm/bridge: parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux"), if someone manually tries to do an AUX transfer (like via `i2cdump ${bus} 0x50 i`) while the panel is off we don't just get a simple transfer error. Instead, the whole ps8640 gets thrown for a loop and goes into a bad state. Let's put the function to wait for the HPD (and the magical 50 ms after first reset) back in when we're doing an AUX transfer. This shouldn't actually make things much slower (assuming the panel is on) because we should immediately poll and see the HPD high. Mostly this is just an extra i2c transfer to the bridge. Fixes: f5aa7d46b0ee ("drm/bridge: parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux") Tested-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Pin-yen Lin <treapking@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231221135548.1.I10f326a9305d57ad32cee7f8d9c60518c8be20fb@changeid
|
#
35ba6bd5 |
|
18-Dec-2023 |
Douglas Anderson <dianders@chromium.org> |
drm/bridge: ps8640: Fix size mismatch warning w/ len After commit 26195af57798 ("drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID"), I got an error compiling: error: comparison of distinct pointer types ('typeof (len) *' (aka 'unsigned int *') and 'typeof (msg->size) *' (aka 'unsigned long *')) [-Werror,-Wcompare-distinct-pointer-types] Fix it by declaring the `len` as size_t. The above error only shows up on downstream kernels without commit d03eba99f5bf ("minmax: allow min()/max()/clamp() if the arguments have the same signedness."), but since commit 26195af57798 ("drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID") is a "Fix" that will likely be backported it seems nice to make it easy. ...plus it's more correct to declare `len` as size_t anyway. Fixes: 26195af57798 ("drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID") Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231218090454.1.I5c6eb80b2f746439c4b58efab788e00701d08759@changeid
|
#
3164c8a7 |
|
14-Dec-2023 |
Douglas Anderson <dianders@chromium.org> |
drm/bridge: parade-ps8640: Never store more than msg->size bytes in AUX xfer While testing, I happened to notice a random crash that looked like: Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: drm_dp_dpcd_probe+0x120/0x120 Analysis of drm_dp_dpcd_probe() shows that we pass in a 1-byte buffer (allocated on the stack) to the aux->transfer() function. Presumably if the aux->transfer() writes more than one byte to this buffer then we're in a bad shape. Dropping into kgdb, I noticed that "aux->transfer" pointed at ps8640_aux_transfer(). Reading through ps8640_aux_transfer(), I can see that there are cases where it could write more bytes to msg->buffer than were specified by msg->size. This could happen if the hardware reported back something bogus to us. Let's fix this so we never write more than msg->size bytes. We'll still read all the bytes from the hardware just in case the hardware requires it since the aux transfer data comes through an auto-incrementing register. NOTE: I have no actual way to reproduce this issue but it seems likely this is what was happening in the crash I looked at. Fixes: 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel") Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231214123752.v3.1.I9d1afcaad76a3e2c0ca046dc4adbc2b632c22eda@changeid
|
#
26195af5 |
|
16-Jun-2023 |
Douglas Anderson <dianders@chromium.org> |
drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID In order to read the EDID from an eDP panel, you not only need to power on the bridge chip itself but also the panel. In the ps8640 driver, this was made to work by having the bridge chip manually power the panel on by calling pre_enable() on everything connectorward on the bridge chain. This worked OK, but... ...when trying to do the same thing on ti-sn65dsi86, feedback was that this wasn't a great idea. As a result, we designed the "DP AUX" bus. With the design we ended up with the panel driver itself was in charge of reading the EDID. The panel driver could power itself on and the bridge chip was able to power itself on because it implemented the DP AUX bus. Despite the fact that we came up with a new scheme, implemented in on ti-sn65dsi86, and even implemented it on parade-ps8640, we still kept the old code around. This was because the new scheme required a DT change. Previously the panel was a simple "platform_device" and in DT at the top level. With the new design the panel needs to be listed in DT under the DP controller node. The old code allowed us to properly fetch EDIDs with ps8640 with the old DTs. Unfortunately, the old code stopped working as of commit 102e80d1fa2c ("drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs"). There are cases at bootup where connector->state->state is NULL and the kernel crashed at: * drm_atomic_bridge_chain_pre_enable * drm_atomic_get_old_bridge_state * drm_atomic_get_old_private_obj_state The crash went away at commit 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order") which added a NULL check. However, even though we were no longer crashing the end result was that we weren't actually powering the panel on when we thought we were. Things could end up working (despite warning splats) if userspace was persistent and tried to get the mode again, but it wasn't great. A bit of digging was done to see if there was an easy fix but there was nothing obvious. Instead, the only device using ps8640 the "old" way had its DT updated so that the panel was no longer a simple "platform_deice". See commit c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move display to ps8640 auxiliary bus") and commit 113b5cc06f44 ("arm64: dts: mediatek: mt8173-elm: remove panel model number in DT"). Let's delete the old broken code so nobody gets tempted to copy it or figure out how it works (since it doesn't). NOTE: from a device tree "purist" point of view, we're supposed to keep old device trees working and this patch is technically "against policy". Reasons I'm still proposing it anyway: 1. Officially, old mt8173-elm device trees worked via the "little white lie" approach. The DT would list an arbitrary/representative panel that would be used for power sequencing. The mode information in the panel driver would then be ignored / overridden by the EDID reading code in ps8640. I don't feel too terrible breaking DTs that contained the wrong "compatible" string to begin with. NOTE that any old device trees that _didn't_ lie about their compatible will still work because the mode information will come from the hardcoded panels in panel-edp. 2. The only users of the old code were Chromebooks and Chromebooks don't bake their DTs into the BIOS (they are bundled with the kernel). Thus we don't need to worry about breaking someone using an old DT with a new kernel. 3. The old code was broken anyway. If someone wants to fix the old code instead of deleting it then they have my blessing, but without a proper fix the old code isn't useful. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230616165517.v2.1.I7b8f60b3fbfda068f9bf452d584dc934494bfbfa@changeid
|
#
332af828 |
|
26-May-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
drm: Switch i2c drivers back to use .probe() After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Martyn Welch <martyn.welch@collabora.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230526090709.1517297-1-u.kleine-koenig@pengutronix.de
|
#
42240113 |
|
30-Mar-2023 |
Pin-yen Lin <treapking@chromium.org> |
drm/bridge: ps8640: Use constant sleep time for polling hpd The default hpd_wait_us in panel_edp.c is 2 seconds. This makes the sleep time in the polling of _ps8640_wait_hpd_asserted become 200ms. Change it to a constant 20ms to speed up the function. Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230331030204.1179524-1-treapking@chromium.org
|
#
14aed8ea |
|
23-Mar-2023 |
Pin-yen Lin <treapking@chromium.org> |
drm/bridge: ps8640: Return NULL immediately when EDID read fail drm_edid_read returns NULL on error, so feeding it directly into drm_edid_duplicate may lead to NULL pointer dereference. Add a check to guard this. Fixes: 6a17b4d1b52f ("drm/bridge: ps8640: Add a cache for EDID") Signed-off-by: Pin-yen Lin <treapking@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230324035909.1727356-1-treapking@chromium.org
|
#
6a17b4d1 |
|
14-Mar-2023 |
Pin-yen Lin <treapking@chromium.org> |
drm/bridge: ps8640: Add a cache for EDID When there are multiple EDID reads, the bridge will be repeatedly enabled and disabled. Add a cache for EDID to speed this up. Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Robert Foss <rfoss@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230315035508.2874915-2-treapking@chromium.org
|
#
845e730e |
|
14-Mar-2023 |
Pin-yen Lin <treapking@chromium.org> |
drm/bridge: ps8640: Skip redundant bridge enable Skip the drm_bridge_chain_pre_enable call when the bridge is already pre_enabled. This make pre_enable and post_disable (thus pm_runtime_get/put) symmetric. Fixes: 46f206304db0 ("drm/bridge: ps8640: Rework power state handling") Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Robert Foss <rfoss@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230315035508.2874915-1-treapking@chromium.org
|
#
102e80d1 |
|
05-Dec-2022 |
Sam Ravnborg <sam@ravnborg.org> |
drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs The atomic variants of enable/disable in drm_bridge_funcs are the preferred operations - introduce these. The ps8640 driver used the non-atomic variants of the drm_bridge_chain_pre_enable/ drm_bridge_chain_post_disable - convert these to the atomic variants. v2: - Init state operations in drm_bridge_funcs (Laurent) Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Cc: Jitao Shi <jitao.shi@mediatek.com> Cc: Philip Chen <philipchen@chromium.org> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221205173328.1395350-2-dave.stevenson@raspberrypi.com Signed-off-by: Maxime Ripard <maxime@cerno.tech>
|
#
b1d2751c |
|
17-Nov-2022 |
Drew Davenport <ddavenport@chromium.org> |
drm/bridge/parade-ps8640: Extend autosuspend Same change as done for panel-samsung-atna33xc20. Extend the autosuspend delay to avoid oscillating between power status during boot. Signed-off-by: Drew Davenport <ddavenport@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221117133655.4.If6153da69ec4bc9e83d5f095ef6e6b07283940a5@changeid
|
#
562d2dd8 |
|
29-Sep-2022 |
Jason Yen <jason.yen@paradetech.corp-partner.google.com> |
drm/bridge: ps8640: Add software to support aux defer This chip can not handle aux defer if the host directly program its aux registers to access edid/dpcd. So we need let software to handle the aux defer situation. Signed-off-by: Jason Yen <jason.yen@paradetech.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220930042506.2529522-1-jason.yen@paradetech.corp-partner.google.com
|
#
cb8e30dd |
|
17-Oct-2022 |
Douglas Anderson <dianders@chromium.org> |
drm/bridge: ps8640: Add back the 50 ms mystery delay after HPD Back in commit 826cff3f7ebb ("drm/bridge: parade-ps8640: Enable runtime power management") we removed a mysterious 50 ms delay because "Parade's support [couldn't] explain what the delay [was] for". While I'm always a fan of removing mysterious delays, I suspect that we need this mysterious delay to avoid some problems. Specifically, what I found recently is that on sc7180-trogdor-homestar sometimes the AUX backlight wasn't initializing properly. Some debugging showed that the drm_dp_dpcd_read() function that the AUX backlight driver was calling was returning bogus data about 1% of the time when I booted up. This confused drm_panel_dp_aux_backlight(). From continued debugging: - If I retried the read then the read worked just fine. - If I added a loop to perform the same read that drm_panel_dp_aux_backlight() was doing 30 times at bootup I could see that some percentage of the time the first read would give bogus data but all 29 additional reads would always be fine. - If I added a large delay _after_ powering on the panel but before powering on PS8640 I could still reproduce the problem. - If I added a delay after PS8640 powered on then I couldn't reproduce the problem. - I couldn't reproduce the problem on a board with the same panel but the ti-sn65dsi86 bridge chip. To me, the above indicated that there was a problem with PS8640 and not the panel. I don't really have any insight into what's going on in the MCU, but my best guess is that when the MCU itself sees the HPD go high that it does some AUX transfers itself and this is confusing things. Let's go back and add back in the mysterious 50 ms delay. We only want to do this the first time we see HPD go high after booting the MCU, not every time we double-check HPD. With this, the backlight initializes reliably on homestar. Fixes: 826cff3f7ebb ("drm/bridge: parade-ps8640: Enable runtime power management") Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221017121813.1.I59700c745fbc31559a5d5c8e2a960279c751dbd5@changeid
|
#
55453c09 |
|
15-Aug-2022 |
Hsin-Yi Wang <hsinyi@chromium.org> |
drm/bridge: ps8640: Add double reset T4 and T5 to power-on sequence The double reset power-on sequence is a workaround for the hardware flaw in some chip that SPI Clock output glitch and cause internal MPU unable to read firmware correctly. The sequence is suggested in ps8640 application note. Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Rock Chiu <rock.chiu@paradetech.corp-partner.google.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220815093905.134164-1-hsinyi@chromium.org
|
#
fc94224c |
|
21-Jul-2022 |
Chen-Yu Tsai <wenst@chromium.org> |
drm/bridge: parade-ps8640: Fix regulator supply order The datasheet says that VDD12 must be enabled and at full voltage before VDD33 is enabled. Reorder the bulk regulator supply names so that VDD12 is enabled before VDD33. Any enable ramp delays should be handled by setting proper constraints on the regulators. Fixes: bc1aee7fc8f0 ("drm/bridge: Add I2C based driver for ps8640 bridge") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220721092258.3397461-1-wenst@chromium.org
|
#
f5aa7d46 |
|
14-Jun-2022 |
Douglas Anderson <dianders@chromium.org> |
drm/bridge: parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux This implements the callback added by the patch ("drm/dp: Add wait_hpd_asserted() callback to struct drm_dp_aux"). With this change and all the two "DP AUX Endpoint" drivers changed to use wait_hpd_asserted(), we no longer need to have an long delay in the AUX transfer function. It's up to the panel code to make sure that the panel is powered now. If someone tried to call the aux transfer function without making sure the panel is powered we'll just get a normal transfer failure. We'll still keep the wait for HPD in the pre_enable() function. Though it's probably not actually needed there, this driver is used in the old mode (pre-DP AUX Endpoints) and it may be important for those cases. If nothing else, it shouldn't cause any big problems. NOTE: When handling the timeout for HPD we start the timer _after_ we've runtime resumed the device. This is definitely important for the panel on my homestar which comes up 170 ms after we start timing (the panel specifies 200 ms max). It's a little unclear how much of this extra time is due to some internal state machine in the parade firmware vs. debouncing but it seems to work for the two test cases I have to do it this way. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220614145327.v4.4.Ie827321ce263be52fdb8c1276f6f8cc00d78029f@changeid
|
#
255490f9 |
|
13-Jun-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Drop drm_edid.h from drm_crtc.h drm_crtc.h has no need for drm_edid.h, so don't include it. Avoids useless rebuilds of the entire universe when touching drm_edid.h. Quite a few placs do currently depend on drm_edid.h without actually including it directly. All of those need to be fixed up. v2: Fix up i915 and msm some more v3: Fix alphabetical ordering (Sam) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220614090245.30283-1-ville.syrjala@linux.intel.com Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Jani Nikula <jani.nikula@intel.com>
|
#
10e619f1 |
|
10-May-2022 |
Douglas Anderson <dianders@chromium.org> |
drm/bridge: parade-ps8640: Handle DP AUX more properly While it works, for the most part, to assume that the panel has finished probing when devm_of_dp_aux_populate_ep_devices() returns, it's a bit fragile. This is talked about at length in commit a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev"). When reviewing the ps8640 code, I managed to convince myself that it was OK not to worry about it there and that maybe it wasn't really _that_ fragile. However, it turns out that it really is. Simply hardcoding panel_edp_probe() to return -EPROBE_DEFER was enough to put the boot process into an infinite loop. I believe this manages to trip the same issues that we used to trip with the main MSM code where something about our actions trigger Linux to re-probe previously deferred devices right away and each time we try again we re-trigger Linux to re-probe. Let's fix this using the callback introduced in the patch ("drm/dp: Callbacks to make it easier for drivers to use DP AUX bus properly"). When using the new callback, we have to be a little careful. The probe_done() callback is no longer always called in the context of our probe routine. That means we can't rely on being able to return -EPROBE_DEFER from it. We re-jigger the order of things a bit to account for that. With this change, the device still boots (though obviously the panel doesn't come up) if I force panel-edp to always return -EPROBE_DEFER. If I fake it and make the panel probe exactly once it also works. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220510122726.v3.4.Ia6324ebc848cd40b4dbd3ad3289a7ffb5c197779@changeid
|
#
e0905322 |
|
28-Apr-2022 |
Minghao Chi <chi.minghao@zte.com.cn> |
drm/bridge: simplify the return expression of ps8640_bridge_host_attach Simplify the return expression. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220429055145.3852271-1-chi.minghao@zte.com.cn
|
#
da68386d |
|
21-Apr-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm: Rename dp/ to display/ Rename dp/ to display/ to account for additional display-related helpers, such as HDMI. Update all related include statements. No functional changes. Various drivers, such as i915 and amdgpu, use similar naming scheme by putting code for video-output standards into a local display/ directory. The new directory's name is aligned with this convention. v2: * update commit message (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-3-tzimmermann@suse.de
|
#
5486eac8 |
|
28-Feb-2022 |
José Expósito <jose.exposito89@gmail.com> |
drm/bridge: parade-ps8640: switch to devm_drm_of_get_bridge The function "drm_of_find_panel_or_bridge" has been deprecated in favor of "devm_drm_of_get_bridge". Switch to the new function and reduce boilerplate. Signed-off-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220228183131.23494-1-jose.exposito89@gmail.com
|
#
032a1259 |
|
13-Jan-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/dp: Move DisplayPort AUX bus helpers into dp/ Move drm_dp_aux_bus.c and its header file into the DP subdirectory and update all users. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220114114535.29157-6-tzimmermann@suse.de
|
#
5b529e8d |
|
13-Jan-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/dp: Move public DisplayPort headers into dp/ Move all public DisplayPort headers into dp/ and update users. No functional changes. v3: * rebased onto latest drm-tip Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220114114535.29157-5-tzimmermann@suse.de
|
#
9294914d |
|
05-Jan-2022 |
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> |
drm/bridge: parade-ps8640: Link device to ensure suspend/resume order Entering suspend while the display attached to this bridge is still on makes the resume sequence to resume the bridge first, display last: when this happens, we get a timeout while resuming the bridge, as its MCU will get stuck due to the display being unpowered. On the other hand, on mt8173-elm, closing the lid makes the display to get powered off first, bridge last, so at resume time the sequence is swapped (compared to the first example) and everything just works as expected. Add a stateless device link to the DRM device that this bridge belongs to, ensuring a correct resume sequence and solving the unability to correctly resume bridge operation in the first mentioned example. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220105090802.73564-1-angelogioacchino.delregno@collabora.com Reviewed-by: Robert Foss <robert.foss@linaro.org>
|
#
f8378c04 |
|
06-Dec-2021 |
Douglas Anderson <dianders@chromium.org> |
drm/bridge: parade-ps8640: Add backpointer to drm_device in drm_dp_aux When we added the support for the AUX channel in commit 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel") we forgot to set "drm_dev" to avoid the warning splat at the beginning of drm_dp_aux_register(). Since everything was working I guess I never noticed the splat when testing against mainline. In any case, it's easy to fix. This is basically just like commit 6cba3fe43341 ("drm/dp: Add backpointer to drm_device in drm_dp_aux") but just for the parade-ps8640. Fixes: 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211206162907.1.I1f5d1eba741e4663050ec1b8e39a753f6e42e38b@changeid
|
#
aa70a099 |
|
12-Nov-2021 |
yangcong <yangcong5@huaqin.corp-partner.google.com> |
drm/bridge: parade-ps8640: Fix additional suspend/resume at bootup Through log and waveform, we can see that there will be additional suspend/resume when booting. This timing does not meet the ps8640 spec. It seems that the delay of 500ms does not satisfied drm_panel_get_modes. I increased it to 900ms and it seems that this problem can be solved. To be safe, I'd just round up to a full 1000. Signed-off-by: yangcong <yangcong5@huaqin.corp-partner.google.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211112084302.2447931-1-yangcong5@huaqin.corp-partner.google.com
|
#
e9d9f958 |
|
28-Oct-2021 |
Philip Chen <philipchen@chromium.org> |
drm/bridge: parade-ps8640: Populate devices on aux-bus Conventionally, panel is listed under the root of the device tree. When userland asks for display mode, ps8640 bridge is responsible for returning EDID when ps8640_bridge_get_edid() is called. Now enable a new option of listing panel under "aux-bus" of ps8640 bridge node in the device tree. In this case, panel driver can retrieve EDID by triggering AUX transactions, without ps8640_bridge_get_edid() calls at all. To prevent the "old" and "new" options from interfering with each other's logic flow, disable DRM_BRIDGE_OP_EDID when the new option is taken. Signed-off-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211028105754.v5.2.I09899dea340f11feab97d719cb4b62bef3179e4b@changeid
|
#
826cff3f |
|
28-Oct-2021 |
Philip Chen <philipchen@chromium.org> |
drm/bridge: parade-ps8640: Enable runtime power management Fit ps8640 driver into runtime power management framework: First, break _poweron() to 3 parts: (1) turn on power and wait for ps8640's internal MCU to finish init (2) check panel HPD (which is proxied by GPIO9) (3) the other configs. As runtime_resume() can be called before panel is powered, we only add (1) to _resume() and leave (2)(3) to _pre_enable(). We also add (2) to _aux_transfer() as we want to ensure panel HPD is asserted before we start AUX CH transactions. Second, the original driver has a mysterious delay of 50 ms between (2) and (3). Since Parade's support can't explain what the delay is for, and we don't see removing the delay break any boards at hand, remove the delay to fit into this driver change. In addition, rename "powered" to "pre_enabled" and don't check for it in the pm_runtime calls. The pm_runtime calls are already refcounted so there's no reason to check there. The other user of "powered", _get_edid(), only cares if pre_enable() has already been called. Lastly, change some existing DRM_...() logging to dev_...() along the way, since DRM_...() seem to be deprecated in [1]. [1] https://patchwork.freedesktop.org/patch/454760/ Signed-off-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> [dianders: fixed whitespace warning reported by dim tool] Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211028105754.v5.1.I828f5db745535fb7e36e8ffdd62d546f6d08b6d1@changeid
|
#
7abbc26f |
|
25-Oct-2021 |
Maxime Ripard <maxime@cerno.tech> |
drm/bridge: ps8640: Register and attach our DSI device at probe 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-13-maxime@cerno.tech
|
#
fe93ae80 |
|
25-Oct-2021 |
Maxime Ripard <maxime@cerno.tech> |
drm/bridge: ps8640: Switch to devm MIPI-DSI helpers Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device on removal. Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-12-maxime@cerno.tech
|
#
13afcdd7 |
|
21-Sep-2021 |
Philip Chen <philipchen@chromium.org> |
drm/bridge: parade-ps8640: Add support for AUX channel Implement the first version of AUX support, which will be useful as we expand the driver to support varied use cases. Signed-off-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> [dianders: whitespace fixes reported by dim apply-branch] Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210921110556.v6.2.I1d6ea362dc76efa77cca2b46253d31b7651eaf17@changeid
|
#
692d8db0 |
|
21-Sep-2021 |
Philip Chen <philipchen@chromium.org> |
drm/bridge: parade-ps8640: Use regmap APIs Replace the direct i2c access (i2c_smbus_* functions) with regmap APIs, which will simplify the future update on ps8640 driver. Signed-off-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> [dianders: whitespace fixes reported by dim apply-branch] Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210921110556.v6.1.I2351df94f18d5d8debc22d4d100f36fac560409a@changeid
|
#
28210a3f |
|
24-Aug-2021 |
Philip Chen <philipchen@chromium.org> |
drm/bridge: parade-ps8640: Reorg the macros Reorg the macros as follows: (1) Group the registers on the same page together. (2) Group the register and its bit operation together while indenting the macros of the bit operation with one space. Also fix a misnomer for the number of mipi data lanes. Signed-off-by: Philip Chen <philipchen@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210824181140.v2.1.I8ead7431357409f2526e5739ec5bc3ddfd242243@changeid
|
#
46f20630 |
|
27-Aug-2020 |
Enric Balletbo i Serra <enric.balletbo@collabora.com> |
drm/bridge: ps8640: Rework power state handling The get_edid() callback can be triggered anytime by an ioctl, i.e drm_mode_getconnector (ioctl) -> drm_helper_probe_single_connector_modes -> drm_bridge_connector_get_modes -> ps8640_bridge_get_edid Actually if the bridge pre_enable() function was not called before get_edid(), the driver will not be able to get the EDID properly and display will not work until a second get_edid() call is issued and if pre_enable() is called before. The side effect of this, for example, is that you see anything when `Frecon` starts, neither the splash screen, until the graphical session manager starts. To fix this we need to make sure that all we need is enabled before reading the EDID. This means the following: 1. If get_edid() is called before having the device powered we need to power on the device. In such case, the driver will power off again the device. 2. If get_edid() is called after having the device powered, all should just work. We added a powered flag in order to avoid recurrent calls to ps8640_bridge_poweron() and unneeded delays. 3. This seems to be specific for this device, but we need to make sure the panel is powered on before do a power on cycle on this device. Otherwise the device fails to retrieve the EDID. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Bilal Wasim <bwasim.lkml@gmail.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200827085911.944899-2-enric.balletbo@collabora.com
|
#
94d4c132 |
|
26-Aug-2020 |
Enric Balletbo i Serra <enric.balletbo@collabora.com> |
drm/bridge: ps8640: Print an error if VDO control fails Print an error message inside ps8640_bridge_vdo_control() function when it fails so we can simplify a bit the callers, they will only need to check the error code. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Bilal Wasim <bwasim.lkml@gmail.com> Tested-by: Bilal Wasim <bwasim.lkml@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200826081526.674866-5-enric.balletbo@collabora.com
|
#
812a65ba |
|
26-Aug-2020 |
Enric Balletbo i Serra <enric.balletbo@collabora.com> |
drm/bridge: ps8640: Return an error for incorrect attach flags Bridge drivers that implement the new model only shall return an error from their attach() handler when the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is not set. So make sure we return an error because only the new drm_bridge model is supported. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Bilal Wasim <bwasim.lkml@gmail.com> Tested-by: Bilal Wasim <bwasim.lkml@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200826081526.674866-4-enric.balletbo@collabora.com
|
#
d82c12ab |
|
26-Aug-2020 |
Enric Balletbo i Serra <enric.balletbo@collabora.com> |
drm/bridge: ps8640: Get the EDID from eDP control The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the .get_edid callback and set the flag to indicate the core to use it. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200826081526.674866-3-enric.balletbo@collabora.com
|
#
4606ed7e |
|
16-Apr-2020 |
Enric Balletbo i Serra <enric.balletbo@collabora.com> |
drm/bridge: ps8640: Let panel to set the connector type The panel connector type should be set by the panel not the bridge, so remove the connector_type assignment. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200416164404.2418426-2-enric.balletbo@collabora.com
|
#
a25b988f |
|
26-Feb-2020 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
drm/bridge: Extend bridge API to disable connector creation Most bridge drivers create a DRM connector to model the connector at the output of the bridge. This model is historical and has worked pretty well so far, but causes several issues: - It prevents supporting more complex display pipelines where DRM connector operations are split over multiple components. For instance a pipeline with a bridge connected to the DDC signals to read EDID data, and another one connected to the HPD signal to detect connection and disconnection, will not be possible to support through this model. - It requires every bridge driver to implement similar connector handling code, resulting in code duplication. - It assumes that a bridge will either be wired to a connector or to another bridge, but doesn't support bridges that can be used in both positions very well (although there is some ad-hoc support for this in the analogix_dp bridge driver). In order to solve these issues, ownership of the connector should be moved to the display controller driver (where it can be implemented using helpers provided by the core). Extend the bridge API to allow disabling connector creation in bridge drivers as a first step towards the new model. The new flags argument to the bridge .attach() operation allows instructing the bridge driver to skip creating a connector. Unconditionally set the new flags argument to 0 for now to keep the existing behaviour, and modify all existing bridge drivers to return an error when connector creation is not requested as they don't support this feature yet. The change is based on the following semantic patch, with manual review and edits. @ rule1 @ identifier funcs; identifier fn; @@ struct drm_bridge_funcs funcs = { ..., .attach = fn }; @ depends on rule1 @ identifier rule1.fn; identifier bridge; statement S, S1; @@ int fn( struct drm_bridge *bridge + , enum drm_bridge_attach_flags flags ) { ... when != S + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) { + DRM_ERROR("Fix bridge driver to make connector optional!"); + return -EINVAL; + } + S1 ... } @ depends on rule1 @ identifier rule1.fn; identifier bridge, flags; expression E1, E2, E3; @@ int fn( struct drm_bridge *bridge, enum drm_bridge_attach_flags flags ) { <... drm_bridge_attach(E1, E2, E3 + , flags ) ...> } @@ expression E1, E2, E3; @@ drm_bridge_attach(E1, E2, E3 + , 0 ) Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-10-laurent.pinchart@ideasonboard.com
|
#
bc1aee7f |
|
30-Dec-2019 |
Jitao Shi <jitao.shi@mediatek.com> |
drm/bridge: Add I2C based driver for ps8640 bridge This patch adds drm_bridge driver for parade DSI to eDP bridge chip. Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> [uli: followed API changes, removed FW update feature] Signed-off-by: Ulrich Hecht <uli@fpond.eu> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191230090419.137141-3-enric.balletbo@collabora.com
|