- 21 Mar, 2021 2 commits
-
-
Fabio Estevam authored
When putting iMX5 into suspend, the following flow is observed: [ 70.023427] [<c07755f0>] (msm_atomic_commit_tail) from [<c06e7218>] (commit_tail+0x9c/0x18c) [ 70.031890] [<c06e7218>] (commit_tail) from [<c0e2920c>] (drm_atomic_helper_commit+0x1a0/0x1d4) [ 70.040627] [<c0e2920c>] (drm_atomic_helper_commit) from [<c06e74d4>] (drm_atomic_helper_disable_all+0x1c4/0x1d4) [ 70.050913] [<c06e74d4>] (drm_atomic_helper_disable_all) from [<c0e2943c>] (drm_atomic_helper_suspend+0xb8/0x170) [ 70.061198] [<c0e2943c>] (drm_atomic_helper_suspend) from [<c06e84bc>] (drm_mode_config_helper_suspend+0x24/0x58) In the i.MX5 case, priv->kms is not populated (as i.MX5 does not use any of the Qualcomm display controllers), causing a NULL pointer dereference in msm_atomic_commit_tail(): [ 24.268964] 8<--- cut here --- [ 24.274602] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 24.283434] pgd = (ptrval) [ 24.286387] [00000000] *pgd=ca212831 [ 24.290788] Internal error: Oops: 17 [#1] SMP ARM [ 24.295609] Modules linked in: [ 24.298777] CPU: 0 PID: 197 Comm: init Not tainted 5.11.0-rc2-next-20210111 #333 [ 24.306276] Hardware name: Freescale i.MX53 (Device Tree Support) [ 24.312442] PC is at msm_atomic_commit_tail+0x54/0xb9c [ 24.317743] LR is at commit_tail+0xa4/0x1b0 Fix the problem by calling drm_mode_config_helper_suspend/resume() only when priv->kms is available. Fixes: ca8199f1 ("drm/msm/dpu: ensure device suspend happens during PM sleep") Signed-off-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Dmitry Baryshkov authored
If GPU components have failed to bind, shutdown callback would fail with the following backtrace. Add safeguard check to stop that oops from happening and allow the board to reboot. [ 66.617046] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 66.626066] Mem abort info: [ 66.628939] ESR = 0x96000006 [ 66.632088] EC = 0x25: DABT (current EL), IL = 32 bits [ 66.637542] SET = 0, FnV = 0 [ 66.640688] EA = 0, S1PTW = 0 [ 66.643924] Data abort info: [ 66.646889] ISV = 0, ISS = 0x00000006 [ 66.650832] CM = 0, WnR = 0 [ 66.653890] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000107f81000 [ 66.660505] [0000000000000000] pgd=0000000100bb2003, p4d=0000000100bb2003, pud=0000000100897003, pmd=0000000000000000 [ 66.671398] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 66.677115] Modules linked in: [ 66.680261] CPU: 6 PID: 352 Comm: reboot Not tainted 5.11.0-rc2-00309-g79e3faa7 #38 [ 66.688473] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) [ 66.695347] pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 66.701507] pc : msm_atomic_commit_tail+0x78/0x4e0 [ 66.706437] lr : commit_tail+0xa4/0x184 [ 66.710381] sp : ffff8000108f3af0 [ 66.713791] x29: ffff8000108f3af0 x28: ffff418c44337000 [ 66.719242] x27: 0000000000000000 x26: ffff418c40a24490 [ 66.724693] x25: ffffd3a842a4f1a0 x24: 0000000000000008 [ 66.730146] x23: ffffd3a84313f030 x22: ffff418c444ce000 [ 66.735598] x21: ffff418c408a4980 x20: 0000000000000000 [ 66.741049] x19: 0000000000000000 x18: ffff800010710fbc [ 66.746500] x17: 000000000000000c x16: 0000000000000001 [ 66.751954] x15: 0000000000010008 x14: 0000000000000068 [ 66.757405] x13: 0000000000000001 x12: 0000000000000000 [ 66.762855] x11: 0000000000000001 x10: 00000000000009b0 [ 66.768306] x9 : ffffd3a843192000 x8 : ffff418c44337000 [ 66.773757] x7 : 0000000000000000 x6 : 00000000a401b34e [ 66.779210] x5 : 00ffffffffffffff x4 : 0000000000000000 [ 66.784660] x3 : 0000000000000000 x2 : ffff418c444ce000 [ 66.790111] x1 : ffffd3a841dce530 x0 : ffff418c444cf000 [ 66.795563] Call trace: [ 66.798075] msm_atomic_commit_tail+0x78/0x4e0 [ 66.802633] commit_tail+0xa4/0x184 [ 66.806217] drm_atomic_helper_commit+0x160/0x390 [ 66.811051] drm_atomic_commit+0x4c/0x60 [ 66.815082] drm_atomic_helper_disable_all+0x1f4/0x210 [ 66.820355] drm_atomic_helper_shutdown+0x80/0x130 [ 66.825276] msm_pdev_shutdown+0x14/0x20 [ 66.829303] platform_shutdown+0x28/0x40 [ 66.833330] device_shutdown+0x158/0x330 [ 66.837357] kernel_restart+0x40/0xa0 [ 66.841122] __do_sys_reboot+0x228/0x250 [ 66.845148] __arm64_sys_reboot+0x28/0x34 [ 66.849264] el0_svc_common.constprop.0+0x74/0x190 [ 66.854187] do_el0_svc+0x24/0x90 [ 66.857595] el0_svc+0x14/0x20 [ 66.860739] el0_sync_handler+0x1a4/0x1b0 [ 66.864858] el0_sync+0x174/0x180 [ 66.868269] Code: 1ac020a0 2a000273 eb02007f 54ffff01 (f9400285) [ 66.874525] ---[ end trace 20dedb2a3229fec8 ]--- Fixes: 9d5cbf5f ("drm/msm: add shutdown support for display platform_driver") Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
-
- 17 Mar, 2021 6 commits
-
-
Rob Clark authored
We have seen a couple cases where low memory situations cause something bad to happen, followed by a flood of these messages obscuring the root cause. Lets ratelimit the dmesg spam so that next time it happens we don't lose the kernel traces leading up to this. Signed-off-by:
Douglas Anderson <dianders@chromium.org>
-
Konrad Dybcio authored
While passing the A530-specific lm_setup func to A530 and A540 to !A530 was fine back when only these two were supported, it certainly is not a good idea to send A540 specifics to smaller GPUs like A508 and friends. Signed-off-by:
Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by:
-
Stephen Boyd authored
In commit 9fc41843 ("drm/msm/dp: unplug interrupt missed after irq_hpd handler") we dropped a reset of the aux phy during aux transfers because resetting the phy during active communication caused us to miss an hpd irq in some cases. Unfortunately, we also dropped the part of the code that changes the aux phy tuning when an aux transfer fails due to a timeout. That part of the code was calling into the phy driver to reconfigure the aux TX swing controls, working around poor channel quality. Let's restore this phy setting code so that aux channel communication is more reliable. Cc: Kuogee Hsieh <khsieh@codeaurora.org> Fixes: 9fc41843 ("drm/msm/dp: unplug interrupt missed after irq_hpd handler") Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
-
Dmitry Baryshkov authored
The PLL_LOCKDET_RATE_1 was being programmed with a hardcoded value directly, but the same value was also being specified in the dsi_pll_regs struct pll_lockdet_rate variable: let's use it! Based on 362cadf3 ("drm/msm/dsi_pll_10nm: Fix variable usage for pll_lockdet_rate") Signed-off-by:
Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by:
-
Dmitry Baryshkov authored
The number of fractional registers bits is known and already set in the frac_bits variable of the dsi_pll_config struct here in 7nm: remove the TODO by simply using that variable. This is a copy of 196145eb ("drm/msm/dsi_pll_10nm: Solve TODO for multiplier frac_bits assignment"). Signed-off-by:
-
Dmitry Baryshkov authored
Fix setting min/max DSI PLL rate for the V4.1 7nm DSI PLL (used on sm8250). Current code checks for pll->type before it is set (as it is set in the msm_dsi_pll_init() after calling device-specific functions. Cc: Jonathan Marek <jonathan@marek.ca> Fixes: 1ef7c99d ("drm/msm/dsi: add support for 7nm DSI PHY/PLL") Signed-off-by:
-
- 27 Feb, 2021 1 commit
-
-
Douglas Anderson authored
When running the latest kernel on an sc7180 with KASAN I got this splat: BUG: KASAN: slab-out-of-bounds in a6xx_gpu_init+0x618/0x644 Read of size 4 at addr ffffff8088f36100 by task kworker/7:1/58 CPU: 7 PID: 58 Comm: kworker/7:1 Not tainted 5.11.0+ #3 Hardware name: Google Lazor (rev1 - 2) with LTE (DT) Workqueue: events deferred_probe_work_func Call trace: dump_backtrace+0x0/0x3a8 show_stack+0x24/0x30 dump_stack+0x174/0x1e0 print_address_description+0x70/0x2e4 kasan_report+0x178/0x1bc __asan_report_load4_noabort+0x44/0x50 a6xx_gpu_init+0x618/0x644 adreno_bind+0x26c/0x438 This is because the speed bin is defined like this: gpu_speed_bin: gpu_speed_bin@1d2 { reg = <0x1d2 0x2>; bits = <5 8>; }; As you can see the "length" is 2 bytes. That means that the nvmem subsystem allocates only 2 bytes. The GPU code, however, was casting the pointer allocated by nvmem to a (u32 *) and dereferencing. That's not so good. Let's fix this to just use the nvmem_cell_read_u16() accessor function which simplifies things and also gets rid of the splat. Let's also put an explicit conversion from little endian in place just to make things clear. The nvmem subsystem today is assuming little endian and this makes it clear. Specifically, the way the above sc7180 cell is interpreted: NVMEM: +--------+--------+--------+--------+--------+ | ...... | 0x1d3 | 0x1d2 | ...... | 0x000 | +--------+--------+--------+--------+--------+ ^ ^ msb lsb You can see that the least significant data is at the lower address which is little endian. NOTE: someone who is truly paying attention might wonder about me picking the "u16" version of this accessor instead of the "u8" (since the value is 8 bits big) or the u32 version (just for fun). At the moment you need to pick the accessor that exactly matches the length the cell was specified as in the device tree. Hopefully future patches to the nvmem subsystem will fix this. Fixes: fe7952c6 ("drm/msm: Add speed-bin support to a618 gpu") Signed-off-by:
-
- 23 Feb, 2021 3 commits
-
-
Jordan Crouse authored
Most a6xx targets have security issues that were fixed with new versions of the microcode(s). Make sure that we are booting with a safe version of the microcode for the target and print a message and error if not. v2: Add more informative error messages and fix typos Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by:
Akhil P Oommen <akhilpo@codeaurora.org> Signed-off-by:
-
Jonathan Marek authored
The cleanup patch broke a6xx_gmu_clear_oob, fix it by adding the missing bitshift operation. Fixes: 555c50a4 ("drm/msm: Clean up GMU OOB set/clear handling") Signed-off-by:
Jonathan Marek <jonathan@marek.ca> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Stephen Boyd authored
We don't need to make up custom lock classes here, we can simply use mutex_lock_nested() and pass in the index of the crtc to the locking APIs instead. This helps lockdep understand that these are really different locks while avoiding having to allocate custom lockdep classes. Cc: Krishna Manikandan <mkrishn@codeaurora.org> Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Fixes: b3d91800 ("drm/msm: Fix race condition in msm driver with async layer updates") Signed-off-by:
-
- 07 Feb, 2021 1 commit
-
-
Stephen Boyd authored
A missing semicolon here causes my external display to stop working. Indeed, missing the semicolon on the return statement leads to dp_panel_update_tu_timings() not existing because the compiler thinks it's part of the return statement of a void function, so it must not be important. $ ./scripts/bloat-o-meter before.o after.o add/remove: 1/1 grow/shrink: 0/1 up/down: 7400/-7540 (-140) Function old new delta dp_panel_update_tu_timings - 7400 +7400 _dp_ctrl_calc_tu.constprop 18024 17900 -124 dp_panel_update_tu_timings.constprop 7416 - -7416 Total: Before=54440, After=54300, chg -0.26% Add a semicolon so this function works like it used to. Cc: Sean Paul <sean@poorly.run> Cc: Kuogee Hsieh <khsieh@codeaurora.org> Cc: linux-arm-msm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org Cc: Lee Jones <lee.jones@linaro.org> Fixes: cc9014bf ("drm/msm/dp/dp_ctrl: Move 'tu' from the stack to the heap") Signed-off-by:
-
- 06 Feb, 2021 1 commit
-
-
Kuogee Hsieh authored
DP_SW_RESET is the global SW reset that is used to initialize DP controller. If DP_SW_RESET executed during connection setup, two HPD related side effects may occurred, 1) pending HPD interrupts cleared unexpected 2) re start debounce logic which trigger another interrupt This patch only issue DP_SW_RESET at boot up and pm_resume. This patch also reinit video_comp before configure dp controller to avoid missing VIDEO_READY interrupt. Fixes: 9fc41843 ("drm/msm/dp: unplug interrupt missed after irq_hpd handler") Signed-off-by:
Kuogee Hsieh <khsieh@codeaurora.org> Reviewed-by:
-
- 05 Feb, 2021 2 commits
-
-
Rob Clark authored
In moving code around, we ended up using the same pointer to copy_from_user() the relocs tables as we used for the cmd table entry, which is clearly not right. This went unnoticed because modern mesa on non-ancent kernels does not actually use relocs. But this broke ancient mesa on modern kernels. Reported-by:
Emil Velikov <emil.velikov@collabora.com> Fixes: 20224d71 ("drm/msm/submit: Move copy_from_user ahead of locking bos") Signed-off-by:
-
Konrad Dybcio authored
The maximum mdp clock rate on msm8974v2 is 320MHz. Fix it. Signed-off-by:
-
- 04 Feb, 2021 1 commit
-
-
Bernard Zhao authored
remove unneeded variable: "rc". Signed-off-by:
Bernard Zhao <bernard@vivo.com> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Reviewed-by:
-
- 01 Feb, 2021 4 commits
-
-
AngeloGioacchino Del Regno authored
DRM_DEV_ERROR should be used across this entire source: convert the pr_err prints to the first as a cleanup. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by:
-
AngeloGioacchino Del Regno authored
The PLL_LOCKDET_RATE_1 was being programmed with a hardcoded value directly, but the same value was also being specified in the dsi_pll_regs struct pll_lockdet_rate variable: let's use it! Signed-off-by:
-
AngeloGioacchino Del Regno authored
The number of fractional registers bits is known and already set in the frac_bits variable of the dsi_pll_config struct here in 10nm: remove the TODO by simply using that variable. Signed-off-by:
-
AngeloGioacchino Del Regno authored
In function dsi_pll_calc_dec_frac we are calculating the decimal div start parameter by dividing the decimal multiple by the fractional multiplier: the remainder of that operation is stored to then get programmed to the fractional divider registers of the PLL. It's useless to call div_u64_rem to get the remainder and *then* call div_u64 to get the division result, as the first is already giving that result: let's fix it by just caring about the result of div_u64_rem. Signed-off-by:
-
- 31 Jan, 2021 19 commits
-
-
Judy Hsiao authored
1. Trigger the unplug event in msm_dp_display_disable() to shutdown audio properly. 2. Reset the completion before signal the disconnect event. Fixes: 158b9aa7 ("drm/msm/dp: wait for audio notification before disabling clocks") Reviewed-by:
Judy Hsiao <judyhsiao@chromium.org> Signed-off-by:
-
Xu Wang authored
fix semicolon.cocci warnings: drivers/gpu/drm/msm/dp/dp_ctrl.c:1161:2-3: Unneeded semicolon Signed-off-by:
Xu Wang <vulab@iscas.ac.cn> Signed-off-by:
-
Xu Wang authored
fix semicolon.cocci warnings: drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:752:2-3: Unneeded semicolon Signed-off-by:
-
Jiapeng Zhong authored
Fix below warnings reported by coccicheck: ./drivers/gpu/drm/msm/msm_gem.c:991:3-9: WARNING: NULL check before some freeing functions is not needed. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Zhong <abaci-bugfix@linux.alibaba.com> Signed-off-by:
-
Stephen Boyd authored
Lockdep complains about an AA deadlock when rebooting the device. base-commit: 19c329f6 ============================================ WARNING: possible recursive locking detected 5.4.91 #1 Not tainted -------------------------------------------- reboot/5213 is trying to acquire lock: ffffff80d13391b0 (&kms->commit_lock[i]){+.+.}, at: lock_crtcs+0x60/0xa4 but task is already holding lock: ffffff80d1339110 (&kms->commit_lock[i]){+.+.}, at: lock_crtcs+0x60/0xa4 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&kms->commit_lock[i]); lock(&kms->commit_lock[i]); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by reboot/5213: __arm64_sys_reboot+0x148/0x2a0 device_shutdown+0x10c/0x2c4 drm_atomic_helper_shutdown+0x48/0xfc modeset_lock+0x120/0x24c lock_crtcs+0x60/0xa4 stack backtrace: CPU: 4 PID: 5213 Comm: reboot Not tainted 5.4.91 #1 Hardware name: Google Pompom (rev1) with LTE (DT) Call trace: dump_backtrace+0x0/0x1dc show_stack+0x24/0x30 dump_stack+0xfc/0x1a8 __lock_acquire+0xcd0/0x22b8 lock_acquire+0x1ec/0x240 __mutex_lock_common+0xe0/0xc84 mutex_lock_nested+0x48/0x58 lock_crtcs+0x60/0xa4 msm_atomic_commit_tail+0x348/0x570 commit_tail+0xdc/0x178 drm_atomic_helper_commit+0x160/0x168 drm_atomic_commit+0x68/0x80 This is because lockdep thinks all the locks taken in lock_crtcs() are the same lock, when they actually aren't. That's because we call mutex_init() in msm_kms_init() and that assigns one static key for every lock initialized in this loop. Let's allocate a dynamic number of lock_class_keys and assign them to each lock so that lockdep can figure out an AA deadlock isn't possible here. Fixes: b3d91800 ("drm/msm: Fix race condition in msm driver with async layer updates") Cc: Krishna Manikandan <mkrishn@codeaurora.org> Signed-off-by:
-
Eric Anholt authored
Now that the bug is fixed in the minimal way for stable, go make the code table-driven. Signed-off-by:
-
Eric Anholt authored
Now that we're not racing with GPU setup, also fix races of timestamps against other timestamps. In freedreno CI, we were seeing this path trigger timeouts on setting the GMU bit, producing: [drm:_a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set GPU_SET: 0x0 and this triggered especially on the first set of tests right after boot (it's probably easier to lose the race than one might think, given that we start many tests in parallel, and waiting for NFS to page in code probably means that lots of tests hit the same point of screen init at the same time). As of this patch, the message seems to have completely gone away. Signed-off-by:
-
Eric Anholt authored
We were using the same force-poweron bit in the two codepaths, so they could race to have one of them lose GPU power early. freedreno CI was seeing intermittent errors like: [drm:_a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set GPU_SET: 0x0 and this issue could have contributed to it. Signed-off-by:
-
Iskren Chernev authored
Before the offending commit in msm_atomic_commit_tail wait_flush was called once per frame, after the commit was submitted. After it wait_flush is also called at the beginning to ensure previous potentially async commits are done. For cmd panels the source of wait_flush is a ping-pong irq notifying a completion. The completion needs to be notified with complete_all so multiple waiting parties (new async committers) can proceed. Signed-off-by:
Iskren Chernev <iskren.chernev@gmail.com> Suggested-by:
Rob Clark <robdclark@gmail.com> Fixes: 2d99ced7 ("drm/msm: async commit support") Signed-off-by:
-
Konrad Dybcio authored
The previous registers were *almost* correct, but instead of PHYs, they were pointing at DSI PLLs, resulting in the PHY id autodetection failing miserably. Fixes: dcefc117 ("drm/msm/dsi: Add support for msm8x94") Signed-off-by:
-
Dmitry Baryshkov authored
SM8250 has quite unique qseed lut type: qseed3lite, which is a lightweight version of qseed3 scaler. Signed-off-by:
-
Kuogee Hsieh authored
There is HPD unplug interrupts missed at scenario of an irq_hpd followed by unplug interrupts with around 10 ms in between. Since both AUX_SW_RESET and DP_SW_RESET clear pending HPD interrupts, irq_hpd handler should not issues either aux or sw reset to avoid following unplug interrupt be cleared accidentally. This patch also postpone handling of irq_hpd until connected state if it happened at connection pending state. Changes in V2: -- add postpone handling of irq_hpd until connected state -- check DP_TRAINING_1 instead of DP_TRAINING_NONE Signed-off-by:
-
AngeloGioacchino Del Regno authored
The call to dpu_encoder_phys_cmd_prepare_for_kickoff is useless as it's unused because the serialize_wait4pp variable is never set to true by .. anything, literally: remove the call. While at it, also reduce indentation by inverting the check for dpu_encoder_phys_cmd_is_master. Signed-off-by:
-
AngeloGioacchino Del Regno authored
When configuring the tearcheck, the parameters for the engine were being set mostly as they should've been, but then it wasn't getting configured to get the vsync indication from the TE GPIO input because it was assumed that autorefresh could be enabled: since a previous commit makes sure to disable the autorefresh bit when committing to the cmd engine, it is now safe to just enable the vsync pin input at tearcheck setup time (instead of erroneously never enabling it). Also, set the right sync_cfg_height to enable the DPU auto-generated TE signal in order to avoid stalls in the event that we miss one external TE signal: this will still trigger recovery mechanisms in case the display is really unreachable. Signed-off-by:
-
AngeloGioacchino Del Regno authored
When a command mode display is used, it may be retaining the bootloader configuration which, in most of the cases, enables the autorefresh feature in order to keep the splash up. Since there is no autorefresh management in this driver, wire up the autorefresh ops in the dpu_hw_pingpong and disable the feature when preparing for cmd commit: instead of disabling it when initializing the command mode, this road was chosen as to open future possibility of enabling and managing the autorefresh feature in the driver. Signed-off-by:
-
AngeloGioacchino Del Regno authored
The DSPP_BLK macro was ad-hoc made for SC7180, but this is wrong because not all of the DPU DSPP versions can use the same DSPP block configuration, and not all of them have got the same features. For this reason, add two more params to the DSPP_BLK macro, so that it is possible to specify the feature mask and the sblk config for each DSPP. Fixes: 4259ff7a ("drm/msm/dpu: add support for pcc color block in dpu driver") Signed-off-by:
-
AngeloGioacchino Del Regno authored
Not all DPU interface sub-block versions need the same value for prog_fetch_lines_worst_case: add this to the INTF_BLK macro, so that it becomes possible to vary it for other INTF versions. For example, this is needed to implement support for older SoCs, like MSM8998 and SDM630/660 and most probably will also be needed for future SoCs. Signed-off-by:
-
AngeloGioacchino Del Regno authored
Not all DPU versions that are supported in this driver are supposed to have a 8-Levels VIG QoS setting. Move this flag to SDM845 and SC7180 specific masks. Signed-off-by:
-
AngeloGioacchino Del Regno authored
On DPUs prior to version 4 the VBIF_XINL_QOS_LVL_REMAP_000 register is at 0x570 offset from vbif base instead of 0x590, due to the VBIF_XINL_QOS_RP_REMAP_000 having less instances (less possible XINs). Signed-off-by:
-
