[Why]
Avoid conflict with address ranges mapped by SVM
mechanism that try to be allocated again through
ioctl_alloc in the same process. And viceversa.

[How]
For ioctl_alloc_memory_of_gpu allocations
Check if the address range passed into ioctl memory
alloc does not exist already in the kfd_process
svms->objects interval tree.

For SVM allocations
Look for the address range into the interval tree VA from
the VM inside of each pdds used in a kfd_process.
Signed-off-by: NAlex Sierra <alex.sierra@amd.com>
Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It's used internally by firmware.  Using it in the driver
could conflict with firmware.

v2: squash in fix for navi1x (Alex)
Reviewed-by: NJames Zhu <James.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It's used internally by firmware.  Using it in the driver
could conflict with firmware.
Reviewed-by: NJames Zhu <James.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Query default sclk instead of hard code.
Signed-off-by: NLang Yu <lang.yu@amd.com>
Acked-by: NHuang Rui <ray.huang@amd.com>
Reviewed-by: NLijo Lazar <lijo.lazar@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Generated by: scripts/checkincludes.pl
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Remove all but the first include of reg_helper.h and core_types.h
from dcn201_clk_mgr.c.
Reported-by: NZeal Robot <zealci@zte.com.cn>
Signed-off-by: NLv Ruyi <lv.ruyi@zte.com.cn>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

adev_to_drm is used everywhere, so improve recent changes
when accessing drm_device pointer from amdgpu_device.
Signed-off-by: NGuchun Chen <guchun.chen@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This fix the deadlock with the BO reservations during SVM_BO evictions
while allocations in VRAM are concurrently performed. More specific,
while the ttm waits for the fence to be signaled (ttm_bo_wait), it
already has the BO reserved. In parallel, the restore worker might be
running, prefetching memory to VRAM. This also requires to reserve the
BO, but blocks the mmap semaphore first. The deadlock happens when the
SVM_BO eviction worker kicks in and waits for the mmap semaphore held
in restore worker. Preventing signal the fence back, causing the
deadlock until the ttm times out.

We don't need to hold the BO reservation anymore during validation
and mapping. Now the physical addresses are taken from hmm_range_fault.
We also take migrate_mutex to prevent range migration while
validate_and_map update GPU page table.
Signed-off-by: NAlex Sierra <alex.sierra@amd.com>
Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: NPhilip Yang <philip.yang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why & How]
Got Werror when building with Clang-13:

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dpia.c:195:2:
error: variable 'ts' is used uninitialized whenever switch default is
taken [-Werror,-Wsometimes-uninitialized]

        default:

        ^~~~~~~

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dpia.c:200:9:
note: uninitialized use occurs here

        return ts;

               ^~

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dpia.c:180:2:
note: variable 'ts' is declared here

        enum dpia_set_config_ts ts;

        ^

1 error generated.

Fix it.
Reported-by: NMike Lothian <mike@fireburn.co.uk>
Signed-off-by: NWayne Lin <Wayne.Lin@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Missing 4.1.2.
Reviewed-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The variable result is being initialized with a value that is never
read, it is being updated immediately afterwards in both branches
of an if statement. The assignment is redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Was missed when converting the driver over to IP based
initialization.
Tested-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NGuchun Chen <guchun.chen@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

When trying to bring IS_ACTIVE to linux/kconfig.h I thought it wouldn't
provide much value just encapsulating it in a boolean context. So I also
added the support for handling undefined macros as the IS_ENABLED()
counterpart. However the feedback received from Masahiro Yamada was that
it is too ugly, not providing much value. And just wrapping in a boolean
context is too dumb - we could simply open code it.

As detailed in commit babaab2f ("drm/i915: Encapsulate kconfig
constant values inside boolean predicates"), the IS_ACTIVE macro was
added to workaround a compilation warning. However after checking again
our current uses of IS_ACTIVE it turned out there is only
1 case in which it triggers a warning in clang (due
-Wconstant-logical-operand) and 2 in smatch. All the others
can simply use the shorter version, without wrapping it in any macro.

So here I'm dialing all the way back to simply removing the macro. That
single case hit by clang can be changed to make the constant come first,
so it doesn't think it's mask:

	-       if (context && CONFIG_DRM_I915_FENCE_TIMEOUT)
	+       if (CONFIG_DRM_I915_FENCE_TIMEOUT && context)

As talked with Dan Carpenter, that logic will be added in smatch as
well, so it will also stop warning about it.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMasahiro Yamada <masahiroy@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211005171728.3147094-1-lucas.demarchi@intel.com

Unify BO evicting functionality for possible memory
types in amdgpu_ttm.c.
Signed-off-by: NNirmoy Das <nirmoy.das@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Extend the rcar_du_device_info structure and rcar_du_output enum to
support DSI outputs and utilise these additions to provide support for
the R8A779A0 V3U platform.
Signed-off-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Not all platforms require both per-crtc IRQ and per-crtc clock
management. In preparation for suppporting such platforms, split the
feature macro to be able to specify both features independently.

The other features are incremented accordingly, to keep the two crtc
features adjacent.
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NKieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The DIDSR fields named LDCS were incorrectly defined as LCDS.
Both the Gen2 and Gen3 documentation refer to the fields as the "LVDS
Dot Clock Select".

Correct the definitions.
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NKieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The R-Car DU as found on the D3, E3, and V3U do not have support
for an external synchronisation method.

In these cases, the dsysr cached register should not be initialised
in DSYSR_TVM_TVSYNC, but instead should be left clear to configure as
DSYSR_TVM_MASTER by default.
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NKieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Sort the DU outputs alphabetically, with the exception of the final
entry which is there as a sentinal.
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: NCai Huoqing <caihuoqing@baidu.com>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: NCai Huoqing <caihuoqing@baidu.com>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The correct format specifier for size_t is %zu. Using %d (or %u)
generates a warning on 64-bit platforms. Fix it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NPhilippe Cornu <philippe.cornu@foss.st.com>

The driver accesses the drm_bridge.of_node field, which is present only
if CONFIG_OF is enabled. As all platforms using omapdrm are OF-based, we
can simply depend on CONFIG_OF.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On 64-bit platforms, the compiler complains that casting a void pointer
to an unsigned int loses data. Cast the pointer to a uintptr_t to fix
this.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com>

The correct format specifier for size_t is %zu. Using %d (or %u)
generates a warning on 64-bit platforms. Fix it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com>

strncpy() is widely regarded as unsafe due to the fact that it may leave
the destination string without a nul-termination when the source string
size is too large. When compiling the kernel with W=1, the gcc warns
about this:

drivers/gpu/drm/drm_property.c: In function ‘drm_property_create’:
drivers/gpu/drm/drm_property.c:130:2: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation]
  130 |  strncpy(property->name, name, DRM_PROP_NAME_LEN);
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are three occurrences of strncpy() in drm_property.c. None of them
are actually unsafe, as the very next line forces nul-termination of the
destination buffer. The warning is thus a false positive, but adds noise
to the kernel log. It can easily be silenced by using strscpy_pad()
instead. Do so.

One of the three occurrences, in drm_property_add_enum(), fills a char
array that is later copied to userspace with copy_to_user() in
drm_mode_getproperty_ioctl(). To avoid leaking kernel data,
strscpy_pad() is required. Similarly, a second occurrence, in
drm_mode_getproperty_ioctl(), copies the string to an ioctl data buffer
that isn't previously zero'ed, to strscpy_pad() is also required. The
last occurrence, in drm_property_create(), would be safe to replace with
strscpy(), as the destination buffer is copied to userspace with
strscpy_pad(). However, given that this isn't in a hot path, let's avoid
future data leaks in case someone copies the whole char array blindly.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On R-Car Gen3, the DU uses a separate IP core named VSP to perform DMA
from memory and composition of planes. The DU hardware then only handles
the video timings and the interface with the encoders. This differs from
Gen2, where the DU included a composer with DMA engines.

When sourcing from the VSP, the DU hardware performs no memory access,
and thus has no requirements on imported dma-buf memory types. The GEM
CMA helpers however still create a DMA mapping to the DU device, which
isn't used. The mapping to the VSP is done when processing the atomic
commits, in the plane .prepare_fb() handler.

When the system uses an IOMMU, the VSP device is attached to it, which
enables the VSP to use non physically contiguous memory. The DU, as it
performs no memory access, isn't connected to the IOMMU. The GEM CMA
drm_gem_cma_prime_import_sg_table() helper will in that case fail to map
non-contiguous imported dma-bufs, as the DMA mapping to the DU device
will have multiple entries in its sgtable. The prevents using non
physically contiguous memory for display.

The DRM PRIME and GEM CMA helpers are designed to create the sgtable
when the dma-buf is imported. By default, the device referenced by the
drm_device is used to create the dma-buf attachment. Drivers can use a
different device by using the drm_gem_prime_import_dev() function. While
the DU has access to the VSP device, this won't help here, as different
CRTCs use different VSP instances, connected to different IOMMU
channels. The driver doesn't know at import time which CRTC a GEM object
will be used, and thus can't select the right VSP device to pass to
drm_gem_prime_import_dev().

To support non-contiguous memory, implement a custom
.gem_prime_import_sg_table() operation that accepts all imported dma-buf
regardless of the number of scatterlist entries. The sgtable will be
mapped to the VSP at .prepare_fb() time, which will reject the
framebuffer if the VSP isn't connected to an IOMMU.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>

The DU DMA address space is limited to 32 bits, so the DMA coherent mask
should be set accordingly. The DMA mapping implementation will
transparently map high memory buffers to 32-bit addresses through an
IOMMU when present (or through bounce buffers otherwise, which isn't a
supported use case as performances would be terrible).

However, when sourcing frames from a VSP, the situation is more
complicated. The DU delegates all memory accesses to the VSP and doesn't
perform any DMA access by itself. Due to how the GEM CMA helpers are
structured buffers are still mapped to the DU device. They are later
mapped to the VSP as well to perform DMA access, through the IOMMU
connected to the VSP.

Setting the DMA coherent mask to 32 bits for the DU when using a VSP can
cause issues when importing a dma_buf. If the buffer is located above
the 32-bit address space, the DMA mapping implementation will try to map
it to the DU's DMA address space. As the DU has no IOMMU a bounce buffer
will be allocated, which in the best case will waste memory and in the
worst case will just fail.

To work around this issue, set the DMA coherent mask to the full 40-bit
address space for the DU. All dma-buf instances will be imported without
any restriction, and will be mapped to the VSP when preparing the
associated framebuffer.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NLiviu Dudau <liviu.dudau@arm.com>

Improve the debugging and error messages printing when initializing
encoders by replacing the output number by the output name, printing the
bridge OF node name, and the error code of failed operations.

While at it, move the related rcar_du_output enumeration from
rcar_du_crtc.h to rcar_du_drv.h as it's not specific to the CRTC.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

On R-Car D3 and E3, the LVDS encoders provide the pixel clock to the DU,
even when LVDS outputs are not used. For this reason, the rcar-lvds
driver probes successfully on those platforms even if no further bridge
or panel is connected to the LVDS output, in order to provide the
rcar_lvds_clk_enable() and rcar_lvds_clk_disable() functions to the DU
driver.

If an LVDS output isn't connected, trying to create a DRM connector for
the output will fail. Fix this by skipping connector creation in that
case, and also skip creation of the DRM encoder as there's no point in
an encoder without a connector.

Fixes: e9e05694 ("drm: rcar-du: lvds: Convert to DRM panel bridge helper")
Reported-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>

[Why]
For those video format with 60 fps, the user space player could
ask for 120Hz for playback.

[How]
Add 120 in the table of common rates.
Signed-off-by: NSolomon Chiu <solomon.chiu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

On Aldebaran, GPU driver will handle bad page retirement
for GPU memory even though UMC is host managed. As a result,
register a bad page retirement handler on the mce notifier
chain to retire bad pages on Aldebaran.
Signed-off-by: NMukul Joshi <mukul.joshi@amd.com>
Reviewed-by: NYazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Check first if debugfs is initialized before creating
amdgpu debugfs files.

References: https://gitlab.freedesktop.org/drm/amd/-/issues/1686Signed-off-by: NNirmoy Das <nirmoy.das@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NLijo Lazar <lijo.lazar@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
YELLOW_CARP_B0 address was not correct

[How]
Set YELLOW_CARP_B0 to 0x1A.
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: NWayne Lin <Wayne.Lin@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NJude Shih <shenshih@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Condition variable sometimes terminated unexpectedly

[How]
Use wait_for_completion_timeout to avoid unexpected termination of CV
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: NWayne Lin <Wayne.Lin@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NJude Shih <shenshih@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[why]
1. HPD callback function has deadlock problem
2. HPD status is not assigned
3. There is crash due to null pointer
4. link_enc is NULL in DPIA case

[How]
1. Fix deadlock problem by moving it out of the
   drm_modeset_lock
2. Assign HPD status from the notify of outbox
   from dmub FW
3. Fix the crash by checking if pin or enc exists
4. Use link_enc_cfg_get_link_enc_used_by_link to
   dynamically assign
Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: NWayne Lin <Wayne.Lin@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NJude Shih <shenshih@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why & How]
1. Remove unnecessary dummy interrupt source for USB4 HPD & HPD RX
2. Adjust parameter for DPCD writing of link training process of DPIA link
3. Adjust specific AUX defer delay for DPIA link
Reviewed-by: NJimmy Kizito <Jimmy.Kizito@amd.com>
Acked-by: NWayne Lin <Wayne.Lin@amd.com>
Acked-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NMeenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why & How]
Additional debug flags that can be useful for testing USB4 DP
link training.

Add flags:
- 0x2 : Forces USB4 DP link to non-LTTPR mode
- 0x4 : Extends status read intervals to about 60s.
Reviewed-by: NMeenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com>
Reviewed-by: NJun Lei <Jun.Lei@amd.com>
Acked-by: NWayne Lin <Wayne.Lin@amd.com>
Acked-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NJimmy Kizito <Jimmy.Kizito@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
DIB_BE_CNTL<i>.DIG_HPD_SELECT selects the HPD block being used
by the display endpoint assigned to DIG<i>. In the case of USB4
display endpoints, no physical HPD block is assigned.

[How]
Setting DIB_BE_CNTL<i>.DIG_HPD_SELECT to 5 indicates that no HPD
is assigned to a display endpoint. Firmware decrements the
HPD_SELECT value by 1 before writing it to the register.
Reviewed-by: NMeenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com>
Acked-by: NWayne Lin <Wayne.Lin@amd.com>
Acked-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NJimmy Kizito <Jimmy.Kizito@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
To process SET_CONFIG transactions with DMUB using inbox1 and
outbox1 mail boxes.

[How]
1) DMUB posts SET_CONFIG reply as an Outbox1 message of type
   DMUB_OUT_CMD__SET_CONFIG_REPLY.
2) The dmub async to sync mechanism for AUX is modified to accommodate
   SET_CONFIG commands for both command issue and reply code paths.
Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: NWayne Lin <Wayne.Lin@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NJude Shih <shenshih@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>