- 23 Aug, 2022 14 commits
-
-
Lyude Paul authored
Post-NV50, the only kind of encoder you'll find for DP connectors on Nvidia GPUs are SORs (serial output resources). Because SORs have fixed associations with their connectors, we can correctly assume that any DP connector on a nvidia GPU will have exactly one SOR encoder routed to it for DisplayPort. Since we're going to need to be able to retrieve this fixed SOR DP encoder much more often as a result of hooking up MST helpers for tracking SST<->MST transitions in atomic states, let's simply cache this encoder in nouveau_connector for any DP connectors on the system to avoid looking it up each time. This isn't safe for NV50 since PIORs then come into play, however there's no code pre-NV50 that would need to look this up anyhow - so it's not really an issue. Signed-off-by:
Lyude Paul <lyude@redhat.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-12-lyude@redhat.com
-
Lyude Paul authored
Currently with the MST helpers we avoid releasing payloads _and_ avoid pulling in the MST state if there aren't any actual payload changes. While we want to keep the first step, we need to now make sure that we're always pulling in the MST state on all modesets that can modify payloads - even if the resulting payloads in the atomic state are identical to the previous ones. This is mainly to make it so that if a CRTC is still assigned to a connector but is set to DPMS off, the CRTC still holds it's payload allocation in the atomic state and still appropriately pulls in the MST state for commit tracking. Otherwise, we'll occasionally forget to update MST payloads from changes caused by non-atomic DPMS changes. Doing this also allows us to track bandwidth limitations in a state correctly even between DPMS changes, so that there's no chance of a simple ->active change being rejected by the atomic check. Signed-off-by:
-
Lyude Paul authored
I'm not sure why, but at the time I originally wrote the find/release time slot helpers I thought we should avoid keeping modeset tracking out of the MST helpers. In retrospect though there's no actual good reason to do this, and the logic has ended up being identical across all the drivers using the helpers. Also, it needs to be fixed anyway so we don't break things when going atomic-only with MST. So, let's just move this code into drm_dp_atomic_release_time_slots() and stop open coding it. Signed-off-by:
-
Lyude Paul authored
As Daniel Vetter pointed out, if we only use the atomic modesetting locks with MST it's technically possible for a driver with non-blocking modesets to race when it comes to MST displays - as we make the mistake of not doing our own CRTC commit tracking in the topology_state object. This could potentially cause problems if something like this happens: * User starts non-blocking commit to disable CRTC-1 on MST topology 1 * User starts non-blocking commit to enable CRTC-2 on MST topology 1 There's no guarantee here that the commit for disabling CRTC-2 will only occur after CRTC-1 has finished, since neither commit shares a CRTC - only the private modesetting object for MST. Keep in mind this likely isn't a problem for blocking modesets, only non-blocking. So, begin fixing this by keeping track of which CRTCs on a topology have changed by keeping track of which CRTCs we release or allocate timeslots on. As well, add some helpers for: * Setting up the drm_crtc_commit structs in the ->commit_setup hook * Waiting for any CRTC dependencies from the previous topology state v2: * Use drm_dp_mst_atomic_setup_commit() directly - Jani Signed-off-by:
-
Lyude Paul authored
We already open-code this quite often, and will be iterating through payloads even more once we've moved all of the payload tracking into the atomic state. So, let's add a helper for doing this. Signed-off-by:
-
Lyude Paul authored
Since we're about to start adding some stuff here, we may as well fill in any missing documentation that we forgot to write. Signed-off-by:
-
Lyude Paul authored
For some reason we mention returning 0 if "slots have been added back to drm_dp_mst_topology_state->avail_slots". This is totally misleading, avail_slots is simply for figuring out the total number of slots available in total on the topology and has no relation to the current payload allocations. So, let's get rid of that comment. Signed-off-by:
-
Lyude Paul authored
VCPI is only sort of the correct term here, originally the majority of this code simply referred to timeslots vaguely as "slots" - and since I started working on it and adding atomic functionality, the name "VCPI slots" has been used to represent time slots. Now that we actually have consistent access to the DisplayPort spec thanks to VESA, I now know this isn't actually the proper term - as the specification refers to these as time slots. Since we're trying to make this code as easy to figure out as possible, let's take this opportunity to correct this nomenclature and call them by their proper name - timeslots. Likewise, we rename various functions appropriately, along with replacing references in the kernel documentation and various debugging messages. It's important to note that this patch series leaves the legacy MST code untouched for the most part, which is fine since we'll be removing it soon anyhow. There should be no functional changes in this series. v2: * Add note that Wayne Lin from AMD suggested regarding slots being between the source DP Tx and the immediate downstream DP Rx Signed-off-by:
-
Lyude Paul authored
In retrospect, the name I chose for this originally is confusing, as there's a lot more info in here then just the VCPI. This really should be called a payload. Let's make it more obvious that this is meant to be related to the atomic state and is about payloads by renaming it to drm_dp_mst_atomic_payload. Also, rename various variables throughout the code that use atomic payloads. Signed-off-by:
-
Lyude Paul authored
This function isn't too confusing if you see the comment around the call-site for it, but if you don't then it's not at all obvious this is meant to copy DRM's payload table over to DC's internal state structs. Seeing this function before finding that comment definitely threw me into a loop a few times. So, let's rename this to make it's purpose more obvious regardless of where in the code you are. Signed-off-by:
-
Lyude Paul authored
Just to make this more clear to outside contributors that these are DC-specific structs, as this also threw me into a loop a number of times before I figured out the purpose of this. Signed-off-by:
-
Steev Klimaszewski authored
Add an eDP panel entry for IVO M133NW4J-R3. Due to lack of documentation, use the delay_200_500_p2e100 timings for now. Signed-off-by:
Steev Klimaszewski <steev@kali.org> [dianders: fixed typo in commit message] Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
wangjianli authored
Delete the redundant word 'at'. Signed-off-by:
wangjianli <wangjianli@cdjrlc.com> Reviewed-by:
Karol Herbst <kherbst@redhat.com> Signed-off-by:
-
Beniamin Sandu authored
This makes the code look cleaner and easier to read. Signed-off-by:
Beniamin Sandu <beniaminsandu@gmail.com> Reviewed-by:
-
- 22 Aug, 2022 12 commits
-
-
Johan Hovold authored
Add an eDP panel entry for AUO B133UAN02.1. Due to lack of documentation, use the delay_200_500_e50 timings like some other AUO entries for now. Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Reviewed-by:
-
Marek Vasut authored
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. Acked-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Liu Ying <victor.liu@nxp.com> Reported-by:
Liu Ying <victor.liu@oss.nxp.com> Tested-by:
Martyn Welch <martyn.welch@collabora.com> Fixes: 9db35bb3 ("drm: lcdif: Add support for i.MX8MP LCDIF variant") Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Alexander Stein <alexander.stein@ew.tq-group.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Liu Ying <victor.liu@nxp.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Marek Vasut <marex@denx.de> Cc: Martyn Welch <martyn.welch@collabora.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Robby Cai <robby.cai@nxp.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Stefan Agner <stefan@agner.ch> Reviewed-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220819140852.255187-4-marex@denx.de
-
Marek Vasut authored
Update debug print to report bridge timings over connector ones. Drop missed comment commit from mxsfb. Acked-by:
-
Marek Vasut authored
Drop the crtc_ prefix from mode, consistently use the plain one. Acked-by:
-
Marek Vasut authored
Drop unneeded headers, sort rest alphabetically, no functional change. Acked-by:
-
Arunpravin Paneer Selvam authored
Apply new intersect and compatible callback instead of having a generic placement range verfications. v2: Added a separate callback for compatiblilty checks (Christian) v3: Cleanups and removal of workarounds Signed-off-by:Christian König <christian.koenig@amd.com> Signed-off-by:
Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by:
-
Arunpravin Paneer Selvam authored
Implemented a new intersect and compatible callback function fetching the start offset from struct ttm_resource. Signed-off-by:
-
Arunpravin Paneer Selvam authored
Implemented a new intersect and compatible callback function fetching start offset from drm buddy allocator. v3: move the bits that are specific to buddy_man (Matthew) v4: consider the block size /range (Matthew) Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
Arunpravin Paneer Selvam authored
Implemented a new intersect and compatible callback function fetching start offset from backend drm buddy allocator. Signed-off-by:
-
Arunpravin Paneer Selvam authored
Implemented a new intersect and compatible callback functions to ttm range manager fetching start offset from drm mm range allocator. Signed-off-by:
-
Arunpravin Paneer Selvam authored
We are adding two new callbacks to ttm resource manager function to handle intersection and compatibility of placement and resources. v2: move the amdgpu and ttm_range_manager changes to separate patches (Christian) v3: rename "intersect" to "intersects" (Matthew) v4: move !place check to the !res if and return false in ttm_resource_compatible() function (Christian) v5: move bits of code from patch number 6 to avoid temporary driver breakup (Christian) Signed-off-by: -
Javier Martinez Canillas authored
Drivers' .remove and .shutdown callbacks are executed on different code paths. The former is called when a device is removed from the bus, while the latter is called at system shutdown time to quiesce the device. This means that some overlap exists between the two, because both have to take care of properly shutting down the hardware. But currently the logic used in these two callbacks isn't consistent in msm drivers, which could lead to kernel panic. For example, on .remove the component is deleted and its .unbind callback leads to the hardware being shutdown but only if the DRM device has been marked as registered. That check doesn't exist in the .shutdown logic and this can lead to the driver calling drm_atomic_helper_shutdown() for a DRM device that hasn't been properly initialized. A situation like this can happen if drivers for expected sub-devices fail to probe, since the .bind callback will never be executed. If that is the case, drm_atomic_helper_shutdown() will attempt to take mutexes that are only initialized if drm_mode_config_init() is called during a device bind. This bug was attempted to be fixed in commit 623f279c ("drm/msm: fix shutdown hook in case GPU components failed to bind"), but unfortunately it still happens in some cases as the one mentioned above, i.e: systemd-shutdown[1]: Powering off. kvm: exiting hardware virtualization platform wifi-firmware.0: Removing from iommu group 12 platform video-firmware.0: Removing from iommu group 10 ------------[ cut here ]------------ WARNING: CPU: 6 PID: 1 at drivers/gpu/drm/drm_modeset_lock.c:317 drm_modeset_lock_all_ctx+0x3c4/0x3d0 ... Hardware name: Google CoachZ (rev3+) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_modeset_lock_all_ctx+0x3c4/0x3d0 lr : drm_modeset_lock_all_ctx+0x48/0x3d0 sp : ffff80000805bb80 x29: ffff80000805bb80 x28: ffff327c00128000 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000001 x24: ffffc95d820ec030 x23: ffff327c00bbd090 x22: ffffc95d8215eca0 x21: ffff327c039c5800 x20: ffff327c039c5988 x19: ffff80000805bbe8 x18: 0000000000000034 x17: 000000040044ffff x16: ffffc95d80cac920 x15: 0000000000000000 x14: 0000000000000315 x13: 0000000000000315 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff80000805bc28 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff327c00128000 x1 : 0000000000000000 x0 : ffff327c039c59b0 Call trace: drm_modeset_lock_all_ctx+0x3c4/0x3d0 drm_atomic_helper_shutdown+0x70/0x134 msm_drv_shutdown+0x30/0x40 platform_shutdown+0x28/0x40 device_shutdown+0x148/0x350 kernel_power_off+0x38/0x80 __do_sys_reboot+0x288/0x2c0 __arm64_sys_reboot+0x28/0x34 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x44/0xec do_el0_svc+0x2c/0xc0 el0_svc+0x2c/0x84 el0t_64_sync_handler+0x11c/0x150 el0t_64_sync+0x18c/0x190 ---[ end trace 0000000000000000 ]--- Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010eab1000 [0000000000000018] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP ... Hardware name: Google CoachZ (rev3+) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ww_mutex_lock+0x28/0x32c lr : drm_modeset_lock_all_ctx+0x1b0/0x3d0 sp : ffff80000805bb50 x29: ffff80000805bb50 x28: ffff327c00128000 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000001 x24: 0000000000000018 x23: ffff80000805bc10 x22: ffff327c039c5ad8 x21: ffff327c039c5800 x20: ffff80000805bbe8 x19: 0000000000000018 x18: 0000000000000034 x17: 000000040044ffff x16: ffffc95d80cac920 x15: 0000000000000000 x14: 0000000000000315 x13: 0000000000000315 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff80000805bc28 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff327c00128000 x1 : 0000000000000000 x0 : 0000000000000018 Call trace: ww_mutex_lock+0x28/0x32c drm_modeset_lock_all_ctx+0x1b0/0x3d0 drm_atomic_helper_shutdown+0x70/0x134 msm_drv_shutdown+0x30/0x40 platform_shutdown+0x28/0x40 device_shutdown+0x148/0x350 kernel_power_off+0x38/0x80 __do_sys_reboot+0x288/0x2c0 __arm64_sys_reboot+0x28/0x34 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x44/0xec do_el0_svc+0x2c/0xc0 el0_svc+0x2c/0x84 el0t_64_sync_handler+0x11c/0x150 el0t_64_sync+0x18c/0x190 Code: aa0103f4 d503201f d2800001 aa0103e3 (c8e37c02) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Kernel Offset: 0x495d77c00000 from 0xffff800008000000 PHYS_OFFSET: 0xffffcd8500000000 CPU features: 0x800,00c2a015,19801c82 Memory Limit: none ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- Fixes: 9d5cbf5f ("drm/msm: add shutdown support for display platform_driver") Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220816134612.916527-1-javierm@redhat.com
-
- 19 Aug, 2022 1 commit
-
-
Danilo Krummrich authored
drmm_universal_plane_alloc() already registers drm_plane_cleanup() as managed release action via drmm_add_action_or_reset(). Hence, drm_plane_cleanup() should not be set as drm_plane_funcs.destroy hook. Fixes: 78476288 ("drm/virtio: plane: use drm managed resources") Reviewed-by:
Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220803145520.1143208-1-dakr@redhat.com
-
- 16 Aug, 2022 1 commit
-
-
Lyude Paul authored
As it turns out: while Nvidia does actually have interlacing knobs on their GPU still pretty much no current GPUs since Volta actually support it. Trying interlacing on these GPUs will result in NVDisplay being quite unhappy like so: nouveau 0000:1f:00.0: disp: chid 0 stat 00004802 reason 4 [INVALID_ARG] mthd 2008 data 00000001 code 00080000 nouveau 0000:1f:00.0: disp: chid 0 stat 10005080 reason 5 [INVALID_STATE] mthd 0200 data 00000001 code 00000001 So let's fix this by following the same behavior Nvidia's driver does and disable interlacing entirely. Signed-off-by:
-
- 15 Aug, 2022 1 commit
-
-
Maíra Canal authored
This driver includes the deprecated OF GPIO header <linux/of_gpio.h> yet fail to use symbols from it, so drop the include. Cc: Emma Anholt <emma@anholt.net> Cc: Maxime Ripard <mripard@kernel.org> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220812205746.609107-6-mairacanal@riseup.net
-
- 11 Aug, 2022 4 commits
-
-
Jouni Högander authored
Instead of using fixed 0 - 512 range use luminance range calculated as a part of edid parsing. As a backup fall back to static 0 - 512. v3: Clean-ups suggested by Jani Nikula v2: Use values calculated during edid parsing Cc: Lyude Paul <lyude@redhat.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
-
Jouni Högander authored
Luminance range calculation was split out into drm_edid.c and is now part of edid parsing. Rely on values calculated during edid parsing and use these for caps->aux_max_input_signal and caps->aux_min_input_signal. v2: Use values calculated during edid parsing Cc: Roman Li <roman.li@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Jouni Högander authored
Split luminance min/max calculation using static hdr metadata from drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:update_connector_ext_caps into drm/drm_edid.c and use it during edid parsing. Calculated range is stored into connector->display_info->luminance_range. Add new data structure (drm_luminance_range_inf) to store luminance range calculated using data from EDID's static hdr metadata block. Add this new struct as a part of drm_display_info struct. v3: Squashed adding drm_luminance_range_info patch here v2: Calculate range during edid parsing Cc: Roman Li <roman.li@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Liang He authored
The reference 'child' in the iteration of for_each_available_child_of_node() is only escaped out into a local variable which is only used to check its value. So we still need to the of_node_put() when breaking of the for_each_available_child_of_node() which will automatically increase and decrease the refcount. Fixes: ca454bd4 ("drm/pl111: Support the Versatile Express") Signed-off-by:
Liang He <windhl@126.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220711131550.361350-1-windhl@126.com
-
- 10 Aug, 2022 7 commits
-
-
Lucas Stach authored
Disable the main link PHYs and put them into reset when the main link is disabled. When the PHYs stay enabled while the rest of the DP link circuits are disabled there is some noise on the data lanes, which some displays try to lock onto, waking them up from their low power state. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Reviewed-by:
-
Lucas Stach authored
The current CLRSIPO count is marginal and does not work with high DSI clock rates. Increase it a bit to allow the DSI link to work at up to 1Gbps lane speed. Signed-off-by:
-
Lucas Stach authored
There is no need to enforce a specific sync signal polarity on the DPI interface, as we can simply tell the TC358767 which polarities it should expect on the input interface. Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Reviewed-by:
-
XueBing Chen authored
The strlcpy should not be used because it doesn't limit the source length. Preferred is strscpy. Signed-off-by:
XueBing Chen <chenxuebing@jari.cn> Signed-off-by:
-
Takashi Iwai authored
BUG_ON() is a tasteless choice as a sanity check for a driver like UDL that isn't really a core code. Replace with WARN_ON() and proper error handling instead. Tested-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
At both suspend and disconnect, we should rather cancel the pending URBs immediately. For the suspend case, the display will be turned off, so it makes no sense to process the rendering. And for the disconnect case, the device may be no longer accessible, hence we shouldn't do any submission. Tested-by:
-
Takashi Iwai authored
We need to wait for finishing to process the all URBs after disabling the pipe; otherwise pending URBs may stray at suspend/resume, leading to a possible memory corruption in a worst case. Tested-by:
-
