- 14 Oct, 2022 4 commits
-
-
Aashish Sharma authored
Rectify the below smatch warning: drivers/gpu/drm/msm/msm_gem_submit.c:963 msm_ioctl_gem_submit() warn: variable dereferenced before check 'submit' 'submit' is normally error pointer or valid, so remove its NULL initializer as it's confusing and also remove a redundant check for it's value. Signed-off-by:
Aashish Sharma <shraash@google.com> Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/506653/ Link: https://lore.kernel.org/r/20221011075519.3111928-1-shraash@google.comSigned-off-by:
Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Technically it worked as it was before, only because it was using the _safe version of the iterator. But it is sloppy practice to leave dangling pointers. Signed-off-by:
Chia-I Wu <olvaffe@gmail.com> Reviewed-by:
Akhil P Oommen <quic_akhilpo@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/507017/ Link: https://lore.kernel.org/r/20221013225520.371226-4-robdclark@gmail.com
-
Rob Clark authored
Some buffers are unused on certain sub-generations of a6xx. So just skip them. Signed-off-by:
-
Rob Clark authored
adreno_show_object() is a trap! It will re-allocate the pointer it is passed on first call, when the data is ascii85 encoded, using kvmalloc/ kvfree(). Which means the data *passed* to it must be kvmalloc'd, ie. we cannot use the state_kcalloc() helper. This partially reverts commit ec8f1813 ("drm/msm/a6xx: Replace kcalloc() with kvzalloc()"), but adds the missing kvfree() to fix the memory leak that was present previously. And adds a warning comment. Fixes: ec8f1813 ("drm/msm/a6xx: Replace kcalloc() with kvzalloc()") Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/20Signed-off-by:
-
- 30 Sep, 2022 14 commits
-
-
Kuogee Hsieh authored
DOWNSPREAD_CTRL (0x107) shall be cleared to 0 upon power-on reset or an upstream device disconnect. This patch will enforce this rule by always cleared DOWNSPREAD_CTRL register to 0 before start link training. At rare case that DP MSA timing parameters may be mis-interpreted by the sink which causes audio sampling rate be calculated wrongly and cause audio did not work at sink if DOWNSPREAD_CTRL register is not cleared to 0. Changes in v2: 1) fix spelling at commit text 2) merge ssc variable into encoding[0] Changes in v3: -- correct spelling of DOWNSPREAD_CTRL -- replace err with len of ssize_t Changes in v4: -- split into 2 patches Signed-off-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: c943b494 ("drm/msm/dp: add displayPort driver support") Patchwork: https://patchwork.freedesktop.org/patch/502532/ Link: https://lore.kernel.org/r/1662999830-13916-2-git-send-email-quic_khsieh@quicinc.comSigned-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com>
-
Johan Hovold authored
Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred. This is specifically true for the HDMI IRQ, which will otherwise remain requested so that the next bind attempt fails when requesting the IRQ a second time. Fix this by tying the device-managed lifetime of the HDMI IRQ to the DRM device so that it is released when bind fails. Fixes: 067fef37 ("drm/msm/hdmi: refactor bind/init") Cc: stable@vger.kernel.org # 3.19 Reviewed-by:
Johan Hovold <johan+linaro@kernel.org> Tested-by:
-
Johan Hovold authored
Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred. This can lead resource leaks or failure to bind the aggregate device when binding is later retried and a second attempt to allocate the resources is made. For the DP bridges, previously allocated bridges will leak on probe deferral. Fix this by amending the DP parser interface and tying the lifetime of the bridge device to the DRM device rather than DP platform device. Fixes: c3bf8e21 ("drm/msm/dp: Add eDP support via aux_bus") Cc: stable@vger.kernel.org # 5.19 Reviewed-by:
-
Johan Hovold authored
Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred. This can lead resource leaks or failure to bind the aggregate device when binding is later retried and a second attempt to allocate the resources is made. For the DP aux-bus, an attempt to populate the bus a second time will simply fail ("DP AUX EP device already populated"). Fix this by tying the lifetime of the EP device to the DRM device rather than DP controller platform device. Fixes: c3bf8e21 ("drm/msm/dp: Add eDP support via aux_bus") Cc: stable@vger.kernel.org # 5.19 Signed-off-by:Douglas Anderson <dianders@chromium.org> Tested-by:
-
Johan Hovold authored
Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred. This is specifically true for the DP IRQ, which will otherwise remain requested so that the next bind attempt fails when requesting the IRQ a second time. Since commit c3bf8e21 ("drm/msm/dp: Add eDP support via aux_bus") this can happen when the aux-bus panel driver has not yet been loaded so that probe is deferred. Fix this by tying the device-managed lifetime of the DP IRQ to the DRM device so that it is released when bind fails. Fixes: c943b494 ("drm/msm/dp: add displayPort driver support") Cc: stable@vger.kernel.org # 5.10 Reviewed-by:
-
Johan Hovold authored
Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Fixes: a3376e3e ("drm/msm: convert to drm_bridge") Cc: stable@vger.kernel.org # 3.12 Signed-off-by:
-
Johan Hovold authored
Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Fixes: a689554b ("drm/msm: Initial add DSI connector support") Cc: stable@vger.kernel.org # 4.1 Signed-off-by:
-
Johan Hovold authored
Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Fixes: 8a3b4c17 ("drm/msm/dp: employ bridge mechanism for display enable and disable") Cc: stable@vger.kernel.org # 5.17 Signed-off-by:
-
Johan Hovold authored
The bridge counter was never reset when tearing down the DRM device so that stale pointers to deallocated structures would be accessed on the next tear down (e.g. after a second late bind deferral). Given enough bridges and a few probe deferrals this could currently also lead to data beyond the bridge array being corrupted. Fixes: d28ea556 ("drm/msm: properly add and remove internal bridges") Fixes: a3376e3e ("drm/msm: convert to drm_bridge") Cc: stable@vger.kernel.org # 3.12 Reviewed-by:
-
Nathan Huckleberry authored
The mode_valid field in drm_connector_helper_funcs is expected to be of type: enum drm_mode_status (* mode_valid) (struct drm_connector *connector, struct drm_display_mode *mode); The mismatched return type breaks forward edge kCFI since the underlying function definition does not match the function hook definition. The return type of mdp4_lvds_connector_mode_valid should be changed from int to enum drm_mode_status. Reported-by:Dan Carpenter <error27@gmail.com> Link: https://github.com/ClangBuiltLinux/linux/issues/1703 Cc: llvm@lists.linux.dev Signed-off-by:
Nathan Huckleberry <nhuck@google.com> Fixes: 3e87599b ("drm/msm/mdp4: add LVDS panel support") Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Patchwork: https://patchwork.freedesktop.org/patch/502878/ Link: https://lore.kernel.org/r/20220913205551.155128-1-nhuck@google.comSigned-off-by:
-
Kuogee Hsieh authored
DRM commit_tails() will disable downstream crtc/encoder/bridge if both disable crtc is required and crtc->active is set before pushing a new frame downstream. There is a rare case that user space display manager issue an extra screen update immediately followed by close DRM device while down stream display interface is disabled. This extra screen update will timeout due to the downstream interface is disabled but will cause crtc->active be set. Hence the followed commit_tails() called by drm_release() will pass the disable downstream crtc/encoder/bridge conditions checking even downstream interface is disabled. This cause the crash to happen at dp_bridge_disable() due to it trying to access the main link register to push the idle pattern out while main link clocks is disabled. This patch adds atomic_check to prevent the extra frame will not be pushed down if display interface is down so that crtc->active will not be set neither. This will fail the conditions checking of disabling down stream crtc/encoder/bridge which prevent drm_release() from calling dp_bridge_disable() so that crash at dp_bridge_disable() prevented. There is no protection in the DRM framework to check if the display pipeline has been already disabled before trying again. The only check is the crtc_state->active but this is controlled by usermode using UAPI. Hence if the usermode sets this and then crashes, the driver needs to protect against double disable. SError Interrupt on CPU7, code 0x00000000be000411 -- SError CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google Lazor (rev3 - 8) (DT) pstate: a04000c9 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __cmpxchg_case_acq_32+0x14/0x2c lr : do_raw_spin_lock+0xa4/0xdc sp : ffffffc01092b6a0 x29: ffffffc01092b6a0 x28: 0000000000000028 x27: 0000000000000038 x26: 0000000000000004 x25: ffffffd2973dce48 x24: 0000000000000000 x23: 00000000ffffffff x22: 00000000ffffffff x21: ffffffd2978d0008 x20: ffffffd2978d0008 x19: ffffff80ff759fc0 x18: 0000000000000000 x17: 004800a501260460 x16: 0441043b04600438 x15: 04380000089807d0 x14: 07b0089807800780 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000438 x10: 00000000000007d0 x9 : ffffffd2973e09e4 x8 : ffffff8092d53300 x7 : ffffff808902e8b8 x6 : 0000000000000001 x5 : ffffff808902e880 x4 : 0000000000000000 x3 : ffffff80ff759fc0 x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffffff80ff759fc0 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google Lazor (rev3 - 8) (DT) Call trace: dump_backtrace.part.0+0xbc/0xe4 show_stack+0x24/0x70 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 panic+0x14c/0x32c nmi_panic+0x58/0x7c arm64_serror_panic+0x78/0x84 do_serror+0x40/0x64 el1h_64_error_handler+0x30/0x48 el1h_64_error+0x68/0x6c __cmpxchg_case_acq_32+0x14/0x2c _raw_spin_lock_irqsave+0x38/0x4c lock_timer_base+0x40/0x78 __mod_timer+0xf4/0x25c schedule_timeout+0xd4/0xfc __wait_for_common+0xac/0x140 wait_for_completion_timeout+0x2c/0x54 dp_ctrl_push_idle+0x40/0x88 dp_bridge_disable+0x24/0x30 drm_atomic_bridge_chain_disable+0x90/0xbc drm_atomic_helper_commit_modeset_disables+0x198/0x444 msm_atomic_commit_tail+0x1d0/0x374 commit_tail+0x80/0x108 drm_atomic_helper_commit+0x118/0x11c drm_atomic_commit+0xb4/0xe0 drm_client_modeset_commit_atomic+0x184/0x224 drm_client_modeset_commit_locked+0x58/0x160 drm_client_modeset_commit+0x3c/0x64 __drm_fb_helper_restore_fbdev_mode_unlocked+0x98/0xac drm_fb_helper_set_par+0x74/0x80 drm_fb_helper_hotplug_event+0xdc/0xe0 __drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xac drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x2c drm_fb_helper_lastclose+0x20/0x2c drm_lastclose+0x44/0x6c drm_release+0x88/0xd4 __fput+0x104/0x220 ____fput+0x1c/0x28 task_work_run+0x8c/0x100 do_exit+0x450/0x8d0 do_group_exit+0x40/0xac __wake_up_parent+0x0/0x38 invoke_syscall+0x84/0x11c el0_svc_common.constprop.0+0xb8/0xe4 do_el0_svc+0x8c/0xb8 el0_svc+0x2c/0x54 el0t_64_sync_handler+0x120/0x1c0 el0t_64_sync+0x190/0x194 SMP: stopping secondary CPUs Kernel Offset: 0x128e800000 from 0xffffffc008000000 PHYS_OFFSET: 0x80000000 CPU features: 0x800,00c2a015,19801c82 Memory Limit: none Changes in v2: -- add more commit text Changes in v3: -- add comments into dp_bridge_atomic_check() Changes in v4: -- rewording the comment into dp_bridge_atomic_check() Changes in v5: -- removed quote x at end of commit text Changes in v6: -- removed quote x at end of comment in dp_bridge_atomic_check() Fixes: 8a3b4c17 ("drm/msm/dp: employ bridge mechanism for display enable and disable") Reported-by:
Leonard Lausen <leonard@lausen.nl> Suggested-by:
Rob Clark <robdclark@gmail.com> Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/17Signed-off-by:
-
Akhil P Oommen authored
In adreno_unbind, we should clean up gpu device's drvdata to avoid accessing a stale pointer during system suspend. Also, check for NULL ptr in both system suspend/resume callbacks. Signed-off-by:
-
Akhil P Oommen authored
In order to reduce chance of allocation failure while capturing a6xx gpu state, use kvzalloc() instead of kcalloc() in state_kcalloc(). Indirectly, this patch helps to fix leaking memory allocated for gmu_debug object. Fixes: b859f9b0 (drm/msm/gpu: Snapshot GMU debug buffer) Signed-off-by:
-
Rob Clark authored
The introduction of "drm/msm/gem: Evict active GEM objects when necessary" exposes a problem with "drm/msm/gem: Unpin buffers earlier", in that we need to keep the object pinned in the time the submit is queued up in the gpu scheduler. Otherwise the shrinker will see it as a thing that can be evicted if we wait for it to be signaled. But if the shrinker path is waiting on it with the obj lock held, the job cannot be scheduled, as that also requires briefly grabbing the obj lock, leading to deadlock. (Not to mention, we don't want the shrinker to evict an obj queued up in gpu scheduler.) Fixes: f371bcc0 ("drm/msm/gem: Unpin buffers earlier") Fixes: 025d2723 ("drm/msm/gem: Evict active GEM objects when necessary") Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/19Signed-off-by:
-
- 18 Sep, 2022 22 commits
-
-
Dmitry Baryshkov authored
On MSM8996 the HDMI PHY provides the PLL clock to the MMCC. As we are preparing to convert the MSM8996 to use DT clocks properties (rather than global clock names), register the OF clock provider. While we are at it, also change the driver to use clk_parent_data rather parent_names to setup a link to the XO clock. Signed-off-by:
-
Dmitry Baryshkov authored
As the QMP HDMI PHY is a clock provider, add constant #clock-cells property. For the compatibility with older DTs the property is not marked as required. Also add the XO clock to the list of the clocks used by the driver. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Patchwork: https://patchwork.freedesktop.org/patch/492316/ Link: https://lore.kernel.org/r/20220704161148.814510-2-dmitry.baryshkov@linaro.orgSigned-off-by:
-
Nathan Chancellor authored
Clang warns: drivers/gpu/drm/msm/dsi/dsi_host.c:1903:14: error: variable 'device_node' is uninitialized when used here [-Werror,-Wuninitialized] of_node_put(device_node); ^~~~~~~~~~~ drivers/gpu/drm/msm/dsi/dsi_host.c:1870:44: note: initialize the variable 'device_node' to silence this warning struct device_node *endpoint, *device_node; ^ = NULL 1 error generated. device_node's assignment was removed but not all of its uses. Remove the call to of_node_put() and the variable declaration to clean up the warning. Fixes: 36246dd50225 ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE") Link: https://github.com/ClangBuiltLinux/linux/issues/1700Signed-off-by: -
Dmitry Baryshkov authored
Currently the DSI driver has two separate paths: one if the next device in a chain is a bridge and another one if the panel is connected directly to the DSI host. Simplify the code path by using panel-bridge driver (already selected in Kconfig) and dropping support for handling the panel directly. Signed-off-by:
-
Dmitry Baryshkov authored
Complete the move of DSC data pointer from struct drm_panel to struct mipi_dsi_device. Signed-off-by:
-
Dmitry Baryshkov authored
Now that struct mipi_dsi_device provides DSC data, fetch it from the mentioned struct rather than from the struct drm_panel itself. This would allow supporting MIPI DSI bridges handling DSC on their input side. Signed-off-by:
-
Dmitry Baryshkov authored
The commit 0f40ba48 ("drm/msm/dsi: Pass DSC params to drm_panel") added a pointer to the DSC data to the struct drm_panel. However DSC support is not limited to the DSI panels. MIPI DSI bridges can also consume DSC command streams. Thus add struct drm_dsc_config pointer to the struct mipi_dsi_device. Signed-off-by:
-
ye xingchen authored
Return the value msm_dsi_phy_enable() directly instead of storing it in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
ye xingchen <ye.xingchen@zte.com.cn> Reviewed-by:
-
Dmitry Baryshkov authored
It makes no sense to have the HPD worker in the MSM DSI driver anymore. It is only queued from the dsi_host_attach/detach() callbacks, where it plays no useful role. Either way the panel or next bridge will be present and will report it's status directly. Signed-off-by:
-
Douglas Anderson authored
The dsi_phy_driver_probe() function has a "goto fail" for no reason. Change it to just always return directly when it sees an error. Make this simpler by leveraging dev_err_probe() which is designed to make code like this shorter / simpler. NOTE: as part of this, we now pass through error codes directly from msm_ioremap_size() rather than translating to -ENOMEM. This changed mostly because it's much more convenient when using dev_err_probe() and also it's usually encouraged not to hide error codes like the old code was doing unless there is a good reason. I can't see any reason why we'd need to return -ENOMEM instead of -EINVAL from the probe function. Signed-off-by:
-
Douglas Anderson authored
As of the commit 1de452a0 ("regulator: core: Allow drivers to define their init data as const") we no longer need to do copying of regulator bulk data from initdata to something dynamic. Let's take advantage of that. In addition to saving some code, this also moves us to using ARRAY_SIZE() to specify how many regulators we have which is less error prone. This gets rid of some layers of wrappers which makes it obvious that we can get rid of an extra error print. devm_regulator_bulk_get_const() prints errors for you so you don't need an extra layer of printing. In all cases here I have preserved the old settings without any investigation about whether the loads being set are sensible. In the cases of some of the PHYs if several PHYs in the same file used exactly the same settings I had them point to the same data structure. NOTE: Though I haven't done the math, this is likely an overall savings in terms of "static const" data. We previously always allocated space for 8 supplies. Each of these supplies took up 36 bytes of data (32 for name, 4 for an int). Signed-off-by:
-
Douglas Anderson authored
As of commit 6eabfc01 ("regulator: core: Allow specifying an initial load w/ the bulk API") we can now specify the initial load in the bulk data rather than having to manually call regulator_set_load() on each regulator. Let's use it. Signed-off-by:
-
Douglas Anderson authored
As of commit 5451781d ("regulator: core: Only count load for enabled consumers"), a load isn't counted for a disabled regulator. That means all the code in the DSI driver to specify and set loads before disabling a regulator is not actually doing anything useful. Let's remove it. It should be noted that all of the loads set that were being specified were pointless noise anyway. The only use for this number is to pick between low power and high power modes of regulators. Regulators appear to do this changeover at loads on the order of 10000 uA. You would need a lot of clients of the same rail for that 100 uA number to count for anything. Note that now that we get rid of the setting of the load at disable time, we can just set the load once when we first get the regulator and then forget it. It should also be noted that the regulator functions regulator_bulk_enable() and regulator_set_load() already print error messages when they encounter problems so while moving things around we get rid of some extra error prints. Signed-off-by:
-
Marijn Suijten authored
parent_hw pointers are easier to manage and cheaper to use than repeatedly formatting the parent name and subsequently leaving the clk framework to perform lookups based on that name. Signed-off-by:
Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by:
-
Marijn Suijten authored
parent_hw pointers are easier to manage and cheaper to use than repeatedly formatting the parent name and subsequently leaving the clk framework to perform lookups based on that name. Signed-off-by:
-
Marijn Suijten authored
parent_hw pointers are easier to manage and cheaper to use than repeatedly formatting the parent name and subsequently leaving the clk framework to perform lookups based on that name. Signed-off-by:
-
Marijn Suijten authored
parent_hw pointers are easier to manage and cheaper to use than repeatedly formatting the parent name and subsequently leaving the clk framework to perform lookups based on that name. Signed-off-by:
-
Marijn Suijten authored
parent_hw pointers are easier to manage and cheaper to use than repeatedly formatting the parent name and subsequently leaving the clk framework to perform lookups based on that name. Signed-off-by:
-
Marijn Suijten authored
Now that the last DSI PHY PLL driver (dsi_phy_28nm_8960) has been converted to use a simple stack-local char-array instead of a devm_kzalloc heap allocation we can safely call sizeof() on every string variable (that's now a sized array instead of a pointer) passed into snprintf instead of hardcoding the size. Signed-off-by:
-
Marijn Suijten authored
The clock names formatted into the hw_clk's init structure are only used for the duration of the registration function where they are kstrdup'ed, making it unnecessary to keep the allocations alive for the duration of the device (through devm). Just like the other DSI PHY PLL clock trees, use a stack-local char array and save on memory outside of the pll_28nm_register function. Signed-off-by:
-
Marijn Suijten authored
The commit 613cbd1d ("drm/msm/dsi: use devm_clk_*register to registe DSI PHY clocks") introduced the devm_ prefix to clk_hw registration calls, without updating the indentation of the arguments on the following lines. Similarly commit e55b3fbb ("drm/msm/dsi: drop PLL accessor functions") moved from pll_write to dsi_phy_write without updating the indentation of followup arguments either. Preparing for a series that heavily touches the clk calls, reflow and reindent function calls that are adhering to an 80-char column limit by spanning multiple lines. Where function names are very long the arguments are indented with a fixed number of two tab characters instead of aligning with the opening parenthesis of the function call. Signed-off-by:
-
Kuogee Hsieh authored
At current implementation there is an extra 0 at 1.62G link rate which cause no correct pixel_div selected for 1.62G link rate to calculate mvid and nvid. This patch delete the extra 0 to have mvid and nvid be calculated correctly. Changes in v2: -- fix Fixes tag's text Changes in v3: -- fix misspelling of "Reviewed-by" Fixes: 937f941c ("drm/msm/dp: Use qmp phy for DP PLL and PHY") Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
-
