summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-02-18net: mvpp2: always set port pcs opsJeremy Linton
Booting a MACCHIATObin with 5.17, the system OOPs with a null pointer deref when the network is started. This is caused by the pcs->ops structure being null in mcpp2_acpi_start() when it tries to call pcs_config(). Hoisting the code which sets pcs_gmac.ops and pcs_xlg.ops, assuring they are always set, fixes the problem. The OOPs looks like: [ 18.687760] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000010 [ 18.698561] Mem abort info: [ 18.698564] ESR = 0x96000004 [ 18.698567] EC = 0x25: DABT (current EL), IL = 32 bits [ 18.709821] SET = 0, FnV = 0 [ 18.714292] EA = 0, S1PTW = 0 [ 18.718833] FSC = 0x04: level 0 translation fault [ 18.725126] Data abort info: [ 18.729408] ISV = 0, ISS = 0x00000004 [ 18.734655] CM = 0, WnR = 0 [ 18.738933] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000111bbf000 [ 18.745409] [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 [ 18.752235] Internal error: Oops: 96000004 [#1] SMP [ 18.757134] Modules linked in: rfkill ip_set nf_tables nfnetlink qrtr sunrpc vfat fat omap_rng fuse zram xfs crct10dif_ce mvpp2 ghash_ce sbsa_gwdt phylink xhci_plat_hcd ahci_plam [ 18.773481] CPU: 0 PID: 681 Comm: NetworkManager Not tainted 5.17.0-0.rc3.89.fc36.aarch64 #1 [ 18.781954] Hardware name: Marvell Armada 7k/8k Family Board /Armada 7k/8k Family Board , BIOS EDK II Jun 4 2019 [ 18.795222] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 18.802213] pc : mvpp2_start_dev+0x2b0/0x300 [mvpp2] [ 18.807208] lr : mvpp2_start_dev+0x298/0x300 [mvpp2] [ 18.812197] sp : ffff80000b4732c0 [ 18.815522] x29: ffff80000b4732c0 x28: 0000000000000000 x27: ffffccab38ae57f8 [ 18.822689] x26: ffff6eeb03065a10 x25: ffff80000b473a30 x24: ffff80000b4735b8 [ 18.829855] x23: 0000000000000000 x22: 00000000000001e0 x21: ffff6eeb07b6ab68 [ 18.837021] x20: ffff6eeb07b6ab30 x19: ffff6eeb07b6a9c0 x18: 0000000000000014 [ 18.844187] x17: 00000000f6232bfe x16: ffffccab899b1dc0 x15: 000000006a30f9fa [ 18.851353] x14: 000000003b77bd50 x13: 000006dc896f0e8e x12: 001bbbfccfd0d3a2 [ 18.858519] x11: 0000000000001528 x10: 0000000000001548 x9 : ffffccab38ad0fb0 [ 18.865685] x8 : ffff80000b473330 x7 : 0000000000000000 x6 : 0000000000000000 [ 18.872851] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff80000b4732f8 [ 18.880017] x2 : 000000000000001a x1 : 0000000000000002 x0 : ffff6eeb07b6ab68 [ 18.887183] Call trace: [ 18.889637] mvpp2_start_dev+0x2b0/0x300 [mvpp2] [ 18.894279] mvpp2_open+0x134/0x2b4 [mvpp2] [ 18.898483] __dev_open+0x128/0x1e4 [ 18.901988] __dev_change_flags+0x17c/0x1d0 [ 18.906187] dev_change_flags+0x30/0x70 [ 18.910038] do_setlink+0x278/0xa7c [ 18.913540] __rtnl_newlink+0x44c/0x7d0 [ 18.917391] rtnl_newlink+0x5c/0x8c [ 18.920892] rtnetlink_rcv_msg+0x254/0x314 [ 18.925006] netlink_rcv_skb+0x48/0x10c [ 18.928858] rtnetlink_rcv+0x24/0x30 [ 18.932449] netlink_unicast+0x290/0x2f4 [ 18.936386] netlink_sendmsg+0x1d0/0x41c [ 18.940323] sock_sendmsg+0x60/0x70 [ 18.943825] ____sys_sendmsg+0x248/0x260 [ 18.947762] ___sys_sendmsg+0x74/0xa0 [ 18.951438] __sys_sendmsg+0x64/0xcc [ 18.955027] __arm64_sys_sendmsg+0x30/0x40 [ 18.959140] invoke_syscall+0x50/0x120 [ 18.962906] el0_svc_common.constprop.0+0x4c/0xf4 [ 18.967629] do_el0_svc+0x30/0x9c [ 18.970958] el0_svc+0x28/0xb0 [ 18.974025] el0t_64_sync_handler+0x10c/0x140 [ 18.978400] el0t_64_sync+0x1a4/0x1a8 [ 18.982078] Code: 52800004 b9416262 aa1503e0 52800041 (f94008a5) [ 18.988196] ---[ end trace 0000000000000000 ]--- Fixes: cff056322372 ("net: mvpp2: use .mac_select_pcs() interface") Suggested-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Marcin Wojtas <mw@semihalf.com> Link: https://lore.kernel.org/r/20220214231852.3331430-1-jeremy.linton@arm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-19Merge branches 'msm-next-lumag-core', 'msm-next-lumag-dpu', ↵Dmitry Baryshkov
'msm-next-lumag-dp', 'msm-next-lumag-dsi', 'msm-next-lumag-hdmi' and 'msm-next-lumag-mdp5' into msm-next-lumag
2022-02-19drm/msm/dp: support finding next bridge even for DP interfacesDmitry Baryshkov
It is possible to supply display-connector (bridge) to the DP interface, add support for parsing it too. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20220211224006.1797846-4-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2022-02-19drm/msm/dp: support attaching bridges to the DP encoderDmitry Baryshkov
Currently DP driver will allocate panel bridge for eDP panels. This supports only the following topology: - eDP encoder ⇒ eDP panel (wrapped using panel-bridge) Simplify this code to just check if there is any next bridge in the chain (be it a panel bridge or regular bridge). Rename panel_bridge field to next_bridge accordingly. This allows one to use e.g. one of the following display topologies: - eDP encoder ⇒ ptn3460 ⇒ fixed LVDS panel - eDP encoder ⇒ ptn3460 ⇒ LVDS connector with EDID lines for panel autodetect - eDP encoder ⇒ ptn3460 ⇒ THC63LVD1024 ⇒ DPI panel. - eDP encoder ⇒ LT8912 ⇒ DSI panel Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20220211224006.1797846-3-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2022-02-19drm/msm/dp: fix panel bridge attachmentDmitry Baryshkov
In commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display enable and disable") the DP driver received a drm_bridge instance, which is always attached to the encoder as a root bridge. However it conflicts with the panel_bridge support for eDP panels. The panel bridge attaches to the encoder before the "dp" bridge (DP driver's drm_bridge instance created in msm_dp_bridge_init()) has a chance to do so. Change panel bridge attachment to come after the "dp" bridge attachment (and to use it as a previous bridge). Fixes: 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display enable and disable") Cc: Kuogee Hsieh <quic_khsieh@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20220211224006.1797846-2-dmitry.baryshkov@linaro.org [db: fixed commit message according to Stephen's suggestions] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2022-02-19Merge tag 'intel-pinctrl-v5.17-5' of ↵Linus Walleij
gitolite.kernel.org:pub/scm/linux/kernel/git/pinctrl/intel into fixes intel-pinctrl for v5.17-5 * Revert misplaced ID The following is an automated git shortlog grouped by driver: tigerlake: - Revert "Add Alder Lake-M ACPI ID"
2022-02-19gpio: tegra186: Fix chip_data type confusionMarc Zyngier
The tegra186 GPIO driver makes the assumption that the pointer returned by irq_data_get_irq_chip_data() is a pointer to a tegra_gpio structure. Unfortunately, it is actually a pointer to the inner gpio_chip structure, as mandated by the gpiolib infrastructure. Nice try. The saving grace is that the gpio_chip is the first member of tegra_gpio, so the bug has gone undetected since... forever. Fix it by performing a container_of() on the pointer. This results in no additional code, and makes it possible to understand how the whole thing works. Fixes: 5b2b135a87fc ("gpio: Add Tegra186 support") Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20220211093904.1112679-1-maz@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-02-19pinctrl: starfive: Use a static name for the GPIO irq_chipMarc Zyngier
Drop the device name used for the GPIO irq_chip and replace it with something static. The information is still available from debugfs and carried as part of the irqdomain. Suggested-by: Emil Renner Berthing <kernel@esmil.dk> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Link: https://lore.kernel.org/r/20220211092345.1093332-1-maz@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-02-18Merge tag 'nfs-for-5.17-3' of git://git.linux-nfs.org/projects/anna/linux-nfsLinus Torvalds
Pull NFS client bugfixes from Anna Schumaker: - Fix unnecessary changeattr revalidations - Fix resolving symlinks during directory lookups - Don't report writeback errors in nfs_getattr() * tag 'nfs-for-5.17-3' of git://git.linux-nfs.org/projects/anna/linux-nfs: NFS: Do not report writeback errors in nfs_getattr() NFS: LOOKUP_DIRECTORY is also ok with symlinks NFS: Remove an incorrect revalidation in nfs4_update_changeattr_locked()
2022-02-18Merge tag 'acpi-5.17-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "These make an excess warning message go away and fix a recently introduced boot failure on a vintage machine. Specifics: - Change the log level of the "table not found" message in acpi_table_parse_entries_array() to debug to prevent it from showing up in the logs unnecessarily (Dan Williams) - Add a C-state limit quirk for 32-bit ThinkPad T40 to prevent it from crashing on boot after recent changes in the ACPI processor driver (Woody Suwalski)" * tag 'acpi-5.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: processor: idle: fix lockup regression on 32-bit ThinkPad T40 ACPI: tables: Quiet ACPI table not found warning
2022-02-18Merge tag 'riscv-for-linus-5.17-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: "A set of three fixes, all aimed at fixing some fallout from the recent sparse hart ID support" * tag 'riscv-for-linus-5.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: RISC-V: Fix IPI/RFENCE hmask on non-monotonic hartid ordering RISC-V: Fix handling of empty cpu masks RISC-V: Fix hartid mask handling for hartid 31 and up
2022-02-18drm/i915/dg2: Enable 5th portMatt Roper
DG2 supports a 5th display output which the hardware refers to as "TC1," even though it isn't a Type-C output. This behaves similarly to the TC1 on past platforms with just a couple minor differences: * DG2's TC1 bit in SDEISR is at bit 25 rather than 24 as it is on ICP/TGP/ADP. * DG2 doesn't need the hpd inversion setting that we had to use on DG1 v2: intel_ddi_init(dev_priv, PORT_TC1); [Matt] Cc: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218010328.183423-3-lucas.demarchi@intel.com
2022-02-18drm/i915/dg2: Drop 38.4 MHz MPLLB tablesMatt Roper
Our early understanding of DG2 was incorrect; since the 5th display isn't actually a Type-C output, 38.4 MHz input clocks are never used on this platform and we can drop the corresponding MPLLB tables. Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218010328.183423-2-lucas.demarchi@intel.com
2022-02-18drm/i915: Fix for PHY_MISC_TC1 offsetJouni Högander
Currently ICL_PHY_MISC macro is returning offset 0x64C10 for PHY_E. The PORT_TC1 port is not yet enabled properly in the driver, but intel_phy_snps.c is relying on intel_phy_is_snps() to filter out unavailable phys. That function was already considering the last phy as available. Just correct the offset of the last phy to 0x64C14 as the rest of the support for it is coming on next commits. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218010328.183423-1-lucas.demarchi@intel.com
2022-02-18Input: psmouse - set up dependency between PS/2 and SMBus companionsDmitry Torokhov
When we switch from emulated PS/2 to native (RMI4 or Elan) protocols, we create SMBus companion devices that are attached to I2C/SMBus controllers. However, when suspending and resuming, we also need to make sure that we take into account the PS/2 device they are associated with, so that PS/2 device is suspended after the companion and resumed before it, otherwise companions will not work properly. Before I2C devices were marked for asynchronous suspend/resume, this ordering happened naturally, but now we need to enforce it by establishing device links, with PS/2 devices being suppliers and SMBus companions being consumers. Fixes: 172d931910e1 ("i2c: enable async suspend/resume on i2c client devices") Reported-and-tested-by: Hugh Dickins <hughd@google.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Link: https://lore.kernel.org/r/89456fcd-a113-4c82-4b10-a9bcaefac68f@google.com Link: https://lore.kernel.org/r/YgwQN8ynO88CPMju@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-02-18ice: initialize local variable 'tlv'Tom Rix
Clang static analysis reports this issues ice_common.c:5008:21: warning: The left expression of the compound assignment is an uninitialized value. The computed value will also be garbage ldo->phy_type_low |= ((u64)buf << (i * 16)); ~~~~~~~~~~~~~~~~~ ^ When called from ice_cfg_phy_fec() ldo is the uninitialized local variable tlv. So initialize. Fixes: ea78ce4dab05 ("ice: add link lenient and default override support") Signed-off-by: Tom Rix <trix@redhat.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-02-18ice: check the return of ice_ptp_gettimex64Tom Rix
Clang static analysis reports this issue time64.h:69:50: warning: The left operand of '+' is a garbage value set_normalized_timespec64(&ts_delta, lhs.tv_sec + rhs.tv_sec, ~~~~~~~~~~ ^ In ice_ptp_adjtime_nonatomic(), the timespec64 variable 'now' is set by ice_ptp_gettimex64(). This function can fail with -EBUSY, so 'now' can have a gargbage value. So check the return. Fixes: 06c16d89d2cb ("ice: register 1588 PTP clock device object for E810 devices") Signed-off-by: Tom Rix <trix@redhat.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-02-18ice: fix concurrent reset and removal of VFsJacob Keller
Commit c503e63200c6 ("ice: Stop processing VF messages during teardown") introduced a driver state flag, ICE_VF_DEINIT_IN_PROGRESS, which is intended to prevent some issues with concurrently handling messages from VFs while tearing down the VFs. This change was motivated by crashes caused while tearing down and bringing up VFs in rapid succession. It turns out that the fix actually introduces issues with the VF driver caused because the PF no longer responds to any messages sent by the VF during its .remove routine. This results in the VF potentially removing its DMA memory before the PF has shut down the device queues. Additionally, the fix doesn't actually resolve concurrency issues within the ice driver. It is possible for a VF to initiate a reset just prior to the ice driver removing VFs. This can result in the remove task concurrently operating while the VF is being reset. This results in similar memory corruption and panics purportedly fixed by that commit. Fix this concurrency at its root by protecting both the reset and removal flows using the existing VF cfg_lock. This ensures that we cannot remove the VF while any outstanding critical tasks such as a virtchnl message or a reset are occurring. This locking change also fixes the root cause originally fixed by commit c503e63200c6 ("ice: Stop processing VF messages during teardown"), so we can simply revert it. Note that I kept these two changes together because simply reverting the original commit alone would leave the driver vulnerable to worse race conditions. Fixes: c503e63200c6 ("ice: Stop processing VF messages during teardown") Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-02-18ice: fix setting l4 port flag when adding filterMichal Swiatkowski
Accidentally filter flag for none encapsulated l4 port field is always set. Even if user wants to add encapsulated l4 port field. Remove this unnecessary flag setting. Fixes: 9e300987d4a81 ("ice: VXLAN and Geneve TC support") Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-02-18ice: Match on all profiles in slow-pathWojciech Drewek
In switchdev mode, slow-path rules need to match all protocols, in order to correctly redirect unfiltered or missed packets to the uplink. To set this up for the virtual function to uplink flow, the rule that redirects packets to the control VSI must have the tunnel type set to ICE_SW_TUN_AND_NON_TUN. As a result of that new tunnel type being set, ice_get_compat_fv_bitmap will select ICE_PROF_ALL. At that point all profiles would be selected for this rule, resulting in the desired behavior. Without this change slow-path would not work with tunnel protocols. Fixes: 8b032a55c1bd ("ice: low level support for tunnels") Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-02-18drm/i915: Pimp icl+ sagv pre/post updateVille Syrjälä
Add some debugs on what exactly we're doing to the QGV point mask in the icl+ sagv pre/post plane update hooks. Currently we're just guessing. v2: s/u32/u16/ for consistency with the mask sizes (Stan) Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-5-ville.syrjala@linux.intel.com
2022-02-18drm/i915: Split pre-icl vs. icl+ SAGV hooks apartVille Syrjälä
To further reduce the confusion between the pre-icl vs. icl+ SAGV codepaths let's do a full split. Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-4-ville.syrjala@linux.intel.com
2022-02-18drm/i915: Fix bw atomic check when switching between SAGV vs. no SAGVVille Syrjälä
If the only thing that is changing is SAGV vs. no SAGV but the number of active planes and the total data rates end up unchanged we currently bail out of intel_bw_atomic_check() early and forget to actually compute the new WGV point mask and thus won't actually enable/disable SAGV as requested. This ends up poorly if we end up running with SAGV enabled when we shouldn't. Usually ends up in underruns. To fix this let's go through the QGV point mask computation if either the data rates/number of planes, or the state of SAGV is changing. v2: Check more carefully if things are changing to avoid the extra calculations/debugs from introducing unwanted overhead Cc: stable@vger.kernel.org Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> #v1 Fixes: 20f505f22531 ("drm/i915: Restrict qgv points which don't have enough bandwidth.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-3-ville.syrjala@linux.intel.com
2022-02-18drm/i915: Correctly populate use_sagv_wm for all pipesVille Syrjälä
When changing between SAGV vs. no SAGV on tgl+ we have to update the use_sagv_wm flag for all the crtcs or else an active pipe not already in the state will end up using the wrong watermarks. That is especially bad when we end up with the tighter non-SAGV watermarks with SAGV enabled. Usually ends up in underruns. Cc: stable@vger.kernel.org Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: 7241c57d3140 ("drm/i915: Add TGL+ SAGV support") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-2-ville.syrjala@linux.intel.com
2022-02-18drm/amdgpu: add dm ip block for dcn 3.1.5Yifan Zhang
this patch adds dm ip block for dcn 3.1.5. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amd/display: Add DCN315 DM SupportQingqing Zhuo
Add display manager support for DCN 3.1.5. Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amd/display: Add DCN315 COREQingqing Zhuo
DC core changes for DCN 3.1.5. Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amd/display: Add DCN315 blocks to MakefileQingqing Zhuo
Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amd/display: Add DCN315 Command Table HelperQingqing Zhuo
Add vbios table support for DCN 3.1.5. Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amd/display: Add DCN315 ResourceQingqing Zhuo
Add display resource management for DCN 3.1.5. Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amd/display: Add DCN315 DMUBQingqing Zhuo
Add support for the DMUB firmware for DCN 3.1.5. Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amd/display: Add DCN315 IRQQingqing Zhuo
Add irq interfaces for DCN 3.1.5. Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amd/display: Add DCN315 GPIOQingqing Zhuo
Add GPIO interfaces for DCN 3.1.5. Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amd/display: Add DCN315 CLK_MGRQingqing Zhuo
Clk and SMU interfaces for DCN 3.1.5. Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amd/display: Add DCN315 family informationQingqing Zhuo
Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Acked-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amd/include: add DCN 3.1.5 registersQingqing Zhuo
Add DCN 3.1.5 and DPCS 4.2.2 register headers. Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Change-Id: I5588a1c422ae384cc76aa42380545dfc1aad1948 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amdgpu: add mp 13.0.5 header filesYifan Zhang
This patch is to add mp 13.0.5 header files. v2: update headers Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amd/pm: add smu_v13_0_5_ppt implementationYifan Zhang
this patch adds smu_v13_0_5_ppt implementation. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amd/pm: update smc message sequence for smu 13.0.5Yifan Zhang
this patch updates smc message sequence for smu 13.0.5. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/admgpu/pm: add smu 13.0.5 driver interface headersYifan Zhang
This patch is to add smu 13.0.5 driver interface headers. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amdgpu: add support for psp 13.0.5Yifan Zhang
Enabl psp support for psp 13.0.5. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amdgpu: add smuio support for smuio 13.0.10Yifan Zhang
this patch adds smuio support for smuio 13.0.10. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amdgpu: add support for nbio 7.3.0Yifan Zhang
this patch adds support for nbio 7.3.0. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amdgpu: enable vcn pg and cg for vcn 3.1.2Boyuan Zhang
Enable PG and CG for VCN/JPEG Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amdgpu/vcn: add vcn support for vcn 3.1.2Boyuan Zhang
Load VCN FW, set caps. Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amdgpu: add support for sdma 5.2.6Yifan Zhang
This patch adds support for sdma 5.2.6. Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18drm/amdgpu: do not enable asic reset for raven2Chen Gong
The GPU reset function of raven2 is not maintained or tested, so it should be very unstable. Now the amdgpu_asic_reset function is added to amdgpu_pmops_suspend, which causes the S3 test of raven2 to fail, so the asic_reset of raven2 is ignored here. Fixes: daf8de0874ab5b ("drm/amdgpu: always reset the asic in suspend (v2)") Signed-off-by: Chen Gong <curry.gong@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-02-18Merge branch 'acpi-processor'Rafael J. Wysocki
Merge fix for a recent boot lockup regression on 32-bit ThinkPad T40. * acpi-processor: ACPI: processor: idle: fix lockup regression on 32-bit ThinkPad T40
2022-02-18Merge tag 'mtd/fixes-for-5.17-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull MTD fixes from Miquel Raynal: "MTD changes: - Qcom: - Don't print error message on -EPROBE_DEFER - Fix kernel panic on skipped partition - Fix missing free for pparts in cleanup - phram: Prevent divide by zero bug in phram_setup() Raw NAND controller changes: - ingenic: Fix missing put_device in ingenic_ecc_get - qcom: Fix clock sequencing in qcom_nandc_probe() - omap2: Prevent invalid configuration and build error - gpmi: Don't leak PM reference in error path - brcmnand: Fix incorrect sub-page ECC status" * tag 'mtd/fixes-for-5.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: rawnand: brcmnand: Fixed incorrect sub-page ECC status mtd: rawnand: gpmi: don't leak PM reference in error path mtd: phram: Prevent divide by zero bug in phram_setup() mtd: rawnand: omap2: Prevent invalid configuration and build error mtd: parsers: qcom: Fix missing free for pparts in cleanup mtd: parsers: qcom: Fix kernel panic on skipped partition mtd: parsers: qcom: Don't print error message on -EPROBE_DEFER mtd: rawnand: qcom: Fix clock sequencing in qcom_nandc_probe() mtd: rawnand: ingenic: Fix missing put_device in ingenic_ecc_get
2022-02-18drm/msm/dpu: Fix timeout issues on command mode panelsAngeloGioacchino Del Regno
In function dpu_encoder_phys_cmd_wait_for_commit_done we are always checking if the relative CTL is started by waiting for an interrupt to fire: it is fine to do that, but then sometimes we call this function while the CTL is up and has never been put down, but that interrupt gets raised only when the CTL gets a state change from 0 to 1 (disabled to enabled), so we're going to wait for something that will never happen on its own. Solving this while avoiding to restart the CTL is actually possible and can be done by just checking if it is already up and running when the wait_for_commit_done function is called: in this case, so, if the CTL was already running, we can say that the commit is done if the command transmission is complete (in other terms, if the interface has been flushed). Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210911163919.47173-2-angelogioacchino.delregno@somainline.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>