Add SM8350 qcom iommu implementation to the table of
qcom_smmu_impl_of_match table which brings in iommu support for SM8350
SoC
Signed-off-by: NVinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20210115090322.2287538-2-vkoul@kernel.orgSigned-off-by: NWill Deacon <will@kernel.org>

The primary SMMU found in Qualcomm SC8180X platform needs to use the
Qualcomm implementation, so add a specific compatible for this.
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210121014005.1612382-2-bjorn.andersson@linaro.orgSigned-off-by: NWill Deacon <will@kernel.org>

linux/dma-map-ops.h is included more than once, Remove the one that
isn't necessary.
Signed-off-by: NTian Tao <tiantao6@hisilicon.com>
Acked-by: NLu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/1609118774-10083-1-git-send-email-tiantao6@hisilicon.comSigned-off-by: NWill Deacon <will@kernel.org>

SDM630 and MSM8998 are among the SoCs that use Qualcomm's implementation
of SMMUv2 which has already proven to be problematic over the years. Add
their compatibles to the lookup list to prevent the platforms from being
shut down by the hypervisor at MMU probe.
Signed-off-by: NKonrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: NAngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Link: https://lore.kernel.org/r/20210109165622.149777-1-konrad.dybcio@somainline.orgSigned-off-by: NWill Deacon <will@kernel.org>

The VT-d hardware will ignore those Addr bits which have been masked by
the AM field in the PASID-based-IOTLB invalidation descriptor. As the
result, if the starting address in the descriptor is not aligned with
the address mask, some IOTLB caches might not invalidate. Hence people
will see below errors.

[ 1093.704661] dmar_fault: 29 callbacks suppressed
[ 1093.704664] DMAR: DRHD: handling fault status reg 3
[ 1093.712738] DMAR: [DMA Read] Request device [7a:02.0] PASID 2
               fault addr 7f81c968d000 [fault reason 113]
               SM: Present bit in first-level paging entry is clear

Fix this by using aligned address for PASID-based-IOTLB invalidation.

Fixes: 1c4f88b7 ("iommu/vt-d: Shared virtual address in scalable mode")
Reported-and-tested-by: NGuo Kaijie <Kaijie.Guo@intel.com>
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20201231005323.2178523-2-baolu.lu@linux.intel.comSigned-off-by: NWill Deacon <will@kernel.org>

iommu_flush_dev_iotlb() is called to invalidate caches on a device but
only loops over the devices which are fully-attached to the domain. For
sub-devices, this is ineffective and can result in invalid caching
entries left on the device.

Fix the missing invalidation by adding a loop over the subdevices and
ensuring that 'domain->has_iotlb_device' is updated when attaching to
subdevices.

Fixes: 67b8e02b ("iommu/vt-d: Aux-domain specific domain attach/detach")
Signed-off-by: NLiu Yi L <yi.l.liu@intel.com>
Acked-by: NLu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/1609949037-25291-4-git-send-email-yi.l.liu@intel.comSigned-off-by: NWill Deacon <will@kernel.org>

The aux-domain attach/detach are not tracked, some data structures might
be used after free. This causes general protection faults when multiple
subdevices are created and assigned to a same guest machine:

  | general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] SMP NOPTI
  | RIP: 0010:intel_iommu_aux_detach_device+0x12a/0x1f0
  | [...]
  | Call Trace:
  |  iommu_aux_detach_device+0x24/0x70
  |  vfio_mdev_detach_domain+0x3b/0x60
  |  ? vfio_mdev_set_domain+0x50/0x50
  |  iommu_group_for_each_dev+0x4f/0x80
  |  vfio_iommu_detach_group.isra.0+0x22/0x30
  |  vfio_iommu_type1_detach_group.cold+0x71/0x211
  |  ? find_exported_symbol_in_section+0x4a/0xd0
  |  ? each_symbol_section+0x28/0x50
  |  __vfio_group_unset_container+0x4d/0x150
  |  vfio_group_try_dissolve_container+0x25/0x30
  |  vfio_group_put_external_user+0x13/0x20
  |  kvm_vfio_group_put_external_user+0x27/0x40 [kvm]
  |  kvm_vfio_destroy+0x45/0xb0 [kvm]
  |  kvm_put_kvm+0x1bb/0x2e0 [kvm]
  |  kvm_vm_release+0x22/0x30 [kvm]
  |  __fput+0xcc/0x260
  |  ____fput+0xe/0x10
  |  task_work_run+0x8f/0xb0
  |  do_exit+0x358/0xaf0
  |  ? wake_up_state+0x10/0x20
  |  ? signal_wake_up_state+0x1a/0x30
  |  do_group_exit+0x47/0xb0
  |  __x64_sys_exit_group+0x18/0x20
  |  do_syscall_64+0x57/0x1d0
  |  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fix the crash by tracking the subdevices when attaching and detaching
aux-domains.

Fixes: 67b8e02b ("iommu/vt-d: Aux-domain specific domain attach/detach")
Co-developed-by: NXin Zeng <xin.zeng@intel.com>
Signed-off-by: NXin Zeng <xin.zeng@intel.com>
Signed-off-by: NLiu Yi L <yi.l.liu@intel.com>
Acked-by: NLu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/1609949037-25291-3-git-send-email-yi.l.liu@intel.comSigned-off-by: NWill Deacon <will@kernel.org>

'struct intel_svm' is shared by all devices bound to a give process,
but records only a single pointer to a 'struct intel_iommu'. Consequently,
cache invalidations may only be applied to a single DMAR unit, and are
erroneously skipped for the other devices.

In preparation for fixing this, rework the structures so that the iommu
pointer resides in 'struct intel_svm_dev', allowing 'struct intel_svm'
to track them in its device list.

Fixes: 1c4f88b7 ("iommu/vt-d: Shared virtual address in scalable mode")
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Raj Ashok <ashok.raj@intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Reported-by: NGuo Kaijie <Kaijie.Guo@intel.com>
Reported-by: NXin Zeng <xin.zeng@intel.com>
Signed-off-by: NGuo Kaijie <Kaijie.Guo@intel.com>
Signed-off-by: NXin Zeng <xin.zeng@intel.com>
Signed-off-by: NLiu Yi L <yi.l.liu@intel.com>
Tested-by: NGuo Kaijie <Kaijie.Guo@intel.com>
Cc: stable@vger.kernel.org # v5.0+
Acked-by: NLu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/1609949037-25291-2-git-send-email-yi.l.liu@intel.comSigned-off-by: NWill Deacon <will@kernel.org>

On SM8150 it's occasionally observed that the boot hangs in between the
writing of SMEs and context banks in arm_smmu_device_reset().

The problem seems to coincide with a display refresh happening after
updating the stream mapping, but before clearing - and there by
disabling translation - the context bank picked to emulate translation
bypass.

Resolve this by explicitly disabling the bypass context already in
cfg_probe.

Fixes: f9081b8f ("iommu/arm-smmu-qcom: Implement S2CR quirk")
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210106005038.4152731-1-bjorn.andersson@linaro.orgSigned-off-by: NWill Deacon <will@kernel.org>

Lock(&iommu->lock) without disabling irq causes lockdep warnings.

========================================================
WARNING: possible irq lock inversion dependency detected
5.11.0-rc1+ #828 Not tainted
--------------------------------------------------------
kworker/0:1H/120 just changed the state of lock:
ffffffffad9ea1b8 (device_domain_lock){..-.}-{2:2}, at:
iommu_flush_dev_iotlb.part.0+0x32/0x120
but this lock took another, SOFTIRQ-unsafe lock in the past:
 (&iommu->lock){+.+.}-{2:2}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
 Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&iommu->lock);
                               local_irq_disable();
                               lock(device_domain_lock);
                               lock(&iommu->lock);
  <Interrupt>
    lock(device_domain_lock);

 *** DEADLOCK ***
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20201231005323.2178523-5-baolu.lu@linux.intel.comSigned-off-by: NWill Deacon <will@kernel.org>

This reverts commit 65f746e8.

As commit 8a473dba ("drm/i915: Fix DMA mapped scatterlist walks") and
commit 934941ed ("drm/i915: Fix DMA mapped scatterlist lookup") fixed
the DMA scatterlist limitations in the i915 driver, remove this temporary
workaround.

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Tom Murphy <murphyt7@tcd.ie>
Cc: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20201231005323.2178523-4-baolu.lu@linux.intel.comSigned-off-by: NWill Deacon <will@kernel.org>

Use IS_ALIGNED() instead. Otherwise, an unaligned address will be ignored.

Fixes: 33cd6e64 ("iommu/vt-d: Flush PASID-based iotlb for iova over first level")
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20201231005323.2178523-1-baolu.lu@linux.intel.comSigned-off-by: NWill Deacon <will@kernel.org>

The AMD IOMMU initialisation registers the IRQ remapping domain for
each IOMMU before doing the final sanity check that every I/OAPIC is
covered.

This means that the AMD irq_remapping_select() function gets invoked
even when IRQ remapping has been disabled, eventually leading to a NULL
pointer dereference in alloc_irq_table().

Unfortunately, the IVRS isn't fully parsed early enough that the sanity
check can be done in time to registering the IRQ domain altogether.
Doing that would be nice, but is a larger and more error-prone task. The
simple fix is just for irq_remapping_select() to refuse to report a
match when IRQ remapping has disabled.

Link: https://lore.kernel.org/lkml/ed4be9b4-24ac-7128-c522-7ef359e8185d@gmx.at
Fixes: a1a785b5 ("iommu/amd: Implement select() method on remapping irqdomain")
Reported-by: NJohnathan Smithinovic <johnathan.smithinovic@gmx.at>
Signed-off-by: NDavid Woodhouse <dwmw@amazon.co.uk>
Link: https://lore.kernel.org/r/04bbe8bca87f81a3cfa93ec4299e53f47e00e5b3.camel@infradead.orgSigned-off-by: NWill Deacon <will@kernel.org>

When I made the INTCAPXT support stop gratuitously pretending to be MSI,
I missed the fact that iommu_setup_msi() also sets the ->int_enabled
flag. I missed this in the iommu_setup_intcapxt() code path, which means
that a resume from suspend will try to allocate the IRQ domains again,
accidentally re-enabling interrupts as it does, resulting in much sadness.

Lift out the bit which sets iommu->int_enabled into the iommu_init_irq()
function which is also where it gets checked.

Link: https://lore.kernel.org/r/20210104132250.GE32151@zn.tnic/
Fixes: d1adcfbb ("iommu/amd: Fix IOMMU interrupt generation in X2APIC mode")
Reported-by: NBorislav Petkov <bp@alien8.de>
Signed-off-by: NDavid Woodhouse <dwmw@amazon.co.uk>
Tested-by: NBorislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/50cd5f55be8ead0937ac315cd2f5b89364f6a9a5.camel@infradead.orgSigned-off-by: NWill Deacon <will@kernel.org>

When irq_domain_get_irq_data() or irqd_cfg() fails
at i == 0, data allocated by kzalloc() has not been
freed before returning, which leads to memleak.

Fixes: b106ee63 ("irq_remapping/vt-d: Enhance Intel IR driver to support hierarchical irqdomains")
Signed-off-by: NDinghao Liu <dinghao.liu@zju.edu.cn>
Acked-by: NLu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20210105051837.32118-1-dinghao.liu@zju.edu.cnSigned-off-by: NWill Deacon <will@kernel.org>

Replace misspelled 'doamin' with 'domain' in several comments.
Signed-off-by: NStefano Garzarella <sgarzare@redhat.com>
Link: https://lore.kernel.org/r/20201222164232.88795-1-sgarzare@redhat.comSigned-off-by: NWill Deacon <will@kernel.org>

Commit c9a3c4e6 ("mfd: ab8500-debugfs: Remove extraneous curly
brace") removed a left-over curly brace that caused build failures, but
Joe Perches points out that the subsequent 'seq_putc()' should also be
removed, because the commit that caused all these problems already added
the final '\n' to the seq_printf() above it.
Reported-by: NJoe Perches <joe@perches.com>
Fixes: 886c8121 ("mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc")
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Clang errors:

  drivers/mfd/ab8500-debugfs.c:1526:2: error: non-void function does not return a value [-Werror,-Wreturn-type]
          }
          ^
  drivers/mfd/ab8500-debugfs.c:1528:2: error: expected identifier or '('
  return 0;
          ^
  drivers/mfd/ab8500-debugfs.c:1529:1: error: extraneous closing brace ('}')
  }
  ^
  3 errors generated.

The cleanup in ab8500_interrupts_show left a curly brace around, remove
it to fix the error.

Fixes: 886c8121 ("mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc")
Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 660c4865 ("PCI: dwc: Set 32-bit DMA mask for MSI target address
allocation") added dma_mask_set() call to explicitly set 32-bit DMA mask
for MSI message mapping, but for now it throws a warning on ret == 0, while
dma_set_mask() returns 0 in case of success.

Fix this by inverting the condition.

[bhelgaas: join string to make it greppable]
Fixes: 660c4865 ("PCI: dwc: Set 32-bit DMA mask for MSI target address allocation")
Link: https://lore.kernel.org/r/20201222150708.67983-1-alobakin@pm.meSigned-off-by: NAlexander Lobakin <alobakin@pm.me>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Commit b9ac0f9d ("PCI: dwc: Move dw_pcie_setup_rc() to DWC common
code") broke enumeration of downstream devices on Tegra:

In non-working case (next-20201211):

  0001:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad2 (rev a1)
  0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 (rev 13)
  0005:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad0 (rev a1)

In working case (v5.10-rc7):

  0001:00:00.0 PCI bridge: Molex Incorporated Device 1ad2 (rev a1)
  0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 (rev 13)
  0005:00:00.0 PCI bridge: Molex Incorporated Device 1ad0 (rev a1)
  0005:01:00.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab)
  0005:02:02.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab)
  0005:03:00.0 USB controller: PLX Technology, Inc. Device 3380 (rev ab)

The problem seems to be dw_pcie_setup_rc() is now called twice before and
after the link up handling. The fix is to move Tegra's link up handling to
.start_link() function like other DWC drivers. Tegra is a bit more
complicated than others as it re-inits the whole DWC controller to retry
the link. With this, the initialization ordering is restored to match the
prior sequence.

Fixes: b9ac0f9d ("PCI: dwc: Move dw_pcie_setup_rc() to DWC common code")
Link: https://lore.kernel.org/r/20201218143905.1614098-1-robh@kernel.orgReported-by: NMian Yousaf Kaukab <ykaukab@suse.de>
Tested-by: NMian Yousaf Kaukab <ykaukab@suse.de>
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: Vidya Sagar <vidyas@nvidia.com>

clang (quite rightly) complains fairly loudly about the newly added
mpc1_get_mpc_out_mux() function returning an uninitialized value if the
'opp_id' checks don't pass.

This may not happen in practice, but the code really shouldn't return
garbage if the sanity checks don't pass.

So just initialize 'val' to zero to avoid the issue.

Fixes: 110b055b ("drm/amd/display: add getter routine to retrieve mpcc mux")
Cc: Josip Pavic <Josip.Pavic@amd.com>
Cc: Bindu Ramamurthy <bindu.r@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Swap the calling sequence of krealloc() and __request_region(), call the
latter first. In this way, the value of dev_dax->nr_range does not need to
be considered when __request_region() failed.
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20201219081840.1149-2-thunder.leizhen@huawei.comSigned-off-by: NDan Williams <dan.j.williams@intel.com>

There are multiple locations that open-code the release of the last
range in a device-dax instance. Consolidate this into a new
dev_dax_trim_range() helper.

This also addresses a kmemleak report:

# cat /sys/kernel/debug/kmemleak
[..]
unreferenced object 0xffff976bd46f6240 (size 64):
   comm "ndctl", pid 23556, jiffies 4299514316 (age 5406.733s)
   hex dump (first 32 bytes):
     00 00 00 00 00 00 00 00 00 00 20 c3 37 00 00 00  .......... .7...
     ff ff ff 7f 38 00 00 00 00 00 00 00 00 00 00 00  ....8...........
   backtrace:
     [<00000000064003cf>] __kmalloc_track_caller+0x136/0x379
     [<00000000d85e3c52>] krealloc+0x67/0x92
     [<00000000d7d3ba8a>] __alloc_dev_dax_range+0x73/0x25c
     [<0000000027d58626>] devm_create_dev_dax+0x27d/0x416
     [<00000000434abd43>] __dax_pmem_probe+0x1c9/0x1000 [dax_pmem_core]
     [<0000000083726c1c>] dax_pmem_probe+0x10/0x1f [dax_pmem]
     [<00000000b5f2319c>] nvdimm_bus_probe+0x9d/0x340 [libnvdimm]
     [<00000000c055e544>] really_probe+0x230/0x48d
     [<000000006cabd38e>] driver_probe_device+0x122/0x13b
     [<0000000029c7b95a>] device_driver_attach+0x5b/0x60
     [<0000000053e5659b>] bind_store+0xb7/0xc3
     [<00000000d3bdaadc>] drv_attr_store+0x27/0x31
     [<00000000949069c5>] sysfs_kf_write+0x4a/0x57
     [<000000004a8b5adf>] kernfs_fop_write+0x150/0x1e5
     [<00000000bded60f0>] __vfs_write+0x1b/0x34
     [<00000000b92900f0>] vfs_write+0xd8/0x1d1
Reported-by: NJane Chu <jane.chu@oracle.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/160834570161.1791850.14911670304441510419.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by: NDan Williams <dan.j.williams@intel.com>

EDID parsing in S3 resume pushes new display modes
to probed_modes list but doesn't consolidate to actual
mode list. This creates a race condition when
amdgpu_dm_connector_ddc_get_modes() re-initializes the
list head without walking the list and results in  memory leak.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=209987Acked-by: NHarry Wentland <harry.wentland@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: NStylon Wang <stylon.wang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

This is not a scsi driver.
Reviewed-by: NNirmoy Das <nirmoy.das@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fixes a crash in drm_object_property_set_value() because the property
is not set for internal DP ports that connect to a bridge chips
(e.g., DP to VGA or DP to LVDS).

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=210739
Fixes: 65bf2cf9 ("drm/amdgpu: utilize subconnector property for DP through atombios")
Tested-By: NKris Karas <bugs-a17@moonlit-rail.com>
Cc: Oleg Vasilev <oleg.vasilev@intel.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 5.10.x

This can suppress the annoying but unharmful prompts.
Signed-off-by: NEvan Quan <evan.quan@amd.com>
Reviewed-by: NGuchun Chen <guchun.chen@amd.com>
Reviewed-by: NLijo Lazar <lijo.lazar@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why & How]
Add function to identify which MPCC is providing input to a specified OPP
Signed-off-by: NJosip Pavic <Josip.Pavic@amd.com>
Acked-by: NBindu Ramamurthy <bindu.r@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
We defer clock updates to after pipes have been programmed. In
some instances we use DPPCLK that have been previously set to be
"unused". This results in a brief window of time where underflow
could occur.

[How]
During prepare bandwidth allow rn_update_clocks_update_dpp_dto
to check each instance and compare previous clock to new clock.
If new clock is higher than previous clock, program DPPDTO.
Signed-off-by: NJake Wang <haonan.wang2@amd.com>
Acked-by: NBindu Ramamurthy <bindu.r@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

- restore lvtma_pwrseq_delay2 from vbios integrated info table
- restore MVID/NVID after power up.
- Enable timer wake up mask when enable timer interrupt.
Signed-off-by: NYongqiang Sun <yongqiang.sun@amd.com>
Acked-by: NBindu Ramamurthy <bindu.r@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
For certain timings, Renoir may underflow due to sr exit  latency
being too slow.

[How]
Updated wm table for renoir.
Signed-off-by: NJake Wang <haonan.wang2@amd.com>
Acked-by: NBindu Ramamurthy <bindu.r@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[WHY]
DSC should only be acquired per OPP. Therefore, DSC should only
be acquired for the top_pipe when ODM is enabled.
Not doing this check may lead to acquiring more DSC's than needed
when doing MPO + ODM Combine.

[HOW]
Only acquire DSC if pipe is top_pipe.
Signed-off-by: NSung Lee <sung.lee@amd.com>
Acked-by: NBindu Ramamurthy <bindu.r@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
FP2 programming not happening when topology changes occur with multiple
displays.

[How]
Ensure FP2 is programmed whenever global sync changes occur but wait for
VACTIVE first to avoid underflow.
Signed-off-by: NAric Cyr <aric.cyr@amd.com>
Acked-by: NBindu Ramamurthy <bindu.r@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
new_crtc_state is already dereferenced earlier in the function

[How]
Remove the check
Signed-off-by: NEryk Brol <eryk.brol@amd.com>
Acked-by: NBindu Ramamurthy <bindu.r@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[WHY]
Virtual signals were previously counted as a workaround to S0i2 hang
which is fixed on Renoir. This blocks S0i3 diags testing.

[HOW]
Stop counting virtual signals as S0i2 hang is fixed on Renoir.
Signed-off-by: NMichael Strauss <michael.strauss@amd.com>
Acked-by: NBindu Ramamurthy <bindu.r@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
there is some garbage showing up during reboot test.
Reason:
SMU might handle display driver msg defered and driver will send
next msg to SMU after 10ms timeout, once SMU FW handle previous msg,
parameters are changed to next one, which result in a wrong value be programmed.

[How]
Extend timeout to 2s so SMU will have enough time to handle driver msg.
Signed-off-by: NYongqiang Sun <yongqiang.sun@amd.com>
Acked-by: NBindu Ramamurthy <bindu.r@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Need driver to pass values of backlight ramp start and ramp reduction so
that intensity can be ramped down appropriately.

[How]
Using abm_parameters structure to get these values from driver.
Signed-off-by: NRizvi <syerizvi@amd.com>
Acked-by: NBindu Ramamurthy <bindu.r@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
The sink count change HPD_IRQ will be ignored if the branch device has only
DP DFP.

[how]
To remove the port type restriction.
Signed-off-by: NMartin Tsai <martin.tsai@amd.com>
Acked-by: NBindu Ramamurthy <bindu.r@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
Some MST display may not report the internal panel to DEVICE_COUNT,
that makes the check condition always failed.

[how]
To update this condition with the reported device count + 1
(because the immediate repeater's internal panel is possibly
not included in DEVICE_COUNT)
Signed-off-by: NMartin Tsai <martin.tsai@amd.com>
Acked-by: NBindu Ramamurthy <bindu.r@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[WHY]
HUBP blanking sequence on DCN30 requires us to check if HUBP is in blank
and also toggle HUBP_DISABLE, which should instead be called
HUBP_SOFT_RESET for what it does in HW.
Signed-off-by: NWesley Chalmers <Wesley.Chalmers@amd.com>
Acked-by: NBindu Ramamurthy <bindu.r@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>