summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2021-06-08drm/amdgpu: allocate psp fw private buffer from VRAM for sriov vfZhigang Luo
psp added new feature to check fw buffer address for sriov vf. the address range must be in vf fb. Signed-off-by: Zhigang Luo <zhigang.luo@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-By : Shaoyun.liu <shaoyunl@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-08drm/amdgpu: add psp ta microcode init for aldebaran sriov vfZhigang Luo
need to load xgmi ta for aldebaran sriov vf. Signed-off-by: Zhigang Luo <zhigang.luo@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-By : Shaoyun.liu <shaoyunl@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-08drm/amdgpu: remove sriov vf mmhub system aperture and fb location programmingZhigang Luo
host driver programmed mmhub system aperture and fb location for vf, no need to program in guest side. Signed-off-by: Zhigang Luo <zhigang.luo@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-By : Shaoyun.liu <shaoyunl@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-08drm/amdgpu: remove sriov vf gfxhub fb location programmingZhigang Luo
host driver programmed the gfxhub fb location for vf, no need to program in guest side. Signed-off-by: Zhigang Luo <zhigang.luo@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-By : Shaoyun.liu <shaoyunl@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-08drm/amdgpu: remove sriov vf checking from getting fb locationZhigang Luo
host driver programmed fb location registers for vf, no need to check anymore. Signed-off-by: Zhigang Luo <zhigang.luo@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-By : Shaoyun.liu <shaoyunl@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-08drm/amd/pm: fix warning reported by kernel test robotXiaomeng Hou
Kernel test robot throws warning -> >> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/yellow_carp_ppt.c:483:2: warning: variable 'member_type' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized] default: ^~~~~~~ drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/yellow_carp_ppt.c:487:47: note: uninitialized use occurs here return yellow_carp_get_smu_metrics_data(smu, member_type, value); ^~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/yellow_carp_ppt.c:465:2: note: variable 'member_type' is declared here MetricsMember_t member_type; ^ 1 warning generated. Fix this warning by return errno when the clk type is unsupported. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Xiaomeng Hou <Xiaomeng.Hou@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-08drm/amdgpu: fix shadow bo skip conditionNirmoy Das
Create shadow BOs only for no-compute VM context and only for dGPU. The existing if-condition would create shadow bo for compute context on dGPU which not what we wanted. Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-08amdgpu/pm: add kernel documentation for smu_get_power_limitDarren Powell
added doc tag "amdgpu_pp_power" with description added tags for enums pp_power_limit_level, pp_power_type added tag for function smu_get_power_limit Test: * Temporary insertion into Documentation/gpu/amdgpu.rst ------------START------------ Power Limit ----------- .. kernel-doc:: drivers/gpu/drm/amd/include/kgd_pp_interface.h :doc: amdgpu_pp_power .. kernel-doc:: drivers/gpu/drm/amd/include/kgd_pp_interface.h :identifiers: pp_power_limit_level .. kernel-doc:: drivers/gpu/drm/amd/include/kgd_pp_interface.h :identifiers: pp_power_type .. kernel-doc:: drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c :identifiers: smu_get_power_limit -------------END------------- Signed-off-by: Darren Powell <darren.powell@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-08amdgpu/pm: handle return value for get_power_limitDarren Powell
Signed-off-by: Darren Powell <darren.powell@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-08amdgpu/pm: modify and add smu_get_power_limit to Powerplay APIDarren Powell
modify args of smu_get_power_limit to match Powerplay API .get_power_limit add smu_get_power_limit to Powerplay API swsmu_pm_funcs remove special handling of smu in amdgpu_hwmon_show_power_cap* * Test AMDGPU_PCI_ADDR=`lspci -nn | grep "VGA\|Display" | cut -d " " -f 1` AMDGPU_HWMON=`ls -la /sys/class/hwmon | grep $AMDGPU_PCI_ADDR | cut -d " " -f 11` HWMON_DIR=/sys/class/hwmon/${AMDGPU_HWMON} lspci -nn | grep "VGA\|Display" ; \ echo "=== power1 cap ===" ; cat $HWMON_DIR/power1_cap ; \ echo "=== power1 cap max ===" ; cat $HWMON_DIR/power1_cap_max ; \ echo "=== power1 cap def ===" ; cat $HWMON_DIR/power1_cap_default Signed-off-by: Darren Powell <darren.powell@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-08amdgpu/pm: modify Powerplay API get_power_limit to use new pp_power enumsDarren Powell
updated {amd_pm_funcs}->get_power_limit() signature rewrote pp_get_power_limit to use new enums pp_get_power_limit now returns -EOPNOTSUPP for unknown power limit update calls to {amd_pm_funcs}->get_power_limit() * Test Notes * testing hardware was NAVI10 (tests SMU path) ** needs testing on VANGOGH ** needs testing on SMU < 11 ** ie, one of TOPAZ, FIJI, TONGA, POLARIS10, POLARIS11, POLARIS12, VEGAM, CARRIZO, STONEY, VEGA10, VEGA12,VEGA20, RAVEN, BONAIRE, HAWAII * Test AMDGPU_PCI_ADDR=`lspci -nn | grep "VGA\|Display" | cut -d " " -f 1` AMDGPU_HWMON=`ls -la /sys/class/hwmon | grep $AMDGPU_PCI_ADDR | cut -d " " -f 11` HWMON_DIR=/sys/class/hwmon/${AMDGPU_HWMON} lspci -nn | grep "VGA\|Display" ; \ echo "=== power1 cap ===" ; cat $HWMON_DIR/power1_cap ; \ echo "=== power1 cap max ===" ; cat $HWMON_DIR/power1_cap_max ; \ echo "=== power1 cap def ===" ; cat $HWMON_DIR/power1_cap_default Signed-off-by: Darren Powell <darren.powell@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-08amdgpu/pm: clean up smu_get_power_limit function signatureDarren Powell
add two new powerplay enums (limit_level, type) add enums to smu_get_power_limit signature remove input bitfield stuffing of output variable limit update calls to smu_get_power_limit * Test AMDGPU_PCI_ADDR=`lspci -nn | grep "VGA\|Display" | cut -d " " -f 1` AMDGPU_HWMON=`ls -la /sys/class/hwmon | grep $AMDGPU_PCI_ADDR | cut -d " " -f 11` HWMON_DIR=/sys/class/hwmon/${AMDGPU_HWMON} lspci -nn | grep "VGA\|Display" ; \ echo "=== power1 cap ===" ; cat $HWMON_DIR/power1_cap ; \ echo "=== power1 cap max ===" ; cat $HWMON_DIR/power1_cap_max ; \ echo "=== power1 cap def ===" ; cat $HWMON_DIR/power1_cap_default Signed-off-by: Darren Powell <darren.powell@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-08amdgpu/pm: reorder definition of swsmu_pm_funcs for readabilityDarren Powell
Match the order of definition to the structure's declaration to help with locating included and missing functions of the API Signed-off-by: Darren Powell <darren.powell@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-08drm/vc4: fix vc4_atomic_commit_tail() logicMark Rutland
In vc4_atomic_commit_tail() we iterate of the set of old CRTCs, and attempt to wait on any channels which are still in use. When we iterate over the CRTCs, we have: * `i` - the index of the CRTC * `channel` - the channel a CRTC is using When we check the channel state, we consult: old_hvs_state->fifo_state[channel].in_use ... but when we wait for the channel, we erroneously wait on: old_hvs_state->fifo_state[i].pending_commit ... rather than: old_hvs_state->fifo_state[channel].pending_commit ... and this bogus access has been observed to result in boot-time hangs on some arm64 configurations, and can be detected using KASAN. FIx this by using the correct index. I've tested this on a Raspberry Pi 3 model B v1.2 with KASAN. Trimmed KASAN splat: | ================================================================== | BUG: KASAN: slab-out-of-bounds in vc4_atomic_commit_tail+0x1cc/0x910 | Read of size 8 at addr ffff000007360440 by task kworker/u8:0/7 | CPU: 2 PID: 7 Comm: kworker/u8:0 Not tainted 5.13.0-rc3-00009-g694c523e7267 #3 | | Hardware name: Raspberry Pi 3 Model B (DT) | Workqueue: events_unbound deferred_probe_work_func | Call trace: | dump_backtrace+0x0/0x2b4 | show_stack+0x1c/0x30 | dump_stack+0xfc/0x168 | print_address_description.constprop.0+0x2c/0x2c0 | kasan_report+0x1dc/0x240 | __asan_load8+0x98/0xd4 | vc4_atomic_commit_tail+0x1cc/0x910 | commit_tail+0x100/0x210 | ... | | Allocated by task 7: | kasan_save_stack+0x2c/0x60 | __kasan_kmalloc+0x90/0xb4 | vc4_hvs_channels_duplicate_state+0x60/0x1a0 | drm_atomic_get_private_obj_state+0x144/0x230 | vc4_atomic_check+0x40/0x73c | drm_atomic_check_only+0x998/0xe60 | drm_atomic_commit+0x34/0x94 | drm_client_modeset_commit_atomic+0x2f4/0x3a0 | drm_client_modeset_commit_locked+0x8c/0x230 | drm_client_modeset_commit+0x38/0x60 | drm_fb_helper_set_par+0x104/0x17c | fbcon_init+0x43c/0x970 | visual_init+0x14c/0x1e4 | ... | | The buggy address belongs to the object at ffff000007360400 | which belongs to the cache kmalloc-128 of size 128 | The buggy address is located 64 bytes inside of | 128-byte region [ffff000007360400, ffff000007360480) | The buggy address belongs to the page: | page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7360 | flags: 0x3fffc0000000200(slab|node=0|zone=0|lastcpupid=0xffff) | raw: 03fffc0000000200 dead000000000100 dead000000000122 ffff000004c02300 | raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 | page dumped because: kasan: bad access detected | | Memory state around the buggy address: | ffff000007360300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb | ffff000007360380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc | >ffff000007360400: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc | ^ | ffff000007360480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc | ffff000007360500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb | ================================================================== Link: https://lore.kernel.org/r/4d0c8318-bad8-2be7-e292-fc8f70c198de@samsung.com Link: https://lore.kernel.org/linux-arm-kernel/20210607151740.moncryl5zv3ahq4s@gilmour Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: Emma Anholt <emma@anholt.net> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Will Deacon <will@kernel.org> Cc: dri-devel@lists.freedesktop.org Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210608085513.2069-1-mark.rutland@arm.com
2021-06-08mmc: renesas_sdhi: Fix HS400 on R-Car M3-W+Geert Uytterhoeven
R-Car M3-W ES3.0 is marketed as R-Car M3-W+ (R8A77961), and has its own compatible value "renesas,r8a77961". Hence using soc_device_match() with soc_id = "r8a7796" and revision = "ES3.*" does not actually match running on an R-Car M3-W+ SoC. Fix this by matching with soc_id = "r8a77961" instead. Fixes: a38c078fea0b1393 ("mmc: renesas_sdhi: Avoid bad TAP in HS400") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/ee8af5d631f5331139ffea714539030d97352e93.1622811525.git.geert+renesas@glider.be Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-06-08mmc: renesas_sdhi: abort tuning when timeout detectedWolfram Sang
We have to bring the eMMC from sending-data state back to transfer state once we detected a CRC error (timeout) during tuning. So, send a stop command via mmc_abort_tuning(). Fixes: 4f11997773b6 ("mmc: tmio: Add tuning support") Reported-by Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20210602073435.5955-1-wsa+renesas@sang-engineering.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2021-06-08drm/ttm: fix deref of bo->ttm without holding the lock v2Christian König
We need to grab the resv lock first before doing that check. v2 (chk): simplify the change for -fixes Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210528130041.1683-1-christian.koenig@amd.com
2021-06-08drm/bridge: ti-sn65dsi83: Fix syntax formatting issuesMarek Vasut
Fix checkpatch.pl --strict -f drivers/gpu/drm/bridge/ti-sn65dsi83.c CHECKs, no functional change. This is the same modification done to V7 of the original patch. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Adam Ford <aford173@gmail.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Frieder Schrempf <frieder.schrempf@kontron.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Loic Poulain <loic.poulain@linaro.org> Cc: Marek Vasut <marex@denx.de> Cc: Philippe Schenker <philippe.schenker@toradex.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Stephen Boyd <swboyd@chromium.org> Cc: Valentin Raevsky <valentin@compulab.co.il> To: dri-devel@lists.freedesktop.org Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210608095322.23644-1-marex@denx.de
2021-06-08drm/ttm: nuke VM_MIXEDMAP on BO mappings v3Christian König
We discussed if that is really the right approach for quite a while now, but digging deeper into a bug report on arm turned out that this is actually horrible broken right now. The reason for this is that vmf_insert_mixed_prot() always tries to grab a reference to the underlaying page on architectures without ARCH_HAS_PTE_SPECIAL and as far as I can see also enabled GUP. So nuke using VM_MIXEDMAP here and use VM_PFNMAP instead. Also make sure to reject mappings without VM_SHARED. v2: reject COW mappings, merge function with only caller v3: adjust comment as suggested by Thomas Signed-off-by: Christian König <christian.koenig@amd.com> Bugs: https://gitlab.freedesktop.org/drm/amd/-/issues/1606#note_936174 Link: https://patchwork.freedesktop.org/patch/msgid/20210607135830.8574-1-christian.koenig@amd.com Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2021-06-08drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driverMarek Vasut
Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on, but easy to add. The driver operates the chip via I2C bus. Currently the LVDS clock are always derived from DSI clock lane, which is the usual mode of operation. Support for clock from external oscillator is not implemented, but it is easy to add if ever needed. Only RGB888 pixel format is implemented, the LVDS666 is not supported, but could be added if needed. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> Tested-by: Adam Ford <aford173@gmail.com> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Douglas Anderson <dianders@chromium.org> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Loic Poulain <loic.poulain@linaro.org> Cc: Philippe Schenker <philippe.schenker@toradex.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Stephen Boyd <swboyd@chromium.org> Cc: Valentin Raevsky <valentin@compulab.co.il> To: dri-devel@lists.freedesktop.org Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210607174258.16300-2-marex@denx.de
2021-06-08drm/ttm: fix pipelined gutting v2Christian König
We need to make sure to allocate the sys_mem resource before the point of no return. v2: add missing return value checking, also handle idle case Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210608081931.11339-1-christian.koenig@amd.com
2021-06-07scsi: core: Only put parent device if host state differs from SHOST_CREATEDMing Lei
get_device(shost->shost_gendev.parent) is called after host state has switched to SHOST_RUNNING. scsi_host_dev_release() shouldn't release the parent device if host state is still SHOST_CREATED. Link: https://lore.kernel.org/r/20210602133029.2864069-5-ming.lei@redhat.com Cc: Bart Van Assche <bvanassche@acm.org> Cc: John Garry <john.garry@huawei.com> Cc: Hannes Reinecke <hare@suse.de> Tested-by: John Garry <john.garry@huawei.com> Reviewed-by: John Garry <john.garry@huawei.com> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-07scsi: core: Put .shost_dev in failure path if host state changes to RUNNINGMing Lei
scsi_host_dev_release() only frees dev_name when host state is SHOST_CREATED. After host state has changed to SHOST_RUNNING, scsi_host_dev_release() no longer cleans up. Fix this by doing a put_device(&shost->shost_dev) in the failure path when host state is SHOST_RUNNING. Move get_device(&shost->shost_gendev) before device_add(&shost->shost_dev) so that scsi_host_cls_release() can do a put on this reference. Link: https://lore.kernel.org/r/20210602133029.2864069-4-ming.lei@redhat.com Cc: Bart Van Assche <bvanassche@acm.org> Cc: Hannes Reinecke <hare@suse.de> Reported-by: John Garry <john.garry@huawei.com> Tested-by: John Garry <john.garry@huawei.com> Reviewed-by: John Garry <john.garry@huawei.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-07scsi: core: Fix failure handling of scsi_add_host_with_dma()Ming Lei
When scsi_add_host_with_dma() returns failure, the caller will call scsi_host_put(shost) to release everything allocated for this host instance. Consequently we can't also free allocated stuff in scsi_add_host_with_dma(), otherwise we will end up with a double free. Strictly speaking, host resource allocations should have been done in scsi_host_alloc(). However, the allocations may need information which is not yet provided by the driver when that function is called. So leave the allocations where they are but rely on host device's release handler to free resources. Link: https://lore.kernel.org/r/20210602133029.2864069-3-ming.lei@redhat.com Cc: Bart Van Assche <bvanassche@acm.org> Cc: John Garry <john.garry@huawei.com> Cc: Hannes Reinecke <hare@suse.de> Tested-by: John Garry <john.garry@huawei.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: John Garry <john.garry@huawei.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-07scsi: core: Fix error handling of scsi_host_alloc()Ming Lei
After device is initialized via device_initialize(), or its name is set via dev_set_name(), the device has to be freed via put_device(). Otherwise device name will be leaked because it is allocated dynamically in dev_set_name(). Fix the leak by replacing kfree() with put_device(). Since scsi_host_dev_release() properly handles IDA and kthread removal, remove special-casing these from the error handling as well. Link: https://lore.kernel.org/r/20210602133029.2864069-2-ming.lei@redhat.com Cc: Bart Van Assche <bvanassche@acm.org> Cc: John Garry <john.garry@huawei.com> Cc: Hannes Reinecke <hare@suse.de> Tested-by: John Garry <john.garry@huawei.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: John Garry <john.garry@huawei.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-06-07mlxsw: core: Set thermal zone polling delay argument to real value at initMykola Kostenok
Thermal polling delay argument for modules and gearboxes thermal zones used to be initialized with zero value, while actual delay was used to be set by mlxsw_thermal_set_mode() by thermal operation callback set_mode(). After operations set_mode()/get_mode() have been removed by cited commits, modules and gearboxes thermal zones always have polling time set to zero and do not perform temperature monitoring. Set non-zero "polling_delay" in thermal_zone_device_register() routine, thus, the relevant thermal zones will perform thermal monitoring. Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Fixes: 5d7bd8aa7c35 ("thermal: Simplify or eliminate unnecessary set_mode() methods") Fixes: 1ee14820fd8e ("thermal: remove get_mode() operation of drivers") Signed-off-by: Mykola Kostenok <c_mykolak@nvidia.com> Acked-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-07mlxsw: spectrum_qdisc: Pass handle, not band number to find_class()Petr Machata
In mlxsw Qdisc offload, find_class() is an operation that yields a qdisc offload descriptor given a parental qdisc descriptor and a class handle. In __mlxsw_sp_qdisc_ets_graft() however, a band number is passed to that function instead of a handle. This can lead to a trigger of a WARN_ON with the following splat: WARNING: CPU: 3 PID: 808 at drivers/net/ethernet/mellanox/mlxsw/spectrum_qdisc.c:1356 __mlxsw_sp_qdisc_ets_graft+0x115/0x130 [mlxsw_spectrum] [...] Call Trace: mlxsw_sp_setup_tc_prio+0xe3/0x100 [mlxsw_spectrum] qdisc_offload_graft_helper+0x35/0xa0 prio_graft+0x176/0x290 [sch_prio] qdisc_graft+0xb3/0x540 tc_modify_qdisc+0x56a/0x8a0 rtnetlink_rcv_msg+0x12c/0x370 netlink_rcv_skb+0x49/0xf0 netlink_unicast+0x1f6/0x2b0 netlink_sendmsg+0x1fb/0x410 ____sys_sendmsg+0x1f3/0x220 ___sys_sendmsg+0x70/0xb0 __sys_sendmsg+0x54/0xa0 do_syscall_64+0x3a/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xae Since the parent handle is not passed with the offload information, compute it from the band number and qdisc handle. Fixes: 28052e618b04 ("mlxsw: spectrum_qdisc: Track children per qdisc") Reported-by: Maksym Yaremchuk <maksymy@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-07mlxsw: reg: Spectrum-3: Enforce lowest max-shaper burst size of 11Petr Machata
A max-shaper is the HW component responsible for delaying egress traffic above a configured transmission rate. Burst size is the amount of traffic that is allowed to pass without accounting. The burst size value needs to be such that it can be expressed as 2^BS * 512 bits, where BS lies in a certain ASIC-dependent range. mlxsw enforces that this holds before attempting to configure the shaper. The assumption for Spectrum-3 was that the lower limit of BS would be 5, like for Spectrum-1. But as of now, the limit is still 11. Therefore fix the driver accordingly, so that incorrect values are rejected early with a proper message. Fixes: 23effa2479ba ("mlxsw: reg: Add max_shaper_bs to QoS ETS Element Configuration") Reported-by: Maksym Yaremchuk <maksymy@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-07drm/amd/display: Fix two spelling mistakes, clean wide linesColin Ian King
There are two spelling mistakes in dml_print messages, fix these and clear up checkpatch warning on overly wide line length. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdgpu: Fix a a typo in a commentChristophe JAILLET
s/than/then/ Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amd/display: Fix duplicate included dce110_hw_sequencer.hJiapeng Chong
Clean up the following includecheck warning: ./drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c: dce110_hw_sequencer.h is included more than once. No functional change. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amd/display: remove no need variableBernard Zhao
remove no need variable, just return the DC_OK Signed-off-by: Bernard Zhao <bernard@vivo.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdgpu: Fix warning of Function parameter or member not describedEric Huang
Add the parameter table_freed description on function description. Signed-off-by: Eric Huang <jinhuieric.huang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdkfd: remove duplicate include of kfd_svm.hWan Jiabing
kfd_svm.h is included duplicately in commit 42de677f79999 ("drm/amdkfd: register svm range"). After checking possible related header files, remove the former one to make the code format more reasonable. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdgpu: fix VM handling for GART allocationsChristian König
For GTT allocations with a GART address the res contains the VMID0 addresses and can't be used for VM handling. So ignore the res when the pages array is given or we fill the page tables with nonsense. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Nirmoy Das <nirmoy.das@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdgpu: Fixing "Indirect register access for Navi12 sriov" for vega10Peng Ju Zhou
The NV12 and VEGA10 share the same interface W/RREG32_SOC15*, the callback functions in these macros may not be defined, so NULL pointer must be checked but not in macro __WREG32_SOC15_RLC__, fixing the lock of NULL pointer check. Signed-off-by: Peng Ju Zhou <PengJu.Zhou@amd.com> Reviewed-by: Emily Deng <Emily.Deng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdgpu: Update psp fw attestation support listJohn Clements
Disable support on APU Reviewed-by: Changfeng <Changfeng.Zhu@amd.com> Signed-off-by: John Clements <john.clements@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdkfd: add sdma poison consumption handlingHawking Zhang
Follow the same apporach as GFX to handle SDMA poison consumption. Send SIGBUS to application when receives SDMA_ECC interrupt and issue gpu reset either mode 2 or mode 1 to get the engine back Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Dennis Li<dennis.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdkfd: pages_addr offset must be 0 for system rangePhilip Yang
prange->offset is for VRAM range mm_nodes, if multiple ranges share same mm_nodes, migrate range back to VRAM will reuse the VRAM at offset of the same mm_nodes. For system memory pages_addr array, the offset is always 0, otherwise, update GPU mapping will use incorrect system memory page, and cause system memory corruption. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/amdgpu: Modify register access in sdma_v5_2 to use _SOC15 macrosRohit Khaire
In SRIOV environment, KMD should access SDMA registers through RLCG if GC indirect access flag enabled. Using _SOC15 read/write macros ensures that they go through RLC when the flag is enabled. Signed-off-by: Rohit Khaire <rohit.khaire@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-06-07drm/ttm: fix warning after moving resource to ghost objChristian König
After we moved the resource to the ghost the bo->resource pointer needs to be reset since the owner of the resource is now the ghost. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210607175737.1405-1-christian.koenig@amd.com
2021-06-07drm/i915/display: Drop FIXME about turn off infoframesJosé Roberto de Souza
intel_dp_set_infoframes() call in intel_ddi_post_disable_dp() will take care to disable all enabled infoframes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514232247.144542-4-jose.souza@intel.com
2021-06-07drm/i915/display: Allow fastsets when DP_SDP_VSC infoframe do not match with ↵José Roberto de Souza
PSR enabled When PSR is enabled it handles DP_SDP_VSC, changing revision and all the other fields as necessary. It can also enabled and disable this SDP as needed without a full modeset. So here masking DP_SDP_VSC bit when previous and future state PSR enabled, it will still be checked when comparing the asked state to what was programmed to hardware. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 78b772e1a01f ("drm/i915/display: Fill PSR state during hardware configuration read out") Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514232247.144542-2-jose.souza@intel.com
2021-06-07drm/i915/display: Fix fastsets involving PSRJosé Roberto de Souza
Commit 78b772e1a01f ("drm/i915/display: Fill PSR state during hardware configuration read out") is not allowing fastsets to happen when PSR states changes but PSR is a feature that can be enabled and disabled during fastsets. So here moving the PSR pipe conf checks to a block that is only executed when checking if HW state matches with requested state, not during the phase where it checks if fastset is possible or not. There still a state mismatch not allowing fastsets between states turning off or on PSR because of crtc_state->infoframes.enable BIT(DP_SDP_VSC) but at least for now it will allow a fastset between PSR1 <-> PSR2, that is a case heavilly used by CI due to pipe CRC not work with PSR2, but the remaning issue will be fixed in a future patch. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 78b772e1a01f ("drm/i915/display: Fill PSR state during hardware configuration read out") Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514232247.144542-1-jose.souza@intel.com
2021-06-07drm/ttm: fix access to uninitialized variable.Christian König
The resource is not allocated yet, so no chance that this will work. Use the placement instead. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210607171152.15914-1-christian.koenig@amd.com
2021-06-07drm/hyperv: Handle feature change message from deviceDeepak Rawat
Virtual device inform if screen update is needed or not with SYNTHVID_FEATURE_CHANGE message. Handle this message to set dirt_needed flag. Suggested-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210527112230.1274-2-drawat.floss@gmail.com
2021-06-07drm/hyperv: Add DRM driver for hyperv synthetic video deviceDeepak Rawat
DRM driver for hyperv synthetic video device, based on hyperv_fb framebuffer driver. Also added config option "DRM_HYPERV" to enabled this driver. v2: - Add support for gen2 VM - Fixed review comments v3: - Split into multiple files as suggested by Thomas Zimmermann - Fixed hibernation issue as suggested by Dexuan Cui - Use ioremap_cache as suggested by Dexuan Cui - Incorporated other review comments v4: - Fix bitrotted code - Review comments - Updated the copyright and license to match hyperv_fb v5: - Address review comments and rebased with drm-misc-next v6: - Minor code/comment improvement as suggested by Dexuan Cui Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210527112230.1274-1-drawat.floss@gmail.com
2021-06-07drm/ttm, drm/amdgpu: Allow the driver some control over swappingThomas Hellström
We are calling the eviction_valuable driver callback at eviction time to determine whether we actually can evict a buffer object. The upcoming i915 TTM backend needs the same functionality for swapout, and that might actually be beneficial to other drivers as well. Add an eviction_valuable call also in the swapout path. Try to keep the current behaviour for all drivers by returning true if the buffer object is already in the TTM_PL_SYSTEM placement. We change behaviour for the case where a buffer object is in a TT backed placement when swapped out, in which case the drivers normal eviction_valuable path is run. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20210602083818.241793-8-thomas.hellstrom@linux.intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20210602083818.241793-8-thomas.hellstrom@linux.intel.com
2021-06-07drm/ttm: Document and optimize ttm_bo_pipeline_gutting()Thomas Hellström
If the bo is idle when calling ttm_bo_pipeline_gutting(), we unnecessarily create a ghost object and push it out to delayed destroy. Fix this by adding a path for idle, and document the function. Also avoid having the bo end up in a bad state vulnerable to user-space triggered kernel BUGs if the call to ttm_tt_create() fails. Finally reuse ttm_bo_pipeline_gutting() in ttm_bo_evict(). Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20210602083818.241793-7-thomas.hellstrom@linux.intel.com
2021-06-07drm/ttm: Use drm_memcpy_from_wc for TTM bo movesThomas Hellström
Use fast wc memcpy for reading out of wc memory for TTM bo moves. Cc: Dave Airlie <airlied@gmail.com> Cc: Christian König <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> #v4 Link: https://lore.kernel.org/r/20210602083818.241793-6-thomas.hellstrom@linux.intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20210602083818.241793-6-thomas.hellstrom@linux.intel.com
generated by cgit (git 2.34.1) at 2025-10-02 15:01:01 +0000