Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems
Am 21.02.19 um 22:02 schrieb Thomas Hellstrom: > Hi, > > On Thu, 2019-02-21 at 20:24 +, Kuehling, Felix wrote: >> On 2019-02-21 12:34 p.m., Thomas Hellstrom wrote: >>> On Thu, 2019-02-21 at 16:57 +, Kuehling, Felix wrote: On 2019-02-21 2:59 a.m., Koenig, Christian wrote: > On x86 with HIGHMEM there is no dma32 zone. Why do we need one > on >>> x86_64? Can we make x86_64 more like HIGHMEM instead? >>> >>> Regards, >>>Felix >>> >> IIRC with x86, the kernel zone is always smaller than any >> dma32 >> zone, >> so we'd always exhaust the kernel zone before dma32 anyway. >> >> Not sure why we have dma32 on x86 without highmem, though. >> sounds >> superflous but harmless. > Well DMA32 denotes memory which is accessible by devices who > can > only do > 32bit addressing. And IIRC we can actually do DMA32 to highmem > since > something like 2.4.*. > > Because of this it is actually irrelevant if you have highmem > or > not, > what matters for DMA32 is if you have an IOMMU or not. Are you saying we should have a dma32_zone even on x86 with HIGHMEM? > So even on x86_64 you actually do need the DMA32 zone if you > don't > have > an IOMMU which remaps all memory for devices which can't > directly > address it. Why is DMA32 special in this way? For example AMD GFX8 GPUs support 40-bit DMA. But we don't have a special zone for that. >>> If you're running on a non-IOMMU system with physical memory >>> addresses 40 bits, and tell the DMA subsystem that you need to restrict to 40 >>> bits, it will probably start using bounce buffers for streaming DMA >>> (which won't work with most graphics drivers), or for >>> dma_alloc_coherent(), it will probably use memory from the DMA32 >>> zone. >> OK, then why is it not needed when CONFIG_HIGHMEM is defined? >> >> I found that there is a CONFIG_ZONE_DMA32 parameter. Maybe we should >> use >> that to decide whether to account for the DMA32 zone in TTM. It is >> set >> on x86_64 and a number of other 64-bit architectures. >> >> How common is it to have devices that need DMA32 on an x86_64 system? >>> IIRC All devices using dma_alloc_coherent() allocate DMA32 memory >>> unless they explicitly set the dma coherent mask to something >>> larger. >>> Like Christian says, if an IOMMU is present and enabled, the need >>> for >>> the DMA32 zone goes away. In theory at least. >> Thanks. I read up a bit on DMA32 and memory zones in general. I >> found >> that there is a lowmem_reserve_ratio feature that protects against >> normal page allocations overflowing into lowmem zones. There is some >> documentation in Documentation/scsctl/vm.txt (search for >> lowmem_reserve_ratio). The protected amount of memory in each zone >> can >> be seen in /proc/zoneinfo. >> >> With that, can we conclude that we don't need to count >> ttm_mem_global_alloc against the dma32 zone. > Yes, it indeed looks like that. > But then I would suggest removing the DMA32 zone entirely. We still need it for the pages we allocate, but we should just stop accounting all the housekeeping to it. To answer Felix earlier question we really still need DMA32 without IOMMU even on a 64bit system. The problem is simply that you have tons of PCIe hardware which can do only 32bit addressing, for example the audio codecs even on our newest Vega chips. Regards, Christian. > > /Thomas > > >> Thanks, >> Felix >> >> >>> /Thomas >>> >>> Regards, Felix > Regards, > Christian. > >> /Thomas >> >> ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 8/8] drm/amd/powerplay: show the right override pcie parameters
Series is:
Acked-by: Alex Deucher
On Thu, Feb 21, 2019 at 10:09 PM Evan Quan wrote:
>
> Instead of the hard-coded ones from VBIOS.
>
> Change-Id: Ic317e292fbea89f01badfcfe240134aabcbe84ec
> Signed-off-by: Evan Quan
> ---
> .../drm/amd/powerplay/hwmgr/vega20_hwmgr.c| 46 ---
> .../drm/amd/powerplay/hwmgr/vega20_hwmgr.h| 4 ++
> 2 files changed, 34 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
> index 740268315adf..800ab2702ec7 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
> @@ -783,6 +783,8 @@ static int vega20_init_smc_table(struct pp_hwmgr *hwmgr)
> static int vega20_override_pcie_parameters(struct pp_hwmgr *hwmgr)
> {
> struct amdgpu_device *adev = (struct amdgpu_device *)(hwmgr->adev);
> + struct vega20_hwmgr *data =
> + (struct vega20_hwmgr *)(hwmgr->backend);
> uint32_t pcie_gen = 0, pcie_width = 0, smu_pcie_arg;
> int ret;
>
> @@ -819,6 +821,10 @@ static int vega20_override_pcie_parameters(struct
> pp_hwmgr *hwmgr)
> "[OverridePcieParameters] Attempt to override pcie params
> failed!",
> return ret);
>
> + data->pcie_parameters_override = 1;
> + data->pcie_gen_level1 = pcie_gen;
> + data->pcie_width_level1 = pcie_width;
> +
> return 0;
> }
>
> @@ -3103,7 +3109,7 @@ static int vega20_print_clock_levels(struct pp_hwmgr
> *hwmgr,
> &(data->dpm_table.fclk_table);
> int i, now, size = 0;
> int ret = 0;
> - uint32_t gen_speed, lane_width;
> + uint32_t gen_speed, lane_width, current_gen_speed, current_lane_width;
>
> switch (type) {
> case PP_SCLK:
> @@ -3187,28 +3193,36 @@ static int vega20_print_clock_levels(struct pp_hwmgr
> *hwmgr,
> break;
>
> case PP_PCIE:
> - gen_speed = (RREG32_PCIE(smnPCIE_LC_SPEED_CNTL) &
> + current_gen_speed = (RREG32_PCIE(smnPCIE_LC_SPEED_CNTL) &
>
> PSWUSP0_PCIE_LC_SPEED_CNTL__LC_CURRENT_DATA_RATE_MASK)
> >>
> PSWUSP0_PCIE_LC_SPEED_CNTL__LC_CURRENT_DATA_RATE__SHIFT;
> - lane_width = (RREG32_PCIE(smnPCIE_LC_LINK_WIDTH_CNTL) &
> + current_lane_width = (RREG32_PCIE(smnPCIE_LC_LINK_WIDTH_CNTL)
> &
> PCIE_LC_LINK_WIDTH_CNTL__LC_LINK_WIDTH_RD_MASK)
> >>
> PCIE_LC_LINK_WIDTH_CNTL__LC_LINK_WIDTH_RD__SHIFT;
> - for (i = 0; i < NUM_LINK_LEVELS; i++)
> + for (i = 0; i < NUM_LINK_LEVELS; i++) {
> + if (i == 1 && data->pcie_parameters_override) {
> + gen_speed = data->pcie_gen_level1;
> + lane_width = data->pcie_width_level1;
> + } else {
> + gen_speed = pptable->PcieGenSpeed[i];
> + lane_width = pptable->PcieLaneCount[i];
> + }
> size += sprintf(buf + size, "%d: %s %s %dMhz %s\n", i,
> - (pptable->PcieGenSpeed[i] == 0) ?
> "2.5GT/s," :
> - (pptable->PcieGenSpeed[i] == 1) ?
> "5.0GT/s," :
> - (pptable->PcieGenSpeed[i] == 2) ?
> "8.0GT/s," :
> - (pptable->PcieGenSpeed[i] == 3) ?
> "16.0GT/s," : "",
> - (pptable->PcieLaneCount[i] == 1) ?
> "x1" :
> - (pptable->PcieLaneCount[i] == 2) ?
> "x2" :
> - (pptable->PcieLaneCount[i] == 3) ?
> "x4" :
> - (pptable->PcieLaneCount[i] == 4) ?
> "x8" :
> - (pptable->PcieLaneCount[i] == 5) ?
> "x12" :
> - (pptable->PcieLaneCount[i] == 6) ?
> "x16" : "",
> + (gen_speed == 0) ? "2.5GT/s," :
> + (gen_speed == 1) ? "5.0GT/s," :
> + (gen_speed == 2) ? "8.0GT/s," :
> + (gen_speed == 3) ? "16.0GT/s," : "",
> + (lane_width == 1) ? "x1" :
> + (lane_width == 2) ? "x2" :
> + (lane_width == 3) ? "x4" :
> + (lane_width == 4) ? "x8" :
> + (lane_width == 5) ? "x12" :
> + (lane_width == 6) ? "x16" : "",
> pptable->LclkFreq[i],
> -
Re: [PATCH] drm/amd/display: Fix reference counting for struct dc_sink.
Good Morning, On Thursday, 21 February 2019 22:00:40 CET Li, Sun peng (Leo) wrote: > > On 2019-02-20 12:24 a.m., Mathias Fröhlich wrote: > > Hi, > > > > ping? > > ... to the dc folks? > > > > best > > Mathias > > Hi Mathias, > > Sorry for the wait, change looks good to me. > > Reviewed-by: Leo Li > ...and merged. > > Thanks for cleaning this up. > Leo Thanks! Mathias ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Use vrr friendly pageflip throttling in DC
On 2/9/19 1:52 AM, Mario Kleiner wrote:
> In VRR mode, keep track of the vblank count of the last
> completed pageflip in amdgpu_crtc->last_flip_vblank, as
> recorded in the pageflip completion handler after each
> completed flip.
>
> Use that count to prevent mmio programming a new pageflip
> within the same vblank in which the last pageflip completed,
> iow. to throttle pageflips to at most one flip per video
> frame, while at the same time allowing to request a flip
> not only before start of vblank, but also anywhere within
> vblank.
>
> The old logic did the same, and made sense for regular fixed
> refresh rate flipping, but in vrr mode it prevents requesting
> a flip anywhere inside the possibly huge vblank, thereby
> reducing framerate in vrr mode instead of improving it, by
> delaying a slightly delayed flip requests up to a maximum
> vblank duration + 1 scanout duration. This would limit VRR
> usefulness to only help applications with a very high GPU
> demand, which can submit the flip request before start of
> vblank, but then have to wait long for fences to complete.
>
> With this method a flip can be both requested and - after
> fences have completed - executed, ie. it doesn't matter if
> the request (amdgpu_dm_do_flip()) gets delayed until deep
> into the extended vblank due to cpu execution delays. This
> also allows clients which want to regulate framerate within
> the vrr range a much more fine-grained control of flip timing,
> a feature that might be useful for video playback, and is
> very useful for neuroscience/vision research applications.
>
> In regular non-VRR mode, retain the old flip submission
> behavior. This to keep flip scheduling for fullscreen X11/GLX
> OpenGL clients intact, if they use the GLX_OML_sync_control
> extensions glXSwapBufferMscOML(, ..., target_msc,...) function
> with a specific target_msc target vblank count.
>
> glXSwapBuffersMscOML() or DRI3/Present PresentPixmap() will
> not flip at the proper target_msc for a non-zero target_msc
> if VRR mode is active with this patch. They'd often flip one
> frame too early. However, this limitation should not matter
> much in VRR mode, as scheduling based on vblank counts is
> pretty futile/unusable under variable refresh duration
> anyway, so no real extra harm is done.
>
> According to some testing already done with this patch by
> Nicholas on top of my tests, IGT tests didn't report any
> problems. If fixes stuttering and flickering when flipping
> at rates below the minimum vrr refresh rate.
>
> Fixes: bb47de736661 ("drm/amdgpu: Set FreeSync state using drm VRR
> properties")
> Signed-off-by: Mario Kleiner
> Cc:
> Cc: Nicholas Kazlauskas
> Cc: Harry Wentland
> Cc: Alex Deucher
> Cc: Michel Dänzer
This gets rid of stuttering with FreeSync for me. The current behavior
shows constant periodic stutters at lower than maximum framerates. Please
try pushing this into 5.1.
Tested-by: Bruno Filipe
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 8/8] drm/amd/powerplay: show the right override pcie parameters
Instead of the hard-coded ones from VBIOS.
Change-Id: Ic317e292fbea89f01badfcfe240134aabcbe84ec
Signed-off-by: Evan Quan
---
.../drm/amd/powerplay/hwmgr/vega20_hwmgr.c| 46 ---
.../drm/amd/powerplay/hwmgr/vega20_hwmgr.h| 4 ++
2 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
index 740268315adf..800ab2702ec7 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
@@ -783,6 +783,8 @@ static int vega20_init_smc_table(struct pp_hwmgr *hwmgr)
static int vega20_override_pcie_parameters(struct pp_hwmgr *hwmgr)
{
struct amdgpu_device *adev = (struct amdgpu_device *)(hwmgr->adev);
+ struct vega20_hwmgr *data =
+ (struct vega20_hwmgr *)(hwmgr->backend);
uint32_t pcie_gen = 0, pcie_width = 0, smu_pcie_arg;
int ret;
@@ -819,6 +821,10 @@ static int vega20_override_pcie_parameters(struct pp_hwmgr
*hwmgr)
"[OverridePcieParameters] Attempt to override pcie params
failed!",
return ret);
+ data->pcie_parameters_override = 1;
+ data->pcie_gen_level1 = pcie_gen;
+ data->pcie_width_level1 = pcie_width;
+
return 0;
}
@@ -3103,7 +3109,7 @@ static int vega20_print_clock_levels(struct pp_hwmgr
*hwmgr,
&(data->dpm_table.fclk_table);
int i, now, size = 0;
int ret = 0;
- uint32_t gen_speed, lane_width;
+ uint32_t gen_speed, lane_width, current_gen_speed, current_lane_width;
switch (type) {
case PP_SCLK:
@@ -3187,28 +3193,36 @@ static int vega20_print_clock_levels(struct pp_hwmgr
*hwmgr,
break;
case PP_PCIE:
- gen_speed = (RREG32_PCIE(smnPCIE_LC_SPEED_CNTL) &
+ current_gen_speed = (RREG32_PCIE(smnPCIE_LC_SPEED_CNTL) &
PSWUSP0_PCIE_LC_SPEED_CNTL__LC_CURRENT_DATA_RATE_MASK)
>>
PSWUSP0_PCIE_LC_SPEED_CNTL__LC_CURRENT_DATA_RATE__SHIFT;
- lane_width = (RREG32_PCIE(smnPCIE_LC_LINK_WIDTH_CNTL) &
+ current_lane_width = (RREG32_PCIE(smnPCIE_LC_LINK_WIDTH_CNTL) &
PCIE_LC_LINK_WIDTH_CNTL__LC_LINK_WIDTH_RD_MASK)
>> PCIE_LC_LINK_WIDTH_CNTL__LC_LINK_WIDTH_RD__SHIFT;
- for (i = 0; i < NUM_LINK_LEVELS; i++)
+ for (i = 0; i < NUM_LINK_LEVELS; i++) {
+ if (i == 1 && data->pcie_parameters_override) {
+ gen_speed = data->pcie_gen_level1;
+ lane_width = data->pcie_width_level1;
+ } else {
+ gen_speed = pptable->PcieGenSpeed[i];
+ lane_width = pptable->PcieLaneCount[i];
+ }
size += sprintf(buf + size, "%d: %s %s %dMhz %s\n", i,
- (pptable->PcieGenSpeed[i] == 0) ?
"2.5GT/s," :
- (pptable->PcieGenSpeed[i] == 1) ?
"5.0GT/s," :
- (pptable->PcieGenSpeed[i] == 2) ?
"8.0GT/s," :
- (pptable->PcieGenSpeed[i] == 3) ?
"16.0GT/s," : "",
- (pptable->PcieLaneCount[i] == 1) ? "x1"
:
- (pptable->PcieLaneCount[i] == 2) ? "x2"
:
- (pptable->PcieLaneCount[i] == 3) ? "x4"
:
- (pptable->PcieLaneCount[i] == 4) ? "x8"
:
- (pptable->PcieLaneCount[i] == 5) ?
"x12" :
- (pptable->PcieLaneCount[i] == 6) ?
"x16" : "",
+ (gen_speed == 0) ? "2.5GT/s," :
+ (gen_speed == 1) ? "5.0GT/s," :
+ (gen_speed == 2) ? "8.0GT/s," :
+ (gen_speed == 3) ? "16.0GT/s," : "",
+ (lane_width == 1) ? "x1" :
+ (lane_width == 2) ? "x2" :
+ (lane_width == 3) ? "x4" :
+ (lane_width == 4) ? "x8" :
+ (lane_width == 5) ? "x12" :
+ (lane_width == 6) ? "x16" : "",
pptable->LclkFreq[i],
- (gen_speed == pptable->PcieGenSpeed[i])
&&
- (lane_width ==
pptable->PcieLaneCount[i]) ?
+ (current_gen_speed == gen_speed) &&
+ (current_lane_width ==
[PATCH 2/8] drm/amd/powerplay: need to reapply the dpm level settings
As these settings got reset during above phm_apply_clock_adjust_rules.
Change-Id: Ie3296a87ef1d1b02e2195cdf69bdfb45c0b9f453
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
index ce177d7f04cb..6bf48934fdc4 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c
@@ -277,8 +277,7 @@ int psm_adjust_power_state_dynamic(struct pp_hwmgr *hwmgr,
bool skip_display_set
if (!skip_display_settings)
phm_notify_smc_display_config_after_ps_adjustment(hwmgr);
- if ((hwmgr->request_dpm_level != hwmgr->dpm_level) &&
- !phm_force_dpm_levels(hwmgr, hwmgr->request_dpm_level))
+ if (!phm_force_dpm_levels(hwmgr, hwmgr->request_dpm_level))
hwmgr->dpm_level = hwmgr->request_dpm_level;
if (hwmgr->dpm_level != AMD_DPM_FORCED_LEVEL_MANUAL) {
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 6/8] drm/amd/powerplay: set default fclk for no fclk dpm support case
Set the default fclk as what we got from VBIOS.
Change-Id: If1c54dc854a5ebe0cdb439bad8fefc26e80f0511
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c | 3 +++
drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.h | 1 +
drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 7 +--
drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.h | 1 +
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
index a28192bfb035..615cf2c09e54 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
@@ -545,6 +545,9 @@ static void
pp_atomfwctrl_copy_vbios_bootup_values_3_2(struct pp_hwmgr *hwmgr,
if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU11_SYSPLL0_DCLK_ID, SMU11_SYSPLL0_ID, ))
boot_values->ulDClk = frequency;
+
+ if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU11_SYSPLL1_0_FCLK_ID, SMU11_SYSPLL1_2_ID, ))
+ boot_values->ulFClk = frequency;
}
static void pp_atomfwctrl_copy_vbios_bootup_values_3_1(struct pp_hwmgr *hwmgr,
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.h
b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.h
index 9bafd00324a9..b7e2651b570b 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.h
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.h
@@ -139,6 +139,7 @@ struct pp_atomfwctrl_bios_boot_up_values {
uint32_t ulEClk;
uint32_t ulVClk;
uint32_t ulDClk;
+ uint32_t ulFClk;
uint16_t usVddc;
uint16_t usVddci;
uint16_t usMvddc;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
index 15408807e23e..1f63fb4e7610 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
@@ -711,8 +711,10 @@ static int vega20_setup_default_dpm_tables(struct pp_hwmgr
*hwmgr)
PP_ASSERT_WITH_CODE(!ret,
"[SetupDefaultDpmTable] failed to get fclk dpm
levels!",
return ret);
- } else
- dpm_table->count = 0;
+ } else {
+ dpm_table->count = 1;
+ dpm_table->dpm_levels[0].value = data->vbios_boot_state.fclock
/ 100;
+ }
vega20_init_dpm_state(&(dpm_table->dpm_state));
/* save a copy of the default DPM table */
@@ -754,6 +756,7 @@ static int vega20_init_smc_table(struct pp_hwmgr *hwmgr)
data->vbios_boot_state.eclock = boot_up_values.ulEClk;
data->vbios_boot_state.vclock = boot_up_values.ulVClk;
data->vbios_boot_state.dclock = boot_up_values.ulDClk;
+ data->vbios_boot_state.fclock = boot_up_values.ulFClk;
data->vbios_boot_state.uc_cooling_id = boot_up_values.ucCoolingID;
smum_send_msg_to_smc_with_parameter(hwmgr,
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.h
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.h
index 37f5f5e657da..4a4cad35dc8f 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.h
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.h
@@ -219,6 +219,7 @@ struct vega20_vbios_boot_state {
uint32_teclock;
uint32_tdclock;
uint32_tvclock;
+ uint32_tfclock;
};
#define DPMTABLE_OD_UPDATE_SCLK 0x0001
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 7/8] drm/amd/powerplay: honor the OD settings
Set the soft/hard max settings as max possible to
not violate the OD settings.
Change-Id: Ia87eb13b914cb85aac64525a30ef7af57fddf912
Signed-off-by: Evan Quan
---
.../drm/amd/powerplay/hwmgr/vega20_hwmgr.c| 32 +--
.../drm/amd/powerplay/hwmgr/vega20_hwmgr.h| 2 ++
2 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
index 1f63fb4e7610..740268315adf 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
@@ -463,9 +463,9 @@ static int vega20_setup_asic_task(struct pp_hwmgr *hwmgr)
static void vega20_init_dpm_state(struct vega20_dpm_state *dpm_state)
{
dpm_state->soft_min_level = 0x0;
- dpm_state->soft_max_level = 0x;
+ dpm_state->soft_max_level = VG20_CLOCK_MAX_DEFAULT;
dpm_state->hard_min_level = 0x0;
- dpm_state->hard_max_level = 0x;
+ dpm_state->hard_max_level = VG20_CLOCK_MAX_DEFAULT;
}
static int vega20_get_number_of_dpm_level(struct pp_hwmgr *hwmgr,
@@ -3458,9 +3458,9 @@ static int vega20_apply_clocks_adjust_rules(struct
pp_hwmgr *hwmgr)
/* gfxclk */
dpm_table = &(data->dpm_table.gfx_table);
dpm_table->dpm_state.soft_min_level = dpm_table->dpm_levels[0].value;
- dpm_table->dpm_state.soft_max_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+ dpm_table->dpm_state.soft_max_level = VG20_CLOCK_MAX_DEFAULT;
dpm_table->dpm_state.hard_min_level = dpm_table->dpm_levels[0].value;
- dpm_table->dpm_state.hard_max_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+ dpm_table->dpm_state.hard_max_level = VG20_CLOCK_MAX_DEFAULT;
if (PP_CAP(PHM_PlatformCaps_UMDPState)) {
if (VEGA20_UMD_PSTATE_GFXCLK_LEVEL < dpm_table->count) {
@@ -3482,9 +3482,9 @@ static int vega20_apply_clocks_adjust_rules(struct
pp_hwmgr *hwmgr)
/* memclk */
dpm_table = &(data->dpm_table.mem_table);
dpm_table->dpm_state.soft_min_level = dpm_table->dpm_levels[0].value;
- dpm_table->dpm_state.soft_max_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+ dpm_table->dpm_state.soft_max_level = VG20_CLOCK_MAX_DEFAULT;
dpm_table->dpm_state.hard_min_level = dpm_table->dpm_levels[0].value;
- dpm_table->dpm_state.hard_max_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+ dpm_table->dpm_state.hard_max_level = VG20_CLOCK_MAX_DEFAULT;
if (PP_CAP(PHM_PlatformCaps_UMDPState)) {
if (VEGA20_UMD_PSTATE_MCLK_LEVEL < dpm_table->count) {
@@ -3526,18 +3526,18 @@ static int vega20_apply_clocks_adjust_rules(struct
pp_hwmgr *hwmgr)
/* fclk */
dpm_table = &(data->dpm_table.fclk_table);
dpm_table->dpm_state.soft_min_level = dpm_table->dpm_levels[0].value;
- dpm_table->dpm_state.soft_max_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+ dpm_table->dpm_state.soft_max_level = VG20_CLOCK_MAX_DEFAULT;
dpm_table->dpm_state.hard_min_level = dpm_table->dpm_levels[0].value;
- dpm_table->dpm_state.hard_max_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+ dpm_table->dpm_state.hard_max_level = VG20_CLOCK_MAX_DEFAULT;
if (hwmgr->display_config->nb_pstate_switch_disable)
dpm_table->dpm_state.soft_min_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
/* vclk */
dpm_table = &(data->dpm_table.vclk_table);
dpm_table->dpm_state.soft_min_level = dpm_table->dpm_levels[0].value;
- dpm_table->dpm_state.soft_max_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+ dpm_table->dpm_state.soft_max_level = VG20_CLOCK_MAX_DEFAULT;
dpm_table->dpm_state.hard_min_level = dpm_table->dpm_levels[0].value;
- dpm_table->dpm_state.hard_max_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+ dpm_table->dpm_state.hard_max_level = VG20_CLOCK_MAX_DEFAULT;
if (PP_CAP(PHM_PlatformCaps_UMDPState)) {
if (VEGA20_UMD_PSTATE_UVDCLK_LEVEL < dpm_table->count) {
@@ -3554,9 +3554,9 @@ static int vega20_apply_clocks_adjust_rules(struct
pp_hwmgr *hwmgr)
/* dclk */
dpm_table = &(data->dpm_table.dclk_table);
dpm_table->dpm_state.soft_min_level = dpm_table->dpm_levels[0].value;
- dpm_table->dpm_state.soft_max_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+ dpm_table->dpm_state.soft_max_level = VG20_CLOCK_MAX_DEFAULT;
dpm_table->dpm_state.hard_min_level = dpm_table->dpm_levels[0].value;
- dpm_table->dpm_state.hard_max_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+ dpm_table->dpm_state.hard_max_level = VG20_CLOCK_MAX_DEFAULT;
if (PP_CAP(PHM_PlatformCaps_UMDPState)) {
if (VEGA20_UMD_PSTATE_UVDCLK_LEVEL < dpm_table->count) {
@@ -3573,9 +3573,9 @@
[PATCH 3/8] drm/amd/powerplay: force FCLK to highest also for 5K or higher displays
This can fix possible screen freeze on high resolution displays.
Change-Id: Ia1f1708638a85d57789a61ba0937c5221bd28c31
Signed-off-by: Evan Quan
---
.../drm/amd/powerplay/hwmgr/vega20_hwmgr.c| 38 ++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
index 6bde0782da7d..c594ca4ef17e 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
@@ -3332,6 +3332,31 @@ static int vega20_set_uclk_to_highest_dpm_level(struct
pp_hwmgr *hwmgr,
return ret;
}
+static int vega20_set_fclk_to_highest_dpm_level(struct pp_hwmgr *hwmgr)
+{
+ struct vega20_hwmgr *data = (struct vega20_hwmgr *)(hwmgr->backend);
+ struct vega20_single_dpm_table *dpm_table =
&(data->dpm_table.fclk_table);
+ int ret = 0;
+
+ if (data->smu_features[GNLD_DPM_FCLK].enabled) {
+ PP_ASSERT_WITH_CODE(dpm_table->count > 0,
+ "[SetFclkToHightestDpmLevel] Dpm table has no
entry!",
+ return -EINVAL);
+ PP_ASSERT_WITH_CODE(dpm_table->count <= NUM_FCLK_DPM_LEVELS,
+ "[SetFclkToHightestDpmLevel] Dpm table has too
many entries!",
+ return -EINVAL);
+
+ dpm_table->dpm_state.soft_min_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+ PP_ASSERT_WITH_CODE(!(ret =
smum_send_msg_to_smc_with_parameter(hwmgr,
+ PPSMC_MSG_SetSoftMinByFreq,
+ (PPCLK_FCLK << 16 ) |
dpm_table->dpm_state.soft_min_level)),
+ "[SetFclkToHightestDpmLevel] Set soft min fclk
failed!",
+ return ret);
+ }
+
+ return ret;
+}
+
static int vega20_pre_display_configuration_changed_task(struct pp_hwmgr
*hwmgr)
{
struct vega20_hwmgr *data = (struct vega20_hwmgr *)(hwmgr->backend);
@@ -3342,8 +3367,10 @@ static int
vega20_pre_display_configuration_changed_task(struct pp_hwmgr *hwmgr)
ret = vega20_set_uclk_to_highest_dpm_level(hwmgr,
>dpm_table.mem_table);
+ if (ret)
+ return ret;
- return ret;
+ return vega20_set_fclk_to_highest_dpm_level(hwmgr);
}
static int vega20_display_configuration_changed_task(struct pp_hwmgr *hwmgr)
@@ -3502,6 +3529,15 @@ static int vega20_apply_clocks_adjust_rules(struct
pp_hwmgr *hwmgr)
if (hwmgr->display_config->nb_pstate_switch_disable)
dpm_table->dpm_state.hard_min_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+ /* fclk */
+ dpm_table = &(data->dpm_table.fclk_table);
+ dpm_table->dpm_state.soft_min_level = dpm_table->dpm_levels[0].value;
+ dpm_table->dpm_state.soft_max_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+ dpm_table->dpm_state.hard_min_level = dpm_table->dpm_levels[0].value;
+ dpm_table->dpm_state.hard_max_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+ if (hwmgr->display_config->nb_pstate_switch_disable)
+ dpm_table->dpm_state.soft_min_level =
dpm_table->dpm_levels[dpm_table->count - 1].value;
+
/* vclk */
dpm_table = &(data->dpm_table.vclk_table);
dpm_table->dpm_state.soft_min_level = dpm_table->dpm_levels[0].value;
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 4/8] drm/amd/powerplay: overwrite ODSettingsMin for UCLK_FMAX feature
For UCLK_FMAX OD feature, SMU overwrites the highest UCLK DPM level freq.
Therefore it can only take values that are greater than the second highest
DPM level freq.
Change-Id: I81eec21d8212ee08425c6462376b82690f4f8038
Signed-off-by: Evan Quan
---
.../drm/amd/powerplay/hwmgr/vega20_hwmgr.c| 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
index c594ca4ef17e..15408807e23e 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
@@ -979,6 +979,8 @@ static int vega20_od8_set_feature_capabilities(
}
if (data->smu_features[GNLD_DPM_UCLK].enabled) {
+ pptable_information->od_settings_min[OD8_SETTING_UCLK_FMAX] =
+
data->dpm_table.mem_table.dpm_levels[data->dpm_table.mem_table.count - 2].value;
if
(pptable_information->od_feature_capabilities[ATOM_VEGA20_ODFEATURE_UCLK_MAX] &&
pptable_information->od_settings_min[OD8_SETTING_UCLK_FMAX]
> 0 &&
pptable_information->od_settings_max[OD8_SETTING_UCLK_FMAX]
> 0 &&
@@ -2775,7 +2777,6 @@ static int vega20_odn_edit_dpm_table(struct pp_hwmgr
*hwmgr,
data->od8_settings.od8_settings_array;
OverDriveTable_t *od_table =
&(data->smc_state_table.overdrive_table);
- struct pp_clock_levels_with_latency clocks;
int32_t input_index, input_clk, input_vol, i;
int od8_id;
int ret;
@@ -2834,11 +2835,6 @@ static int vega20_odn_edit_dpm_table(struct pp_hwmgr
*hwmgr,
return -EOPNOTSUPP;
}
- ret = vega20_get_memclocks(hwmgr, );
- PP_ASSERT_WITH_CODE(!ret,
- "Attempt to get memory clk levels failed!",
- return ret);
-
for (i = 0; i < size; i += 2) {
if (i + 2 > size) {
pr_info("invalid number of input parameters
%d\n",
@@ -2855,11 +2851,11 @@ static int vega20_odn_edit_dpm_table(struct pp_hwmgr
*hwmgr,
return -EINVAL;
}
- if (input_clk < clocks.data[0].clocks_in_khz / 1000 ||
+ if (input_clk <
od8_settings[OD8_SETTING_UCLK_FMAX].min_value ||
input_clk >
od8_settings[OD8_SETTING_UCLK_FMAX].max_value) {
pr_info("clock freq %d is not within allowed
range [%d - %d]\n",
input_clk,
- clocks.data[0].clocks_in_khz / 1000,
+
od8_settings[OD8_SETTING_UCLK_FMAX].min_value,
od8_settings[OD8_SETTING_UCLK_FMAX].max_value);
return -EINVAL;
}
@@ -3264,13 +3260,8 @@ static int vega20_print_clock_levels(struct pp_hwmgr
*hwmgr,
}
if (od8_settings[OD8_SETTING_UCLK_FMAX].feature_id) {
- ret = vega20_get_memclocks(hwmgr, );
- PP_ASSERT_WITH_CODE(!ret,
- "Fail to get memory clk levels!",
- return ret);
-
size += sprintf(buf + size, "MCLK: %7uMhz %10uMhz\n",
- clocks.data[0].clocks_in_khz / 1000,
+ od8_settings[OD8_SETTING_UCLK_FMAX].min_value,
od8_settings[OD8_SETTING_UCLK_FMAX].max_value);
}
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 5/8] drm/amd/powerplay: support retrieving clock information from other sysplls
There will be some needs to retrieve clock information from other
sysplls also except default 0.
Change-Id: I312f11679b5c146f7315d096fab1d051ce6ecc6c
Signed-off-by: Evan Quan
---
.../drm/amd/powerplay/hwmgr/ppatomfwctrl.c| 27 ++-
.../drm/amd/powerplay/hwmgr/ppatomfwctrl.h| 3 ++-
.../drm/amd/powerplay/hwmgr/vega10_hwmgr.c| 4 +--
3 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
index 4588bddf8b33..a28192bfb035 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c
@@ -489,15 +489,16 @@ int pp_atomfwctrl_get_gpio_information(struct pp_hwmgr
*hwmgr,
}
int pp_atomfwctrl_get_clk_information_by_clkid(struct pp_hwmgr *hwmgr,
- uint8_t id, uint32_t *frequency)
+ uint8_t clk_id, uint8_t
syspll_id,
+ uint32_t *frequency)
{
struct amdgpu_device *adev = hwmgr->adev;
struct atom_get_smu_clock_info_parameters_v3_1 parameters;
struct atom_get_smu_clock_info_output_parameters_v3_1 *output;
uint32_t ix;
- parameters.clk_id = id;
- parameters.syspll_id = 0;
+ parameters.clk_id = clk_id;
+ parameters.syspll_id = syspll_id;
parameters.command = GET_SMU_CLOCK_INFO_V3_1_GET_CLOCK_FREQ;
parameters.dfsdid = 0;
@@ -530,19 +531,19 @@ static void
pp_atomfwctrl_copy_vbios_bootup_values_3_2(struct pp_hwmgr *hwmgr,
boot_values->ulSocClk = 0;
boot_values->ulDCEFClk = 0;
- if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU11_SYSPLL0_SOCCLK_ID, ))
+ if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU11_SYSPLL0_SOCCLK_ID, SMU11_SYSPLL0_ID, ))
boot_values->ulSocClk = frequency;
- if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU11_SYSPLL0_DCEFCLK_ID, ))
+ if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU11_SYSPLL0_DCEFCLK_ID, SMU11_SYSPLL0_ID, ))
boot_values->ulDCEFClk = frequency;
- if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU11_SYSPLL0_ECLK_ID, ))
+ if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU11_SYSPLL0_ECLK_ID, SMU11_SYSPLL0_ID, ))
boot_values->ulEClk = frequency;
- if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU11_SYSPLL0_VCLK_ID, ))
+ if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU11_SYSPLL0_VCLK_ID, SMU11_SYSPLL0_ID, ))
boot_values->ulVClk = frequency;
- if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU11_SYSPLL0_DCLK_ID, ))
+ if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU11_SYSPLL0_DCLK_ID, SMU11_SYSPLL0_ID, ))
boot_values->ulDClk = frequency;
}
@@ -563,19 +564,19 @@ static void
pp_atomfwctrl_copy_vbios_bootup_values_3_1(struct pp_hwmgr *hwmgr,
boot_values->ulSocClk = 0;
boot_values->ulDCEFClk = 0;
- if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU9_SYSPLL0_SOCCLK_ID, ))
+ if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU9_SYSPLL0_SOCCLK_ID, 0, ))
boot_values->ulSocClk = frequency;
- if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU9_SYSPLL0_DCEFCLK_ID, ))
+ if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU9_SYSPLL0_DCEFCLK_ID, 0, ))
boot_values->ulDCEFClk = frequency;
- if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU9_SYSPLL0_ECLK_ID, ))
+ if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU9_SYSPLL0_ECLK_ID, 0, ))
boot_values->ulEClk = frequency;
- if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU9_SYSPLL0_VCLK_ID, ))
+ if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU9_SYSPLL0_VCLK_ID, 0, ))
boot_values->ulVClk = frequency;
- if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU9_SYSPLL0_DCLK_ID, ))
+ if (!pp_atomfwctrl_get_clk_information_by_clkid(hwmgr,
SMU9_SYSPLL0_DCLK_ID, 0, ))
boot_values->ulDClk = frequency;
}
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.h
b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.h
index fe9e8ceef50e..9bafd00324a9 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.h
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.h
@@ -236,7 +236,8 @@ int pp_atomfwctrl_get_vbios_bootup_values(struct pp_hwmgr
*hwmgr,
int pp_atomfwctrl_get_smc_dpm_information(struct pp_hwmgr *hwmgr,
struct pp_atomfwctrl_smc_dpm_parameters *param);
int pp_atomfwctrl_get_clk_information_by_clkid(struct pp_hwmgr *hwmgr,
- uint8_t id,
[PATCH 1/8] drm/amd/powerplay: drop redundant soft min/max settings
As these are already set during apply_clocks_adjust_rules.
Change-Id: I7eb845597ebe0527bf853dffae7e578434651091
Signed-off-by: Evan Quan
---
.../drm/amd/powerplay/hwmgr/vega20_hwmgr.c| 24 ---
1 file changed, 24 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
index aad79affb081..6bde0782da7d 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
@@ -2314,32 +2314,8 @@ static int vega20_force_dpm_lowest(struct pp_hwmgr
*hwmgr)
static int vega20_unforce_dpm_levels(struct pp_hwmgr *hwmgr)
{
- struct vega20_hwmgr *data =
- (struct vega20_hwmgr *)(hwmgr->backend);
- uint32_t soft_min_level, soft_max_level;
int ret = 0;
- soft_min_level =
vega20_find_lowest_dpm_level(&(data->dpm_table.gfx_table));
- soft_max_level =
vega20_find_highest_dpm_level(&(data->dpm_table.gfx_table));
- data->dpm_table.gfx_table.dpm_state.soft_min_level =
- data->dpm_table.gfx_table.dpm_levels[soft_min_level].value;
- data->dpm_table.gfx_table.dpm_state.soft_max_level =
- data->dpm_table.gfx_table.dpm_levels[soft_max_level].value;
-
- soft_min_level =
vega20_find_lowest_dpm_level(&(data->dpm_table.mem_table));
- soft_max_level =
vega20_find_highest_dpm_level(&(data->dpm_table.mem_table));
- data->dpm_table.mem_table.dpm_state.soft_min_level =
- data->dpm_table.mem_table.dpm_levels[soft_min_level].value;
- data->dpm_table.mem_table.dpm_state.soft_max_level =
- data->dpm_table.mem_table.dpm_levels[soft_max_level].value;
-
- soft_min_level =
vega20_find_lowest_dpm_level(&(data->dpm_table.soc_table));
- soft_max_level =
vega20_find_highest_dpm_level(&(data->dpm_table.soc_table));
- data->dpm_table.soc_table.dpm_state.soft_min_level =
- data->dpm_table.soc_table.dpm_levels[soft_min_level].value;
- data->dpm_table.soc_table.dpm_state.soft_max_level =
- data->dpm_table.soc_table.dpm_levels[soft_max_level].value;
-
ret = vega20_upload_dpm_min_level(hwmgr, 0x);
PP_ASSERT_WITH_CODE(!ret,
"Failed to upload DPM Bootup Levels!",
--
2.20.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH libdrm] libdrm: Fix issue about differrent domainID but same BDF
Hi Alex,
Please help, thanks.
Best wishes
Emily Deng
>-Original Message-
>From: Alex Deucher
>Sent: Friday, February 22, 2019 12:13 AM
>To: Deng, Emily ; Maling list - DRI developers de...@lists.freedesktop.org>
>Cc: amd-gfx list
>Subject: Re: [PATCH libdrm] libdrm: Fix issue about differrent domainID but
>same
>BDF
>
>On Thu, Feb 14, 2019 at 2:53 AM Emily Deng wrote:
>>
>> For multiple GPUs which has the same BDF, but has different domain ID,
>> the drmOpenByBusid will return the wrong fd when startx.
>>
>> The reproduce sequence as below:
>> 1. Call drmOpenByBusid to open Card0, then will return the right fd0,
>> and the
>> fd0 is master privilege;
>> 2. Call drmOpenByBusid to open Card1. In function drmOpenByBusid, it
>> will open Card0 first, this time, the fd1 for opening Card0 is not
>> master privilege, and will call drmSetInterfaceVersion to identify the
>> domain ID feature, as the fd1 is not master privilege, then
>> drmSetInterfaceVersion will fail, and then won't compare domain ID, then
>return the wrong fd for Card1.
>>
>> Solution:
>> First loop search the best match fd about drm 1.4.
>>
>> Signed-off-by: Emily Deng
>
>Reviewed-by: Alex Deucher
>
>Do you need someone to commit this for you?
>
>Alex
>
>> ---
>> xf86drm.c | 23 +++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/xf86drm.c b/xf86drm.c
>> index 336d64d..b60e029 100644
>> --- a/xf86drm.c
>> +++ b/xf86drm.c
>> @@ -584,11 +584,34 @@ static int drmOpenByBusid(const char *busid, int
>type)
>> if (base < 0)
>> return -1;
>>
>> +/* We need to try for 1.4 first for proper PCI domain support */
>> drmMsg("drmOpenByBusid: Searching for BusID %s\n", busid);
>> for (i = base; i < base + DRM_MAX_MINOR; i++) {
>> fd = drmOpenMinor(i, 1, type);
>> drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
>> if (fd >= 0) {
>> +sv.drm_di_major = 1;
>> +sv.drm_di_minor = 4;
>> +sv.drm_dd_major = -1;/* Don't care */
>> +sv.drm_dd_minor = -1;/* Don't care */
>> +if (!drmSetInterfaceVersion(fd, )) {
>> +buf = drmGetBusid(fd);
>> +drmMsg("drmOpenByBusid: drmGetBusid reports %s\n", buf);
>> +if (buf && drmMatchBusID(buf, busid, 1)) {
>> +drmFreeBusid(buf);
>> +return fd;
>> +}
>> +if (buf)
>> +drmFreeBusid(buf);
>> +}
>> +close(fd);
>> +}
>> +}
>> +
>> + for (i = base; i < base + DRM_MAX_MINOR; i++) {
>> +fd = drmOpenMinor(i, 1, type);
>> +drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
>> +if (fd >= 0) {
>> /* We need to try for 1.4 first for proper PCI domain support
>> * and if that fails, we know the kernel is busted
>> */
>> --
>> 2.7.4
>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: Differentiate two set_pte_pde function pointers
There were two set_pte_pde function pointers in amdgpu_gmc_funcs and
amdgpu_vm_pte_funcs respectively. Because they are so similar, sometimes
it is confusing. So Rename the one in amdgpu_vm_pte_funcs to
write_pte_pde.
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 6 +++---
drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 6 +++---
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 6 +++---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 6 +++---
drivers/gpu/drm/amd/amdgpu/si_dma.c| 6 +++---
7 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 942b5ebc6dc2..fa86be694e48 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -806,7 +806,7 @@ static int amdgpu_vm_clear_bo(struct amdgpu_device *adev,
if (level != AMDGPU_VM_PTB)
ats_value |= AMDGPU_PDE_PTE;
- amdgpu_vm_set_pte_pde(adev, >ibs[0], addr, 0,
+ amdgpu_vm_write_pte_pde(adev, >ibs[0], addr, 0,
ats_entries, 0, ats_value);
addr += ats_entries * 8;
}
@@ -818,7 +818,7 @@ static int amdgpu_vm_clear_bo(struct amdgpu_device *adev,
if (level == AMDGPU_VM_PTB && adev->asic_type >= CHIP_VEGA10)
value = AMDGPU_PTE_EXECUTABLE;
- amdgpu_vm_set_pte_pde(adev, >ibs[0], addr, 0,
+ amdgpu_vm_write_pte_pde(adev, >ibs[0], addr, 0,
entries, 0, value);
}
@@ -1235,7 +1235,7 @@ static void amdgpu_vm_do_set_ptes(struct
amdgpu_pte_update_params *params,
addr | flags, count, incr);
} else {
- amdgpu_vm_set_pte_pde(params->adev, params->ib, pe, addr,
+ amdgpu_vm_write_pte_pde(params->adev, params->ib, pe, addr,
count, incr, flags);
}
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
index 81ff8177f092..7e345ec2671f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
@@ -161,7 +161,7 @@ struct amdgpu_vm_pte_funcs {
uint64_t value, unsigned count,
uint32_t incr);
/* for linear pte/pde updates without addr mapping */
- void (*set_pte_pde)(struct amdgpu_ib *ib,
+ void (*write_pte_pde)(struct amdgpu_ib *ib,
uint64_t pe,
uint64_t addr, unsigned count,
uint32_t incr, uint64_t flags);
@@ -287,7 +287,7 @@ struct amdgpu_vm_manager {
#define amdgpu_vm_copy_pte(adev, ib, pe, src, count)
((adev)->vm_manager.vm_pte_funcs->copy_pte((ib), (pe), (src), (count)))
#define amdgpu_vm_write_pte(adev, ib, pe, value, count, incr)
((adev)->vm_manager.vm_pte_funcs->write_pte((ib), (pe), (value), (count),
(incr)))
-#define amdgpu_vm_set_pte_pde(adev, ib, pe, addr, count, incr, flags)
((adev)->vm_manager.vm_pte_funcs->set_pte_pde((ib), (pe), (addr), (count),
(incr), (flags)))
+#define amdgpu_vm_write_pte_pde(adev, ib, pe, addr, count, incr, flags)
((adev)->vm_manager.vm_pte_funcs->write_pte_pde((ib), (pe), (addr), (count),
(incr), (flags)))
void amdgpu_vm_manager_init(struct amdgpu_device *adev);
void amdgpu_vm_manager_fini(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
index 189599b694e8..07b874a44ddf 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
+++ b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
@@ -769,7 +769,7 @@ static void cik_sdma_vm_write_pte(struct amdgpu_ib *ib,
uint64_t pe,
}
/**
- * cik_sdma_vm_set_pages - update the page tables using sDMA
+ * cik_sdma_vm_write_pte_pde - update the page tables using sDMA
*
* @ib: indirect buffer to fill with commands
* @pe: addr of the page entry
@@ -780,7 +780,7 @@ static void cik_sdma_vm_write_pte(struct amdgpu_ib *ib,
uint64_t pe,
*
* Update the page tables using sDMA (CIK).
*/
-static void cik_sdma_vm_set_pte_pde(struct amdgpu_ib *ib, uint64_t pe,
+static void cik_sdma_vm_write_pte_pde(struct amdgpu_ib *ib, uint64_t pe,
uint64_t addr, unsigned count,
uint32_t incr, uint64_t flags)
{
@@ -1365,7 +1365,7 @@ static const struct amdgpu_vm_pte_funcs
cik_sdma_vm_pte_funcs = {
.copy_pte = cik_sdma_vm_copy_pte,
.write_pte = cik_sdma_vm_write_pte,
- .set_pte_pde = cik_sdma_vm_set_pte_pde,
+ .write_pte_pde = cik_sdma_vm_write_pte_pde,
};
static void cik_sdma_set_vm_pte_funcs(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
index
[pull] amdgpu, radeon, sched drm-next-5.1
Hi Dave, Daniel, Fixes for 5.1: amdgpu: - Fix missing fw declaration after dropping old CI DPM code - Fix debugfs access to registers beyond the MMIO bar size - Fix context priority handling - Add missing license on some new files - Various cleanups and bug fixes radeon: - Fix missing break in CS parser for evergreen - Various cleanups and bug fixes sched: - Fix entities with 0 run queues The following changes since commit 16065fcdd19ddb9e093192914ac863884f308766: drm/virtio: do NOT reuse resource ids (2019-02-11 14:44:10 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-5.1 for you to fetch changes up to 767e06a9924162ce8ca5890533932174b04471f3: drm/amdgpu: Bump amdgpu version for context priority override. (2019-02-21 15:52:56 -0500) Alex Deucher (6): drm/amdgpu/powerplay: declare firmware for CI cards drm/amdgpu: don't clamp debugfs register access to the BAR size drm/amdgpu: remove some old unused dpm helpers drm/amdgpu: add missing license on baco files drm/amdgpu/powerplay: fix return codes in BACO code drm/amdgpu/powerplay: fix typo in BACO header guards Andrey Grodzovsky (1): drm/amd/display: Fix deadlock with display during hanged ring recovery. Anthony Koo (2): drm/amd/display: remove screen flashes on seamless boot drm/amd/display: Increase precision for backlight curve Bas Nieuwenhuizen (5): drm/sched: Fix entities with 0 rqs. drm/amdgpu: Only add rqs for initialized rings. drm/amdgpu: Check if fd really is an amdgpu fd. drm/amdgpu: Add command to override the context priority. drm/amdgpu: Bump amdgpu version for context priority override. Christian König (3): drm/amdgpu: cleanup amdgpu_ih_process a bit more drm/amdgpu: cleanup setting bulk_movable drm/amdgpu: partial revert cleanup setting bulk_movable v2 Colin Ian King (1): drm/amdgpu: fix several indentation issues Felix Kuehling (4): drm/amdgpu: Add helper to wait for BO fences using a sync object drm/amdgpu: Replace ttm_bo_wait with amdgpu_bo_sync_wait drm/amdgpu: Avoid setting off KFD eviction fences in amdgpu_vm drm/amdgpu: Simplify eviction fence handling Gary Kattan (1): drm/amd/display: Ungate stream before programming registers Gustavo A. R. Silva (9): drm/amd/display/dc/bios_parser2: Mark expected switch fall-throughs drm/radeon/si_dpm: Mark expected switch fall-throughs drm/amd/display/dce_mem_input: Mark expected switch fall-through drm/amd/powerplay/smu7_hwmgr: Mark expected switch fall-throughs drm/radeon/ci_dpm: Mark expected switch fall-throughs drm/amdgpu/si_dpm: Mark expected switch fall-throughs drm/radeon/evergreen_cs: fix missing break in switch statement drm/amd/powerplay/smu8_hwmgr: use struct_size() in kzalloc() drm/amd/powerplay/smu10_hwmgr: use struct_size() in kzalloc() Josip Pavic (2): drm/amd/display: send pipe set command to dmcu when stream unblanks drm/amd/display: send pipe set command to dmcu when backlight is set Nicholas Kazlauskas (5): drm/amd/display: Fix wrong z-order when updating overlay planes drm/amd/display: Don't expose support for DRM_FORMAT_RGB888 drm/amd/display: Fix update type mismatches in atomic check drm/amd/display: Do cursor updates after stream updates drm/amd/display: Clear stream->mode_changed after commit Yong Zhao (8): drm/amdgpu: Fix bugs in setting CP RB/MEC DOORBELL_RANGE registers drm/amdgpu: Delete user queue doorbell variables drm/amdkfd: Move a constant definition around drm/amdgpu: Add first_non_cp and last_non_cp in amdgpu_doorbell_index drm/amdkfd: Fix bugs regarding CP queue doorbell mask on SOC15 drm/amdkfd: Optimize out sdma doorbell array in kgd2kfd_shared_resources Revert "drm/amdgpu: Delete user queue doorbell variables" Revert "drm/amdgpu: Fix bugs in setting CP RB/MEC DOORBELL_RANGE registers" Yongqiang Sun (1): drm/amd/display: Refactor for setup periodic interrupt. wentalou (1): drm/amdgpu: tighten gpu_recover in mailbox_flr to avoid duplicate recover in sriov drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 47 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 138 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c| 11 +- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c| 3 - drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell.h | 9 + drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c| 88 -- drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h| 9 - drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 19 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems
Hi, On Thu, 2019-02-21 at 20:24 +, Kuehling, Felix wrote: > On 2019-02-21 12:34 p.m., Thomas Hellstrom wrote: > > On Thu, 2019-02-21 at 16:57 +, Kuehling, Felix wrote: > > > On 2019-02-21 2:59 a.m., Koenig, Christian wrote: > > > > On x86 with HIGHMEM there is no dma32 zone. Why do we need one > > > > on > > > > > > x86_64? Can we make x86_64 more like HIGHMEM instead? > > > > > > > > > > > > Regards, > > > > > > Felix > > > > > > > > > > > IIRC with x86, the kernel zone is always smaller than any > > > > > dma32 > > > > > zone, > > > > > so we'd always exhaust the kernel zone before dma32 anyway. > > > > > > > > > > Not sure why we have dma32 on x86 without highmem, though. > > > > > sounds > > > > > superflous but harmless. > > > > Well DMA32 denotes memory which is accessible by devices who > > > > can > > > > only do > > > > 32bit addressing. And IIRC we can actually do DMA32 to highmem > > > > since > > > > something like 2.4.*. > > > > > > > > Because of this it is actually irrelevant if you have highmem > > > > or > > > > not, > > > > what matters for DMA32 is if you have an IOMMU or not. > > > Are you saying we should have a dma32_zone even on x86 with > > > HIGHMEM? > > > > > > > > > > So even on x86_64 you actually do need the DMA32 zone if you > > > > don't > > > > have > > > > an IOMMU which remaps all memory for devices which can't > > > > directly > > > > address it. > > > Why is DMA32 special in this way? For example AMD GFX8 GPUs > > > support > > > 40-bit DMA. But we don't have a special zone for that. > > If you're running on a non-IOMMU system with physical memory > > addresses > > > 40 bits, and tell the DMA subsystem that you need to restrict to > > > 40 > > bits, it will probably start using bounce buffers for streaming DMA > > (which won't work with most graphics drivers), or for > > dma_alloc_coherent(), it will probably use memory from the DMA32 > > zone. > > OK, then why is it not needed when CONFIG_HIGHMEM is defined? > > I found that there is a CONFIG_ZONE_DMA32 parameter. Maybe we should > use > that to decide whether to account for the DMA32 zone in TTM. It is > set > on x86_64 and a number of other 64-bit architectures. > > > > > How common is it to have devices that need DMA32 on an x86_64 > > > system? > > IIRC All devices using dma_alloc_coherent() allocate DMA32 memory > > unless they explicitly set the dma coherent mask to something > > larger. > > Like Christian says, if an IOMMU is present and enabled, the need > > for > > the DMA32 zone goes away. In theory at least. > > Thanks. I read up a bit on DMA32 and memory zones in general. I > found > that there is a lowmem_reserve_ratio feature that protects against > normal page allocations overflowing into lowmem zones. There is some > documentation in Documentation/scsctl/vm.txt (search for > lowmem_reserve_ratio). The protected amount of memory in each zone > can > be seen in /proc/zoneinfo. > > With that, can we conclude that we don't need to count > ttm_mem_global_alloc against the dma32 zone. Yes, it indeed looks like that. But then I would suggest removing the DMA32 zone entirely. /Thomas > > Thanks, >Felix > > > > /Thomas > > > > > > > Regards, > > > Felix > > > > > > > > > > Regards, > > > > Christian. > > > > > > > > > /Thomas > > > > > > > > > > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/display: Fix reference counting for struct dc_sink.
On 2019-02-20 12:24 a.m., Mathias Fröhlich wrote: > Hi, > > ping? > ... to the dc folks? > > best > Mathias Hi Mathias, Sorry for the wait, change looks good to me. Reviewed-by: Leo Li ...and merged. Thanks for cleaning this up. Leo > > On Wednesday, 13 February 2019 21:38:03 CET Alex Deucher wrote: >> Add amd-gfx and some DC people. >> >> Alex >> >> On Sun, Feb 10, 2019 at 5:13 AM wrote: >>> >>> From: Mathias Fröhlich >>> >>> Reference counting in amdgpu_dm_connector for amdgpu_dm_connector::dc_sink >>> and amdgpu_dm_connector::dc_em_sink as well as in dc_link::local_sink seems >>> to be out of shape. Thus make reference counting consistent for these >>> members and just plain increment the reference count when the variable >>> gets assigned and decrement when the pointer is set to zero or replaced. >>> Also simplify reference counting in selected function sopes to be sure the >>> reference is released in any case. In some cases add NULL pointer check >>> before dereferencing. >>> At a hand full of places a comment is placed to stat that the reference >>> increment happened already somewhere else. >>> >>> This actually fixes the following kernel bug on my system when enabling >>> display core in amdgpu. There are some more similar bug reports around, >>> so it probably helps at more places. >>> >>> kernel BUG at mm/slub.c:294! >>> invalid opcode: [#1] SMP PTI >>> CPU: 9 PID: 1180 Comm: Xorg Not tainted 5.0.0-rc1+ #2 >>> Hardware name: Supermicro X10DAi/X10DAI, BIOS 3.0a 02/05/2018 >>> RIP: 0010:__slab_free+0x1e2/0x3d0 >>> Code: 8b 54 24 30 48 89 4c 24 28 e8 da fb ff ff 4c 8b 54 24 28 85 c0 0f >>> 85 67 fe ff ff 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b 49 3b >>> 5c 24 28 75 ab 48 8b 44 24 30 49 89 4c 24 28 49 89 44 >>> RSP: 0018:b0978589fa90 EFLAGS: 00010246 >>> RAX: 92f12806c400 RBX: 80200019 RCX: 92f12806c400 >>> RDX: 92f12806c400 RSI: dd6421a01a00 RDI: 92ed2f406e80 >>> RBP: b0978589fb40 R08: 0001 R09: c0ee4748 >>> R10: 92f12806c400 R11: 0001 R12: dd6421a01a00 >>> R13: 92f12806c400 R14: 92ed2f406e80 R15: dd6421a01a20 >>> FS: 7f4170be0ac0() GS:92ed2fb4() >>> knlGS: >>> CS: 0010 DS: ES: CR0: 80050033 >>> CR2: 562818aaa000 CR3: 00045745a002 CR4: 003606e0 >>> DR0: DR1: DR2: >>> DR3: DR6: fffe0ff0 DR7: 0400 >>> Call Trace: >>> ? drm_dbg+0x87/0x90 [drm] >>> dc_stream_release+0x28/0x50 [amdgpu] >>> amdgpu_dm_connector_mode_valid+0xb4/0x1f0 [amdgpu] >>> drm_helper_probe_single_connector_modes+0x492/0x6b0 [drm_kms_helper] >>> drm_mode_getconnector+0x457/0x490 [drm] >>> ? drm_connector_property_set_ioctl+0x60/0x60 [drm] >>> drm_ioctl_kernel+0xa9/0xf0 [drm] >>> drm_ioctl+0x201/0x3a0 [drm] >>> ? drm_connector_property_set_ioctl+0x60/0x60 [drm] >>> amdgpu_drm_ioctl+0x49/0x80 [amdgpu] >>> do_vfs_ioctl+0xa4/0x630 >>> ? __sys_recvmsg+0x83/0xa0 >>> ksys_ioctl+0x60/0x90 >>> __x64_sys_ioctl+0x16/0x20 >>> do_syscall_64+0x5b/0x160 >>> entry_SYSCALL_64_after_hwframe+0x44/0xa9 >>> RIP: 0033:0x7f417110809b >>> Code: 0f 1e fa 48 8b 05 ed bd 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff >>> ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 >>> ff ff 73 01 c3 48 8b 0d bd bd 0c 00 f7 d8 64 89 01 48 >>> RSP: 002b:7ffdd8d1c268 EFLAGS: 0246 ORIG_RAX: 0010 >>> RAX: ffda RBX: 562818a8ebc0 RCX: 7f417110809b >>> RDX: 7ffdd8d1c2a0 RSI: c05064a7 RDI: 0012 >>> RBP: 7ffdd8d1c2a0 R08: 562819012280 R09: 0007 >>> R10: R11: 0246 R12: c05064a7 >>> R13: 0012 R14: 0012 R15: 7ffdd8d1c2a0 >>> Modules linked in: nfsv4 dns_resolver nfs lockd grace fscache fuse vfat >>> fat amdgpu intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp >>> coretemp kvm_intel kvm irqbypass crct10dif_pclmul chash gpu_sched >>> crc32_pclmul snd_hda_codec_realtek ghash_clmulni_intel amd_iommu_v2 >>> iTCO_wdt iTCO_vendor_support ttm snd_hda_codec_generic snd_hda_codec_hdmi >>> ledtrig_audio snd_hda_intel drm_kms_helper snd_hda_codec intel_cstate >>> snd_hda_core drm snd_hwdep snd_seq snd_seq_device intel_uncore snd_pcm >>> intel_rapl_perf snd_timer snd soundcore ioatdma pcspkr >>> intel_wmi_thunderbolt mxm_wmi i2c_i801 lpc_ich pcc_cpufreq auth_rpcgss >>> sunrpc igb crc32c_intel i2c_algo_bit dca wmi hid_cherry analog gameport >>> joydev >>> >>> This patch is based on agd5f/drm-next-5.1-wip. This patch does not require >>> all of that, but agd5f/drm-next-5.1-wip contains at least one more dc_sink >>> counting fix that I could spot. >>>
Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems
On 2019-02-21 12:34 p.m., Thomas Hellstrom wrote: > On Thu, 2019-02-21 at 16:57 +, Kuehling, Felix wrote: >> On 2019-02-21 2:59 a.m., Koenig, Christian wrote: >>> On x86 with HIGHMEM there is no dma32 zone. Why do we need one on > x86_64? Can we make x86_64 more like HIGHMEM instead? > > Regards, > Felix > IIRC with x86, the kernel zone is always smaller than any dma32 zone, so we'd always exhaust the kernel zone before dma32 anyway. Not sure why we have dma32 on x86 without highmem, though. sounds superflous but harmless. >>> Well DMA32 denotes memory which is accessible by devices who can >>> only do >>> 32bit addressing. And IIRC we can actually do DMA32 to highmem >>> since >>> something like 2.4.*. >>> >>> Because of this it is actually irrelevant if you have highmem or >>> not, >>> what matters for DMA32 is if you have an IOMMU or not. >> Are you saying we should have a dma32_zone even on x86 with HIGHMEM? >> >> >>> So even on x86_64 you actually do need the DMA32 zone if you don't >>> have >>> an IOMMU which remaps all memory for devices which can't directly >>> address it. >> Why is DMA32 special in this way? For example AMD GFX8 GPUs support >> 40-bit DMA. But we don't have a special zone for that. > If you're running on a non-IOMMU system with physical memory addresses >> 40 bits, and tell the DMA subsystem that you need to restrict to 40 > bits, it will probably start using bounce buffers for streaming DMA > (which won't work with most graphics drivers), or for > dma_alloc_coherent(), it will probably use memory from the DMA32 zone. OK, then why is it not needed when CONFIG_HIGHMEM is defined? I found that there is a CONFIG_ZONE_DMA32 parameter. Maybe we should use that to decide whether to account for the DMA32 zone in TTM. It is set on x86_64 and a number of other 64-bit architectures. >> How common is it to have devices that need DMA32 on an x86_64 system? > IIRC All devices using dma_alloc_coherent() allocate DMA32 memory > unless they explicitly set the dma coherent mask to something larger. > Like Christian says, if an IOMMU is present and enabled, the need for > the DMA32 zone goes away. In theory at least. Thanks. I read up a bit on DMA32 and memory zones in general. I found that there is a lowmem_reserve_ratio feature that protects against normal page allocations overflowing into lowmem zones. There is some documentation in Documentation/scsctl/vm.txt (search for lowmem_reserve_ratio). The protected amount of memory in each zone can be seen in /proc/zoneinfo. With that, can we conclude that we don't need to count ttm_mem_global_alloc against the dma32 zone. Thanks, Felix > > /Thomas > > >> Regards, >> Felix >> >> >>> Regards, >>> Christian. >>> /Thomas ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH v2 3/3] drm/dsc: Split DSC PPS and SDP header initialisations
The DP 1.4 spec defines the SDP header and SDP contents for
a Picture Parameter Set (PPS) that must be sent in advance
of DSC transmission to define the encoding characteristics.
This was done in one struct, drm_dsc_pps_infoframe, which
conatined the SDP header and PPS. Because the PPS is
a property of DSC over any connector, not just DP, and because
drm drivers may have their own SDP structs they wish to use,
make the functions that initialise SDP and PPS headers take
the components they operate on, not drm_dsc_pps_infoframe,
Signed-off-by: David Francis
---
drivers/gpu/drm/drm_dsc.c | 117 +++---
drivers/gpu/drm/i915/intel_vdsc.c | 4 +-
include/drm/drm_dsc.h | 4 +-
3 files changed, 62 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
index d77570bf6ac4..77f4e5ae4197 100644
--- a/drivers/gpu/drm/drm_dsc.c
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -32,66 +32,65 @@
/**
* drm_dsc_dp_pps_header_init() - Initializes the PPS Header
* for DisplayPort as per the DP 1.4 spec.
- * @pps_sdp: Secondary data packet for DSC Picture Parameter Set
- * as defined in drm_dsc_pps_infoframe
+ * @pps_header: Secondary data packet header for DSC Picture
+ * Parameter Set as defined in dp_sdp_header
*
* DP 1.4 spec defines the secondary data packet for sending the
* picture parameter infoframes from the source to the sink.
- * This function populates the pps header defined in
- * drm_dsc_pps_infoframe as per the header bytes defined
- * in dp_sdp_header.
+ * This function populates the SDP header defined in
+ * dp_sdp_header.
*/
-void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
+void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header)
{
- memset(_sdp->pps_header, 0, sizeof(pps_sdp->pps_header));
+ memset(pps_header, 0, sizeof(*pps_header));
- pps_sdp->pps_header.HB1 = DP_SDP_PPS;
- pps_sdp->pps_header.HB2 = DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1;
+ pps_header->HB1 = DP_SDP_PPS;
+ pps_header->HB2 = DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1;
}
EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
/**
- * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
+ * drm_dsc_pps_payload_pack() - Populates the DSC PPS
*
- * @pps_sdp:
- * Secondary data packet for DSC Picture Parameter Set. This is defined
- * by drm_dsc_pps_infoframe
+ * @pps_payload:
+ * Bitwise struct for DSC Picture Parameter Set. This is defined
+ * by drm_dsc_picture_parameter_set
* @dsc_cfg:
* DSC Configuration data filled by driver as defined by
* drm_dsc_config
*
- * DSC source device sends a secondary data packet filled with all the
- * picture parameter set (PPS) information required by the sink to decode
- * the compressed frame. Driver populates the dsC PPS infoframe using the DSC
- * configuration parameters in the order expected by the DSC Display Sink
- * device. For the DSC, the sink device expects the PPS payload in the big
- * endian format for the fields that span more than 1 byte.
+ * DSC source device sends a picture parameter set (PPS) containing the
+ * information required by the sink to decode the compressed frame. Driver
+ * populates the DSC PPS struct using the DSC configuration parameters in
+ * the order expected by the DSC Display Sink device. For the DSC, the sink
+ * device expects the PPS payload in big endian format for fields
+ * that span more than 1 byte.
*/
-void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe *pps_sdp,
+void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set
*pps_payload,
const struct drm_dsc_config *dsc_cfg)
{
int i;
/* Protect against someone accidently changing struct size */
- BUILD_BUG_ON(sizeof(pps_sdp->pps_payload) !=
+ BUILD_BUG_ON(sizeof(*pps_payload) !=
DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1 + 1);
- memset(_sdp->pps_payload, 0, sizeof(pps_sdp->pps_payload));
+ memset(pps_payload, 0, sizeof(*pps_payload));
/* PPS 0 */
- pps_sdp->pps_payload.dsc_version =
+ pps_payload->dsc_version =
dsc_cfg->dsc_version_minor |
dsc_cfg->dsc_version_major << DSC_PPS_VERSION_MAJOR_SHIFT;
/* PPS 1, 2 is 0 */
/* PPS 3 */
- pps_sdp->pps_payload.pps_3 =
+ pps_payload->pps_3 =
dsc_cfg->line_buf_depth |
dsc_cfg->bits_per_component << DSC_PPS_BPC_SHIFT;
/* PPS 4 */
- pps_sdp->pps_payload.pps_4 =
+ pps_payload->pps_4 =
((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
DSC_PPS_MSB_SHIFT) |
dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
@@ -100,7 +99,7 @@ void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe
*pps_sdp,
dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
[PATCH v2 0/3] Make DRM DSC helpers more generally usable
drm_dsc could use some work so that drm drivers other than i915 can make use of it their own DSC implementations Move rc compute, a function that forms part of the DSC spec, into drm. Update it to DSC 1.2. Also split the PPS packing and SDP header init functions, to allow for drivers with their own SDP struct headers Re-sending due to Mail Delivery System errors v2: Rebase onto drm-next Refactor drm_dsc_dp_pps_header_init Clean up documentation on new drm function David Francis (3): drm/i915: Move dsc rate params compute into drm drm/dsc: Add native 420 and 422 support to compute_rc_params drm/dsc: Split DSC PPS and SDP header initialisations drivers/gpu/drm/drm_dsc.c | 269 +++--- drivers/gpu/drm/i915/intel_vdsc.c | 133 +-- include/drm/drm_dsc.h | 9 +- 3 files changed, 219 insertions(+), 192 deletions(-) -- 2.17.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH v2 1/3] drm/i915: Move dsc rate params compute into drm
The function intel_compute_rc_parameters is part of the dsc spec
and is not driver-specific. Other drm drivers might like to use
it. The function is not changed; just moved and renamed.
Reviewed-by: Harry Wentland
Signed-off-by: David Francis
---
drivers/gpu/drm/drm_dsc.c | 135 ++
drivers/gpu/drm/i915/intel_vdsc.c | 125 +--
include/drm/drm_dsc.h | 1 +
3 files changed, 137 insertions(+), 124 deletions(-)
diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
index bce99f95c1a3..b7f1903508a4 100644
--- a/drivers/gpu/drm/drm_dsc.c
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -244,3 +245,137 @@ void drm_dsc_pps_infoframe_pack(struct
drm_dsc_pps_infoframe *pps_sdp,
/* PPS 94 - 127 are O */
}
EXPORT_SYMBOL(drm_dsc_pps_infoframe_pack);
+
+/**
+ * drm_dsc_compute_rc_parameters() - Write rate control
+ * parameters to the dsc configuration defined in
+ * drm_dsc_config in accordance with the DSC 1.1
+ * specification. Some configuration fields must be present
+ * beforehand.
+ *
+ * @vdsc_cfg:
+ * DSC Configuration data partially filled by driver
+ */
+int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg)
+{
+ unsigned long groups_per_line = 0;
+ unsigned long groups_total = 0;
+ unsigned long num_extra_mux_bits = 0;
+ unsigned long slice_bits = 0;
+ unsigned long hrd_delay = 0;
+ unsigned long final_scale = 0;
+ unsigned long rbs_min = 0;
+
+ /* Number of groups used to code each line of a slice */
+ groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
+ DSC_RC_PIXELS_PER_GROUP);
+
+ /* chunksize in Bytes */
+ vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
+ vdsc_cfg->bits_per_pixel,
+ (8 * 16));
+
+ if (vdsc_cfg->convert_rgb)
+ num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
+ (4 * vdsc_cfg->bits_per_component + 4)
+ - 2);
+ else
+ num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
+ (4 * vdsc_cfg->bits_per_component + 4) +
+ 2 * (4 * vdsc_cfg->bits_per_component) - 2;
+ /* Number of bits in one Slice */
+ slice_bits = 8 * vdsc_cfg->slice_chunk_size * vdsc_cfg->slice_height;
+
+ while ((num_extra_mux_bits > 0) &&
+ ((slice_bits - num_extra_mux_bits) % vdsc_cfg->mux_word_size))
+ num_extra_mux_bits--;
+
+ if (groups_per_line < vdsc_cfg->initial_scale_value - 8)
+ vdsc_cfg->initial_scale_value = groups_per_line + 8;
+
+ /* scale_decrement_interval calculation according to DSC spec 1.11 */
+ if (vdsc_cfg->initial_scale_value > 8)
+ vdsc_cfg->scale_decrement_interval = groups_per_line /
+ (vdsc_cfg->initial_scale_value - 8);
+ else
+ vdsc_cfg->scale_decrement_interval =
DSC_SCALE_DECREMENT_INTERVAL_MAX;
+
+ vdsc_cfg->final_offset = vdsc_cfg->rc_model_size -
+ (vdsc_cfg->initial_xmit_delay *
+vdsc_cfg->bits_per_pixel + 8) / 16 + num_extra_mux_bits;
+
+ if (vdsc_cfg->final_offset >= vdsc_cfg->rc_model_size) {
+ DRM_DEBUG_KMS("FinalOfs < RcModelSze for this
InitialXmitDelay\n");
+ return -ERANGE;
+ }
+
+ final_scale = (vdsc_cfg->rc_model_size * 8) /
+ (vdsc_cfg->rc_model_size - vdsc_cfg->final_offset);
+ if (vdsc_cfg->slice_height > 1)
+ /*
+* NflBpgOffset is 16 bit value with 11 fractional bits
+* hence we multiply by 2^11 for preserving the
+* fractional part
+*/
+ vdsc_cfg->nfl_bpg_offset =
DIV_ROUND_UP((vdsc_cfg->first_line_bpg_offset << 11),
+ (vdsc_cfg->slice_height
- 1));
+ else
+ vdsc_cfg->nfl_bpg_offset = 0;
+
+ /* 2^16 - 1 */
+ if (vdsc_cfg->nfl_bpg_offset > 65535) {
+ DRM_DEBUG_KMS("NflBpgOffset is too large for this slice
height\n");
+ return -ERANGE;
+ }
+
+ /* Number of groups used to code the entire slice */
+ groups_total = groups_per_line * vdsc_cfg->slice_height;
+
+ /* slice_bpg_offset is 16 bit value with 11 fractional bits */
+ vdsc_cfg->slice_bpg_offset = DIV_ROUND_UP(((vdsc_cfg->rc_model_size -
+ vdsc_cfg->initial_offset +
+ num_extra_mux_bits) << 11),
+ groups_total);
+
+ if (final_scale > 9) {
+
[PATCH v2 2/3] drm/dsc: Add native 420 and 422 support to compute_rc_params
Native 420 and 422 transfer modes are new in DSC1.2
In these modes, each two pixels of a slice are treated as one
pixel, so the slice width is half as large (round down) for
the purposes of calucating the groups per line and chunk size
in bytes
In native 422 mode, each pixel has four components, so the
mux component of a group is larger by one additional mux word
and one additional component
Now that there is native 422 support, the configuration option
previously called enable422 is renamed to simple_422 to avoid
confusion
Acked-by: Jani Nikula
Reviewed-by: Manasi Navare
Reviewed-by: Harry Wentland
Signed-off-by: David Francis
---
drivers/gpu/drm/drm_dsc.c | 33 ++-
drivers/gpu/drm/i915/intel_vdsc.c | 4 ++--
include/drm/drm_dsc.h | 4 ++--
3 files changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
index b7f1903508a4..d77570bf6ac4 100644
--- a/drivers/gpu/drm/drm_dsc.c
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -95,7 +95,7 @@ void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe
*pps_sdp,
((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
DSC_PPS_MSB_SHIFT) |
dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
- dsc_cfg->enable422 << DSC_PPS_SIMPLE422_SHIFT |
+ dsc_cfg->simple_422 << DSC_PPS_SIMPLE422_SHIFT |
dsc_cfg->convert_rgb << DSC_PPS_CONVERT_RGB_SHIFT |
dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
@@ -249,7 +249,7 @@ EXPORT_SYMBOL(drm_dsc_pps_infoframe_pack);
/**
* drm_dsc_compute_rc_parameters() - Write rate control
* parameters to the dsc configuration defined in
- * drm_dsc_config in accordance with the DSC 1.1
+ * drm_dsc_config in accordance with the DSC 1.2
* specification. Some configuration fields must be present
* beforehand.
*
@@ -266,19 +266,34 @@ int drm_dsc_compute_rc_parameters(struct drm_dsc_config
*vdsc_cfg)
unsigned long final_scale = 0;
unsigned long rbs_min = 0;
- /* Number of groups used to code each line of a slice */
- groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
- DSC_RC_PIXELS_PER_GROUP);
+ if (vdsc_cfg->native_420 || vdsc_cfg->native_422) {
+ /* Number of groups used to code each line of a slice */
+ groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width / 2,
+ DSC_RC_PIXELS_PER_GROUP);
- /* chunksize in Bytes */
- vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
- vdsc_cfg->bits_per_pixel,
- (8 * 16));
+ /* chunksize in Bytes */
+ vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width
/ 2 *
+
vdsc_cfg->bits_per_pixel,
+ (8 * 16));
+ } else {
+ /* Number of groups used to code each line of a slice */
+ groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
+ DSC_RC_PIXELS_PER_GROUP);
+
+ /* chunksize in Bytes */
+ vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width
*
+
vdsc_cfg->bits_per_pixel,
+ (8 * 16));
+ }
if (vdsc_cfg->convert_rgb)
num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
(4 * vdsc_cfg->bits_per_component + 4)
- 2);
+ else if (vdsc_cfg->native_422)
+ num_extra_mux_bits = 4 * vdsc_cfg->mux_word_size +
+ (4 * vdsc_cfg->bits_per_component + 4) +
+ 3 * (4 * vdsc_cfg->bits_per_component) - 2;
else
num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
(4 * vdsc_cfg->bits_per_component + 4) +
diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
b/drivers/gpu/drm/i915/intel_vdsc.c
index 2d059ebc9bd0..8c8d96157333 100644
--- a/drivers/gpu/drm/i915/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/intel_vdsc.c
@@ -368,7 +368,7 @@ int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
DSC_1_1_MAX_LINEBUF_DEPTH_BITS : line_buf_depth;
/* Gen 11 does not support YCbCr */
- vdsc_cfg->enable422 = false;
+ vdsc_cfg->simple_422 = false;
/* Gen 11 does not support VBR */
vdsc_cfg->vbr_enable = false;
vdsc_cfg->block_pred_enable =
@@ -495,7 +495,7 @@ static void intel_configure_pps_for_dsc_encoder(struct
intel_encoder *encoder,
pps_val |= DSC_BLOCK_PREDICTION;
if
Re: [PATCH] drm/amdgpu: fix HMM config dependency issue
On 2019-02-21 12:48 p.m., Yang, Philip wrote:
> Only select HMM_MIRROR will get kernel config dependency warnings
> if CONFIG_HMM is missing in the config. Add depends on HMM will
> solve the issue.
>
> Add conditional compilation to fix compilation errors if HMM_MIRROR
> is not enabled as HMM config is not enabled.
>
> Change-Id: I1b44a0b5285bbef5e98bfb045d1d82c167af1cb8
> Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
See one semi-related comment inline ...
> ---
> drivers/gpu/drm/amd/amdgpu/Kconfig | 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 12
> 3 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig
> b/drivers/gpu/drm/amd/amdgpu/Kconfig
> index 960a63355705..67553effb649 100644
> --- a/drivers/gpu/drm/amd/amdgpu/Kconfig
> +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
> @@ -26,6 +26,7 @@ config DRM_AMDGPU_CIK
> config DRM_AMDGPU_USERPTR
> bool "Always enable userptr write support"
> depends on DRM_AMDGPU
> + depends on ARCH_HAS_HMM
> select HMM_MIRROR
> help
> This option selects CONFIG_HMM and CONFIG_HMM_MIRROR if it
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 1e675048f790..c1dbca14dce5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -712,7 +712,9 @@ struct amdgpu_ttm_tt {
> uint64_tuserptr;
> struct task_struct *usertask;
> uint32_tuserflags;
> +#if IS_ENABLED(CONFIG_DRM_AMDGPU_USERPTR)
> struct hmm_rangerange;
> +#endif
> };
>
> /**
> @@ -722,6 +724,7 @@ struct amdgpu_ttm_tt {
>* Calling function must call amdgpu_ttm_tt_userptr_range_done() once and
> only
>* once afterwards to stop HMM tracking
>*/
> +#if IS_ENABLED(CONFIG_DRM_AMDGPU_USERPTR)
> int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct page **pages)
> {
> struct amdgpu_ttm_tt *gtt = (void *)ttm;
> @@ -804,6 +807,7 @@ bool amdgpu_ttm_tt_get_user_pages_done(struct ttm_tt *ttm)
>
> return r;
> }
> +#endif
>
> /**
>* amdgpu_ttm_tt_set_user_pages - Copy pages in, putting old pages as
> necessary.
> @@ -904,9 +908,11 @@ static void amdgpu_ttm_tt_unpin_userptr(struct ttm_tt
> *ttm)
>
> sg_free_table(ttm->sg);
>
> +#if IS_ENABLED(CONFIG_DRM_AMDGPU_USERPTR)
> if (gtt->range.pfns &&
> ttm->pages[0] == hmm_pfn_to_page(>range, gtt->range.pfns[0]))
> WARN_ONCE(1, "Missing get_user_page_done\n");
> +#endif
> }
>
> int amdgpu_ttm_gart_bind(struct amdgpu_device *adev,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> index 8988c87fff9d..c9d87271a4cb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> @@ -101,8 +101,20 @@ int amdgpu_mmap(struct file *filp, struct vm_area_struct
> *vma);
> int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo);
> int amdgpu_ttm_recover_gart(struct ttm_buffer_object *tbo);
>
> +#if IS_ENABLED(CONFIG_DRM_AMDGPU_USERPTR)
> int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct page **pages);
> bool amdgpu_ttm_tt_get_user_pages_done(struct ttm_tt *ttm);
> +#else
> +static inline int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct
> page **pages)
> +{
> + return -EPERM;
> +}
> +static inline bool amdgpu_ttm_tt_get_user_pages_done(struct ttm_tt *ttm)
> +{
> + return false;
> +}
> +#endif
> +
> void amdgpu_ttm_tt_set_user_pages(struct ttm_tt *ttm, struct page **pages);
> void amdgpu_ttm_tt_mark_user_pages(struct ttm_tt *ttm);
mark_user_pages isn't used any more. This function could be removed.
Regards,
Felix
> int amdgpu_ttm_tt_set_userptr(struct ttm_tt *ttm, uint64_t addr,
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: fix HMM config dependency issue
Only select HMM_MIRROR will get kernel config dependency warnings
if CONFIG_HMM is missing in the config. Add depends on HMM will
solve the issue.
Add conditional compilation to fix compilation errors if HMM_MIRROR
is not enabled as HMM config is not enabled.
Change-Id: I1b44a0b5285bbef5e98bfb045d1d82c167af1cb8
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdgpu/Kconfig | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 12
3 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig
b/drivers/gpu/drm/amd/amdgpu/Kconfig
index 960a63355705..67553effb649 100644
--- a/drivers/gpu/drm/amd/amdgpu/Kconfig
+++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
@@ -26,6 +26,7 @@ config DRM_AMDGPU_CIK
config DRM_AMDGPU_USERPTR
bool "Always enable userptr write support"
depends on DRM_AMDGPU
+ depends on ARCH_HAS_HMM
select HMM_MIRROR
help
This option selects CONFIG_HMM and CONFIG_HMM_MIRROR if it
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 1e675048f790..c1dbca14dce5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -712,7 +712,9 @@ struct amdgpu_ttm_tt {
uint64_tuserptr;
struct task_struct *usertask;
uint32_tuserflags;
+#if IS_ENABLED(CONFIG_DRM_AMDGPU_USERPTR)
struct hmm_rangerange;
+#endif
};
/**
@@ -722,6 +724,7 @@ struct amdgpu_ttm_tt {
* Calling function must call amdgpu_ttm_tt_userptr_range_done() once and only
* once afterwards to stop HMM tracking
*/
+#if IS_ENABLED(CONFIG_DRM_AMDGPU_USERPTR)
int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct page **pages)
{
struct amdgpu_ttm_tt *gtt = (void *)ttm;
@@ -804,6 +807,7 @@ bool amdgpu_ttm_tt_get_user_pages_done(struct ttm_tt *ttm)
return r;
}
+#endif
/**
* amdgpu_ttm_tt_set_user_pages - Copy pages in, putting old pages as
necessary.
@@ -904,9 +908,11 @@ static void amdgpu_ttm_tt_unpin_userptr(struct ttm_tt *ttm)
sg_free_table(ttm->sg);
+#if IS_ENABLED(CONFIG_DRM_AMDGPU_USERPTR)
if (gtt->range.pfns &&
ttm->pages[0] == hmm_pfn_to_page(>range, gtt->range.pfns[0]))
WARN_ONCE(1, "Missing get_user_page_done\n");
+#endif
}
int amdgpu_ttm_gart_bind(struct amdgpu_device *adev,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index 8988c87fff9d..c9d87271a4cb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
@@ -101,8 +101,20 @@ int amdgpu_mmap(struct file *filp, struct vm_area_struct
*vma);
int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo);
int amdgpu_ttm_recover_gart(struct ttm_buffer_object *tbo);
+#if IS_ENABLED(CONFIG_DRM_AMDGPU_USERPTR)
int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct page **pages);
bool amdgpu_ttm_tt_get_user_pages_done(struct ttm_tt *ttm);
+#else
+static inline int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct page
**pages)
+{
+ return -EPERM;
+}
+static inline bool amdgpu_ttm_tt_get_user_pages_done(struct ttm_tt *ttm)
+{
+ return false;
+}
+#endif
+
void amdgpu_ttm_tt_set_user_pages(struct ttm_tt *ttm, struct page **pages);
void amdgpu_ttm_tt_mark_user_pages(struct ttm_tt *ttm);
int amdgpu_ttm_tt_set_userptr(struct ttm_tt *ttm, uint64_t addr,
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: select ARCH_HAS_HMM and ZONE_DEVICE option
Thanks Jerome for the the correct HMM config option, only select HMM_MIRROR is not good enough because CONFIG_HMM option maybe missing, add depends on ARCH_HAS_HMM will solve the issue. I will submit new patch to fix the compilation error if HMM_MIRROR config is missing and the HMM config dependency issue. Philip On 2019-02-20 7:25 p.m., Jerome Glisse wrote: > On Thu, Feb 21, 2019 at 12:17:33AM +, Kuehling, Felix wrote: >> On 2019-02-20 6:34 p.m., Jerome Glisse wrote: >>> On Wed, Feb 20, 2019 at 10:39:49PM +, Kuehling, Felix wrote: On 2019-02-20 5:12 p.m., Jerome Glisse wrote: > On Wed, Feb 20, 2019 at 07:18:17PM +, Kuehling, Felix wrote: >> [+Jerome] >> >> Why to we need ZONE_DEVICE. I didn't think this was needed for mirroring >> CPU page tables to device page tables. >> >> ARCH_HAS_HMM depends on (X86_64 || PPC64). Do we have some alternative >> for ARM support? >> >> Also, the name ARCH_HAS_HMM looks like it's meant to be selected by the >> CPU architecture rather than any driver. Jerome, do you have any advice? > This patch is wrong you need to depend on ARCH_HAS_HMM and Who selects ARCH_HAS_HMM? Currently I don't see this selected anywhere. So any config option that depends on it will be invisible in menuconfig. Do we need ARCH_HAS_HMM somewhere in the arch/x86/Kconfig and arch/powerpc/Kconfig? Also, ARCH_HAS_HMM does not currently support ARM. Does that mean we can't have ARM support in AMDGPU if we start using HMM? >>> ARCH_HAS_HMM is defined by architecture that support HMM. So par x86 >>> and PPC. It should not be hard to add it to ARM (i can not remember if >>> ARM has DAX yet or not, if ARM does not have DAX then you need to add >>> that first). >> >> Not having ARM support is a bummer. I just enabled KFD on ARM a few >> weeks ago. Now depending on HMM makes KFD unusable on ARM. [+Mark FYI] I >> hope this is only a temporary setback. > > It should not be hard to add in fact all it might need is a Kconfig > patch. I have no easy access to ARM with PCIE so i have not tackle > this yet. > >> >> Finally, ARCH_HAS_HMM has a bunch of dependencies. If they are not met, I guess it can't be enabled. Should those be "select"s instead? >>> No they should not be selected, people configuring their system need >>> to have the freedom of doing so. All those option are selected in all >>> the big distribution. >> As far as I can tell, the arch/x86/Kconfig doesn't select ARCH_HAS_HMM. >> Its default is "y", so it should be enabled on anything that meets the >> dependencies. But ZONE_DEVICE was not enabled by default. I think that's >> what broke our kernel configs. >> >> We'll fix our own kernel configs to enable ZONE_DEVICE and ARCH_HAS_HMM >> to get our internal builds to work again. > > You seem to be doing weird thing with your kconfig ... > >> >> I suspect other users with their own kernel configs will stumble over >> this and wonder why KFD and userptr support are disabled in their builds. > > Patch to improve kconfig are welcome but they should not force select > thing. Configuration is there to give user freedom to select fewature > they want to give up. > > Maybe following would help: > ARCH_HAS_HMM > - bool > - default y > + def_bool y > > Cheers, > Jérôme > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems
On Thu, 2019-02-21 at 16:57 +, Kuehling, Felix wrote: > On 2019-02-21 2:59 a.m., Koenig, Christian wrote: > > On x86 with HIGHMEM there is no dma32 zone. Why do we need one on > > > > x86_64? Can we make x86_64 more like HIGHMEM instead? > > > > > > > > Regards, > > > > Felix > > > > > > > IIRC with x86, the kernel zone is always smaller than any dma32 > > > zone, > > > so we'd always exhaust the kernel zone before dma32 anyway. > > > > > > Not sure why we have dma32 on x86 without highmem, though. sounds > > > superflous but harmless. > > Well DMA32 denotes memory which is accessible by devices who can > > only do > > 32bit addressing. And IIRC we can actually do DMA32 to highmem > > since > > something like 2.4.*. > > > > Because of this it is actually irrelevant if you have highmem or > > not, > > what matters for DMA32 is if you have an IOMMU or not. > > Are you saying we should have a dma32_zone even on x86 with HIGHMEM? > > > > So even on x86_64 you actually do need the DMA32 zone if you don't > > have > > an IOMMU which remaps all memory for devices which can't directly > > address it. > > Why is DMA32 special in this way? For example AMD GFX8 GPUs support > 40-bit DMA. But we don't have a special zone for that. If you're running on a non-IOMMU system with physical memory addresses > 40 bits, and tell the DMA subsystem that you need to restrict to 40 bits, it will probably start using bounce buffers for streaming DMA (which won't work with most graphics drivers), or for dma_alloc_coherent(), it will probably use memory from the DMA32 zone. > > How common is it to have devices that need DMA32 on an x86_64 system? IIRC All devices using dma_alloc_coherent() allocate DMA32 memory unless they explicitly set the dma coherent mask to something larger. Like Christian says, if an IOMMU is present and enabled, the need for the DMA32 zone goes away. In theory at least. /Thomas > > Regards, >Felix > > > > Regards, > > Christian. > > > > > /Thomas > > > > > > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems
On 2019-02-21 2:59 a.m., Koenig, Christian wrote: > On x86 with HIGHMEM there is no dma32 zone. Why do we need one on >>> x86_64? Can we make x86_64 more like HIGHMEM instead? >>> >>> Regards, >>> Felix >>> >> IIRC with x86, the kernel zone is always smaller than any dma32 zone, >> so we'd always exhaust the kernel zone before dma32 anyway. >> >> Not sure why we have dma32 on x86 without highmem, though. sounds >> superflous but harmless. > Well DMA32 denotes memory which is accessible by devices who can only do > 32bit addressing. And IIRC we can actually do DMA32 to highmem since > something like 2.4.*. > > Because of this it is actually irrelevant if you have highmem or not, > what matters for DMA32 is if you have an IOMMU or not. Are you saying we should have a dma32_zone even on x86 with HIGHMEM? > > So even on x86_64 you actually do need the DMA32 zone if you don't have > an IOMMU which remaps all memory for devices which can't directly > address it. Why is DMA32 special in this way? For example AMD GFX8 GPUs support 40-bit DMA. But we don't have a special zone for that. How common is it to have devices that need DMA32 on an x86_64 system? Regards, Felix > > Regards, > Christian. > >> /Thomas >> >> ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH libdrm] libdrm: Fix issue about differrent domainID but same BDF
On Thu, Feb 14, 2019 at 2:53 AM Emily Deng wrote:
>
> For multiple GPUs which has the same BDF, but has different domain ID,
> the drmOpenByBusid will return the wrong fd when startx.
>
> The reproduce sequence as below:
> 1. Call drmOpenByBusid to open Card0, then will return the right fd0, and the
> fd0 is master privilege;
> 2. Call drmOpenByBusid to open Card1. In function drmOpenByBusid, it will
> open Card0 first, this time, the fd1 for opening Card0 is not master
> privilege, and will call drmSetInterfaceVersion to identify the
> domain ID feature, as the fd1 is not master privilege, then
> drmSetInterfaceVersion
> will fail, and then won't compare domain ID, then return the wrong fd for
> Card1.
>
> Solution:
> First loop search the best match fd about drm 1.4.
>
> Signed-off-by: Emily Deng
Reviewed-by: Alex Deucher
Do you need someone to commit this for you?
Alex
> ---
> xf86drm.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 336d64d..b60e029 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -584,11 +584,34 @@ static int drmOpenByBusid(const char *busid, int type)
> if (base < 0)
> return -1;
>
> +/* We need to try for 1.4 first for proper PCI domain support */
> drmMsg("drmOpenByBusid: Searching for BusID %s\n", busid);
> for (i = base; i < base + DRM_MAX_MINOR; i++) {
> fd = drmOpenMinor(i, 1, type);
> drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
> if (fd >= 0) {
> +sv.drm_di_major = 1;
> +sv.drm_di_minor = 4;
> +sv.drm_dd_major = -1;/* Don't care */
> +sv.drm_dd_minor = -1;/* Don't care */
> +if (!drmSetInterfaceVersion(fd, )) {
> +buf = drmGetBusid(fd);
> +drmMsg("drmOpenByBusid: drmGetBusid reports %s\n", buf);
> +if (buf && drmMatchBusID(buf, busid, 1)) {
> +drmFreeBusid(buf);
> +return fd;
> +}
> +if (buf)
> +drmFreeBusid(buf);
> +}
> +close(fd);
> +}
> +}
> +
> + for (i = base; i < base + DRM_MAX_MINOR; i++) {
> +fd = drmOpenMinor(i, 1, type);
> +drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
> +if (fd >= 0) {
> /* We need to try for 1.4 first for proper PCI domain support
> * and if that fails, we know the kernel is busted
> */
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v2 0/2] drm/drv: Rework drm_dev_unplug() (was: Remove drm_dev_unplug())
Den 08.02.2019 15.01, skrev Noralf Trønnes: > This series makes drm_dev_unplug() compatible with the upcoming > devm_drm_dev_init(), fixes a double drm_dev_unregister() situation and > simplifies the drm_device ref handling wrt to the last fd closed after > unregister. > > The first version of this patchset removed drm_dev_unplug(), see here > for the discussion as to why it is kept for the time being: > > [2/6] drm/drv: Prepare to remove drm_dev_unplug() > https://patchwork.freedesktop.org/patch/282902/ > > Noralf. > > Noralf Trønnes (2): > drm: Fix drm_release() and device unplug > drm/drv: drm_dev_unplug(): Move out drm_dev_put() call > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + > drivers/gpu/drm/drm_drv.c | 5 - > drivers/gpu/drm/drm_file.c | 6 ++ > drivers/gpu/drm/udl/udl_drv.c | 1 + > drivers/gpu/drm/xen/xen_drm_front.c | 1 + > 5 files changed, 5 insertions(+), 9 deletions(-) > Applied to drm-misc-next, thanks for reviewing. Noralf. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] drm: add func to better detect wether swiotlb is needed
> -Original Message-
> From: Michael D Labriola [mailto:michael.d.labri...@gmail.com]
> Sent: 19 February 2019 23:08
> To: dri-de...@lists.freedesktop.org; Alex Deucher
> ; Christian Koenig ;
> Chunming Zhou ; amd-gfx@lists.freedesktop.org; Monk
> Liu
> Cc: Juergen Gross ; Christoph Hellwig
> ; Andrew Cooper ; Paul
> Durrant ; xen-de...@lists.xen.org; Jan Beulich
> ; Konrad Rzeszutek Wilk ;
> Michael D Labriola
> Subject: [PATCH] drm: add func to better detect wether swiotlb is needed
>
> This commit fixes DRM failures on Xen PV systems that were introduced in
> v4.17 by the following commits:
>
> 82626363 drm: add func to get max iomem address v2
> fd5fd480 drm/amdgpu: only enable swiotlb alloc when need v2
> 1bc3d3cc drm/radeon: only enable swiotlb path when need v2
>
> The introduction of ->need_swiotlb to the ttm_dma_populate() conditionals
> in the radeon and amdgpu device drivers causes Gnome to immediately crash
> on Xen PV systems, returning the user to the login screen. The following
> kernel errors get logged:
>
> [ 28.554259] radeon_dp_aux_transfer_native: 200 callbacks suppressed
> [ 31.219821] radeon :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [ 31.220030] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
> allocate GEM object (16384000, 2, 4096, -14)
> [ 31.226109] radeon :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [ 31.226300] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
> allocate GEM object (16384000, 2, 4096, -14)
> [ 31.300734] gnome-shell[1935]: segfault at 88 ip 7f39151cd904 sp
> 7ffc97611ad8 error 4 in libmutter-cogl.so[7f3915178000+aa000]
> [ 31.300745] Code: 5f c3 0f 1f 40 00 48 8b 47 78 48 8b 40 40 ff e0 66 0f
> 1f 44 00 00 48 8b 47 78 48 8b 40 48 ff e0 66 0f 1f 44 00 00 48 8b 47 78
> <48> 8b 80 88 00 00 00 ff e0 0f 1f 00 48 8b 47 78 48 8b 40 68 ff e0
> [ 38.193302] radeon_dp_aux_transfer_native: 116 callbacks suppressed
> [ 40.009317] radeon :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [ 40.009488] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
> allocate GEM object (16384000, 2, 4096, -14)
> [ 40.015114] radeon :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [ 40.015297] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
> allocate GEM object (16384000, 2, 4096, -14)
> [ 40.028302] gnome-shell[2431]: segfault at 2dadf40 ip 02dadf40
> sp 7ffcd24ea5f8 error 15
> [ 40.028306] Code: 20 6e 31 00 00 00 00 00 00 00 00 37 e3 3d 2d 7f 00 00
> 80 f4 e6 3d 2d 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> <00> 00 00 00 00 00 00 00 c1 00 00 00 00 00 00 00 80 e1 d2 03 00 00
>
> This commit renames drm_get_max_iomem() to drm_need_swiotlb(), adds a
> xen_pv_domain() check to it, and moves the bit shifting comparison that
> always follows its usage into the function (simplifying the drm driver
> code).
>
> Signed-off-by: Michael D Labriola
> ---
> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 2 +-
> drivers/gpu/drm/drm_memory.c | 19 ---
> drivers/gpu/drm/radeon/radeon_device.c | 2 +-
> include/drm/drm_cache.h| 2 +-
> 6 files changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> index 910c4ce..6bc0266 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> @@ -1029,7 +1029,7 @@ static int gmc_v7_0_sw_init(void *handle)
> pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
> pr_warn("amdgpu: No coherent DMA available\n");
> }
> - adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
> + adev->need_swiotlb = drm_need_swiotlb(dma_bits);
>
> r = gmc_v7_0_init_microcode(adev);
> if (r) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> index 747c068..8638adf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> @@ -1155,7 +1155,7 @@ static int gmc_v8_0_sw_init(void *handle)
> pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
> pr_warn("amdgpu: No coherent DMA available\n");
> }
> - adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
> + adev->need_swiotlb = drm_need_swiotlb(dma_bits);
>
> r = gmc_v8_0_init_microcode(adev);
> if (r) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> index f35d7a5..4f67093 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> @@ -989,7 +989,7 @@ static int gmc_v9_0_sw_init(void *handle)
> pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
>
Re: s2idle not working
HI Alex, I will check with your patch. if it doesn't work i will raise bug . Regards, Sk shahul. On Thu, Feb 21, 2019 at 12:01 PM Alex Deucher wrote: > On Wed, Feb 20, 2019 at 11:56 PM shahul hameed > wrote: > > > > Hi All, > > > > I did below exoeriments: > > > > -> S2idle is working in software rendering mode(disable AMDGPU driver). > > > > -> For experiment purpose i commented suspend/resume calls of amdgpu > driver, in this case S2idle worked. > > > > With above experiments it is clear that my platform supports s2idel. > > Some issue in AMDGPU suspend/resume sequence for s2idle. > > So can you please help me. > > I'd suggest filing a bug (https://bugs.freedesktop.org) and attaching > your full dmesg output. I'm not too familiar with s2idle and what > pmops paths it uses. I suspect what is happening is that the power is > not getting fully cut the the device when s2idle is invoked, and it's > left in a bad state on resume. Maybe something like the attached > patch might help. That said, if the platform is not properly cutting > power to the device at s2idle time, you probably aren't saving any > power anyway. > > Alex > > > > > Thanks & Regards, > > Sk shahul. > > > > On Thu, Feb 21, 2019 at 3:32 AM Alex Deucher > wrote: > >> > >> On Wed, Feb 20, 2019 at 4:59 PM shahul hameed > >> wrote: > >> > > >> > Hi > >> > > >> > I am facing below issue. Can any one please help me to resolve it. > >> > >> As I mentioned previously, please make sure the platform supports > >> s2idle and that it is enabled in the sbios. Does s2idle work on other > >> devices and the platform itself? > >> > >> Alex > >> > >> > > >> > Regards, > >> > Sk shahul > >> > > >> > -- Forwarded message - > >> > From: shahul hameed > >> > Date: Wed, Feb 20, 2019, 3:13 PM > >> > Subject: s2idle not working > >> > To: > >> > > >> > > >> > Hi Shirish > >> > > >> > I am porting Android_N and keenel 4.19.2 to Ryzen platform. Graphic > card is gfx9. > >> > Porting is done successfully. Now i am working on suspend/resume. > >> > Suspend/resume is working fine in deep mode. > >> > But suspend/resume is not working in s2idle (Suspend to idle) mode. > >> > > >> > during resume i found error in gpu driver. > >> > > >> > [ 105.862161] [drm:gfx_v9_0_hw_init [amdgpu]] *ERROR* KCQ enable > failed (scratch(0xC040)=0xCAFEDEAD) > >> > [ 105.862187] [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* > resume of IP block failed -22 > >> > [ 105.862210] [drm:amdgpu_device_resume [amdgpu]] *ERROR* > amdgpu_device_ip_resume failed (-22). > >> > [ 105.862215] dpm_run_callback(): pci_pm_resume+0x0/0xd6 returns -22 > >> > [ 105.862345] PM: Device :03:00.0 failed to resume async: error > -22 > >> > > >> > same issue is reproduced with ubuntu16.04. > >> > > >> > Can you please help me to resolve this issue. > >> > Thanks in Advance, > >> > Regards, > >> > Sk shahul. > >> > ___ > >> > amd-gfx mailing list > >> > amd-gfx@lists.freedesktop.org > >> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: disable bulk moves for now
Am 21.02.19 um 04:09 schrieb Sasha Levin: On Wed, Feb 20, 2019 at 03:16:06PM +0100, Christian König wrote: The changes to fix those are two invasive for backporting. Just disable the feature in 4.20 and 5.0. Signed-off-by: Christian König Cc: [4.20+] For the sake of having it in the log, could you point to the upstream commit(s) that fix it? That turned out to be a larger set of patches and won't go upstream before the 5.1 cycle. Christian. -- Thanks, Sasha ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
