Re: [kbuild-all] Re: [PATCH v3 8/8] drm: Upcast struct drm_device.dev to struct pci_device; replace pdev
Hi Am 08.01.21 um 02:25 schrieb Rong Chen: Hi Thomas, Thanks for the feedback, do you mean the patch was applied to a wrong base? I'm on drm-tip, which already has the patches that fix these issues. I think I should start using git's --base option when sending out patchsets. Best regards Thomas Best Regards, Rong Chen On 1/7/21 6:45 PM, Thomas Zimmermann wrote: AFAICT these are false positives. The instances have been fixed already. Am 07.01.21 um 10:45 schrieb kernel test robot: Hi Thomas, I love your patch! Yet something to improve: [auto build test ERROR on drm-tip/drm-tip] [cannot apply to drm-intel/for-linux-next linus/master v5.11-rc2 next-20210104] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip config: x86_64-randconfig-s021-20210107 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.3-208-g46a52ca4-dirty # https://github.com/0day-ci/linux/commit/380912f7b62c23322562c40e19efd7ad84d57e9c git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007 git checkout 380912f7b62c23322562c40e19efd7ad84d57e9c # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): drivers/gpu/drm/gma500/oaktrail_device.c: In function 'oaktrail_chip_setup': drivers/gpu/drm/gma500/oaktrail_device.c:509:26: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 509 | if (pci_enable_msi(dev->pdev)) | ^~~~ | dev -- drivers/gpu/drm/gma500/oaktrail_lvds.c: In function 'oaktrail_lvds_set_power': drivers/gpu/drm/gma500/oaktrail_lvds.c:63:25: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 63 | pm_request_idle(&dev->pdev->dev); | ^~~~ | dev -- drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'get_clock': drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:69:11: warning: variable 'tmp' set but not used [-Wunused-but-set-variable] 69 | u32 val, tmp; | ^~~ drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'get_data': drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:83:11: warning: variable 'tmp' set but not used [-Wunused-but-set-variable] 83 | u32 val, tmp; | ^~~ drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'oaktrail_lvds_i2c_init': drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:148:35: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 148 | chan->adapter.dev.parent = &dev->pdev->dev; | ^~~~ | dev -- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function 'vmw_driver_load': drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:661:22: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 661 | pci_set_master(dev->pdev); | ^~~~ | dev In file included from drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:31: drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:690:47: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 690 | dev_priv->io_start = pci_resource_start(dev->pdev, 0); | ^~~~ include/linux/pci.h:1854:40: note: in definition of macro 'pci_resource_start' 1854 | #define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start) | ^~~ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:691:49: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 691 | dev_priv->vram_start = pci_resource_start(dev->pdev, 1); | ^~~~ include/linux/pci.h:1854:40: note: in definition of macro 'pci_resource_start' 1854 | #define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start) | ^~~ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:692:49: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 692 | dev_priv->mmio_start = pci_resource_start(dev->pdev, 2); |
Re: [RFC] drm/connector: Set the default callback function for drm_connector_funcs
Hi
Am 08.01.21 um 08:54 schrieb Tian Tao:
The member functions of drm_connector_funcs are not specific to each
manufacturer's driver, so drm_connector_funcs is allowed to use default
values, which prevents all drivers from setting the same member
functions for drm_connector_funcs.
I don't think that's a good idea.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/drm_connector.c | 7 ++-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 1 -
include/drm/drm_connector.h | 2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 98b6ec4..356d8a3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -216,7 +217,7 @@ void drm_connector_free_work_fn(struct work_struct *work)
*/
int drm_connector_init(struct drm_device *dev,
struct drm_connector *connector,
- const struct drm_connector_funcs *funcs,
+ struct drm_connector_funcs *funcs,
Drivers cannot legally declare the funcs instance as static const.
Having static const allows for write protected pages.
int connector_type)
{
struct drm_mode_config *config = &dev->mode_config;
@@ -228,6 +229,10 @@ int drm_connector_init(struct drm_device *dev,
(!funcs->atomic_destroy_state ||
!funcs->atomic_duplicate_state));
+ if (!funcs->fill_modes)
+ funcs->fill_modes = &drm_helper_probe_single_connector_modes;
It's not clear that this is really the correct function for this driver.
Best regards
Thomas
+
+
ret = __drm_mode_object_add(dev, &connector->base,
DRM_MODE_OBJECT_CONNECTOR,
false, drm_connector_free);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
index c76f996..7d3b662 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
@@ -64,7 +64,6 @@ static const struct drm_connector_helper_funcs
};
static const struct drm_connector_funcs hibmc_connector_funcs = {
- .fill_modes = drm_helper_probe_single_connector_modes,
.destroy = hibmc_connector_destroy,
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1922b27..4810583 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1561,7 +1561,7 @@ struct drm_connector {
int drm_connector_init(struct drm_device *dev,
struct drm_connector *connector,
- const struct drm_connector_funcs *funcs,
+ struct drm_connector_funcs *funcs,
int connector_type);
int drm_connector_init_with_ddc(struct drm_device *dev,
struct drm_connector *connector,
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] drm/msm: drm-msm-fixes-2021-01-07
On Thu, Jan 07, 2021 at 01:54:59PM -0800, Rob Clark wrote: > Hi Dave, > > A few misc fixes > > The following changes since commit e319a1b956f785f618611857cd946dca2bb68542: > > drm/msm: add IOMMU_SUPPORT dependency (2020-12-05 08:25:52 -0800) > > are available in the Git repository at: > > https://gitlab.freedesktop.org/drm/msm.git drm-msm-fixes-2021-01-07 Applied, thanks. -Daniel > > for you to fetch changes up to 00fd44a1a4700718d5d962432b55c09820f7e709: > > drm/msm: Only enable A6xx LLCC code on A6xx (2021-01-07 09:23:05 -0800) > > > Craig Tatlor (1): > drm/msm: Call msm_init_vram before binding the gpu > > Iskren Chernev (3): > drm/msm: Fix null dereference in _msm_gem_new > drm/msm: Ensure get_pages is called when locked > drm/msm: Add modparam to allow vram carveout > > Konrad Dybcio (1): > drm/msm: Only enable A6xx LLCC code on A6xx > > Kuogee Hsieh (1): > drm/msm/dp: postpone irq_hpd event during connection pending state > > Rob Clark (1): > drm/msm: Fix WARN_ON() splat in _free_object() > > drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 6 -- > drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 6 -- > drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 6 -- > drivers/gpu/drm/msm/adreno/adreno_device.c | 4 > drivers/gpu/drm/msm/adreno/adreno_gpu.c| 21 - > drivers/gpu/drm/msm/adreno/adreno_gpu.h| 6 ++ > drivers/gpu/drm/msm/dp/dp_display.c| 7 +++ > drivers/gpu/drm/msm/dp/dp_panel.c | 12 +--- > drivers/gpu/drm/msm/msm_drv.c | 8 > drivers/gpu/drm/msm/msm_gem.c | 13 + > 10 files changed, 63 insertions(+), 26 deletions(-) > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Patch] fbcon: i want fbcon soft scrollback feature come back
This commit 50145474f6ef(fbcon: remove soft scrollback code) remove soft scrollback in fbcon. So the shift+PageDown and shift+PageUp is missing. But PageUp is a vary important feature when system panic or reset. I can get log by PageUp before, but now there is no way to get. Especially on the server system, we always use bmc to control computer. So I hope the community can add this feature back. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Patch] fbcon: i want fbcon soft scrollback feature come back
___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Jan 7 (drivers/gpu/drm/imx/parallel-display.o)
On 1/6/21 7:01 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20210106: > on x86_64: ld: drivers/gpu/drm/imx/parallel-display.o: in function `imx_pd_connector_get_modes': parallel-display.c:(.text+0x8d): undefined reference to `of_get_drm_display_mode' Full randconfig file is attached. -- ~Randy Reported-by: Randy Dunlap config-r7085.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/msm/dp: unplug interrupt missed after irq_hpd handler
There is HPD unplug interrupts missed at scenario of an irq_hpd
followed by unplug interrupts with around 10 ms in between.
Since both AUX_SW_RESET and DP_SW_RESET clear pending HPD interrupts,
irq_hpd handler should not issues either aux or sw reset to avoid
following unplug interrupt be cleared accidentally.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_aux.c | 7 ---
drivers/gpu/drm/msm/dp/dp_catalog.c | 24
drivers/gpu/drm/msm/dp/dp_ctrl.c| 15 ++-
3 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 19b35ae..1c6e1d2 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -336,7 +336,6 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
ssize_t ret;
int const aux_cmd_native_max = 16;
int const aux_cmd_i2c_max = 128;
- int const retry_count = 5;
struct dp_aux_private *aux = container_of(dp_aux,
struct dp_aux_private, dp_aux);
@@ -378,12 +377,6 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
ret = dp_aux_cmd_fifo_tx(aux, msg);
if (ret < 0) {
- if (aux->native) {
- aux->retry_cnt++;
- if (!(aux->retry_cnt % retry_count))
- dp_catalog_aux_update_cfg(aux->catalog);
- dp_catalog_aux_reset(aux->catalog);
- }
usleep_range(400, 500); /* at least 400us to next try */
goto unlock_exit;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 44f0c57..9c0ce98 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -190,6 +190,18 @@ int dp_catalog_aux_clear_hw_interrupts(struct dp_catalog
*dp_catalog)
return 0;
}
+/**
+ * dp_catalog_aux_reset() - reset AUX controller
+ *
+ * @aux: DP catalog structure
+ *
+ * return: void
+ *
+ * This function reset AUX controller
+ *
+ * NOTE: reset AUX controller will also clear any pending HPD related
interrupts
+ *
+ */
void dp_catalog_aux_reset(struct dp_catalog *dp_catalog)
{
u32 aux_ctrl;
@@ -483,6 +495,18 @@ int dp_catalog_ctrl_set_pattern(struct dp_catalog
*dp_catalog,
return 0;
}
+/**
+ * dp_catalog_ctrl_reset() - reset DP controller
+ *
+ * @aux: DP catalog structure
+ *
+ * return: void
+ *
+ * This function reset DP controller
+ *
+ * NOTE: reset DP controller will also clear any pending HPD related interrupts
+ *
+ */
void dp_catalog_ctrl_reset(struct dp_catalog *dp_catalog)
{
u32 sw_reset;
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index e3462f5..f96c415 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1296,7 +1296,8 @@ static int dp_ctrl_setup_main_link(struct dp_ctrl_private
*ctrl,
* transitioned to PUSH_IDLE. In order to start transmitting
* a link training pattern, we have to first do soft reset.
*/
- dp_catalog_ctrl_reset(ctrl->catalog);
+ if (*training_step != DP_TRAINING_NONE)
+ dp_catalog_ctrl_reset(ctrl->catalog);
ret = dp_ctrl_link_train(ctrl, cr, training_step);
@@ -1491,15 +1492,18 @@ static int dp_ctrl_deinitialize_mainlink(struct
dp_ctrl_private *ctrl)
return 0;
}
+static void dp_ctrl_link_idle_reset(struct dp_ctrl_private *ctrl)
+{
+ dp_ctrl_push_idle(&ctrl->dp_ctrl);
+ dp_catalog_ctrl_reset(ctrl->catalog);
+}
+
static int dp_ctrl_link_maintenance(struct dp_ctrl_private *ctrl)
{
int ret = 0;
struct dp_cr_status cr;
int training_step = DP_TRAINING_NONE;
- dp_ctrl_push_idle(&ctrl->dp_ctrl);
- dp_catalog_ctrl_reset(ctrl->catalog);
-
ctrl->dp_ctrl.pixel_rate = ctrl->panel->dp_mode.drm_mode.clock;
ret = dp_ctrl_setup_main_link(ctrl, &cr, &training_step);
@@ -1626,6 +1630,7 @@ void dp_ctrl_handle_sink_request(struct dp_ctrl *dp_ctrl)
if (sink_request & DP_TEST_LINK_TRAINING) {
dp_link_send_test_response(ctrl->link);
+ dp_ctrl_link_idle_reset(ctrl);
if (dp_ctrl_link_maintenance(ctrl)) {
DRM_ERROR("LM failed: TEST_LINK_TRAINING\n");
return;
@@ -1679,7 +1684,7 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
break;
}
- training_step = DP_TRAINING_NONE;
+ training_step = DP_TRAINING_1;
rc = dp_ctrl_setup_main_link(ctrl, &cr, &training_step);
if (rc == 0) {
/* training completed successfully */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-
Re: [PATCH v2] soc: mediatek: cmdq: add address shift in jump
On Wed, 2020-12-23 at 16:34 +0800, Yongqiang Niu wrote:
> Add address shift when compose jump instruction
> to compatible with 35bit format.
>
> Fixes: 0858fde496f8 ("mailbox: cmdq: variablize address shift in platform")
>
> Signed-off-by: Yongqiang Niu
> Reviewed-by: Nicolas Boichat
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> index 5665b6e..75378e3 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -168,7 +168,8 @@ static void cmdq_task_insert_into_thread(struct cmdq_task
> *task)
> dma_sync_single_for_cpu(dev, prev_task->pa_base,
> prev_task->pkt->cmd_buf_size, DMA_TO_DEVICE);
> prev_task_base[CMDQ_NUM_CMD(prev_task->pkt) - 1] =
> - (u64)CMDQ_JUMP_BY_PA << 32 | task->pa_base;
> + (u64)CMDQ_JUMP_BY_PA << 32 |
> + (task->pa_base >> task->cmdq->shift_pa);
> dma_sync_single_for_device(dev, prev_task->pa_base,
> prev_task->pkt->cmd_buf_size, DMA_TO_DEVICE);
>
hi jassi
please confirm is there any question about this patch.
if not, please apply this into next version, tks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] *** fix missing unplug interrupt problem ***
Both AUX_SW_RESET and DP_SW_RESET clear pending HPD interrupts. Therefore irq_hpd handler should not issues either aux or sw reset to avoid following unplug interrupt be cleared accidentally. Kuogee Hsieh (2): drm/msm/dp: postpone irq_hpd event during connection pending state drm/msm/dp: unplug interrupt missed after irq_hpd handler drivers/gpu/drm/msm/dp/dp_aux.c | 7 --- drivers/gpu/drm/msm/dp/dp_catalog.c | 24 drivers/gpu/drm/msm/dp/dp_ctrl.c| 15 ++- drivers/gpu/drm/msm/dp/dp_display.c | 7 +++ drivers/gpu/drm/msm/dp/dp_panel.c | 12 +--- 5 files changed, 50 insertions(+), 15 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/48] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
05.01.2021 20:11, Krzysztof Kozlowski пишет: > On Thu, Dec 17, 2020 at 09:05:50PM +0300, Dmitry Osipenko wrote: >> Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces >> power consumption and heating of the Tegra chips. Tegra SoC has multiple >> hardware units which belong to a core power domain of the SoC and share >> the core voltage. The voltage must be selected in accordance to a minimum >> requirement of every core hardware unit. >> >> The minimum core voltage requirement depends on: >> >> 1. Clock enable state of a hardware unit. >> 2. Clock frequency. >> 3. Unit's internal idling/active state. >> >> This series is tested on Acer A500 (T20), AC100 (T20), Nexus 7 (T30), >> Ouya (T30), TK1 (T124) and some others. I also added voltage scaling to >> the Ventana (T20) and Cardhu (T30) boards which are tested by NVIDIA's CI >> farm. Tegra30 is now couple degrees cooler on Nexus 7 and stays cool on >> Ouya (instead of becoming burning hot) while system is idling. It should >> be possible to improve this further by implementing a more advanced power >> management features for the kernel drivers. >> >> The DVFS support is opt-in for all boards, meaning that older DTBs will >> continue to work like they did it before this series. It should be possible >> to easily add the core voltage scaling support for Tegra114+ SoCs based on >> this grounding work later on, if anyone will want to implement it. > > The same comment as for your interconnect work: for sets touching > multiple systems please mention the dependencies between patches in the > cover letter. Not as a reply to such remark like I make here, but as a > separate entry in the cover letter. I'll describe all the dependencies in the next revision, thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/msm/dp: postpone irq_hpd event during connection pending state
irq_hpd event can only be executed at connected state. Therefore
irq_hpd event should be postponed if it happened at connection
pending state. This patch also make sure both link rate and lane
are valid before start link training.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 7 +++
drivers/gpu/drm/msm/dp/dp_panel.c | 12 +---
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 6e971d5..3bc7ed2 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -693,6 +693,13 @@ static int dp_irq_hpd_handle(struct dp_display_private
*dp, u32 data)
return 0;
}
+ if (state == ST_CONNECT_PENDING) {
+ /* wait until ST_CONNECTED */
+ dp_add_event(dp, EV_IRQ_HPD_INT, 0, 1); /* delay = 1 */
+ mutex_unlock(&dp->event_mutex);
+ return 0;
+ }
+
ret = dp_display_usbpd_attention_cb(&dp->pdev->dev);
if (ret == -ECONNRESET) { /* cable unplugged */
dp->core_initialized = false;
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 97dca3e..d1780bc 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -167,12 +167,18 @@ int dp_panel_read_sink_caps(struct dp_panel *dp_panel,
panel = container_of(dp_panel, struct dp_panel_private, dp_panel);
rc = dp_panel_read_dpcd(dp_panel);
+ if (rc) {
+ DRM_ERROR("read dpcd failed %d\n", rc);
+ return rc;
+ }
+
bw_code = drm_dp_link_rate_to_bw_code(dp_panel->link_info.rate);
- if (rc || !is_link_rate_valid(bw_code) ||
+ if (!is_link_rate_valid(bw_code) ||
!is_lane_count_valid(dp_panel->link_info.num_lanes) ||
(bw_code > dp_panel->max_bw_code)) {
- DRM_ERROR("read dpcd failed %d\n", rc);
- return rc;
+ DRM_ERROR("Illegal link rate=%d lane=%d\n",
dp_panel->link_info.rate,
+ dp_panel->link_info.num_lanes);
+ return -EINVAL;
}
if (dp_panel->dfp_present) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: bcm2835-vec: Add power-domains property
On 1/7/2021 6:42 PM, Rob Herring wrote: > On Wed, 23 Dec 2020 20:24:33 +0100, Stefan Wahren wrote: >> Adding the missing property power-domains to the bcm2835-vec schema to fix >> the following dtbs_check issue: >> >> vec@7e806000: 'power-domains' does not match any of the regexes: ... >> >> Signed-off-by: Stefan Wahren >> --- >> Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml | 3 +++ >> 1 file changed, 3 insertions(+) >> > > Acked-by: Rob Herring > I thought you were going to apply this directly? -- Florian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] drm/connector: Set the default callback function for drm_connector_funcs
The member functions of drm_connector_funcs are not specific to each
manufacturer's driver, so drm_connector_funcs is allowed to use default
values, which prevents all drivers from setting the same member
functions for drm_connector_funcs.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/drm_connector.c | 7 ++-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 1 -
include/drm/drm_connector.h | 2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 98b6ec4..356d8a3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -216,7 +217,7 @@ void drm_connector_free_work_fn(struct work_struct *work)
*/
int drm_connector_init(struct drm_device *dev,
struct drm_connector *connector,
- const struct drm_connector_funcs *funcs,
+ struct drm_connector_funcs *funcs,
int connector_type)
{
struct drm_mode_config *config = &dev->mode_config;
@@ -228,6 +229,10 @@ int drm_connector_init(struct drm_device *dev,
(!funcs->atomic_destroy_state ||
!funcs->atomic_duplicate_state));
+ if (!funcs->fill_modes)
+ funcs->fill_modes = &drm_helper_probe_single_connector_modes;
+
+
ret = __drm_mode_object_add(dev, &connector->base,
DRM_MODE_OBJECT_CONNECTOR,
false, drm_connector_free);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
index c76f996..7d3b662 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
@@ -64,7 +64,6 @@ static const struct drm_connector_helper_funcs
};
static const struct drm_connector_funcs hibmc_connector_funcs = {
- .fill_modes = drm_helper_probe_single_connector_modes,
.destroy = hibmc_connector_destroy,
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1922b27..4810583 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1561,7 +1561,7 @@ struct drm_connector {
int drm_connector_init(struct drm_device *dev,
struct drm_connector *connector,
- const struct drm_connector_funcs *funcs,
+ struct drm_connector_funcs *funcs,
int connector_type);
int drm_connector_init_with_ddc(struct drm_device *dev,
struct drm_connector *connector,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Patch] fbcon: i want fbcon soft scrollback feature come back
On 2021/01/08 0:48, xuhuijie wrote: > This commit 50145474f6ef(fbcon: remove soft scrollback code) remove soft > scrollback in > fbcon. So the shift+PageDown and shift+PageUp is missing. But PageUp is a > vary important > feature when system panic or reset. I can get log by PageUp before, but now > there is no > way to get. Especially on the server system, we always use bmc to control > computer. > So I hope the community can add this feature back. > You can configure kdump for panic, and netconsole for reset. (I don't know whether PageUp key works after panic...) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm/connector: Set the default callback function for drm_connector_funcs
On Fri, Jan 8, 2021 at 9:12 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 08.01.21 um 08:54 schrieb Tian Tao:
> > The member functions of drm_connector_funcs are not specific to each
> > manufacturer's driver, so drm_connector_funcs is allowed to use default
> > values, which prevents all drivers from setting the same member
> > functions for drm_connector_funcs.
>
> I don't think that's a good idea.
Yeah this breaks the helper/core separation. We have occasionally move
functionality across that border, but this is the one place where
we're ok with a pile of duplication, since it helps in making sure
that the helper library (like the probe function you want to make the
default here) really stays an optional helper library and doesn't
become some kind of midlayer spaghetti mess.
-Daniel
>
> >
> > Signed-off-by: Tian Tao
> > ---
> > drivers/gpu/drm/drm_connector.c | 7 ++-
> > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 1 -
> > include/drm/drm_connector.h | 2 +-
> > 3 files changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 98b6ec4..356d8a3 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -25,6 +25,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -216,7 +217,7 @@ void drm_connector_free_work_fn(struct work_struct
> > *work)
> >*/
> > int drm_connector_init(struct drm_device *dev,
> > struct drm_connector *connector,
> > -const struct drm_connector_funcs *funcs,
> > +struct drm_connector_funcs *funcs,
>
> Drivers cannot legally declare the funcs instance as static const.
> Having static const allows for write protected pages.
>
> > int connector_type)
> > {
> > struct drm_mode_config *config = &dev->mode_config;
> > @@ -228,6 +229,10 @@ int drm_connector_init(struct drm_device *dev,
> > (!funcs->atomic_destroy_state ||
> >!funcs->atomic_duplicate_state));
> >
> > + if (!funcs->fill_modes)
> > + funcs->fill_modes = &drm_helper_probe_single_connector_modes;
>
> It's not clear that this is really the correct function for this driver.
>
> Best regards
> Thomas
>
> > +
> > +
> > ret = __drm_mode_object_add(dev, &connector->base,
> > DRM_MODE_OBJECT_CONNECTOR,
> > false, drm_connector_free);
> > diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> > b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> > index c76f996..7d3b662 100644
> > --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> > +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> > @@ -64,7 +64,6 @@ static const struct drm_connector_helper_funcs
> > };
> >
> > static const struct drm_connector_funcs hibmc_connector_funcs = {
> > - .fill_modes = drm_helper_probe_single_connector_modes,
> > .destroy = hibmc_connector_destroy,
> > .reset = drm_atomic_helper_connector_reset,
> > .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 1922b27..4810583 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -1561,7 +1561,7 @@ struct drm_connector {
> >
> > int drm_connector_init(struct drm_device *dev,
> > struct drm_connector *connector,
> > -const struct drm_connector_funcs *funcs,
> > +struct drm_connector_funcs *funcs,
> > int connector_type);
> > int drm_connector_init_with_ddc(struct drm_device *dev,
> > struct drm_connector *connector,
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [kbuild-all] Re: [PATCH v3 8/8] drm: Upcast struct drm_device.dev to struct pci_device; replace pdev
On Fri, Jan 08, 2021 at 09:04:44AM +0100, Thomas Zimmermann wrote: > Hi > > Am 08.01.21 um 02:25 schrieb Rong Chen: > > Hi Thomas, > > > > Thanks for the feedback, do you mean the patch was applied to a wrong base? > > I'm on drm-tip, which already has the patches that fix these issues. I think > I should start using git's --base option when sending out patchsets. >From today all the patches should also be in linux-next. Our maintainer script didn't push the branches to the right tags because drm-misc-fixes wasn't rolled forward yet (there's some trickery to make sure we don't push patches to linux-next for the subsequent merge window before -rc1 is tagged). -Daniel > > Best regards > Thomas > > > > > Best Regards, > > Rong Chen > > > > On 1/7/21 6:45 PM, Thomas Zimmermann wrote: > > > AFAICT these are false positives. The instances have been fixed already. > > > > > > Am 07.01.21 um 10:45 schrieb kernel test robot: > > > > Hi Thomas, > > > > > > > > I love your patch! Yet something to improve: > > > > > > > > [auto build test ERROR on drm-tip/drm-tip] > > > > [cannot apply to drm-intel/for-linux-next linus/master v5.11-rc2 > > > > next-20210104] > > > > [If your patch is applied to the wrong git tree, kindly drop us a note. > > > > And when submitting patch, we suggest to use '--base' as documented in > > > > https://git-scm.com/docs/git-format-patch] > > > > > > > > url: > > > > https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007 > > > > > > > > base: git://anongit.freedesktop.org/drm/drm-tip drm-tip > > > > config: x86_64-randconfig-s021-20210107 (attached as .config) > > > > compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 > > > > reproduce: > > > > # apt-get install sparse > > > > # sparse version: v0.6.3-208-g46a52ca4-dirty > > > > # > > > > https://github.com/0day-ci/linux/commit/380912f7b62c23322562c40e19efd7ad84d57e9c > > > > > > > > git remote add linux-review https://github.com/0day-ci/linux > > > > git fetch --no-tags linux-review > > > > Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007 > > > > > > > > git checkout 380912f7b62c23322562c40e19efd7ad84d57e9c > > > > # save the attached .config to linux build tree > > > > make W=1 C=1 CF='-fdiagnostic-prefix > > > > -D__CHECK_ENDIAN__' ARCH=x86_64 > > > > > > > > If you fix the issue, kindly add following tag as appropriate > > > > Reported-by: kernel test robot > > > > > > > > All errors (new ones prefixed by >>): > > > > > > > > drivers/gpu/drm/gma500/oaktrail_device.c: In function > > > > 'oaktrail_chip_setup': > > > > > > drivers/gpu/drm/gma500/oaktrail_device.c:509:26: error: > > > > > > 'struct drm_device' has no member named 'pdev'; did you > > > > > > mean 'dev'? > > > > 509 | if (pci_enable_msi(dev->pdev)) > > > > | ^~~~ > > > > | dev > > > > -- > > > > drivers/gpu/drm/gma500/oaktrail_lvds.c: In function > > > > 'oaktrail_lvds_set_power': > > > > > > drivers/gpu/drm/gma500/oaktrail_lvds.c:63:25: error: > > > > > > 'struct drm_device' has no member named 'pdev'; did you > > > > > > mean 'dev'? > > > > 63 | pm_request_idle(&dev->pdev->dev); > > > > | ^~~~ > > > > | dev > > > > -- > > > > drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'get_clock': > > > > drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:69:11: warning: > > > > variable 'tmp' set but not used [-Wunused-but-set-variable] > > > > 69 | u32 val, tmp; > > > > | ^~~ > > > > drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'get_data': > > > > drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:83:11: warning: > > > > variable 'tmp' set but not used [-Wunused-but-set-variable] > > > > 83 | u32 val, tmp; > > > > | ^~~ > > > > drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function > > > > 'oaktrail_lvds_i2c_init': > > > > > > drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:148:35: > > > > > > error: 'struct drm_device' has no member named 'pdev'; > > > > > > did you mean 'dev'? > > > > 148 | chan->adapter.dev.parent = &dev->pdev->dev; > > > > | ^~~~ > > > > | dev > > > > -- > > > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function 'vmw_driver_load': > > > > > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:661:22: error: > > > > > > 'struct drm_device' has no member named 'pdev'; did you > > > > > > mean 'dev'? > > > > 661 | pci_set_master(dev->pdev); > > > > | ^~~~ > > > > | dev > > > > In file included from drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:31: > > > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:690:47: error: 'struct
Re: linux-next: Tree for Jan 7 (drivers/gpu/drm/imx/parallel-display.o)
On Fri, Jan 8, 2021 at 9:55 AM Randy Dunlap wrote: > > On 1/6/21 7:01 PM, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20210106: > > > > on x86_64: > > ld: drivers/gpu/drm/imx/parallel-display.o: in function > `imx_pd_connector_get_modes': > parallel-display.c:(.text+0x8d): undefined reference to > `of_get_drm_display_mode' Probably something in the pull from philipp that I just merged yesterday. Philip, can you pls take care? -Daniel > > > Full randconfig file is attached. > > -- > ~Randy > Reported-by: Randy Dunlap > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Dave and Daniel,
sorry for being a bit late. Here's this week's PR for drm-misc-fixes.
Best regards
Thomas
drm-misc-fixes-2021-01-08:
* dma-buf: fix a use-after-free
* radeon: don't init the TTM page pool manually
* ttm: unexport ttm_pool_{init,fini}()
The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62:
Linux 5.11-rc2 (2021-01-03 15:55:30 -0800)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-01-08
for you to fetch changes up to a73858ef4d5e1d425e171f0f6a52864176a6a979:
drm/ttm: unexport ttm_pool_init/fini (2021-01-07 14:25:43 +0100)
* dma-buf: fix a use-after-free
* radeon: don't init the TTM page pool manually
* ttm: unexport ttm_pool_{init,fini}()
Charan Teja Reddy (1):
dmabuf: fix use-after-free of dmabuf's file->f_inode
Christian König (2):
drm/radeon: stop re-init the TTM page pool
drm/ttm: unexport ttm_pool_init/fini
drivers/dma-buf/dma-buf.c | 21 +
drivers/gpu/drm/radeon/radeon_ttm.c | 3 ---
drivers/gpu/drm/ttm/ttm_pool.c | 2 --
3 files changed, 17 insertions(+), 9 deletions(-)
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 00/13] drm: Support short-term vmap via vmap_local
GEM VRAM helpers used to pin the BO in their implementation of vmap, so
that they could not be relocated. In recent discussions, [1][2] it became
clear that this is incorrect for in-kernel use cases, such as fbdev
emulation; which should rather depend on the reservation lock to prevent
relocation.
This patchset addresses the issue by introducing the new interfaces
vmap_local and vunmap_local throughout dma-buf and GEM. It further adds
support to DRM's CMA, SHMEM and VRAM helpers and finally converts fbdev
emulation to the new interface.
Patches 1 and 2 add the vmap_local infrastructure throughout dma-buf,
GEM and PRIME.
Patches 3 to 11 add implementations of vmap_local to DRM's various GEM
helper libraries. Due to the simple nature of these libraries, existing
vmap code can be reused easily. Several drivers are updated as well to
use the new interfaces.
Patch 12 converts generic fbdev emulation to use vmap_local. Only DRM
drivers that use GEM helpers currently use fbdev emulation, so patches
3 to 11 covered all necessary instances.
Finally patch 13 removes drm_gem_vram_vmap() functionality, which is now
unused.
I smoke-tested the patchset with ast (VRAM helpers), mgag200 (SHMEM) and
vc4 (CMA). I also tested with a version of radeon (raw TTM) that had been
converted to generic fbdev emulation.
v4:
* move driver changes out of SHMEM and VRAM patches (Daniel)
* call dma_buf_vmap_local() in SHMEM implementation (Daniel)
* remove unused drm_gem_vram_vmap() functionality
* update documentation (Daniel)
v3:
* rewrite patchset around vmap_local
v2:
* make importers acquire resv locks by themselves
* document dma-buf vmap/vunmap ops
[1] https://patchwork.freedesktop.org/patch/400054/?series=83765&rev=1
[2] https://patchwork.freedesktop.org/patch/405407/?series=84401&rev=2
Thomas Zimmermann (13):
dma-buf: Add vmap_local and vnumap_local operations
drm/gem: Create infrastructure for GEM vmap_local
drm/cma-helper: Provide a vmap function for short-term mappings
drm/shmem-helper: Provide a vmap function for short-term mappings
drm/mgag200: Use drm_gem_shmem_vmap_local() in damage handling
drm/cirrus: Use drm_gem_shmem_vmap_local() in damage handling
drm/gm12u320: Use drm_gem_shmem_vmap_local() in damage handling
drm/udl: Use drm_gem_shmem_vmap_local() in damage handling
drm/vram-helper: Provide a vmap function for short-term mappings
drm/ast: Use drm_gem_vram_vmap_local() in cursor update
drm/vboxvideo: Use drm_gem_vram_vmap_local() in cursor update
drm/fb-helper: Move BO locking from DRM client to fbdev damage worker
drm/vram-helper: Remove unused drm_gem_vram_{vmap,vunmap}()
drivers/dma-buf/dma-buf.c | 81 ++
drivers/gpu/drm/ast/ast_cursor.c | 37 +--
drivers/gpu/drm/drm_client.c | 94 +
drivers/gpu/drm/drm_fb_helper.c| 41
drivers/gpu/drm/drm_gem.c | 28 +
drivers/gpu/drm/drm_gem_cma_helper.c | 27 +
drivers/gpu/drm/drm_gem_shmem_helper.c | 90 ++--
drivers/gpu/drm/drm_gem_vram_helper.c | 139 -
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_prime.c| 39 +++
drivers/gpu/drm/mgag200/mgag200_mode.c | 16 ++-
drivers/gpu/drm/tiny/cirrus.c | 10 +-
drivers/gpu/drm/tiny/gm12u320.c| 14 ++-
drivers/gpu/drm/udl/udl_modeset.c | 18 ++--
drivers/gpu/drm/vboxvideo/vbox_mode.c | 15 +--
drivers/gpu/drm/vc4/vc4_bo.c | 1 +
drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +
include/drm/drm_client.h | 4 +
include/drm/drm_gem.h | 21
include/drm/drm_gem_cma_helper.h | 1 +
include/drm/drm_gem_shmem_helper.h | 2 +
include/drm/drm_gem_vram_helper.h | 4 +-
include/drm/drm_prime.h| 2 +
include/linux/dma-buf.h| 34 ++
24 files changed, 566 insertions(+), 156 deletions(-)
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 02/13] drm/gem: Create infrastructure for GEM vmap_local
This patch adds vmap_local and vunmap_local to struct drm_gem_object_funcs;
including the PRIME helpers to connect with dma-buf's related interfaces.
Besides the generic DRM core, this will become relevant for fbdev emulation
with virtio, so we update it as well.
v4:
* update documentation (Daniel)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 28 ++
drivers/gpu/drm/drm_internal.h | 2 ++
drivers/gpu/drm/drm_prime.c| 39 ++
drivers/gpu/drm/virtio/virtgpu_prime.c | 2 ++
include/drm/drm_gem.h | 21 ++
include/drm/drm_prime.h| 2 ++
6 files changed, 94 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 92f89cee213e..6e131d9bb7bd 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1234,6 +1234,34 @@ void drm_gem_vunmap(struct drm_gem_object *obj, struct
dma_buf_map *map)
dma_buf_map_clear(map);
}
+int drm_gem_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map)
+{
+ int ret;
+
+ if (!obj->funcs->vmap_local)
+ return -EOPNOTSUPP;
+
+ ret = obj->funcs->vmap_local(obj, map);
+ if (ret)
+ return ret;
+ else if (dma_buf_map_is_null(map))
+ return -ENOMEM;
+
+ return 0;
+}
+
+void drm_gem_vunmap_local(struct drm_gem_object *obj, struct dma_buf_map *map)
+{
+ if (dma_buf_map_is_null(map))
+ return;
+
+ if (obj->funcs->vunmap_local)
+ obj->funcs->vunmap_local(obj, map);
+
+ /* Always set the mapping to NULL. Callers may rely on this. */
+ dma_buf_map_clear(map);
+}
+
/**
* drm_gem_lock_reservations - Sets up the ww context and acquires
* the lock on an array of GEM objects.
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 81d386b5b92a..b0bf6aba763a 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -190,6 +190,8 @@ int drm_gem_pin(struct drm_gem_object *obj);
void drm_gem_unpin(struct drm_gem_object *obj);
int drm_gem_vmap(struct drm_gem_object *obj, struct dma_buf_map *map);
void drm_gem_vunmap(struct drm_gem_object *obj, struct dma_buf_map *map);
+int drm_gem_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map);
+void drm_gem_vunmap_local(struct drm_gem_object *obj, struct dma_buf_map *map);
/* drm_debugfs.c drm_debugfs_crc.c */
#if defined(CONFIG_DEBUG_FS)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 683aa29ecd3b..633edea76985 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -695,6 +695,43 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, struct
dma_buf_map *map)
}
EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
+/**
+ * drm_gem_dmabuf_vmap_local - dma_buf vmap_local implementation for GEM
+ * @dma_buf: buffer to be mapped
+ * @map: the virtual address of the buffer
+ *
+ * Sets up a kernel virtual mapping. This can be used as the
&dma_buf_ops.vmap_local
+ * callback. Calls into &drm_gem_object_funcs.vmap_local for device specific
handling.
+ * The kernel virtual address is returned in map.
+ *
+ * Returns:
+ * 0 on success or a negative errno code otherwise.
+ */
+int drm_gem_dmabuf_vmap_local(struct dma_buf *dma_buf, struct dma_buf_map *map)
+{
+ struct drm_gem_object *obj = dma_buf->priv;
+
+ return drm_gem_vmap_local(obj, map);
+}
+EXPORT_SYMBOL(drm_gem_dmabuf_vmap_local);
+
+/**
+ * drm_gem_dmabuf_vunmap_local - dma_buf vunmap_local implementation for GEM
+ * @dma_buf: buffer to be unmapped
+ * @map: the virtual address of the buffer
+ *
+ * Releases a kernel virtual mapping. This can be used as the
+ * &dma_buf_ops.vunmap_local callback. Calls into
&drm_gem_object_funcs.vunmap_local
+ * for device specific handling.
+ */
+void drm_gem_dmabuf_vunmap_local(struct dma_buf *dma_buf, struct dma_buf_map
*map)
+{
+ struct drm_gem_object *obj = dma_buf->priv;
+
+ drm_gem_vunmap_local(obj, map);
+}
+EXPORT_SYMBOL(drm_gem_dmabuf_vunmap_local);
+
/**
* drm_gem_prime_mmap - PRIME mmap function for GEM drivers
* @obj: GEM object
@@ -787,6 +824,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =
{
.mmap = drm_gem_dmabuf_mmap,
.vmap = drm_gem_dmabuf_vmap,
.vunmap = drm_gem_dmabuf_vunmap,
+ .vmap_local = drm_gem_dmabuf_vmap_local,
+ .vunmap_local = drm_gem_dmabuf_vunmap_local,
};
/**
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index 807a27a16365..fea11a53d8fc 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -54,6 +54,8 @@ static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops = {
.mmap = drm_gem_dmabuf_mmap,
.vmap = drm_gem_dmabuf_vmap,
.vunmap = drm_gem
[PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local operations
The existing dma-buf calls dma_buf_vmap() and dma_buf_vunmap() are
allowed to pin the buffer or acquire the buffer's reservation object
lock.
This is a problem for callers that only require a short-term mapping
of the buffer without the pinning, or callers that have special locking
requirements. These may suffer from unnecessary overhead or interfere
with regular pin operations.
The new interfaces dma_buf_vmap_local(), dma_buf_vunmapo_local(), and
their rsp callbacks in struct dma_buf_ops provide an alternative without
pinning or reservation locking. Callers are responsible for these
operations.
v4:
* update documentation (Daniel)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Suggested-by: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 81 +++
include/linux/dma-buf.h | 34
2 files changed, 115 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index b8465243eca2..01f9c74d97fa 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1295,6 +1295,87 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct
dma_buf_map *map)
}
EXPORT_SYMBOL_GPL(dma_buf_vunmap);
+/**
+ * dma_buf_vmap_local - Create virtual mapping for the buffer object into
kernel
+ * address space.
+ * @dmabuf:[in]buffer to vmap
+ * @map: [out] returns the vmap pointer
+ *
+ * Unlike dma_buf_vmap() this is a short term mapping and will not pin
+ * the buffer. The struct dma_resv for the @dmabuf must be locked until
+ * dma_buf_vunmap_local() is called.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map *map)
+{
+ struct dma_buf_map ptr;
+ int ret = 0;
+
+ dma_buf_map_clear(map);
+
+ if (WARN_ON(!dmabuf))
+ return -EINVAL;
+
+ dma_resv_assert_held(dmabuf->resv);
+
+ if (!dmabuf->ops->vmap_local)
+ return -EINVAL;
+
+ mutex_lock(&dmabuf->lock);
+ if (dmabuf->vmapping_counter) {
+ dmabuf->vmapping_counter++;
+ BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
+ *map = dmabuf->vmap_ptr;
+ goto out_unlock;
+ }
+
+ BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
+
+ ret = dmabuf->ops->vmap_local(dmabuf, &ptr);
+ if (WARN_ON_ONCE(ret))
+ goto out_unlock;
+
+ dmabuf->vmap_ptr = ptr;
+ dmabuf->vmapping_counter = 1;
+
+ *map = dmabuf->vmap_ptr;
+
+out_unlock:
+ mutex_unlock(&dmabuf->lock);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(dma_buf_vmap_local);
+
+/**
+ * dma_buf_vunmap_local - Unmap a vmap obtained by dma_buf_vmap_local.
+ * @dmabuf:[in]buffer to vunmap
+ * @map: [in]vmap pointer to vunmap
+ *
+ * Release a mapping established with dma_buf_vmap_local().
+ */
+void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct dma_buf_map *map)
+{
+ if (WARN_ON(!dmabuf))
+ return;
+
+ dma_resv_assert_held(dmabuf->resv);
+
+ BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
+ BUG_ON(dmabuf->vmapping_counter == 0);
+ BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map));
+
+ mutex_lock(&dmabuf->lock);
+ if (--dmabuf->vmapping_counter == 0) {
+ if (dmabuf->ops->vunmap_local)
+ dmabuf->ops->vunmap_local(dmabuf, map);
+ dma_buf_map_clear(&dmabuf->vmap_ptr);
+ }
+ mutex_unlock(&dmabuf->lock);
+}
+EXPORT_SYMBOL_GPL(dma_buf_vunmap_local);
+
#ifdef CONFIG_DEBUG_FS
static int dma_buf_debug_show(struct seq_file *s, void *unused)
{
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 628681bf6c99..aeed754b5467 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -264,6 +264,38 @@ struct dma_buf_ops {
int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
+
+ /**
+* @vmap_local:
+*
+* Creates a virtual mapping for the buffer into kernel address space.
+*
+* This callback establishes short-term mappings for situations where
+* callers only use the buffer for a bounded amount of time; such as
+* updates to the framebuffer or reading back contained information.
+* In contrast to the regular @vmap callback, vmap_local does never pin
+* the buffer to a specific domain or acquire the buffer's reservation
+* lock.
+*
+* This is called with the &dma_buf.resv object locked. Callers must
hold
+* the lock until after removing the mapping with @vunmap_local.
+*
+* This callback is optional.
+*
+* Returns:
+*
+* 0 on success or a negative error code on failure.
+*/
+ int (*vmap_local)(struct dma_buf *dmabuf, struct dma_buf_map *map
[PATCH v4 07/13] drm/gm12u320: Use drm_gem_shmem_vmap_local() in damage handling
Damage handling in gm12u320 requires a short-term mapping of the source
BO. Use drm_gem_shmem_vmap_local().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/gm12u320.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
index 33f65f4626e5..b0c6e350f2b3 100644
--- a/drivers/gpu/drm/tiny/gm12u320.c
+++ b/drivers/gpu/drm/tiny/gm12u320.c
@@ -265,11 +265,16 @@ static void gm12u320_copy_fb_to_blocks(struct
gm12u320_device *gm12u320)
y1 = gm12u320->fb_update.rect.y1;
y2 = gm12u320->fb_update.rect.y2;
- ret = drm_gem_shmem_vmap(fb->obj[0], &map);
+ ret = dma_resv_lock(fb->obj[0]->resv, NULL);
if (ret) {
- GM12U320_ERR("failed to vmap fb: %d\n", ret);
+ GM12U320_ERR("failed to reserve fb: %d\n", ret);
goto put_fb;
}
+ ret = drm_gem_shmem_vmap_local(fb->obj[0], &map);
+ if (ret) {
+ GM12U320_ERR("failed to vmap fb: %d\n", ret);
+ goto unlock_resv;
+ }
vaddr = map.vaddr; /* TODO: Use mapping abstraction properly */
if (fb->obj[0]->import_attach) {
@@ -321,8 +326,11 @@ static void gm12u320_copy_fb_to_blocks(struct
gm12u320_device *gm12u320)
if (ret)
GM12U320_ERR("dma_buf_end_cpu_access err: %d\n", ret);
}
+
+unlock_resv:
+ dma_resv_unlock(fb->obj[0]->resv);
vunmap:
- drm_gem_shmem_vunmap(fb->obj[0], &map);
+ drm_gem_shmem_vunmap_local(fb->obj[0], &map);
put_fb:
drm_framebuffer_put(fb);
gm12u320->fb_update.fb = NULL;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 03/13] drm/cma-helper: Provide a vmap function for short-term mappings
Implementations of the vmap/vunmap GEM callbacks may perform pinning
of the BO and may acquire the associated reservation object's lock.
Callers that only require a mapping of the contained memory can thus
interfere with other tasks that require exact pinning, such as scanout.
This is less of an issue with private CMA buffers, but may happen
with imported ones.
Therefore provide the new interface drm_gem_cma_vmap_local(), which only
performs the vmap operations. Callers have to hold the reservation lock
while the mapping persists.
This patch also connects GEM CMA helpers to the GEM object function with
equivalent functionality.
v4:
* vc4: don't wrap drm_gem_cma_vmap_local() in BO funcs (Daniel)
* remove the TODO comment (Daniel)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_cma_helper.c | 27 +++
drivers/gpu/drm/vc4/vc4_bo.c | 1 +
include/drm/drm_gem_cma_helper.h | 1 +
3 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 7942cf05cd93..f854027fa01f 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -38,6 +38,7 @@ static const struct drm_gem_object_funcs
drm_gem_cma_default_funcs = {
.print_info = drm_gem_cma_print_info,
.get_sg_table = drm_gem_cma_get_sg_table,
.vmap = drm_gem_cma_vmap,
+ .vmap_local = drm_gem_cma_vmap_local,
.mmap = drm_gem_cma_mmap,
.vm_ops = &drm_gem_cma_vm_ops,
};
@@ -471,6 +472,32 @@ int drm_gem_cma_vmap(struct drm_gem_object *obj, struct
dma_buf_map *map)
}
EXPORT_SYMBOL_GPL(drm_gem_cma_vmap);
+/**
+ * drm_gem_cma_vmap_local - map a CMA GEM object into the kernel's virtual
+ * address space
+ * @obj: GEM object
+ * @map: Returns the kernel virtual address of the CMA GEM object's backing
+ * store.
+ *
+ * This function maps a buffer into the kernel's
+ * virtual address space. Since the CMA buffers are already mapped into the
+ * kernel virtual address space this simply returns the cached virtual
+ * address. Drivers using the CMA helpers should set this as their DRM
+ * driver's &drm_gem_object_funcs.vmap_local callback.
+ *
+ * Returns:
+ * 0 on success, or a negative error code otherwise.
+ */
+int drm_gem_cma_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map)
+{
+ struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
+
+ dma_buf_map_set_vaddr(map, cma_obj->vaddr);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(drm_gem_cma_vmap_local);
+
/**
* drm_gem_cma_mmap - memory-map an exported CMA GEM object
* @obj: GEM object
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index dc316cb79e00..7283c018dbaf 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -387,6 +387,7 @@ static const struct drm_gem_object_funcs
vc4_gem_object_funcs = {
.export = vc4_prime_export,
.get_sg_table = drm_gem_cma_get_sg_table,
.vmap = vc4_prime_vmap,
+ .vmap_local = drm_gem_cma_vmap_local,
.vm_ops = &vc4_vm_ops,
};
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 0a9711caa3e8..05122e71bc6d 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -99,6 +99,7 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
struct sg_table *sgt);
int drm_gem_cma_vmap(struct drm_gem_object *obj, struct dma_buf_map *map);
+int drm_gem_cma_vmap_local(struct drm_gem_object *obj, struct dma_buf_map
*map);
int drm_gem_cma_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
/**
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 05/13] drm/mgag200: Use drm_gem_shmem_vmap_local() in damage handling
Damage handling in mgag200 requires a short-term mapping of the source
BO. Use drm_gem_shmem_vmap_local().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 1dfc42170059..a33e28d4c5e9 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1552,22 +1552,32 @@ mgag200_handle_damage(struct mga_device *mdev, struct
drm_framebuffer *fb,
struct drm_rect *clip)
{
struct drm_device *dev = &mdev->base;
+ struct drm_gem_object *obj = fb->obj[0];
struct dma_buf_map map;
void *vmap;
int ret;
- ret = drm_gem_shmem_vmap(fb->obj[0], &map);
+ ret = dma_resv_lock(obj->resv, NULL);
if (drm_WARN_ON(dev, ret))
- return; /* BUG: SHMEM BO should always be vmapped */
+ return;
+ ret = drm_gem_shmem_vmap_local(obj, &map);
+ if (drm_WARN_ON(dev, ret))
+ goto err_dma_resv_unlock; /* BUG: SHMEM BO should always be
vmapped */
vmap = map.vaddr; /* TODO: Use mapping abstraction properly */
drm_fb_memcpy_dstclip(mdev->vram, vmap, fb, clip);
- drm_gem_shmem_vunmap(fb->obj[0], &map);
+ drm_gem_shmem_vunmap_local(obj, &map);
+ dma_resv_unlock(obj->resv);
/* Always scanout image at VRAM offset 0 */
mgag200_set_startadd(mdev, (u32)0);
mgag200_set_offset(mdev, fb);
+
+ return;
+
+err_dma_resv_unlock:
+ dma_resv_unlock(obj->resv);
}
static void
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 06/13] drm/cirrus: Use drm_gem_shmem_vmap_local() in damage handling
Damage handling in cirrus requires a short-term mapping of the source
BO. Use drm_gem_shmem_vmap_local().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/cirrus.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index a043e602199e..21cd7056d45f 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -315,6 +315,7 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
struct drm_rect *rect)
{
struct cirrus_device *cirrus = to_cirrus(fb->dev);
+ struct drm_gem_object *obj = fb->obj[0];
struct dma_buf_map map;
void *vmap;
int idx, ret;
@@ -323,9 +324,12 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
if (!drm_dev_enter(&cirrus->dev, &idx))
goto out;
- ret = drm_gem_shmem_vmap(fb->obj[0], &map);
+ ret = dma_resv_lock(obj->resv, NULL);
if (ret)
goto out_dev_exit;
+ ret = drm_gem_shmem_vmap_local(fb->obj[0], &map);
+ if (ret)
+ goto out_dma_resv_unlock;
vmap = map.vaddr; /* TODO: Use mapping abstraction properly */
if (cirrus->cpp == fb->format->cpp[0])
@@ -345,9 +349,11 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
else
WARN_ON_ONCE("cpp mismatch");
- drm_gem_shmem_vunmap(fb->obj[0], &map);
ret = 0;
+ drm_gem_shmem_vunmap_local(obj, &map);
+out_dma_resv_unlock:
+ dma_resv_unlock(obj->resv);
out_dev_exit:
drm_dev_exit(idx);
out:
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 04/13] drm/shmem-helper: Provide a vmap function for short-term mappings
Implementations of the vmap/vunmap GEM callbacks may perform pinning
of the BO and may acquire the associated reservation object's lock.
Callers that only require a mapping of the contained memory can thus
interfere with other tasks that require exact pinning, such as scanout.
This is less of an issue with private SHMEM buffers, but may happen
with imported ones.
Therefore provide the new interfaces drm_gem_shmem_vmap_local() and
drm_gem_shmem_vunmap_local(), which only perform the vmap/vunmap
operations. Callers have to hold the reservation lock while the mapping
persists.
This patch also connects GEM SHMEM helpers to GEM object functions with
equivalent functionality.
v4:
* call dma_buf_{vmap,vunmap}_local() where necessary (Daniel)
* move driver changes into separate patches (Daniel)
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 90 +++---
include/drm/drm_gem_shmem_helper.h | 2 +
2 files changed, 84 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 9825c378dfa6..298832b2b43b 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -32,6 +32,8 @@ static const struct drm_gem_object_funcs drm_gem_shmem_funcs
= {
.get_sg_table = drm_gem_shmem_get_sg_table,
.vmap = drm_gem_shmem_vmap,
.vunmap = drm_gem_shmem_vunmap,
+ .vmap_local = drm_gem_shmem_vmap_local,
+ .vunmap_local = drm_gem_shmem_vunmap_local,
.mmap = drm_gem_shmem_mmap,
};
@@ -261,7 +263,8 @@ void drm_gem_shmem_unpin(struct drm_gem_object *obj)
}
EXPORT_SYMBOL(drm_gem_shmem_unpin);
-static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem,
struct dma_buf_map *map)
+static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem,
struct dma_buf_map *map,
+bool local)
{
struct drm_gem_object *obj = &shmem->base;
int ret = 0;
@@ -272,7 +275,10 @@ static int drm_gem_shmem_vmap_locked(struct
drm_gem_shmem_object *shmem, struct
}
if (obj->import_attach) {
- ret = dma_buf_vmap(obj->import_attach->dmabuf, map);
+ if (local)
+ ret = dma_buf_vmap_local(obj->import_attach->dmabuf,
map);
+ else
+ ret = dma_buf_vmap(obj->import_attach->dmabuf, map);
if (!ret) {
if (WARN_ON(map->is_iomem)) {
ret = -EIO;
@@ -313,7 +319,7 @@ static int drm_gem_shmem_vmap_locked(struct
drm_gem_shmem_object *shmem, struct
return ret;
}
-/*
+/**
* drm_gem_shmem_vmap - Create a virtual mapping for a shmem GEM object
* @shmem: shmem GEM object
* @map: Returns the kernel virtual address of the SHMEM GEM object's backing
@@ -339,15 +345,53 @@ int drm_gem_shmem_vmap(struct drm_gem_object *obj, struct
dma_buf_map *map)
ret = mutex_lock_interruptible(&shmem->vmap_lock);
if (ret)
return ret;
- ret = drm_gem_shmem_vmap_locked(shmem, map);
+ ret = drm_gem_shmem_vmap_locked(shmem, map, false);
mutex_unlock(&shmem->vmap_lock);
return ret;
}
EXPORT_SYMBOL(drm_gem_shmem_vmap);
+/**
+ * drm_gem_shmem_vmap_local - Create a virtual mapping for a shmem GEM object
+ * @shmem: shmem GEM object
+ * @map: Returns the kernel virtual address of the SHMEM GEM object's backing
+ * store.
+ *
+ * This function makes sure that a contiguous kernel virtual address mapping
+ * exists for the buffer backing the shmem GEM object.
+ *
+ * The function is called with the BO's reservation object locked. Callers must
+ * hold the lock until after unmapping the buffer.
+ *
+ * This function can be used to implement &drm_gem_object_funcs.vmap_local. But
+ * it can also be called by drivers directly, in which case it will hide the
+ * differences between dma-buf imported and natively allocated objects.
+ *
+ * Acquired mappings should be cleaned up by calling
drm_gem_shmem_vunmap_local().
+ *
+ * Returns:
+ * 0 on success or a negative error code on failure.
+ */
+int drm_gem_shmem_vmap_local(struct drm_gem_object *obj, struct dma_buf_map
*map)
+{
+ struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
+ int ret;
+
+ dma_resv_assert_held(obj->resv);
+
+ ret = mutex_lock_interruptible(&shmem->vmap_lock);
+ if (ret)
+ return ret;
+ ret = drm_gem_shmem_vmap_locked(shmem, map, true);
+ mutex_unlock(&shmem->vmap_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_shmem_vmap_local);
+
static void drm_gem_shmem_vunmap_locked(struct drm_gem_shmem_object *shmem,
- struct dma_buf_map *map)
+ struct dma_buf_map *map, bool local)
{
struct drm_gem_object *obj = &shmem->base;
@@ -358,7 +40
[PATCH v4 08/13] drm/udl: Use drm_gem_shmem_vmap_local() in damage handling
Damage handling in udl requires a short-term mapping of the source
BO. Use drm_gem_shmem_vmap_local().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_modeset.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 9d34ec9d03f6..46b55b4d03c2 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -290,14 +290,18 @@ static int udl_handle_damage(struct drm_framebuffer *fb,
int x, int y,
else if ((clip.x2 > fb->width) || (clip.y2 > fb->height))
return -EINVAL;
+ ret = dma_resv_lock(fb->obj[0]->resv, NULL);
+ if (ret)
+ return ret;
+
if (import_attach) {
ret = dma_buf_begin_cpu_access(import_attach->dmabuf,
DMA_FROM_DEVICE);
if (ret)
- return ret;
+ goto out_dma_resv_unlock;
}
- ret = drm_gem_shmem_vmap(fb->obj[0], &map);
+ ret = drm_gem_shmem_vmap_local(fb->obj[0], &map);
if (ret) {
DRM_ERROR("failed to vmap fb\n");
goto out_dma_buf_end_cpu_access;
@@ -307,7 +311,7 @@ static int udl_handle_damage(struct drm_framebuffer *fb,
int x, int y,
urb = udl_get_urb(dev);
if (!urb) {
ret = -ENOMEM;
- goto out_drm_gem_shmem_vunmap;
+ goto out_drm_gem_shmem_vunmap_local;
}
cmd = urb->transfer_buffer;
@@ -320,7 +324,7 @@ static int udl_handle_damage(struct drm_framebuffer *fb,
int x, int y,
&cmd, byte_offset, dev_byte_offset,
byte_width);
if (ret)
- goto out_drm_gem_shmem_vunmap;
+ goto out_drm_gem_shmem_vunmap_local;
}
if (cmd > (char *)urb->transfer_buffer) {
@@ -336,8 +340,8 @@ static int udl_handle_damage(struct drm_framebuffer *fb,
int x, int y,
ret = 0;
-out_drm_gem_shmem_vunmap:
- drm_gem_shmem_vunmap(fb->obj[0], &map);
+out_drm_gem_shmem_vunmap_local:
+ drm_gem_shmem_vunmap_local(fb->obj[0], &map);
out_dma_buf_end_cpu_access:
if (import_attach) {
tmp_ret = dma_buf_end_cpu_access(import_attach->dmabuf,
@@ -345,6 +349,8 @@ static int udl_handle_damage(struct drm_framebuffer *fb,
int x, int y,
if (tmp_ret && !ret)
ret = tmp_ret; /* only update ret if not set yet */
}
+out_dma_resv_unlock:
+ dma_resv_unlock(fb->obj[0]->resv);
return ret;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 10/13] drm/ast: Use drm_gem_vram_vmap_local() in cursor update
Cursor updates in ast require a short-term mapping of the source and
destination BO. Use drm_gem_vram_vmap_local() and avoid the pinning
operations.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 37 +++-
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index fac1ee79c372..c38f435bcde2 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -159,6 +159,8 @@ int ast_cursor_blit(struct ast_private *ast, struct
drm_framebuffer *fb)
struct drm_device *dev = &ast->base;
struct drm_gem_vram_object *dst_gbo =
ast->cursor.gbo[ast->cursor.next_index];
struct drm_gem_vram_object *src_gbo = drm_gem_vram_of_gem(fb->obj[0]);
+ struct drm_gem_object *objs[] = {&src_gbo->bo.base, &dst_gbo->bo.base};
+ struct ww_acquire_ctx ctx;
struct dma_buf_map src_map, dst_map;
void __iomem *dst;
void *src;
@@ -168,26 +170,34 @@ int ast_cursor_blit(struct ast_private *ast, struct
drm_framebuffer *fb)
drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT))
return -EINVAL;
- ret = drm_gem_vram_vmap(src_gbo, &src_map);
+ ret = drm_gem_lock_reservations(objs, ARRAY_SIZE(objs), &ctx);
if (ret)
return ret;
+
+ ret = drm_gem_vram_vmap_local(src_gbo, &src_map);
+ if (ret)
+ goto err_drm_gem_unlock_reservations;
src = src_map.vaddr; /* TODO: Use mapping abstraction properly */
- ret = drm_gem_vram_vmap(dst_gbo, &dst_map);
+ ret = drm_gem_vram_vmap_local(dst_gbo, &dst_map);
if (ret)
- goto err_drm_gem_vram_vunmap;
+ goto err_drm_gem_vram_vunmap_local;
dst = dst_map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
/* do data transfer to cursor BO */
update_cursor_image(dst, src, fb->width, fb->height);
- drm_gem_vram_vunmap(dst_gbo, &dst_map);
- drm_gem_vram_vunmap(src_gbo, &src_map);
+ drm_gem_vram_vunmap_local(dst_gbo, &dst_map);
+ drm_gem_vram_vunmap_local(src_gbo, &src_map);
+
+ drm_gem_unlock_reservations(objs, ARRAY_SIZE(objs), &ctx);
return 0;
-err_drm_gem_vram_vunmap:
- drm_gem_vram_vunmap(src_gbo, &src_map);
+err_drm_gem_vram_vunmap_local:
+ drm_gem_vram_vunmap_local(src_gbo, &src_map);
+err_drm_gem_unlock_reservations:
+ drm_gem_unlock_reservations(objs, ARRAY_SIZE(objs), &ctx);
return ret;
}
@@ -241,6 +251,7 @@ void ast_cursor_show(struct ast_private *ast, int x, int y,
{
struct drm_device *dev = &ast->base;
struct drm_gem_vram_object *gbo =
ast->cursor.gbo[ast->cursor.next_index];
+ struct drm_gem_object *obj = &gbo->bo.base;
struct dma_buf_map map;
u8 x_offset, y_offset;
u8 __iomem *dst;
@@ -248,16 +259,22 @@ void ast_cursor_show(struct ast_private *ast, int x, int
y,
u8 jreg;
int ret;
- ret = drm_gem_vram_vmap(gbo, &map);
- if (drm_WARN_ONCE(dev, ret, "drm_gem_vram_vmap() failed, ret=%d\n",
ret))
+ ret = dma_resv_lock(obj->resv, NULL);
+ if (ret)
+ return;
+ ret = drm_gem_vram_vmap_local(gbo, &map);
+ if (drm_WARN_ONCE(dev, ret, "drm_gem_vram_vmap_local() failed,
ret=%d\n", ret)) {
+ dma_resv_unlock(obj->resv);
return;
+ }
dst = map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
sig = dst + AST_HWC_SIZE;
writel(x, sig + AST_HWC_SIGNATURE_X);
writel(y, sig + AST_HWC_SIGNATURE_Y);
- drm_gem_vram_vunmap(gbo, &map);
+ drm_gem_vram_vunmap_local(gbo, &map);
+ dma_resv_unlock(obj->resv);
if (x < 0) {
x_offset = (-x) + offset_x;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 09/13] drm/vram-helper: Provide a vmap function for short-term mappings
Implementations of the vmap/vunmap GEM callbacks may perform pinning
of the BO and may acquire the associated reservation object's lock.
It's somewhat inconvenient to callers that simply require a mapping of
the contained memory; and also ipmplies a certain overhead.
Therefore provide drm_gem_vram_vmap_local() drm_gem_vram_vunmap_local(),
which only perform the vmap/vunmap operations. Callers have to hold the
reservation lock while the mapping persists; or have to pin the BO by
themselves.
This patch connects GEM VRAM helpers to GEM object functions with
equivalent functionality.
v4:
* move driver changes into separate patches (Daniel)
* update documentation (Daniel)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_vram_helper.c | 141 +-
include/drm/drm_gem_vram_helper.h | 2 +
2 files changed, 95 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 02ca22e90290..c7fba3a0758e 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -379,47 +379,6 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
}
EXPORT_SYMBOL(drm_gem_vram_unpin);
-static int drm_gem_vram_kmap_locked(struct drm_gem_vram_object *gbo,
- struct dma_buf_map *map)
-{
- int ret;
-
- if (gbo->vmap_use_count > 0)
- goto out;
-
- ret = ttm_bo_vmap(&gbo->bo, &gbo->map);
- if (ret)
- return ret;
-
-out:
- ++gbo->vmap_use_count;
- *map = gbo->map;
-
- return 0;
-}
-
-static void drm_gem_vram_kunmap_locked(struct drm_gem_vram_object *gbo,
- struct dma_buf_map *map)
-{
- struct drm_device *dev = gbo->bo.base.dev;
-
- if (drm_WARN_ON_ONCE(dev, !gbo->vmap_use_count))
- return;
-
- if (drm_WARN_ON_ONCE(dev, !dma_buf_map_is_equal(&gbo->map, map)))
- return; /* BUG: map not mapped from this BO */
-
- if (--gbo->vmap_use_count > 0)
- return;
-
- /*
-* Permanently mapping and unmapping buffers adds overhead from
-* updating the page tables and creates debugging output. Therefore,
-* we delay the actual unmap operation until the BO gets evicted
-* from memory. See drm_gem_vram_bo_driver_move_notify().
-*/
-}
-
/**
* drm_gem_vram_vmap() - Pins and maps a GEM VRAM object into kernel address
* space
@@ -447,7 +406,7 @@ int drm_gem_vram_vmap(struct drm_gem_vram_object *gbo,
struct dma_buf_map *map)
ret = drm_gem_vram_pin_locked(gbo, 0);
if (ret)
goto err_ttm_bo_unreserve;
- ret = drm_gem_vram_kmap_locked(gbo, map);
+ ret = drm_gem_vram_vmap_local(gbo, map);
if (ret)
goto err_drm_gem_vram_unpin_locked;
@@ -479,13 +438,83 @@ void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo,
struct dma_buf_map *ma
if (WARN_ONCE(ret, "ttm_bo_reserve_failed(): ret=%d\n", ret))
return;
- drm_gem_vram_kunmap_locked(gbo, map);
+ drm_gem_vram_vunmap_local(gbo, map);
drm_gem_vram_unpin_locked(gbo);
ttm_bo_unreserve(&gbo->bo);
}
EXPORT_SYMBOL(drm_gem_vram_vunmap);
+/**
+ * drm_gem_vram_vmap_local() - Maps a GEM VRAM object into kernel address space
+ * @gbo: The GEM VRAM object to map
+ * @map: Returns the kernel virtual address of the VRAM GEM object's backing
+ * store.
+ *
+ * The vmap_local function maps the buffer of a GEM VRAM object into kernel
address
+ * space. Call drm_gem_vram_vunmap_local() with the returned address to unmap
and
+ * unpin the GEM VRAM object.
+ *
+ * The function is called with the BO's reservation object locked. For
short-term
+ * mappings, callers must hold the BO's reservation lock until after unmapping
the
+ * buffer.
+ *
+ * Returns:
+ * 0 on success, or a negative error code otherwise.
+ */
+int drm_gem_vram_vmap_local(struct drm_gem_vram_object *gbo, struct
dma_buf_map *map)
+{
+ int ret;
+
+ dma_resv_assert_held(gbo->bo.base.resv);
+
+ if (gbo->vmap_use_count > 0)
+ goto out;
+
+ ret = ttm_bo_vmap(&gbo->bo, &gbo->map);
+ if (ret)
+ return ret;
+
+out:
+ ++gbo->vmap_use_count;
+ *map = gbo->map;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_gem_vram_vmap_local);
+
+/**
+ * drm_gem_vram_vunmap_local() - Unmaps a GEM VRAM object
+ * @gbo: The GEM VRAM object to unmap
+ * @map: Kernel virtual address where the VRAM GEM object was mapped
+ *
+ * A call to drm_gem_vram_vunmap_local() unmaps a GEM VRAM object's buffer. See
+ * the documentation for drm_gem_vram_vmap_local() for more information.
+ */
+void drm_gem_vram_vunmap_local(struct drm_gem_vram_object *gbo, struct
dma_buf_map *map)
+{
+ struct drm_device *dev = gbo->bo.base.dev;
+
+ dm
[PATCH v4 11/13] drm/vboxvideo: Use drm_gem_vram_vmap_local() in cursor update
Cursor updates in vboxvideo require a short-term mapping of the
source BO. Use drm_gem_vram_vmap_local() and avoid the pinning
operations.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vboxvideo/vbox_mode.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
b/drivers/gpu/drm/vboxvideo/vbox_mode.c
index dbc0dd53c69e..215b37c78c10 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
@@ -381,7 +381,8 @@ static void vbox_cursor_atomic_update(struct drm_plane
*plane,
container_of(plane->dev, struct vbox_private, ddev);
struct vbox_crtc *vbox_crtc = to_vbox_crtc(plane->state->crtc);
struct drm_framebuffer *fb = plane->state->fb;
- struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(fb->obj[0]);
+ struct drm_gem_object *obj = fb->obj[0];
+ struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(obj);
u32 width = plane->state->crtc_w;
u32 height = plane->state->crtc_h;
size_t data_size, mask_size;
@@ -401,11 +402,12 @@ static void vbox_cursor_atomic_update(struct drm_plane
*plane,
vbox_crtc->cursor_enabled = true;
- ret = drm_gem_vram_vmap(gbo, &map);
+ ret = dma_resv_lock(obj->resv, NULL);
+ if (ret)
+ return;
+ ret = drm_gem_vram_vmap_local(gbo, &map);
if (ret) {
- /*
-* BUG: we should have pinned the BO in prepare_fb().
-*/
+ dma_resv_unlock(obj->resv);
mutex_unlock(&vbox->hw_mutex);
DRM_WARN("Could not map cursor bo, skipping update\n");
return;
@@ -421,7 +423,8 @@ static void vbox_cursor_atomic_update(struct drm_plane
*plane,
data_size = width * height * 4 + mask_size;
copy_cursor_image(src, vbox->cursor_data, width, height, mask_size);
- drm_gem_vram_vunmap(gbo, &map);
+ drm_gem_vram_vunmap_local(gbo, &map);
+ dma_resv_unlock(obj->resv);
flags = VBOX_MOUSE_POINTER_VISIBLE | VBOX_MOUSE_POINTER_SHAPE |
VBOX_MOUSE_POINTER_ALPHA;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 13/13] drm/vram-helper: Remove unused drm_gem_vram_{vmap, vunmap}()
VRAM-helper BO's cannot be exported, so calls for vmap and vunmap
can only come from the BO's drivers or a kernel client. These are
supposed use vmap_local functionality.
The vmap and vunmap operations in VRAM helpers are therefore unused
and can be removed.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 98 ---
include/drm/drm_gem_vram_helper.h | 2 -
2 files changed, 100 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index c7fba3a0758e..c7d166cd16df 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -379,72 +379,6 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
}
EXPORT_SYMBOL(drm_gem_vram_unpin);
-/**
- * drm_gem_vram_vmap() - Pins and maps a GEM VRAM object into kernel address
- * space
- * @gbo: The GEM VRAM object to map
- * @map: Returns the kernel virtual address of the VRAM GEM object's backing
- * store.
- *
- * The vmap function pins a GEM VRAM object to its current location, either
- * system or video memory, and maps its buffer into kernel address space.
- * As pinned object cannot be relocated, you should avoid pinning objects
- * permanently. Call drm_gem_vram_vunmap() with the returned address to
- * unmap and unpin the GEM VRAM object.
- *
- * Returns:
- * 0 on success, or a negative error code otherwise.
- */
-int drm_gem_vram_vmap(struct drm_gem_vram_object *gbo, struct dma_buf_map *map)
-{
- int ret;
-
- ret = ttm_bo_reserve(&gbo->bo, true, false, NULL);
- if (ret)
- return ret;
-
- ret = drm_gem_vram_pin_locked(gbo, 0);
- if (ret)
- goto err_ttm_bo_unreserve;
- ret = drm_gem_vram_vmap_local(gbo, map);
- if (ret)
- goto err_drm_gem_vram_unpin_locked;
-
- ttm_bo_unreserve(&gbo->bo);
-
- return 0;
-
-err_drm_gem_vram_unpin_locked:
- drm_gem_vram_unpin_locked(gbo);
-err_ttm_bo_unreserve:
- ttm_bo_unreserve(&gbo->bo);
- return ret;
-}
-EXPORT_SYMBOL(drm_gem_vram_vmap);
-
-/**
- * drm_gem_vram_vunmap() - Unmaps and unpins a GEM VRAM object
- * @gbo: The GEM VRAM object to unmap
- * @map: Kernel virtual address where the VRAM GEM object was mapped
- *
- * A call to drm_gem_vram_vunmap() unmaps and unpins a GEM VRAM buffer. See
- * the documentation for drm_gem_vram_vmap() for more information.
- */
-void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo, struct dma_buf_map
*map)
-{
- int ret;
-
- ret = ttm_bo_reserve(&gbo->bo, false, false, NULL);
- if (WARN_ONCE(ret, "ttm_bo_reserve_failed(): ret=%d\n", ret))
- return;
-
- drm_gem_vram_vunmap_local(gbo, map);
- drm_gem_vram_unpin_locked(gbo);
-
- ttm_bo_unreserve(&gbo->bo);
-}
-EXPORT_SYMBOL(drm_gem_vram_vunmap);
-
/**
* drm_gem_vram_vmap_local() - Maps a GEM VRAM object into kernel address space
* @gbo: The GEM VRAM object to map
@@ -870,36 +804,6 @@ static void drm_gem_vram_object_unpin(struct
drm_gem_object *gem)
drm_gem_vram_unpin(gbo);
}
-/**
- * drm_gem_vram_object_vmap() -
- * Implements &struct drm_gem_object_funcs.vmap
- * @gem: The GEM object to map
- * @map: Returns the kernel virtual address of the VRAM GEM object's backing
- * store.
- *
- * Returns:
- * 0 on success, or a negative error code otherwise.
- */
-static int drm_gem_vram_object_vmap(struct drm_gem_object *gem, struct
dma_buf_map *map)
-{
- struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
-
- return drm_gem_vram_vmap(gbo, map);
-}
-
-/**
- * drm_gem_vram_object_vunmap() -
- * Implements &struct drm_gem_object_funcs.vunmap
- * @gem: The GEM object to unmap
- * @map: Kernel virtual address where the VRAM GEM object was mapped
- */
-static void drm_gem_vram_object_vunmap(struct drm_gem_object *gem, struct
dma_buf_map *map)
-{
- struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
-
- drm_gem_vram_vunmap(gbo, map);
-}
-
static int drm_gem_vram_object_vmap_local(struct drm_gem_object *gem, struct
dma_buf_map *map)
{
struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
@@ -922,8 +826,6 @@ static const struct drm_gem_object_funcs
drm_gem_vram_object_funcs = {
.free = drm_gem_vram_object_free,
.pin = drm_gem_vram_object_pin,
.unpin = drm_gem_vram_object_unpin,
- .vmap = drm_gem_vram_object_vmap,
- .vunmap = drm_gem_vram_object_vunmap,
.vmap_local = drm_gem_vram_object_vmap_local,
.vunmap_local = drm_gem_vram_object_vunmap_local,
.mmap = drm_gem_ttm_mmap,
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index bd6a60e7c22b..e571867f4069 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -97,8 +97,6 @@ u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object *gbo);
s64 drm_gem_vram_o
[PATCH v4 12/13] drm/fb-helper: Move BO locking from DRM client to fbdev damage worker
Fbdev emulation has to lock the BO into place while flushing the shadow
buffer into the BO's memory. Remove any interference with pinning by
using vmap_local functionality (instead of full vmap). This requires
BO reservation locking in fbdev's damage worker.
The new DRM client functions for locking and vmap_local functionality
are added for consistency with the existing style.
v4:
* update documentation (Daniel)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_client.c| 94 +
drivers/gpu/drm/drm_fb_helper.c | 41 +++---
include/drm/drm_client.h| 4 ++
3 files changed, 119 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index ce45e380f4a2..0220165810aa 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -288,6 +288,37 @@ drm_client_buffer_create(struct drm_client_dev *client,
u32 width, u32 height, u
return ERR_PTR(ret);
}
+/**
+ * drm_client_buffer_lock - Locks the DRM client buffer
+ * @buffer: DRM client buffer
+ *
+ * This function locks the client buffer by acquiring the buffer
+ * object's reservation lock.
+ *
+ * Unlock the buffer with drm_client_buffer_unlock().
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int
+drm_client_buffer_lock(struct drm_client_buffer *buffer)
+{
+ return dma_resv_lock(buffer->gem->resv, NULL);
+}
+EXPORT_SYMBOL(drm_client_buffer_lock);
+
+/**
+ * drm_client_buffer_unlock - Unlock DRM client buffer
+ * @buffer: DRM client buffer
+ *
+ * Unlocks a client buffer. See drm_client_buffer_lock().
+ */
+void drm_client_buffer_unlock(struct drm_client_buffer *buffer)
+{
+ dma_resv_unlock(buffer->gem->resv);
+}
+EXPORT_SYMBOL(drm_client_buffer_unlock);
+
/**
* drm_client_buffer_vmap - Map DRM client buffer into address space
* @buffer: DRM client buffer
@@ -305,6 +336,9 @@ drm_client_buffer_create(struct drm_client_dev *client, u32
width, u32 height, u
* other vmap interfaces, you don't need it for the client's vunmap
* function. So you can modify it at will during blit and draw operations.
*
+ * drm_client_buffer_vmap() is for permanent or long-term mappings. See
+ * drm_client_buffer_vmap_local() for short-term mappings.
+ *
* Returns:
* 0 on success, or a negative errno code otherwise.
*/
@@ -348,6 +382,66 @@ void drm_client_buffer_vunmap(struct drm_client_buffer
*buffer)
}
EXPORT_SYMBOL(drm_client_buffer_vunmap);
+/**
+ * drm_client_buffer_vmap_local - Map DRM client buffer into address space
+ * @buffer: DRM client buffer
+ * @map_copy: Returns the mapped memory's address
+ *
+ * This function maps a client buffer into kernel address space. If the
+ * buffer is already mapped, it returns the existing mapping's address.
+ *
+ * Client buffer mappings are not ref'counted. Each call to
+ * drm_client_buffer_vmap_local() should be followed by a call to
+ * drm_client_buffer_vunmap_local(); or the client buffer should be mapped
+ * throughout its lifetime.
+ *
+ * The returned address is a copy of the internal value. In contrast to
+ * other vmap interfaces, you don't need it for the client's vunmap
+ * function. So you can modify it at will during blit and draw operations.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int
+drm_client_buffer_vmap_local(struct drm_client_buffer *buffer, struct
dma_buf_map *map_copy)
+{
+ struct dma_buf_map *map = &buffer->map;
+ int ret;
+
+ /*
+* FIXME: The dependency on GEM here isn't required, we could
+* convert the driver handle to a dma-buf instead and use the
+* backend-agnostic dma-buf vmap_local support instead. This would
+* require that the handle2fd prime ioctl is reworked to pull the
+* fd_install step out of the driver backend hooks, to make that
+* final step optional for internal users.
+*/
+ ret = drm_gem_vmap_local(buffer->gem, map);
+ if (ret)
+ return ret;
+
+ *map_copy = *map;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_client_buffer_vmap_local);
+
+/**
+ * drm_client_buffer_vunmap_local - Unmap DRM client buffer
+ * @buffer: DRM client buffer
+ *
+ * This function removes a client buffer's memory mapping. Calling this
+ * function is only required by clients that manage their buffer mappings
+ * by themselves.
+ */
+void drm_client_buffer_vunmap_local(struct drm_client_buffer *buffer)
+{
+ struct dma_buf_map *map = &buffer->map;
+
+ drm_gem_vunmap_local(buffer->gem, map);
+}
+EXPORT_SYMBOL(drm_client_buffer_vunmap_local);
+
static void drm_client_buffer_rmfb(struct drm_client_buffer *buffer)
{
int ret;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a44c3a438059..283d27f8fe67 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -399,
Re: [PULL] drm-misc-fixes
On Fri, Jan 08, 2021 at 10:34:34AM +0100, Thomas Zimmermann wrote:
> Hi Dave and Daniel,
>
> sorry for being a bit late. Here's this week's PR for drm-misc-fixes.
No worries, Dave's out anyway so this is all in time for me to do the pull
:-)
>
> Best regards
> Thomas
>
> drm-misc-fixes-2021-01-08:
> * dma-buf: fix a use-after-free
> * radeon: don't init the TTM page pool manually
> * ttm: unexport ttm_pool_{init,fini}()
> The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62:
>
> Linux 5.11-rc2 (2021-01-03 15:55:30 -0800)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-01-08
Pulled, thanks.
-Daniel
>
> for you to fetch changes up to a73858ef4d5e1d425e171f0f6a52864176a6a979:
>
> drm/ttm: unexport ttm_pool_init/fini (2021-01-07 14:25:43 +0100)
>
>
> * dma-buf: fix a use-after-free
> * radeon: don't init the TTM page pool manually
> * ttm: unexport ttm_pool_{init,fini}()
>
>
> Charan Teja Reddy (1):
> dmabuf: fix use-after-free of dmabuf's file->f_inode
>
> Christian König (2):
> drm/radeon: stop re-init the TTM page pool
> drm/ttm: unexport ttm_pool_init/fini
>
> drivers/dma-buf/dma-buf.c | 21 +
> drivers/gpu/drm/radeon/radeon_ttm.c | 3 ---
> drivers/gpu/drm/ttm/ttm_pool.c | 2 --
> 3 files changed, 17 insertions(+), 9 deletions(-)
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/modes: add non-OF stub for of_get_drm_display_mode
If CONFIG_OF is disabled, of_get_drm_display_mode is not compiled in,
and drivers using it fail to build:
ld: drivers/gpu/drm/imx/parallel-display.o: in function
`imx_pd_connector_get_modes':
parallel-display.c:(.text+0x8d): undefined reference to
`of_get_drm_display_mode'
Add an inline stub so they can be build-tested with non-OF
configurations.
Reported-by: Randy Dunlap
Signed-off-by: Philipp Zabel
---
include/drm/drm_modes.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index a0d79d1c51e2..29ba4adf0c53 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -461,9 +461,19 @@ void drm_display_mode_from_videomode(const struct
videomode *vm,
void drm_display_mode_to_videomode(const struct drm_display_mode *dmode,
struct videomode *vm);
void drm_bus_flags_from_videomode(const struct videomode *vm, u32 *bus_flags);
+
+#if defined(CONFIG_OF)
int of_get_drm_display_mode(struct device_node *np,
struct drm_display_mode *dmode, u32 *bus_flags,
int index);
+#else
+static inline int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode,
+ u32 *bus_flags, int index)
+{
+ return -EINVAL;
+}
+#endif
void drm_mode_set_name(struct drm_display_mode *mode);
int drm_mode_vrefresh(const struct drm_display_mode *mode);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Jan 7 (drivers/gpu/drm/imx/parallel-display.o)
On Fri, 2021-01-08 at 10:03 +0100, Daniel Vetter wrote: > On Fri, Jan 8, 2021 at 9:55 AM Randy Dunlap wrote: > > On 1/6/21 7:01 PM, Stephen Rothwell wrote: > > > Hi all, > > > > > > Changes since 20210106: > > > > > > > on x86_64: > > > > ld: drivers/gpu/drm/imx/parallel-display.o: in function > > `imx_pd_connector_get_modes': > > parallel-display.c:(.text+0x8d): undefined reference to > > `of_get_drm_display_mode' > > Probably something in the pull from philipp that I just merged > yesterday. That is likely, although I'm not quite sure how that activated, the of_get_drm_display_mode call was there before. > Philip, can you pls take care? > -Daniel Thank you for the notice, since the of_get_drm_display_mode() is only for legacy device trees I'd like to stub it out and keep compile test coverage: https://lore.kernel.org/dri-devel/20210108101343.23695-1-p.za...@pengutronix.de/T/#u regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm/connector: Set the default callback function for drm_connector_funcs
On Fri, 08 Jan 2021, Thomas Zimmermann wrote: > Drivers cannot legally declare the funcs instance as static const. > Having static const allows for write protected pages. This. I've done quite a bit of refactoring all over the place to be ablet to move to the complete opposite direction. We want to keep all callback structs static const. If the idea here was good (on which I'm inclined to side with Thomas and Daniel that it isn't), the way to go would be to add a small wrapper for calling ->fill_modes(), with a different path for when it's NULL. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] topic/dp-hdmi-2.1-pcon for drm-misc-next
On Thu, 07 Jan 2021, Daniel Vetter wrote: > On Wed, Dec 23, 2020 at 10:14:58AM +0200, Jani Nikula wrote: >> >> Hi Maarten, Maxime, and Thomas - >> >> Here's the DP-HDMI2.1 PCON support topic pull consisting of the series >> [1]. The series is split roughly 50-50 between drm helpers and i915, so >> a topic branch seemed to be the right way to go. >> >> I'll also pull this to drm-intel-next once you've merged to >> drm-misc-next. > > I didn't see this merged into drm-misc-next, so pulled into drm-next. I'm > processing an entire batch of pulls, I'll ping you on irc when it's all > ready for backmerging. Thanks, Rodrigo covered the backmerge. BR, Jani. > > Cheers, Daniel > >> >> BR, >> Jani. >> >> >> [1] https://patchwork.freedesktop.org/series/82098/ >> >> >> topic/dp-hdmi-2.1-pcon-2020-12-23: >> Add support for DP-HDMI2.1 PCON >> >> From the series cover letter: >> >> This patch series attempts to add support for a DP-HDMI2.1 Protocol >> Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata >> E5 to DisplayPort_v2.0: >> https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid=42299 >> The details are mentioned in: >> VESA DP-to-HDMI PCON Specification Standalone Document >> https://groups.vesa.org/wg/DP/document/15651 >> >> This series starts with adding support for FRL (Fixed Rate Link) >> Training between the PCON and HDMI2.1 sink. >> As per HDMI2.1 specification, a new data-channel or lane is added in >> FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher >> bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4 >> lanes). >> >> With these patches, the HDMI2.1 PCON can be configured to achieve FRL >> training based on the maximum FRL rate supported by the panel, source >> and the PCON. >> The approach is to add the support for FRL training between PCON and >> HDMI2.1 sink and gradually add other blocks for supporting higher >> resolutions and other HDMI2.1 features, that can be supported by pcon >> for the sources that do not natively support HDMI2.1. >> >> This is done before the DP Link training between the source and PCON >> is started. In case of FRL training is not achieved, the PCON will >> work in the regular TMDS mode, without HDMI2.1 feature support. >> Any interruption in FRL training between the PCON and HDMI2.1 sink is >> notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD >> registers are read and FRL training is re-attempted. >> >> Currently, we have tested the FRL training and are able to enable 4K >> display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting >> panel. >> >> The following changes since commit b3bf99daaee96a141536ce5c60a0d6dba6ec1d23: >> >> drm/i915/display: Defer initial modeset until after GGTT is initialised >> (2020-11-26 11:01:52 +) >> >> are available in the Git repository at: >> >> git://anongit.freedesktop.org/drm/drm-intel >> tags/topic/dp-hdmi-2.1-pcon-2020-12-23 >> >> for you to fetch changes up to 522508b665df3bbfdf40381d4e61777844b1703f: >> >> drm/i915/display: Let PCON convert from RGB to YCbCr if it can (2020-12-22 >> 17:59:07 +0200) >> >> >> Add support for DP-HDMI2.1 PCON >> >> From the series cover letter: >> >> This patch series attempts to add support for a DP-HDMI2.1 Protocol >> Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata >> E5 to DisplayPort_v2.0: >> https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid=42299 >> The details are mentioned in: >> VESA DP-to-HDMI PCON Specification Standalone Document >> https://groups.vesa.org/wg/DP/document/15651 >> >> This series starts with adding support for FRL (Fixed Rate Link) >> Training between the PCON and HDMI2.1 sink. >> As per HDMI2.1 specification, a new data-channel or lane is added in >> FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher >> bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4 >> lanes). >> >> With these patches, the HDMI2.1 PCON can be configured to achieve FRL >> training based on the maximum FRL rate supported by the panel, source >> and the PCON. >> The approach is to add the support for FRL training between PCON and >> HDMI2.1 sink and gradually add other blocks for supporting higher >> resolutions and other HDMI2.1 features, that can be supported by pcon >> for the sources that do not natively support HDMI2.1. >> >> This is done before the DP Link training between the source and PCON >> is started. In case of FRL training is not achieved, the PCON will >> work in the regular TMDS mode, without HDMI2.1 feature support. >> Any interruption in FRL training between the PCON and HDMI2.1 sink is >> notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD >> registers are read and FRL training is re-attempted. >> >> Currently, we have tested the FRL training and are able to enable 4K >> display with TG
[PATCH 1/3] drm/vc4: Use drm_gem_cma_vmap() directly
Validated shaders cannot be exported. There's no need for testing this in
the BO's vmap implementation. Call drm_gem_cma_vmap() directly instead.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_bo.c | 14 +-
drivers/gpu/drm/vc4/vc4_drv.h | 1 -
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index dc316cb79e00..eff12be616b0 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -386,7 +386,7 @@ static const struct drm_gem_object_funcs
vc4_gem_object_funcs = {
.free = vc4_free_object,
.export = vc4_prime_export,
.get_sg_table = drm_gem_cma_get_sg_table,
- .vmap = vc4_prime_vmap,
+ .vmap = drm_gem_cma_vmap,
.vm_ops = &vc4_vm_ops,
};
@@ -785,18 +785,6 @@ int vc4_prime_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
return drm_gem_prime_mmap(obj, vma);
}
-int vc4_prime_vmap(struct drm_gem_object *obj, struct dma_buf_map *map)
-{
- struct vc4_bo *bo = to_vc4_bo(obj);
-
- if (bo->validated_shader) {
- DRM_DEBUG("mmaping of shader BOs not allowed.\n");
- return -EINVAL;
- }
-
- return drm_gem_cma_vmap(obj, map);
-}
-
struct drm_gem_object *
vc4_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 051ad4e31e52..61848c6f85ad 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -808,7 +808,6 @@ int vc4_prime_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma);
struct drm_gem_object *vc4_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment
*attach,
struct sg_table *sgt);
-int vc4_prime_vmap(struct drm_gem_object *obj, struct dma_buf_map *map);
int vc4_bo_cache_init(struct drm_device *dev);
int vc4_bo_inc_usecnt(struct vc4_bo *bo);
void vc4_bo_dec_usecnt(struct vc4_bo *bo);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/vc4: Move mmap implementation into GEM object function
Moving vc4's mmap code from vc4_mmap() into a GEM object function
allows for the use drm_gem_mmap() and drm_gem_prime_mmap(). The content
of vc4_drm_fpos can then be generated by DEFINE_DRM_GEM_FOPS().
The actual mmap implementation is just a check if the BO is a validated
shader plus the default CMA mmap code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_bo.c | 55 +++
drivers/gpu/drm/vc4/vc4_drv.c | 14 ++---
drivers/gpu/drm/vc4/vc4_drv.h | 2 --
3 files changed, 6 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index f9b42ff098e3..28e48ef2d295 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -704,19 +704,9 @@ static vm_fault_t vc4_fault(struct vm_fault *vmf)
return VM_FAULT_SIGBUS;
}
-int vc4_mmap(struct file *filp, struct vm_area_struct *vma)
+static int vc4_gem_object_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
{
- struct drm_gem_object *gem_obj;
- unsigned long vm_pgoff;
- struct vc4_bo *bo;
- int ret;
-
- ret = drm_gem_mmap(filp, vma);
- if (ret)
- return ret;
-
- gem_obj = vma->vm_private_data;
- bo = to_vc4_bo(gem_obj);
+ struct vc4_bo *bo = to_vc4_bo(obj);
if (bo->validated_shader && (vma->vm_flags & VM_WRITE)) {
DRM_DEBUG("mmaping of shader BOs for writing not allowed.\n");
@@ -730,45 +720,7 @@ int vc4_mmap(struct file *filp, struct vm_area_struct *vma)
return -EINVAL;
}
- /*
-* Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
-* vm_pgoff (used as a fake buffer offset by DRM) to 0 as we want to map
-* the whole buffer.
-*/
- vma->vm_flags &= ~VM_PFNMAP;
-
- /* This ->vm_pgoff dance is needed to make all parties happy:
-* - dma_mmap_wc() uses ->vm_pgoff as an offset within the allocated
-* mem-region, hence the need to set it to zero (the value set by
-* the DRM core is a virtual offset encoding the GEM object-id)
-* - the mmap() core logic needs ->vm_pgoff to be restored to its
-* initial value before returning from this function because it
-* encodes the offset of this GEM in the dev->anon_inode pseudo-file
-* and this information will be used when we invalidate userspace
-* mappings with drm_vma_node_unmap() (called from vc4_gem_purge()).
-*/
- vm_pgoff = vma->vm_pgoff;
- vma->vm_pgoff = 0;
- ret = dma_mmap_wc(bo->base.base.dev->dev, vma, bo->base.vaddr,
- bo->base.paddr, vma->vm_end - vma->vm_start);
- vma->vm_pgoff = vm_pgoff;
-
- if (ret)
- drm_gem_vm_close(vma);
-
- return ret;
-}
-
-int vc4_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
-{
- struct vc4_bo *bo = to_vc4_bo(obj);
-
- if (bo->validated_shader && (vma->vm_flags & VM_WRITE)) {
- DRM_DEBUG("mmaping of shader BOs for writing not allowed.\n");
- return -EINVAL;
- }
-
- return drm_gem_prime_mmap(obj, vma);
+ return drm_gem_cma_mmap(obj, vma);
}
static const struct vm_operations_struct vc4_vm_ops = {
@@ -782,6 +734,7 @@ static const struct drm_gem_object_funcs
vc4_gem_object_funcs = {
.export = vc4_prime_export,
.get_sg_table = drm_gem_cma_get_sg_table,
.vmap = drm_gem_cma_vmap,
+ .mmap = vc4_gem_object_mmap,
.vm_ops = &vc4_vm_ops,
};
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 2cd97a39c286..d9b3bba7f2b7 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -140,17 +140,7 @@ static void vc4_close(struct drm_device *dev, struct
drm_file *file)
kfree(vc4file);
}
-static const struct file_operations vc4_drm_fops = {
- .owner = THIS_MODULE,
- .open = drm_open,
- .release = drm_release,
- .unlocked_ioctl = drm_ioctl,
- .mmap = vc4_mmap,
- .poll = drm_poll,
- .read = drm_read,
- .compat_ioctl = drm_compat_ioctl,
- .llseek = noop_llseek,
-};
+DEFINE_DRM_GEM_FOPS(vc4_drm_fops);
static const struct drm_ioctl_desc vc4_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(VC4_SUBMIT_CL, vc4_submit_cl_ioctl, DRM_RENDER_ALLOW),
@@ -193,7 +183,7 @@ static struct drm_driver vc4_drm_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = vc4_prime_import_sg_table,
- .gem_prime_mmap = vc4_prime_mmap,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.dumb_create = vc4_dumb_create,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index a3d8d87fe355..0d9c0ecc4769 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -801
[PATCH 2/3] drm/vc4: Make several BO functions static
Rearrange the code to make BO functions static. This will also help
with streamlining the BO's mmap implementation.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_bo.c | 34 +-
drivers/gpu/drm/vc4/vc4_drv.h | 2 --
2 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index eff12be616b0..f9b42ff098e3 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -21,7 +21,7 @@
#include "vc4_drv.h"
#include "uapi/drm/vc4_drm.h"
-static vm_fault_t vc4_fault(struct vm_fault *vmf);
+static const struct drm_gem_object_funcs vc4_gem_object_funcs;
static const char * const bo_type_names[] = {
"kernel",
@@ -376,20 +376,6 @@ static struct vc4_bo *vc4_bo_get_from_cache(struct
drm_device *dev,
return bo;
}
-static const struct vm_operations_struct vc4_vm_ops = {
- .fault = vc4_fault,
- .open = drm_gem_vm_open,
- .close = drm_gem_vm_close,
-};
-
-static const struct drm_gem_object_funcs vc4_gem_object_funcs = {
- .free = vc4_free_object,
- .export = vc4_prime_export,
- .get_sg_table = drm_gem_cma_get_sg_table,
- .vmap = drm_gem_cma_vmap,
- .vm_ops = &vc4_vm_ops,
-};
-
/**
* vc4_create_object - Implementation of driver->gem_create_object.
* @dev: DRM device
@@ -538,7 +524,7 @@ static void vc4_bo_cache_free_old(struct drm_device *dev)
/* Called on the last userspace/kernel unreference of the BO. Returns
* it to the BO cache if possible, otherwise frees it.
*/
-void vc4_free_object(struct drm_gem_object *gem_bo)
+static void vc4_free_object(struct drm_gem_object *gem_bo)
{
struct drm_device *dev = gem_bo->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
@@ -673,7 +659,7 @@ static void vc4_bo_cache_time_timer(struct timer_list *t)
schedule_work(&vc4->bo_cache.time_work);
}
-struct dma_buf * vc4_prime_export(struct drm_gem_object *obj, int flags)
+static struct dma_buf *vc4_prime_export(struct drm_gem_object *obj, int flags)
{
struct vc4_bo *bo = to_vc4_bo(obj);
struct dma_buf *dmabuf;
@@ -785,6 +771,20 @@ int vc4_prime_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
return drm_gem_prime_mmap(obj, vma);
}
+static const struct vm_operations_struct vc4_vm_ops = {
+ .fault = vc4_fault,
+ .open = drm_gem_vm_open,
+ .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs vc4_gem_object_funcs = {
+ .free = vc4_free_object,
+ .export = vc4_prime_export,
+ .get_sg_table = drm_gem_cma_get_sg_table,
+ .vmap = drm_gem_cma_vmap,
+ .vm_ops = &vc4_vm_ops,
+};
+
struct drm_gem_object *
vc4_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 61848c6f85ad..a3d8d87fe355 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -782,13 +782,11 @@ struct vc4_validated_shader_info {
/* vc4_bo.c */
struct drm_gem_object *vc4_create_object(struct drm_device *dev, size_t size);
-void vc4_free_object(struct drm_gem_object *gem_obj);
struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t size,
bool from_cache, enum vc4_kernel_bo_type type);
int vc4_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-struct dma_buf *vc4_prime_export(struct drm_gem_object *obj, int flags);
int vc4_create_bo_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int vc4_create_shader_bo_ioctl(struct drm_device *dev, void *data,
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/vc4: Streamline the vmap and mmap code
Daniel recently pointed out that vc4 has test in it's vmap code that cannot really fail. [1] I took the opportunity to cleanup vc'4 vmap and mmap implementations. The patches got smoke-tested by running fbdev and Xorg on an RPi3. [1] https://lore.kernel.org/dri-devel/20201211094000.GK401619@phenom.ffwll.local/ Thomas Zimmermann (3): drm/vc4: Use drm_gem_cma_vmap() directly drm/vc4: Make several BO functions static drm/vc4: Move mmap implementation into GEM object function drivers/gpu/drm/vc4/vc4_bo.c | 97 +++ drivers/gpu/drm/vc4/vc4_drv.c | 14 + drivers/gpu/drm/vc4/vc4_drv.h | 5 -- 3 files changed, 21 insertions(+), 95 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Hey Christian, just a ping.
Andrey
On 1/7/21 11:37 AM, Andrey Grodzovsky wrote:
On 1/7/21 11:30 AM, Daniel Vetter wrote:
On Thu, Jan 07, 2021 at 11:26:52AM -0500, Andrey Grodzovsky wrote:
On 1/7/21 11:21 AM, Daniel Vetter wrote:
On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote:
On 11/23/20 3:01 AM, Christian König wrote:
Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky:
On 11/21/20 9:15 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Uff, one page for each exported DMA-buf? That's not something we can do.
We need to find a different approach here.
Can't we call alloc_page() on each fault and link them together
so they are freed when the device is finally reaped?
For sure better to optimize and allocate on demand when we reach
this corner case, but why the linking ?
Shouldn't drm_prime_gem_destroy be good enough place to free ?
I want to avoid keeping the page in the GEM object.
What we can do is to allocate a page on demand for each fault and link
the together in the bdev instead.
And when the bdev is then finally destroyed after the last application
closed we can finally release all of them.
Christian.
Hey, started to implement this and then realized that by allocating a page
for each fault indiscriminately
we will be allocating a new page for each faulting virtual address within a
VA range belonging the same BO
and this is obviously too much and not the intention. Should I instead use
let's say a hashtable with the hash
key being faulting BO address to actually keep allocating and reusing same
dummy zero page per GEM BO
(or for that matter DRM file object address for non imported BOs) ?
Why do we need a hashtable? All the sw structures to track this should
still be around:
- if gem_bo->dma_buf is set the buffer is currently exported as a dma-buf,
so defensively allocate a per-bo page
- otherwise allocate a per-file page
That exactly what we have in current implementation
Or is the idea to save the struct page * pointer? That feels a bit like
over-optimizing stuff. Better to have a simple implementation first and
then tune it if (and only if) any part of it becomes a problem for normal
usage.
Exactly - the idea is to avoid adding extra pointer to drm_gem_object,
Christian suggested to instead keep a linked list of dummy pages to be
allocated on demand once we hit a vm_fault. I will then also prefault the
entire
VA range from vma->vm_end - vma->vm_start to vma->vm_end and map them
to that single dummy page.
This strongly feels like premature optimization. If you're worried about
the overhead on amdgpu, pay down the debt by removing one of the redundant
pointers between gem and ttm bo structs (I think we still have some) :-)
Until we've nuked these easy&obvious ones we shouldn't play "avoid 1
pointer just because" games with hashtables.
-Daniel
Well, if you and Christian can agree on this approach and suggest maybe what
pointer is
redundant and can be removed from GEM struct so we can use the 'credit' to add
the dummy page
to GEM I will be happy to follow through.
P.S Hash table is off the table anyway and we are talking only about linked
list here since by prefaulting
the entire VA range for a vmf->vma i will be avoiding redundant page faults to
same VMA VA range and so
don't need to search and reuse an existing dummy page but simply create a new
one for each next fault.
Andrey
Andrey
-Daniel
Andrey
Andrey
Regards,
Christian.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_file.c | 8
drivers/gpu/drm/drm_prime.c | 10 ++
include/drm/drm_file.h | 2 ++
include/drm/drm_gem.h | 2 ++
4 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 0ac4566..ff3d39f 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -193,6 +193,12 @@ struct drm_file *drm_file_alloc(struct drm_minor
*minor)
goto out_prime_destroy;
}
+ file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!file->dummy_page) {
+ ret = -ENOMEM;
+ goto out_prime_destroy;
+ }
+
return file;
out_prime_destroy:
@@ -289,6 +295,8 @@ void drm_file_free(struct drm_file *file)
if (dev->driver->postclose)
dev->driver->postclose(dev, file);
+ __free_page(file->dummy_page);
+
drm_prime_destroy_file_private(&file->prime);
WARN_ON(!list_empty(&file->event_list));
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1693aa7..987b45c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device
*dev,
ret = drm_prime_add_buf_handle(&file_priv->prime,
dma_buf, *handle);
+
+ if (!ret) {
+ obj->dummy_page = alloc_page
Re: [PATCH 1/2] drm/radeon: stop re-init the TTM page pool
On Thu, Jan 07, 2021 at 09:08:29PM +0100, Christian König wrote:
> Am 07.01.21 um 19:07 schrieb Daniel Vetter:
> > On Tue, Jan 05, 2021 at 07:23:08PM +0100, Christian König wrote:
> > > Drivers are not supposed to init the page pool directly any more.
> > >
> > > Signed-off-by: Christian König
> > Please include reported-by credits and link to the bug reports on
> > lore.kernel.org when merging this. Also I guess this should have a Fixes:
> > line?
>
> I'm not aware of a bug report, but the reported-by/Fixes lines are indeed
> missing.
This one here:
https://lore.kernel.org/dri-devel/20201231104020.ga4...@zn.tnic/
Or did I get confused, and the above is yet another bug?
> BTW: Any idea why dim add-link doesn't work?
Hm we occasionally have fun with email parsing (it's hard) and especially
python changes in how encodings are handled differently between python2
and python3. If you have a specific example I can try and take a look why
it doesn't work.
-Daniel
> > And maybe some words on how/why stuff blows up.
>
> Just a typo. I've forgot to remove two lines in radeon while rebasing and
> still had the symbols exported so never noticed this.
>
> Christian.
>
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/radeon/radeon_ttm.c | 3 ---
> > > 1 file changed, 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> > > b/drivers/gpu/drm/radeon/radeon_ttm.c
> > > index d4328ff57757..35b715f82ed8 100644
> > > --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> > > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> > > @@ -729,9 +729,6 @@ int radeon_ttm_init(struct radeon_device *rdev)
> > > }
> > > rdev->mman.initialized = true;
> > > - ttm_pool_init(&rdev->mman.bdev.pool, rdev->dev, rdev->need_swiotlb,
> > > - dma_addressing_limited(&rdev->pdev->dev));
> > > -
> > > r = radeon_ttm_init_vram(rdev);
> > > if (r) {
> > > DRM_ERROR("Failed initializing VRAM heap.\n");
> > > --
> > > 2.25.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Am 08.01.21 um 15:26 schrieb Andrey Grodzovsky: Hey Christian, just a ping. Was there any question for me here? As far as I can see the best approach would still be to fill the VMA with a single dummy page and avoid pointers in the GEM object. Christian. Andrey On 1/7/21 11:37 AM, Andrey Grodzovsky wrote: On 1/7/21 11:30 AM, Daniel Vetter wrote: On Thu, Jan 07, 2021 at 11:26:52AM -0500, Andrey Grodzovsky wrote: On 1/7/21 11:21 AM, Daniel Vetter wrote: On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote: On 11/23/20 3:01 AM, Christian König wrote: Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky: On 11/21/20 9:15 AM, Christian König wrote: Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: Will be used to reroute CPU mapped BO's page faults once device is removed. Uff, one page for each exported DMA-buf? That's not something we can do. We need to find a different approach here. Can't we call alloc_page() on each fault and link them together so they are freed when the device is finally reaped? For sure better to optimize and allocate on demand when we reach this corner case, but why the linking ? Shouldn't drm_prime_gem_destroy be good enough place to free ? I want to avoid keeping the page in the GEM object. What we can do is to allocate a page on demand for each fault and link the together in the bdev instead. And when the bdev is then finally destroyed after the last application closed we can finally release all of them. Christian. Hey, started to implement this and then realized that by allocating a page for each fault indiscriminately we will be allocating a new page for each faulting virtual address within a VA range belonging the same BO and this is obviously too much and not the intention. Should I instead use let's say a hashtable with the hash key being faulting BO address to actually keep allocating and reusing same dummy zero page per GEM BO (or for that matter DRM file object address for non imported BOs) ? Why do we need a hashtable? All the sw structures to track this should still be around: - if gem_bo->dma_buf is set the buffer is currently exported as a dma-buf, so defensively allocate a per-bo page - otherwise allocate a per-file page That exactly what we have in current implementation Or is the idea to save the struct page * pointer? That feels a bit like over-optimizing stuff. Better to have a simple implementation first and then tune it if (and only if) any part of it becomes a problem for normal usage. Exactly - the idea is to avoid adding extra pointer to drm_gem_object, Christian suggested to instead keep a linked list of dummy pages to be allocated on demand once we hit a vm_fault. I will then also prefault the entire VA range from vma->vm_end - vma->vm_start to vma->vm_end and map them to that single dummy page. This strongly feels like premature optimization. If you're worried about the overhead on amdgpu, pay down the debt by removing one of the redundant pointers between gem and ttm bo structs (I think we still have some) :-) Until we've nuked these easy&obvious ones we shouldn't play "avoid 1 pointer just because" games with hashtables. -Daniel Well, if you and Christian can agree on this approach and suggest maybe what pointer is redundant and can be removed from GEM struct so we can use the 'credit' to add the dummy page to GEM I will be happy to follow through. P.S Hash table is off the table anyway and we are talking only about linked list here since by prefaulting the entire VA range for a vmf->vma i will be avoiding redundant page faults to same VMA VA range and so don't need to search and reuse an existing dummy page but simply create a new one for each next fault. Andrey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: stop re-init the TTM page pool
Am 08.01.21 um 15:31 schrieb Daniel Vetter:
On Thu, Jan 07, 2021 at 09:08:29PM +0100, Christian König wrote:
Am 07.01.21 um 19:07 schrieb Daniel Vetter:
On Tue, Jan 05, 2021 at 07:23:08PM +0100, Christian König wrote:
Drivers are not supposed to init the page pool directly any more.
Signed-off-by: Christian König
Please include reported-by credits and link to the bug reports on
lore.kernel.org when merging this. Also I guess this should have a Fixes:
line?
I'm not aware of a bug report, but the reported-by/Fixes lines are indeed
missing.
This one here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20201231104020.GA4504%40zn.tnic%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C3aede203348b4f32ea3108d8b3e224ec%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637457131179258488%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bHVw4lj1f8g4ohVTeuKNkb0LAbLwY6N4KWortr3VtAo%3D&reserved=0
Or did I get confused, and the above is yet another bug?
Yeah, but that was just reported by mail. The bug tracker I've saw was
opened after the patch was already pushed.
BTW: Any idea why dim add-link doesn't work?
Hm we occasionally have fun with email parsing (it's hard) and especially
python changes in how encodings are handled differently between python2
and python3. If you have a specific example I can try and take a look why
it doesn't work.
It just looks up and doesn't seem to do anything. I'm not familiar with
python so I can just describe the symptoms.
Christian.
-Daniel
And maybe some words on how/why stuff blows up.
Just a typo. I've forgot to remove two lines in radeon while rebasing and
still had the symbols exported so never noticed this.
Christian.
-Daniel
---
drivers/gpu/drm/radeon/radeon_ttm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index d4328ff57757..35b715f82ed8 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -729,9 +729,6 @@ int radeon_ttm_init(struct radeon_device *rdev)
}
rdev->mman.initialized = true;
- ttm_pool_init(&rdev->mman.bdev.pool, rdev->dev, rdev->need_swiotlb,
- dma_addressing_limited(&rdev->pdev->dev));
-
r = radeon_ttm_init_vram(rdev);
if (r) {
DRM_ERROR("Failed initializing VRAM heap.\n");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7Cchristian.koenig%40amd.com%7C3aede203348b4f32ea3108d8b3e224ec%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637457131179258488%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pHzuAsJcXf5HlAfJ7wYYc%2BsizZhSLBGWXBhCyVNRCfo%3D&reserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD
On Thu, Jan 07, 2021 at 11:25:41AM -0500, Felix Kuehling wrote: > Am 2021-01-07 um 4:23 a.m. schrieb Daniel Vetter: > > On Wed, Jan 06, 2021 at 10:00:52PM -0500, Felix Kuehling wrote: > >> This is the first version of our HMM based shared virtual memory manager > >> for KFD. There are still a number of known issues that we're working > >> through > >> (see below). This will likely lead to some pretty significant changes in > >> MMU notifier handling and locking on the migration code paths. So don't > >> get hung up on those details yet. > >> > >> But I think this is a good time to start getting feedback. We're pretty > >> confident about the ioctl API, which is both simple and extensible for the > >> future. (see patches 4,16) The user mode side of the API can be found here: > >> https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/fxkamd/hmm-wip/src/svm.c > >> > >> I'd also like another pair of eyes on how we're interfacing with the GPU VM > >> code in amdgpu_vm.c (see patches 12,13), retry page fault handling (24,25), > >> and some retry IRQ handling changes (32). > >> > >> > >> Known issues: > >> * won't work with IOMMU enabled, we need to dma_map all pages properly > >> * still working on some race conditions and random bugs > >> * performance is not great yet > > Still catching up, but I think there's another one for your list: > > > > * hmm gpu context preempt vs page fault handling. I've had a short > >discussion about this one with Christian before the holidays, and also > >some private chats with Jerome. It's nasty since no easy fix, much less > >a good idea what's the best approach here. > > Do you have a pointer to that discussion or any more details? Essentially if you're handling an hmm page fault from the gpu, you can deadlock by calling dma_fence_wait on a (chain of, possibly) other command submissions or compute contexts with dma_fence_wait. Which deadlocks if you can't preempt while you have that page fault pending. Two solutions: - your hw can (at least for compute ctx) preempt even when a page fault is pending - lots of screaming in trying to come up with an alternate solution. They all suck. Note that the dma_fence_wait is hard requirement, because we need that for mmu notifiers and shrinkers, disallowing that would disable dynamic memory management. Which is the current "ttm is self-limited to 50% of system memory" limitation Christian is trying to lift. So that's really not a restriction we can lift, at least not in upstream where we need to also support old style hardware which doesn't have page fault support and really has no other option to handle memory management than dma_fence_wait. Thread was here: https://lore.kernel.org/dri-devel/CAKMK7uGgoeF8LmFBwWh5mW1k4xWjuUh3hdSFpVH1NBM7K0=e...@mail.gmail.com/ There's a few ways to resolve this (without having preempt-capable hardware), but they're all supremely nasty. -Daniel > > Thanks, > Felix > > > > > > I'll try to look at this more in-depth when I'm catching up on mails. > > -Daniel > > > >> Alex Sierra (12): > >> drm/amdgpu: replace per_device_list by array > >> drm/amdkfd: helper to convert gpu id and idx > >> drm/amdkfd: add xnack enabled flag to kfd_process > >> drm/amdkfd: add ioctl to configure and query xnack retries > >> drm/amdkfd: invalidate tables on page retry fault > >> drm/amdkfd: page table restore through svm API > >> drm/amdkfd: SVM API call to restore page tables > >> drm/amdkfd: add svm_bo reference for eviction fence > >> drm/amdgpu: add param bit flag to create SVM BOs > >> drm/amdkfd: add svm_bo eviction mechanism support > >> drm/amdgpu: svm bo enable_signal call condition > >> drm/amdgpu: add svm_bo eviction to enable_signal cb > >> > >> Philip Yang (23): > >> drm/amdkfd: select kernel DEVICE_PRIVATE option > >> drm/amdkfd: add svm ioctl API > >> drm/amdkfd: Add SVM API support capability bits > >> drm/amdkfd: register svm range > >> drm/amdkfd: add svm ioctl GET_ATTR op > >> drm/amdgpu: add common HMM get pages function > >> drm/amdkfd: validate svm range system memory > >> drm/amdkfd: register overlap system memory range > >> drm/amdkfd: deregister svm range > >> drm/amdgpu: export vm update mapping interface > >> drm/amdkfd: map svm range to GPUs > >> drm/amdkfd: svm range eviction and restore > >> drm/amdkfd: register HMM device private zone > >> drm/amdkfd: validate vram svm range from TTM > >> drm/amdkfd: support xgmi same hive mapping > >> drm/amdkfd: copy memory through gart table > >> drm/amdkfd: HMM migrate ram to vram > >> drm/amdkfd: HMM migrate vram to ram > >> drm/amdgpu: reserve fence slot to update page table > >> drm/amdgpu: enable retry fault wptr overflow > >> drm/amdkfd: refine migration policy with xnack on > >> drm/amdkfd: add svm range validate timestamp > >> drm/amdkfd: multiple gpu migrate vram to vram > >> > >> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c|3 + > >> d
Re: [PATCH 0/3] Revert "drm/amd/display: Expose new CRC window property" and changes associated with this commit
On Thu, Jan 07, 2021 at 03:53:18PM -0500, Rodrigo Siqueira wrote: > Hi, > > A couple of weeks ago, Daniel highlighted [1] some issue related to a > patch entitle "drm/amd/display: Expose new CRC window property". After > discussion, we realize that we can revert that patch because we will > need to create a debugfs or full UAPI for CRC soon, which will make this > code obsolete. We got two other patches related to this same code; for > this reason, this patchset reverts all changes associated with that > specific commit. > > Cc: Wayne Lin > Cc: Alexander Deucher > Cc: Harry Wentland > Cc: Roman Li > Cc: Bindu R > Cc: Daniel Vetter > > 1. https://www.spinics.net/lists/dri-devel/msg283767.html Thanks for taking care of this. Since it's not super pressing I'll leave it to Alex for merging with the usual -fixes pull request train next week. Acked-by: Daniel Vetter Cheers, Daniel > > Thanks > > Rodrigo Siqueira (3): > Revert "drm/amd/display: Fix unused variable warning" > Revert "drm/amdgpu/disply: fix documentation warnings in display > manager" > Revert "drm/amd/display: Expose new CRC window property" > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 142 ++ > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 38 - > .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 56 +-- > .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 5 +- > drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 + > 5 files changed, 14 insertions(+), 229 deletions(-) > > -- > 2.25.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/modes: add non-OF stub for of_get_drm_display_mode
On Fri, Jan 08, 2021 at 11:13:43AM +0100, Philipp Zabel wrote:
> If CONFIG_OF is disabled, of_get_drm_display_mode is not compiled in,
> and drivers using it fail to build:
>
> ld: drivers/gpu/drm/imx/parallel-display.o: in function
> `imx_pd_connector_get_modes':
> parallel-display.c:(.text+0x8d): undefined reference to
> `of_get_drm_display_mode'
>
> Add an inline stub so they can be build-tested with non-OF
> configurations.
>
> Reported-by: Randy Dunlap
> Signed-off-by: Philipp Zabel
Makes sense, we have dummy functions for !CONFIG_OF for all the others
already.
Reviewed-by: Daniel Vetter
Cheers, Daniel
> ---
> include/drm/drm_modes.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index a0d79d1c51e2..29ba4adf0c53 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -461,9 +461,19 @@ void drm_display_mode_from_videomode(const struct
> videomode *vm,
> void drm_display_mode_to_videomode(const struct drm_display_mode *dmode,
> struct videomode *vm);
> void drm_bus_flags_from_videomode(const struct videomode *vm, u32
> *bus_flags);
> +
> +#if defined(CONFIG_OF)
> int of_get_drm_display_mode(struct device_node *np,
> struct drm_display_mode *dmode, u32 *bus_flags,
> int index);
> +#else
> +static inline int of_get_drm_display_mode(struct device_node *np,
> + struct drm_display_mode *dmode,
> + u32 *bus_flags, int index)
> +{
> + return -EINVAL;
> +}
> +#endif
>
> void drm_mode_set_name(struct drm_display_mode *mode);
> int drm_mode_vrefresh(const struct drm_display_mode *mode);
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/hisilicon: Delete the empty function mode_valid
On Fri, Jan 08, 2021 at 06:41:05PM +0800, Tian Tao wrote:
> Based on the drm_connector_mode_valid, if the hibmc implementation
> of mode_valid only returns MODE_OK, then we can not implement the
s/can not/need not/
> mode_valid function.
>
> Signed-off-by: Tian Tao
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> index c76f996..c74a35b 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> @@ -43,12 +43,6 @@ static int hibmc_connector_get_modes(struct drm_connector
> *connector)
> return count;
> }
>
> -static enum drm_mode_status hibmc_connector_mode_valid(struct drm_connector
> *connector,
> -struct drm_display_mode
> *mode)
> -{
> - return MODE_OK;
> -}
> -
> static void hibmc_connector_destroy(struct drm_connector *connector)
> {
> struct hibmc_connector *hibmc_connector = to_hibmc_connector(connector);
> @@ -60,7 +54,6 @@ static void hibmc_connector_destroy(struct drm_connector
> *connector)
> static const struct drm_connector_helper_funcs
> hibmc_connector_helper_funcs = {
> .get_modes = hibmc_connector_get_modes,
> - .mode_valid = hibmc_connector_mode_valid,
> };
>
> static const struct drm_connector_funcs hibmc_connector_funcs = {
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD
Am 08.01.21 um 15:40 schrieb Daniel Vetter: On Thu, Jan 07, 2021 at 11:25:41AM -0500, Felix Kuehling wrote: Am 2021-01-07 um 4:23 a.m. schrieb Daniel Vetter: On Wed, Jan 06, 2021 at 10:00:52PM -0500, Felix Kuehling wrote: This is the first version of our HMM based shared virtual memory manager for KFD. There are still a number of known issues that we're working through (see below). This will likely lead to some pretty significant changes in MMU notifier handling and locking on the migration code paths. So don't get hung up on those details yet. But I think this is a good time to start getting feedback. We're pretty confident about the ioctl API, which is both simple and extensible for the future. (see patches 4,16) The user mode side of the API can be found here: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/fxkamd/hmm-wip/src/svm.c I'd also like another pair of eyes on how we're interfacing with the GPU VM code in amdgpu_vm.c (see patches 12,13), retry page fault handling (24,25), and some retry IRQ handling changes (32). Known issues: * won't work with IOMMU enabled, we need to dma_map all pages properly * still working on some race conditions and random bugs * performance is not great yet Still catching up, but I think there's another one for your list: * hmm gpu context preempt vs page fault handling. I've had a short discussion about this one with Christian before the holidays, and also some private chats with Jerome. It's nasty since no easy fix, much less a good idea what's the best approach here. Do you have a pointer to that discussion or any more details? Essentially if you're handling an hmm page fault from the gpu, you can deadlock by calling dma_fence_wait on a (chain of, possibly) other command submissions or compute contexts with dma_fence_wait. Which deadlocks if you can't preempt while you have that page fault pending. Two solutions: - your hw can (at least for compute ctx) preempt even when a page fault is pending - lots of screaming in trying to come up with an alternate solution. They all suck. Note that the dma_fence_wait is hard requirement, because we need that for mmu notifiers and shrinkers, disallowing that would disable dynamic memory management. Which is the current "ttm is self-limited to 50% of system memory" limitation Christian is trying to lift. So that's really not a restriction we can lift, at least not in upstream where we need to also support old style hardware which doesn't have page fault support and really has no other option to handle memory management than dma_fence_wait. Thread was here: https://lore.kernel.org/dri-devel/CAKMK7uGgoeF8LmFBwWh5mW1k4xWjuUh3hdSFpVH1NBM7K0=e...@mail.gmail.com/ There's a few ways to resolve this (without having preempt-capable hardware), but they're all supremely nasty. -Daniel Thanks, Felix I'll try to look at this more in-depth when I'm catching up on mails. -Daniel Alex Sierra (12): drm/amdgpu: replace per_device_list by array drm/amdkfd: helper to convert gpu id and idx drm/amdkfd: add xnack enabled flag to kfd_process drm/amdkfd: add ioctl to configure and query xnack retries drm/amdkfd: invalidate tables on page retry fault drm/amdkfd: page table restore through svm API drm/amdkfd: SVM API call to restore page tables drm/amdkfd: add svm_bo reference for eviction fence drm/amdgpu: add param bit flag to create SVM BOs drm/amdkfd: add svm_bo eviction mechanism support drm/amdgpu: svm bo enable_signal call condition drm/amdgpu: add svm_bo eviction to enable_signal cb Philip Yang (23): drm/amdkfd: select kernel DEVICE_PRIVATE option drm/amdkfd: add svm ioctl API drm/amdkfd: Add SVM API support capability bits drm/amdkfd: register svm range drm/amdkfd: add svm ioctl GET_ATTR op drm/amdgpu: add common HMM get pages function drm/amdkfd: validate svm range system memory drm/amdkfd: register overlap system memory range drm/amdkfd: deregister svm range drm/amdgpu: export vm update mapping interface drm/amdkfd: map svm range to GPUs drm/amdkfd: svm range eviction and restore drm/amdkfd: register HMM device private zone drm/amdkfd: validate vram svm range from TTM drm/amdkfd: support xgmi same hive mapping drm/amdkfd: copy memory through gart table drm/amdkfd: HMM migrate ram to vram drm/amdkfd: HMM migrate vram to ram drm/amdgpu: reserve fence slot to update page table drm/amdgpu: enable retry fault wptr overflow drm/amdkfd: refine migration policy with xnack on drm/amdkfd: add svm range validate timestamp drm/amdkfd: multiple gpu migrate vram to vram drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c|3 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|4 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 16 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 13 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c| 83 + drivers/gpu/drm/amd/amdgpu/amdgpu_mn.
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Daniel had some objections to this (see bellow) and so I guess I need you both to agree on the approach before I proceed. Andrey On 1/8/21 9:33 AM, Christian König wrote: Am 08.01.21 um 15:26 schrieb Andrey Grodzovsky: Hey Christian, just a ping. Was there any question for me here? As far as I can see the best approach would still be to fill the VMA with a single dummy page and avoid pointers in the GEM object. Christian. Andrey On 1/7/21 11:37 AM, Andrey Grodzovsky wrote: On 1/7/21 11:30 AM, Daniel Vetter wrote: On Thu, Jan 07, 2021 at 11:26:52AM -0500, Andrey Grodzovsky wrote: On 1/7/21 11:21 AM, Daniel Vetter wrote: On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote: On 11/23/20 3:01 AM, Christian König wrote: Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky: On 11/21/20 9:15 AM, Christian König wrote: Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: Will be used to reroute CPU mapped BO's page faults once device is removed. Uff, one page for each exported DMA-buf? That's not something we can do. We need to find a different approach here. Can't we call alloc_page() on each fault and link them together so they are freed when the device is finally reaped? For sure better to optimize and allocate on demand when we reach this corner case, but why the linking ? Shouldn't drm_prime_gem_destroy be good enough place to free ? I want to avoid keeping the page in the GEM object. What we can do is to allocate a page on demand for each fault and link the together in the bdev instead. And when the bdev is then finally destroyed after the last application closed we can finally release all of them. Christian. Hey, started to implement this and then realized that by allocating a page for each fault indiscriminately we will be allocating a new page for each faulting virtual address within a VA range belonging the same BO and this is obviously too much and not the intention. Should I instead use let's say a hashtable with the hash key being faulting BO address to actually keep allocating and reusing same dummy zero page per GEM BO (or for that matter DRM file object address for non imported BOs) ? Why do we need a hashtable? All the sw structures to track this should still be around: - if gem_bo->dma_buf is set the buffer is currently exported as a dma-buf, so defensively allocate a per-bo page - otherwise allocate a per-file page That exactly what we have in current implementation Or is the idea to save the struct page * pointer? That feels a bit like over-optimizing stuff. Better to have a simple implementation first and then tune it if (and only if) any part of it becomes a problem for normal usage. Exactly - the idea is to avoid adding extra pointer to drm_gem_object, Christian suggested to instead keep a linked list of dummy pages to be allocated on demand once we hit a vm_fault. I will then also prefault the entire VA range from vma->vm_end - vma->vm_start to vma->vm_end and map them to that single dummy page. This strongly feels like premature optimization. If you're worried about the overhead on amdgpu, pay down the debt by removing one of the redundant pointers between gem and ttm bo structs (I think we still have some) :-) Until we've nuked these easy&obvious ones we shouldn't play "avoid 1 pointer just because" games with hashtables. -Daniel Well, if you and Christian can agree on this approach and suggest maybe what pointer is redundant and can be removed from GEM struct so we can use the 'credit' to add the dummy page to GEM I will be happy to follow through. P.S Hash table is off the table anyway and we are talking only about linked list here since by prefaulting the entire VA range for a vmf->vma i will be avoiding redundant page faults to same VMA VA range and so don't need to search and reuse an existing dummy page but simply create a new one for each next fault. Andrey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Mhm, I'm not aware of any let over pointer between TTM and GEM and we worked quite hard on reducing the size of the amdgpu_bo, so another extra pointer just for that corner case would suck quite a bit. Christian. Am 08.01.21 um 15:46 schrieb Andrey Grodzovsky: Daniel had some objections to this (see bellow) and so I guess I need you both to agree on the approach before I proceed. Andrey On 1/8/21 9:33 AM, Christian König wrote: Am 08.01.21 um 15:26 schrieb Andrey Grodzovsky: Hey Christian, just a ping. Was there any question for me here? As far as I can see the best approach would still be to fill the VMA with a single dummy page and avoid pointers in the GEM object. Christian. Andrey On 1/7/21 11:37 AM, Andrey Grodzovsky wrote: On 1/7/21 11:30 AM, Daniel Vetter wrote: On Thu, Jan 07, 2021 at 11:26:52AM -0500, Andrey Grodzovsky wrote: On 1/7/21 11:21 AM, Daniel Vetter wrote: On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote: On 11/23/20 3:01 AM, Christian König wrote: Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky: On 11/21/20 9:15 AM, Christian König wrote: Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: Will be used to reroute CPU mapped BO's page faults once device is removed. Uff, one page for each exported DMA-buf? That's not something we can do. We need to find a different approach here. Can't we call alloc_page() on each fault and link them together so they are freed when the device is finally reaped? For sure better to optimize and allocate on demand when we reach this corner case, but why the linking ? Shouldn't drm_prime_gem_destroy be good enough place to free ? I want to avoid keeping the page in the GEM object. What we can do is to allocate a page on demand for each fault and link the together in the bdev instead. And when the bdev is then finally destroyed after the last application closed we can finally release all of them. Christian. Hey, started to implement this and then realized that by allocating a page for each fault indiscriminately we will be allocating a new page for each faulting virtual address within a VA range belonging the same BO and this is obviously too much and not the intention. Should I instead use let's say a hashtable with the hash key being faulting BO address to actually keep allocating and reusing same dummy zero page per GEM BO (or for that matter DRM file object address for non imported BOs) ? Why do we need a hashtable? All the sw structures to track this should still be around: - if gem_bo->dma_buf is set the buffer is currently exported as a dma-buf, so defensively allocate a per-bo page - otherwise allocate a per-file page That exactly what we have in current implementation Or is the idea to save the struct page * pointer? That feels a bit like over-optimizing stuff. Better to have a simple implementation first and then tune it if (and only if) any part of it becomes a problem for normal usage. Exactly - the idea is to avoid adding extra pointer to drm_gem_object, Christian suggested to instead keep a linked list of dummy pages to be allocated on demand once we hit a vm_fault. I will then also prefault the entire VA range from vma->vm_end - vma->vm_start to vma->vm_end and map them to that single dummy page. This strongly feels like premature optimization. If you're worried about the overhead on amdgpu, pay down the debt by removing one of the redundant pointers between gem and ttm bo structs (I think we still have some) :-) Until we've nuked these easy&obvious ones we shouldn't play "avoid 1 pointer just because" games with hashtables. -Daniel Well, if you and Christian can agree on this approach and suggest maybe what pointer is redundant and can be removed from GEM struct so we can use the 'credit' to add the dummy page to GEM I will be happy to follow through. P.S Hash table is off the table anyway and we are talking only about linked list here since by prefaulting the entire VA range for a vmf->vma i will be avoiding redundant page faults to same VMA VA range and so don't need to search and reuse an existing dummy page but simply create a new one for each next fault. Andrey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/4] drm/i915: Keep track of pwm-related backlight hooks separately
On Thu, 07 Jan 2021, Lyude Paul wrote:
> @@ -1628,37 +1633,32 @@ static int lpt_setup_backlight(struct intel_connector
> *connector, enum pipe unus
> panel->backlight.active_low_pwm = pch_ctl1 & BLM_PCH_POLARITY;
>
> pch_ctl2 = intel_de_read(dev_priv, BLC_PWM_PCH_CTL2);
> - panel->backlight.max = pch_ctl2 >> 16;
> + panel->backlight.pwm_level_max = pch_ctl2 >> 16;
>
> cpu_ctl2 = intel_de_read(dev_priv, BLC_PWM_CPU_CTL2);
>
> - if (!panel->backlight.max)
> - panel->backlight.max = get_backlight_max_vbt(connector);
> + if (!panel->backlight.pwm_level_max)
> + panel->backlight.pwm_level_max =
> get_backlight_max_vbt(connector);
>
> - if (!panel->backlight.max)
> + if (!panel->backlight.pwm_level_max)
> return -ENODEV;
>
> - panel->backlight.min = get_backlight_min_vbt(connector);
> + panel->backlight.pwm_level_min = get_backlight_min_vbt(connector);
>
> - panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
> + panel->backlight.pwm_enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
>
> - cpu_mode = panel->backlight.enabled && HAS_PCH_LPT(dev_priv) &&
> + cpu_mode = panel->backlight.pwm_enabled && HAS_PCH_LPT(dev_priv) &&
> !(pch_ctl1 & BLM_PCH_OVERRIDE_ENABLE) &&
> (cpu_ctl2 & BLM_PWM_ENABLE);
> - if (cpu_mode)
> - val = pch_get_backlight(connector);
> - else
> - val = lpt_get_backlight(connector);
> - val = intel_panel_compute_brightness(connector, val);
> - panel->backlight.level = clamp(val, panel->backlight.min,
> -panel->backlight.max);
>
> if (cpu_mode) {
> + val = intel_panel_sanitize_pwm_level(connector,
> pch_get_backlight(connector));
> +
(This really is a PITA to review, not because of how you do it but
because of the hardware and the code itself. I'm just pointing out one
thing here, but I'm not finished yet.)
I think this sanitize call is wrong here. It should be called only when
converting to and from the hw register. Here, we read directly from one
hw register and write back to another hw register.
Now, looking at the history, I think it's been wrong all the way since
commit 5b1ec9ac7ab5 ("drm/i915/backlight: Fix backlight takeover on LPT,
v3."). Probably nobody noticed, because AFAIK inverted brightness
control has only ever been an issue on some gen4 platforms...
*facepalm*
BR,
Jani.
> drm_dbg_kms(&dev_priv->drm,
> "CPU backlight register was enabled, switching to
> PCH override\n");
>
> /* Write converted CPU PWM value to PCH override register */
> - lpt_set_backlight(connector->base.state,
> panel->backlight.level);
> + lpt_set_backlight(connector->base.state, val);
> intel_de_write(dev_priv, BLC_PWM_PCH_CTL1,
> pch_ctl1 | BLM_PCH_OVERRIDE_ENABLE);
>
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: stop re-init the TTM page pool
On Fri, Jan 8, 2021 at 3:36 PM Christian König wrote:
>
> Am 08.01.21 um 15:31 schrieb Daniel Vetter:
> > On Thu, Jan 07, 2021 at 09:08:29PM +0100, Christian König wrote:
> >> Am 07.01.21 um 19:07 schrieb Daniel Vetter:
> >>> On Tue, Jan 05, 2021 at 07:23:08PM +0100, Christian König wrote:
> Drivers are not supposed to init the page pool directly any more.
>
> Signed-off-by: Christian König
> >>> Please include reported-by credits and link to the bug reports on
> >>> lore.kernel.org when merging this. Also I guess this should have a Fixes:
> >>> line?
> >> I'm not aware of a bug report, but the reported-by/Fixes lines are indeed
> >> missing.
> > This one here:
> >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20201231104020.GA4504%40zn.tnic%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C3aede203348b4f32ea3108d8b3e224ec%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637457131179258488%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bHVw4lj1f8g4ohVTeuKNkb0LAbLwY6N4KWortr3VtAo%3D&reserved=0
> >
> > Or did I get confused, and the above is yet another bug?
>
> Yeah, but that was just reported by mail. The bug tracker I've saw was
> opened after the patch was already pushed.
Still good to give reported-by credits for mailing list reports and
link to lore.kernel.org for the report, that's not just useful for
bugzilla reports.
> >> BTW: Any idea why dim add-link doesn't work?
> > Hm we occasionally have fun with email parsing (it's hard) and especially
> > python changes in how encodings are handled differently between python2
> > and python3. If you have a specific example I can try and take a look why
> > it doesn't work.
>
> It just looks up and doesn't seem to do anything. I'm not familiar with
> python so I can just describe the symptoms.
I meant tell me which mail (patchwork or lore) and I'll try to
reproduce and see what's maybe up.
-Daniel
>
> Christian.
>
> > -Daniel
> >
> >>> And maybe some words on how/why stuff blows up.
> >> Just a typo. I've forgot to remove two lines in radeon while rebasing and
> >> still had the symbols exported so never noticed this.
> >>
> >> Christian.
> >>
> >>> -Daniel
> >>>
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index d4328ff57757..35b715f82ed8 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -729,9 +729,6 @@ int radeon_ttm_init(struct radeon_device *rdev)
> }
> rdev->mman.initialized = true;
> - ttm_pool_init(&rdev->mman.bdev.pool, rdev->dev, rdev->need_swiotlb,
> -dma_addressing_limited(&rdev->pdev->dev));
> -
> r = radeon_ttm_init_vram(rdev);
> if (r) {
> DRM_ERROR("Failed initializing VRAM heap.\n");
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7Cchristian.koenig%40amd.com%7C3aede203348b4f32ea3108d8b3e224ec%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637457131179258488%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pHzuAsJcXf5HlAfJ7wYYc%2BsizZhSLBGWXBhCyVNRCfo%3D&reserved=0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] arm64: dts: mt8192: Add node for the Mali GPU
On 05/01/2021 05:36, Nick Fan wrote:
Add a basic GPU node for mt8192.
Signed-off-by: Nick Fan
---
This patch depends on Mediatek power and regulator support.
Listed as following.
[1]https://lore.kernel.org/patchwork/patch/1336293/
[2]https://patchwork.kernel.org/project/linux-mediatek/list/?series=374013
[3]https://lore.kernel.org/patchwork/patch/1356037/
[4]https://patchwork.kernel.org/project/linux-mediatek/list/?series=405777
[5]https://lore.kernel.org/patchwork/patch/1356175/
[6]https://patchwork.kernel.org/project/linux-mediatek/patch/1605700894-32699-6-git-send-email-hsin-hsiung.w...@mediatek.com/
[7]https://patchwork.kernel.org/project/linux-mediatek/patch/1608104827-7937-10-git-send-email-hsin-hsiung.w...@mediatek.com/
---
---
arch/arm64/boot/dts/mediatek/mt8192-evb.dts | 7 +
arch/arm64/boot/dts/mediatek/mt8192.dtsi| 176
2 files changed, 183 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
index 6c1e2b3e8a60..48c0e240dd92 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
@@ -5,6 +5,7 @@
*/
/dts-v1/;
#include "mt8192.dtsi"
+#include "mt6359.dtsi"
/ {
model = "MediaTek MT8192 evaluation board";
@@ -70,6 +71,12 @@
};
};
+&gpu {
+ supply-names = "mali","sram";
+ mali-supply = <&mt6315_7_vbuck1>;
+ sram-supply = <&mt6359_vsram_others_ldo_reg>;
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index d6a4ad242a33..de166ea750af 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -822,6 +822,182 @@
#clock-cells = <1>;
};
+ gpu: mali@1300 {
+ compatible = "mediatek,mt8192-mali", "arm,mali-valhall";
+ reg = <0 0x1300 0 0x4000>;
+ interrupts =
+ ,
+ ,
+ ,
+ ,
+ ;
+ interrupt-names =
+ "GPU",
+ "MMU",
+ "JOB",
+ "EVENT",
+ "PWR";
These interrupt names don't match the binding you've posted (GPU, MMU,
JOB are upper case here, lower case in the binding). Also EVENT and PWR
are not mentioned in the binding - should they be?
I know there are differences here between kbase's requirements and the
existing upstream bindings (case specifically), but I haven't seen a
binding containing EVENT and PWR before.
Steve
+
+ clocks =
+ <&apmixedsys CLK_APMIXED_MFGPLL>,
+ <&topckgen CLK_TOP_MFG_PLL_SEL>,
+ <&topckgen CLK_TOP_MFG_REF_SEL>,
+ <&mfgcfg CLK_MFG_BG3D>;
+ clock-names =
+ "clk_main_parent",
+ "clk_mux",
+ "clk_sub_parent",
+ "subsys_mfg_cg";
+
+ power-domains =
+ <&scpsys MT8192_POWER_DOMAIN_MFG2>,
+ <&scpsys MT8192_POWER_DOMAIN_MFG3>,
+ <&scpsys MT8192_POWER_DOMAIN_MFG4>,
+ <&scpsys MT8192_POWER_DOMAIN_MFG5>,
+ <&scpsys MT8192_POWER_DOMAIN_MFG6>;
+ power-domain-names = "core0",
+"core1",
+"core2",
+"core3",
+"core4";
+
+ operating-points-v2 = <&gpu_opp_table>;
+ #cooling-cells = <2>;
+ };
+
+ gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-35800 {
+ opp-hz = /bits/ 64 <35800>;
+ opp-hz-real = /bits/ 64 <35800>,
+ /bits/ 64 <35800>;
+ opp-microvolt = <606250>,
+ <75>;
+ };
+
+ opp-39900 {
+ opp-hz = /bits/ 64 <39900>;
+ opp-hz-real = /bits/ 64 <39900>,
+ /bits/ 64 <39900>;
+ opp-microvolt = <618750>,
+
Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD
Am 2021-01-08 um 9:40 a.m. schrieb Daniel Vetter: > On Thu, Jan 07, 2021 at 11:25:41AM -0500, Felix Kuehling wrote: >> Am 2021-01-07 um 4:23 a.m. schrieb Daniel Vetter: >>> On Wed, Jan 06, 2021 at 10:00:52PM -0500, Felix Kuehling wrote: This is the first version of our HMM based shared virtual memory manager for KFD. There are still a number of known issues that we're working through (see below). This will likely lead to some pretty significant changes in MMU notifier handling and locking on the migration code paths. So don't get hung up on those details yet. But I think this is a good time to start getting feedback. We're pretty confident about the ioctl API, which is both simple and extensible for the future. (see patches 4,16) The user mode side of the API can be found here: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/fxkamd/hmm-wip/src/svm.c I'd also like another pair of eyes on how we're interfacing with the GPU VM code in amdgpu_vm.c (see patches 12,13), retry page fault handling (24,25), and some retry IRQ handling changes (32). Known issues: * won't work with IOMMU enabled, we need to dma_map all pages properly * still working on some race conditions and random bugs * performance is not great yet >>> Still catching up, but I think there's another one for your list: >>> >>> * hmm gpu context preempt vs page fault handling. I've had a short >>>discussion about this one with Christian before the holidays, and also >>>some private chats with Jerome. It's nasty since no easy fix, much less >>>a good idea what's the best approach here. >> Do you have a pointer to that discussion or any more details? > Essentially if you're handling an hmm page fault from the gpu, you can > deadlock by calling dma_fence_wait on a (chain of, possibly) other command > submissions or compute contexts with dma_fence_wait. Which deadlocks if > you can't preempt while you have that page fault pending. Two solutions: > > - your hw can (at least for compute ctx) preempt even when a page fault is > pending Our GFXv9 GPUs can do this. GFXv10 cannot. > > - lots of screaming in trying to come up with an alternate solution. They > all suck. My idea for GFXv10 is to avoid preemption for memory management purposes and rely 100% on page faults instead. That is, if the memory manager needs to prevent GPU access to certain memory, just invalidate the GPU page table entries pointing to that memory. No waiting for fences is necessary, except for the SDMA job that invalidates the PTEs, which runs on a special high-priority queue that should never deadlock. That should prevent the CPU getting involved in deadlocks in kernel mode. But you can still deadlock the GPU in user mode if all compute units get stuck in page faults and can't switch to any useful work any more. So it's possible that we won't be able to use GPU page faults on our GFXv10 GPUs. Regards, Felix > > Note that the dma_fence_wait is hard requirement, because we need that for > mmu notifiers and shrinkers, disallowing that would disable dynamic memory > management. Which is the current "ttm is self-limited to 50% of system > memory" limitation Christian is trying to lift. So that's really not > a restriction we can lift, at least not in upstream where we need to also > support old style hardware which doesn't have page fault support and > really has no other option to handle memory management than > dma_fence_wait. > > Thread was here: > > https://lore.kernel.org/dri-devel/CAKMK7uGgoeF8LmFBwWh5mW1k4xWjuUh3hdSFpVH1NBM7K0=e...@mail.gmail.com/ > > There's a few ways to resolve this (without having preempt-capable > hardware), but they're all supremely nasty. > -Daniel > >> Thanks, >> Felix >> >> >>> I'll try to look at this more in-depth when I'm catching up on mails. >>> -Daniel >>> Alex Sierra (12): drm/amdgpu: replace per_device_list by array drm/amdkfd: helper to convert gpu id and idx drm/amdkfd: add xnack enabled flag to kfd_process drm/amdkfd: add ioctl to configure and query xnack retries drm/amdkfd: invalidate tables on page retry fault drm/amdkfd: page table restore through svm API drm/amdkfd: SVM API call to restore page tables drm/amdkfd: add svm_bo reference for eviction fence drm/amdgpu: add param bit flag to create SVM BOs drm/amdkfd: add svm_bo eviction mechanism support drm/amdgpu: svm bo enable_signal call condition drm/amdgpu: add svm_bo eviction to enable_signal cb Philip Yang (23): drm/amdkfd: select kernel DEVICE_PRIVATE option drm/amdkfd: add svm ioctl API drm/amdkfd: Add SVM API support capability bits drm/amdkfd: register svm range drm/amdkfd: add svm ioctl GET_ATTR op drm/amdgpu: add common HMM get pages function drm/amdkfd: validate svm range system memory
[PULL] drm-fixes
Hi Linus, Looks like people are back from the break, usual small pile of fixes all over. Next week Dave should be back. Only thing pending I'm aware of is a "this shouldn't have become uapi" reverts for amdgpu, but they're already on the list and not that important really so can wait another week. Cheers, Daniel drm-fixes-2021-01-08: drm-fixes for -rc3 - fix for ttm list corruption in radeon, reported by a few people - fixes for amdgpu, i915, msm - dma-buf use-after free fix Cheers, Daniel The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62: Linux 5.11-rc2 (2021-01-03 15:55:30 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-01-08 for you to fetch changes up to 29f95f20581c4bb4e58c1cc1cb15bff9b931cad9: Merge tag 'drm-misc-fixes-2021-01-08' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2021-01-08 10:39:18 +0100) drm-fixes for -rc3 - fix for ttm list corruption in radeon, reported by a few people - fixes for amdgpu, i915, msm - dma-buf use-after free fix Alex Deucher (2): drm/amdgpu/display: drop DCN support for aarch64 Revert "drm/amd/display: Fix memory leaks in S3 resume" Arnd Bergmann (1): drm/amd/display: Fix unused variable warning Charan Teja Reddy (1): dmabuf: fix use-after-free of dmabuf's file->f_inode Chris Wilson (2): drm/i915/gt: Define guc firmware blob for older Cometlakes drm/i915/dp: Track pm_qos per connector Christian König (2): drm/radeon: stop re-init the TTM page pool drm/ttm: unexport ttm_pool_init/fini Craig Tatlor (1): drm/msm: Call msm_init_vram before binding the gpu Daniel Vetter (4): Merge tag 'amd-drm-fixes-5.11-2021-01-06' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2021-01-07' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'drm-msm-fixes-2021-01-07' of https://gitlab.freedesktop.org/drm/msm into drm-fixes Merge tag 'drm-misc-fixes-2021-01-08' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Dennis Li (3): drm/amdgpu: fix a memory protection fault when remove amdgpu device drm/amdgpu: fix a GPU hang issue when remove device drm/amdgpu: fix no bad_pages issue after umc ue injection Hawking Zhang (1): drm/amdgpu: switched to cached noretry setting for vangogh Iskren Chernev (3): drm/msm: Fix null dereference in _msm_gem_new drm/msm: Ensure get_pages is called when locked drm/msm: Add modparam to allow vram carveout Jiawei Gu (1): drm/amdgpu: fix potential memory leak during navi12 deinitialization John Clements (2): drm/amd/pm: updated PM to I2C controller port on sienna cichlid drm/amdgpu: enable ras eeprom support for sienna cichlid Kevin Wang (1): drm/amd/display: fix sysfs amdgpu_current_backlight_pwm NULL pointer issue Konrad Dybcio (1): drm/msm: Only enable A6xx LLCC code on A6xx Kuogee Hsieh (1): drm/msm/dp: postpone irq_hpd event during connection pending state Matthew Auld (2): drm/i915: clear the shadow batch drm/i915: clear the gpu reloc batch Rob Clark (1): drm/msm: Fix WARN_ON() splat in _free_object() Xiaojian Du (4): drm/amd/pm: correct the sensor value of power for vangogh drm/amd/pm: improve the fine grain tuning function for RV/RV2/PCO drm/amd/pm: fix the failure when change power profile for renoir drm/amd/pm: improve the fine grain tuning function for RV/RV2/PCO drivers/dma-buf/dma-buf.c | 21 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 25 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 8 +- drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c| 2 +- drivers/gpu/drm/amd/display/Kconfig| 2 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 2 +- drivers/gpu/drm/amd/display/dc/calcs/Makefile | 4 - drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile| 21 --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 7 +- drivers/gpu/drm/amd/display/dc/dcn10/Makefile | 7 - .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 7 - drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 4 - drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 4 - drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 5 - drivers/gpu/drm/amd/display/dc/dcn301/Makefile | 4 - drivers/gpu/drm/amd/display/dc/dcn302/Makefile | 4 - drivers/gpu/drm/amd/display/dc/dml/Makefile| 4 - drivers/gpu/drm/amd/display/dc/dsc/Makefile| 4 - drivers/
Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD
On Fri, Jan 8, 2021 at 4:58 PM Felix Kuehling wrote: > > Am 2021-01-08 um 9:40 a.m. schrieb Daniel Vetter: > > On Thu, Jan 07, 2021 at 11:25:41AM -0500, Felix Kuehling wrote: > >> Am 2021-01-07 um 4:23 a.m. schrieb Daniel Vetter: > >>> On Wed, Jan 06, 2021 at 10:00:52PM -0500, Felix Kuehling wrote: > This is the first version of our HMM based shared virtual memory manager > for KFD. There are still a number of known issues that we're working > through > (see below). This will likely lead to some pretty significant changes in > MMU notifier handling and locking on the migration code paths. So don't > get hung up on those details yet. > > But I think this is a good time to start getting feedback. We're pretty > confident about the ioctl API, which is both simple and extensible for > the > future. (see patches 4,16) The user mode side of the API can be found > here: > https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/fxkamd/hmm-wip/src/svm.c > > I'd also like another pair of eyes on how we're interfacing with the GPU > VM > code in amdgpu_vm.c (see patches 12,13), retry page fault handling > (24,25), > and some retry IRQ handling changes (32). > > > Known issues: > * won't work with IOMMU enabled, we need to dma_map all pages properly > * still working on some race conditions and random bugs > * performance is not great yet > >>> Still catching up, but I think there's another one for your list: > >>> > >>> * hmm gpu context preempt vs page fault handling. I've had a short > >>>discussion about this one with Christian before the holidays, and also > >>>some private chats with Jerome. It's nasty since no easy fix, much less > >>>a good idea what's the best approach here. > >> Do you have a pointer to that discussion or any more details? > > Essentially if you're handling an hmm page fault from the gpu, you can > > deadlock by calling dma_fence_wait on a (chain of, possibly) other command > > submissions or compute contexts with dma_fence_wait. Which deadlocks if > > you can't preempt while you have that page fault pending. Two solutions: > > > > - your hw can (at least for compute ctx) preempt even when a page fault is > > pending > > Our GFXv9 GPUs can do this. GFXv10 cannot. Uh, why did your hw guys drop this :-/ > > - lots of screaming in trying to come up with an alternate solution. They > > all suck. > > My idea for GFXv10 is to avoid preemption for memory management purposes > and rely 100% on page faults instead. That is, if the memory manager > needs to prevent GPU access to certain memory, just invalidate the GPU > page table entries pointing to that memory. No waiting for fences is > necessary, except for the SDMA job that invalidates the PTEs, which runs > on a special high-priority queue that should never deadlock. That should > prevent the CPU getting involved in deadlocks in kernel mode. But you > can still deadlock the GPU in user mode if all compute units get stuck > in page faults and can't switch to any useful work any more. So it's > possible that we won't be able to use GPU page faults on our GFXv10 GPUs. This only works if _everything_ in the system works like this, since you're defacto breaking the cross-driver contract. As soon as there's some legacy gl workload (userptr) or another driver involved, this approach falls apart. I do think it can be rescued with what I call gang scheduling of engines: I.e. when a given engine is running a context (or a group of engines, depending how your hw works) that can cause a page fault, you must flush out all workloads running on the same engine which could block a dma_fence (preempt them, or for non-compute stuff, force their completion). And the other way round, i.e. before you can run a legacy gl workload with a dma_fence on these engines you need to preempt all ctxs that could cause page faults and take them at least out of the hw scheduler queue. Just reserving an sdma engine for copy jobs and ptes updates and that stuff is necessary, but not sufficient. Another approach that Jerome suggested is to track the reverse dependency graph of all dma_fence somehow and make sure that direct reclaim never recurses on an engine you're serving a pagefault for. Possible in theory, but in practice I think not feasible to implement because way too much work to implement. Either way it's imo really nasty to come up with a scheme here that doesn't fail in some corner, or becomes really nasty with inconsistent rules across different drivers and hw :-( Cheers, Daniel > > Regards, > Felix > > > > > Note that the dma_fence_wait is hard requirement, because we need that for > > mmu notifiers and shrinkers, disallowing that would disable dynamic memory > > management. Which is the current "ttm is self-limited to 50% of system > > memory" limitation Christian is trying to lift. So that's really not >
RE: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local operations
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Friday, January 8, 2021 4:43 AM
>To: sumit.sem...@linaro.org; christian.koe...@amd.com;
>airl...@redhat.com; dan...@ffwll.ch; maarten.lankho...@linux.intel.com;
>mrip...@kernel.org; kra...@redhat.com; hdego...@redhat.com;
>s...@poorly.run; e...@anholt.net; s...@ravnborg.org
>Cc: Daniel Vetter ; dri-devel@lists.freedesktop.org;
>virtualizat...@lists.linux-foundation.org; linaro-mm-...@lists.linaro.org;
>Thomas Zimmermann ; linux-
>me...@vger.kernel.org
>Subject: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local
>operations
>
>The existing dma-buf calls dma_buf_vmap() and dma_buf_vunmap() are
>allowed to pin the buffer or acquire the buffer's reservation object
>lock.
>
>This is a problem for callers that only require a short-term mapping
>of the buffer without the pinning, or callers that have special locking
>requirements. These may suffer from unnecessary overhead or interfere
>with regular pin operations.
>
>The new interfaces dma_buf_vmap_local(), dma_buf_vunmapo_local(), and
>their rsp callbacks in struct dma_buf_ops provide an alternative without
>pinning or reservation locking. Callers are responsible for these
>operations.
>
>v4:
> * update documentation (Daniel)
>
>Signed-off-by: Thomas Zimmermann
>Reviewed-by: Daniel Vetter
>Suggested-by: Daniel Vetter
>---
> drivers/dma-buf/dma-buf.c | 81
>+++
> include/linux/dma-buf.h | 34
> 2 files changed, 115 insertions(+)
>
>diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>index b8465243eca2..01f9c74d97fa 100644
>--- a/drivers/dma-buf/dma-buf.c
>+++ b/drivers/dma-buf/dma-buf.c
>@@ -1295,6 +1295,87 @@ void dma_buf_vunmap(struct dma_buf *dmabuf,
>struct dma_buf_map *map)
> }
> EXPORT_SYMBOL_GPL(dma_buf_vunmap);
>
>+/**
>+ * dma_buf_vmap_local - Create virtual mapping for the buffer object into
>kernel
>+ * address space.
>+ * @dmabuf: [in]buffer to vmap
>+ * @map: [out] returns the vmap pointer
>+ *
>+ * Unlike dma_buf_vmap() this is a short term mapping and will not pin
>+ * the buffer. The struct dma_resv for the @dmabuf must be locked until
>+ * dma_buf_vunmap_local() is called.
>+ *
>+ * Returns:
>+ * 0 on success, or a negative errno code otherwise.
>+ */
>+int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map
>*map)
>+{
>+ struct dma_buf_map ptr;
>+ int ret = 0;
>+
>+ dma_buf_map_clear(map);
>+
>+ if (WARN_ON(!dmabuf))
>+ return -EINVAL;
>+
>+ dma_resv_assert_held(dmabuf->resv);
>+
>+ if (!dmabuf->ops->vmap_local)
>+ return -EINVAL;
You are clearing the map, and then doing the above checks.
Is it ok to change the map info and then exit on error?
Mike
>+ mutex_lock(&dmabuf->lock);
>+ if (dmabuf->vmapping_counter) {
>+ dmabuf->vmapping_counter++;
>+ BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
>+ *map = dmabuf->vmap_ptr;
>+ goto out_unlock;
>+ }
>+
>+ BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
>+
>+ ret = dmabuf->ops->vmap_local(dmabuf, &ptr);
>+ if (WARN_ON_ONCE(ret))
>+ goto out_unlock;
>+
>+ dmabuf->vmap_ptr = ptr;
>+ dmabuf->vmapping_counter = 1;
>+
>+ *map = dmabuf->vmap_ptr;
>+
>+out_unlock:
>+ mutex_unlock(&dmabuf->lock);
>+ return ret;
>+}
>+EXPORT_SYMBOL_GPL(dma_buf_vmap_local);
>+
>+/**
>+ * dma_buf_vunmap_local - Unmap a vmap obtained by
>dma_buf_vmap_local.
>+ * @dmabuf: [in]buffer to vunmap
>+ * @map: [in]vmap pointer to vunmap
>+ *
>+ * Release a mapping established with dma_buf_vmap_local().
>+ */
>+void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct
>dma_buf_map *map)
>+{
>+ if (WARN_ON(!dmabuf))
>+ return;
>+
>+ dma_resv_assert_held(dmabuf->resv);
>+
>+ BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
>+ BUG_ON(dmabuf->vmapping_counter == 0);
>+ BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map));
>+
>+ mutex_lock(&dmabuf->lock);
>+ if (--dmabuf->vmapping_counter == 0) {
>+ if (dmabuf->ops->vunmap_local)
>+ dmabuf->ops->vunmap_local(dmabuf, map);
>+ dma_buf_map_clear(&dmabuf->vmap_ptr);
>+ }
>+ mutex_unlock(&dmabuf->lock);
>+}
>+EXPORT_SYMBOL_GPL(dma_buf_vunmap_local);
>+
> #ifdef CONFIG_DEBUG_FS
> static int dma_buf_debug_show(struct seq_file *s, void *unused)
> {
>diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>index 628681bf6c99..aeed754b5467 100644
>--- a/include/linux/dma-buf.h
>+++ b/include/linux/dma-buf.h
>@@ -264,6 +264,38 @@ struct dma_buf_ops {
>
> int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map
>*map);
>+
>+ /**
>+ * @vmap_local:
>+ *
>+ * Creates a virtual mapping for the buffer into kernel address s
[PATCH] drm/amdkfd: Fix out-of-bounds read in kdf_create_vcrat_image_cpu()
KASAN reported a slab-out-of-bounds read of size 1 in
kdf_create_vcrat_image_cpu().
This occurs when, for example, when on an x86_64 with a single NUMA node
because kfd_fill_iolink_info_for_cpu() is a no-op, but afterwards the
sub_type_hdr->length, which is out-of-bounds, is read and multiplied by
entries. Fortunately, entries is 0 in this case so the overall
crat_table->length is still correct.
This refactors the helper functions to accept the crat_table directly
and calculate the table entry pointer based on the current table length.
This allows us to avoid an out-of-bounds read and hopefully makes the
pointer arithmetic clearer. It should have no functional change beyond
removing the out-of-bounds read.
Fixes: b7b6c38529c9 ("drm/amdkfd: Calculate CPU VCRAT size dynamically (v2)")
Signed-off-by: Jeremy Cline
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 86 +--
1 file changed, 40 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
index 8cac497c2c45..e50db2c0f4ee 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
@@ -829,21 +829,24 @@ int kfd_create_crat_image_acpi(void **crat_image, size_t
*size)
/* kfd_fill_cu_for_cpu - Fill in Compute info for the given CPU NUMA node
*
* @numa_node_id: CPU NUMA node id
- * @avail_size: Available size in the memory
- * @sub_type_hdr: Memory into which compute info will be filled in
+ * @avail_size: Available space in bytes at the end of the @crat_table.
+ * @crat_table: The CRAT table to append the Compute info to;
+ * on success the table length and total_entries count is updated.
*
* Return 0 if successful else return -ve value
*/
static int kfd_fill_cu_for_cpu(int numa_node_id, int *avail_size,
- int proximity_domain,
- struct crat_subtype_computeunit *sub_type_hdr)
+ struct crat_header *crat_table)
{
const struct cpumask *cpumask;
+ struct crat_subtype_computeunit *sub_type_hdr;
*avail_size -= sizeof(struct crat_subtype_computeunit);
if (*avail_size < 0)
return -ENOMEM;
+ sub_type_hdr = (typeof(sub_type_hdr))((char *)crat_table +
+ crat_table->length);
memset(sub_type_hdr, 0, sizeof(struct crat_subtype_computeunit));
/* Fill in subtype header data */
@@ -855,36 +858,42 @@ static int kfd_fill_cu_for_cpu(int numa_node_id, int
*avail_size,
/* Fill in CU data */
sub_type_hdr->flags |= CRAT_CU_FLAGS_CPU_PRESENT;
- sub_type_hdr->proximity_domain = proximity_domain;
+ sub_type_hdr->proximity_domain = crat_table->num_domains;
sub_type_hdr->processor_id_low = kfd_numa_node_to_apic_id(numa_node_id);
if (sub_type_hdr->processor_id_low == -1)
return -EINVAL;
sub_type_hdr->num_cpu_cores = cpumask_weight(cpumask);
+ crat_table->length += sub_type_hdr->length;
+ crat_table->total_entries++;
+
return 0;
}
/* kfd_fill_mem_info_for_cpu - Fill in Memory info for the given CPU NUMA node
*
* @numa_node_id: CPU NUMA node id
- * @avail_size: Available size in the memory
- * @sub_type_hdr: Memory into which compute info will be filled in
+ * @avail_size: Available space in bytes at the end of the @crat_table.
+ * @crat_table: The CRAT table to append the Memory info to;
+ * on success the table length and total_entries count is updated.
*
* Return 0 if successful else return -ve value
*/
static int kfd_fill_mem_info_for_cpu(int numa_node_id, int *avail_size,
- int proximity_domain,
- struct crat_subtype_memory *sub_type_hdr)
+ struct crat_header *crat_table)
{
uint64_t mem_in_bytes = 0;
pg_data_t *pgdat;
int zone_type;
+ struct crat_subtype_memory *sub_type_hdr;
*avail_size -= sizeof(struct crat_subtype_memory);
if (*avail_size < 0)
return -ENOMEM;
+ sub_type_hdr = (typeof(sub_type_hdr))((char *)crat_table +
+ crat_table->length);
memset(sub_type_hdr, 0, sizeof(struct crat_subtype_memory));
/* Fill in subtype header data */
@@ -905,27 +914,37 @@ static int kfd_fill_mem_info_for_cpu(int numa_node_id,
int *avail_size,
sub_type_hdr->length_low = lower_32_bits(mem_in_bytes);
sub_type_hdr->length_high = upper_32_bits(mem_in_bytes);
- sub_type_hdr->proximity_domain = proximity_domain;
+ sub_type_hdr->proximity_domain = crat_table->num_domains;
+
+ crat_table->length += sub_type_hdr->length;
+ crat_table->total_entries++;
return 0;
}
#ifdef CONFIG_X86_64
+/* kfd_fill_iolink_info_for_cpu() - Add IO link info to a Virtual CRAT
+ *
+ * @numa_node_id: The NUMA node ID
Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD
Am 2021-01-08 um 11:06 a.m. schrieb Daniel Vetter: > On Fri, Jan 8, 2021 at 4:58 PM Felix Kuehling wrote: >> Am 2021-01-08 um 9:40 a.m. schrieb Daniel Vetter: >>> On Thu, Jan 07, 2021 at 11:25:41AM -0500, Felix Kuehling wrote: Am 2021-01-07 um 4:23 a.m. schrieb Daniel Vetter: > On Wed, Jan 06, 2021 at 10:00:52PM -0500, Felix Kuehling wrote: >> This is the first version of our HMM based shared virtual memory manager >> for KFD. There are still a number of known issues that we're working >> through >> (see below). This will likely lead to some pretty significant changes in >> MMU notifier handling and locking on the migration code paths. So don't >> get hung up on those details yet. >> >> But I think this is a good time to start getting feedback. We're pretty >> confident about the ioctl API, which is both simple and extensible for >> the >> future. (see patches 4,16) The user mode side of the API can be found >> here: >> https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/fxkamd/hmm-wip/src/svm.c >> >> I'd also like another pair of eyes on how we're interfacing with the GPU >> VM >> code in amdgpu_vm.c (see patches 12,13), retry page fault handling >> (24,25), >> and some retry IRQ handling changes (32). >> >> >> Known issues: >> * won't work with IOMMU enabled, we need to dma_map all pages properly >> * still working on some race conditions and random bugs >> * performance is not great yet > Still catching up, but I think there's another one for your list: > > * hmm gpu context preempt vs page fault handling. I've had a short >discussion about this one with Christian before the holidays, and also >some private chats with Jerome. It's nasty since no easy fix, much less >a good idea what's the best approach here. Do you have a pointer to that discussion or any more details? >>> Essentially if you're handling an hmm page fault from the gpu, you can >>> deadlock by calling dma_fence_wait on a (chain of, possibly) other command >>> submissions or compute contexts with dma_fence_wait. Which deadlocks if >>> you can't preempt while you have that page fault pending. Two solutions: >>> >>> - your hw can (at least for compute ctx) preempt even when a page fault is >>> pending >> Our GFXv9 GPUs can do this. GFXv10 cannot. > Uh, why did your hw guys drop this :-/ > >>> - lots of screaming in trying to come up with an alternate solution. They >>> all suck. >> My idea for GFXv10 is to avoid preemption for memory management purposes >> and rely 100% on page faults instead. That is, if the memory manager >> needs to prevent GPU access to certain memory, just invalidate the GPU >> page table entries pointing to that memory. No waiting for fences is >> necessary, except for the SDMA job that invalidates the PTEs, which runs >> on a special high-priority queue that should never deadlock. That should >> prevent the CPU getting involved in deadlocks in kernel mode. But you >> can still deadlock the GPU in user mode if all compute units get stuck >> in page faults and can't switch to any useful work any more. So it's >> possible that we won't be able to use GPU page faults on our GFXv10 GPUs. > This only works if _everything_ in the system works like this, since > you're defacto breaking the cross-driver contract. As soon as there's > some legacy gl workload (userptr) or another driver involved, this > approach falls apart. I think the scenario you have in mind involves a dma_fence that depends on the resolution of a GPU page fault. With our user mode command submission model for compute contexts, there are no DMA fences that get signaled by compute jobs that could get stuck on page faults. The legacy GL workload would not get GPU page faults. The only way it could get stuck is, if all CUs are stuck on page faults and the command processor can't find any HW resources to execute it on. That's my user mode deadlock scenario below. So yeah, you're right, kernel mode can't avoid getting involved in that unless everything uses user mode command submissions. If (big if) we switched to user mode command submission for all compute and graphics contexts, and no longer use DMA fences to signal their completion, I think that would solve the problem as far as the kernel is concerned. > > I do think it can be rescued with what I call gang scheduling of > engines: I.e. when a given engine is running a context (or a group of > engines, depending how your hw works) that can cause a page fault, you > must flush out all workloads running on the same engine which could > block a dma_fence (preempt them, or for non-compute stuff, force their > completion). And the other way round, i.e. before you can run a legacy > gl workload with a dma_fence on these engines you need to preempt all > ctxs that could cause page faults and take them at least out of the hw > scheduler queue
Re: [Freedreno] [PATCH] drm/msm: Only enable A6xx LLCC code on A6xx
On Fri, Jan 8, 2021 at 6:05 AM Sai Prakash Ranjan wrote: > > On 2021-01-08 19:09, Konrad Dybcio wrote: > >> Konrad, can you please test this below change without your change? > > > > This brings no difference, a BUG still happens. We're still calling > > to_a6xx_gpu on ANY device that's probed! Too bad it won't turn my A330 > > into an A640.. > > > > Also, relying on disabling LLCC in the config is out of question as it > > makes the arm32 kernel not compile with DRM/MSM and it just removes > > the functionality on devices with a6xx.. (unless somebody removes the > > dependency on it, which in my opinion is even worse and will cause > > more problems for developers!). > > > > Disabling LLCC is not the suggestion, I was under the impression that > was the cause here for the smmu bug. Anyways, the check for llc slice > in case llcc is disabled is not correct as well. I will send a patch for > that as well. > > > The bigger question is how and why did that piece of code ever make it > > to adreno_gpu.c and not a6xx_gpu.c? > > > > My mistake, I will move it. Thanks, since we don't have kernel-CI coverage for gpu, and there probably isn't one person who has all the different devices supported (or enough hours in the day to test them all), it is probably better/safer to keep things in the backend code that is specific to a given generation. > > To solve it in a cleaner way I propose to move it to an a6xx-specific > > file, or if it's going to be used with next-gen GPUs, perhaps manage > > calling of this code via an adreno quirk/feature in adreno_device.c. > > Now that I think about it, A5xx GPMU en/disable could probably managed > > like that, instead of using tons of if-statements for each GPU model > > that has it.. > > > > While we're at it, do ALL (and I truly do mean ALL, including the > > low-end ones, this will be important later on) A6xx GPUs make use of > > that feature? > > > > I do not have a list of all A6XX GPUs with me currently, but from what > I know, A618, A630, A640, A650 has the support. > >From the PoV of bringing up new a6xx, we should probably consider that some of them may not *yet* have LLCC enabled. I have an 8cx laptop and once I find time to get the display working, the next step would be bringing up a680.. and I'd probably like to start without LLCC.. BR, -R > Thanks, > Sai > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a > member > of Code Aurora Forum, hosted by The Linux Foundation > ___ > Freedreno mailing list > freedr...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/freedreno ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Ok then, I guess I will proceed with the dummy pages list implementation then. Andrey From: Koenig, Christian Sent: 08 January 2021 09:52 To: Grodzovsky, Andrey ; Daniel Vetter Cc: amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org ; daniel.vet...@ffwll.ch ; r...@kernel.org ; l.st...@pengutronix.de ; yuq...@gmail.com ; e...@anholt.net ; Deucher, Alexander ; gre...@linuxfoundation.org ; ppaala...@gmail.com ; Wentland, Harry Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object Mhm, I'm not aware of any let over pointer between TTM and GEM and we worked quite hard on reducing the size of the amdgpu_bo, so another extra pointer just for that corner case would suck quite a bit. Christian. Am 08.01.21 um 15:46 schrieb Andrey Grodzovsky: > Daniel had some objections to this (see bellow) and so I guess I need > you both to agree on the approach before I proceed. > > Andrey > > On 1/8/21 9:33 AM, Christian König wrote: >> Am 08.01.21 um 15:26 schrieb Andrey Grodzovsky: >>> Hey Christian, just a ping. >> >> Was there any question for me here? >> >> As far as I can see the best approach would still be to fill the VMA >> with a single dummy page and avoid pointers in the GEM object. >> >> Christian. >> >>> >>> Andrey >>> >>> On 1/7/21 11:37 AM, Andrey Grodzovsky wrote: On 1/7/21 11:30 AM, Daniel Vetter wrote: > On Thu, Jan 07, 2021 at 11:26:52AM -0500, Andrey Grodzovsky wrote: >> On 1/7/21 11:21 AM, Daniel Vetter wrote: >>> On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote: On 11/23/20 3:01 AM, Christian König wrote: > Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky: >> On 11/21/20 9:15 AM, Christian König wrote: >>> Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: Will be used to reroute CPU mapped BO's page faults once device is removed. >>> Uff, one page for each exported DMA-buf? That's not >>> something we can do. >>> >>> We need to find a different approach here. >>> >>> Can't we call alloc_page() on each fault and link them together >>> so they are freed when the device is finally reaped? >> For sure better to optimize and allocate on demand when we reach >> this corner case, but why the linking ? >> Shouldn't drm_prime_gem_destroy be good enough place to free ? > I want to avoid keeping the page in the GEM object. > > What we can do is to allocate a page on demand for each fault > and link > the together in the bdev instead. > > And when the bdev is then finally destroyed after the last > application > closed we can finally release all of them. > > Christian. Hey, started to implement this and then realized that by allocating a page for each fault indiscriminately we will be allocating a new page for each faulting virtual address within a VA range belonging the same BO and this is obviously too much and not the intention. Should I instead use let's say a hashtable with the hash key being faulting BO address to actually keep allocating and reusing same dummy zero page per GEM BO (or for that matter DRM file object address for non imported BOs) ? >>> Why do we need a hashtable? All the sw structures to track this >>> should >>> still be around: >>> - if gem_bo->dma_buf is set the buffer is currently exported as >>> a dma-buf, >>> so defensively allocate a per-bo page >>> - otherwise allocate a per-file page >> >> That exactly what we have in current implementation >> >> >>> Or is the idea to save the struct page * pointer? That feels a >>> bit like >>> over-optimizing stuff. Better to have a simple implementation >>> first and >>> then tune it if (and only if) any part of it becomes a problem >>> for normal >>> usage. >> >> Exactly - the idea is to avoid adding extra pointer to >> drm_gem_object, >> Christian suggested to instead keep a linked list of dummy pages >> to be >> allocated on demand once we hit a vm_fault. I will then also >> prefault the entire >> VA range from vma->vm_end - vma->vm_start to vma->vm_end and map >> them >> to that single dummy page. > This strongly feels like premature optimization. If you're worried > about > the overhead on amdgpu, pay down the debt by removing one of the > redundant > pointers between gem and ttm bo structs (I think we still have > some) :-) > > Until we've nuked these easy&obvious ones we shouldn't play "avoid 1 > pointer just because" games with hashtables. > -Daniel Well, if you and Christian can agree on this approach and sugges
Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD
On Fri, Jan 8, 2021 at 5:36 PM Felix Kuehling wrote: > > > Am 2021-01-08 um 11:06 a.m. schrieb Daniel Vetter: > > On Fri, Jan 8, 2021 at 4:58 PM Felix Kuehling > > wrote: > >> Am 2021-01-08 um 9:40 a.m. schrieb Daniel Vetter: > >>> On Thu, Jan 07, 2021 at 11:25:41AM -0500, Felix Kuehling wrote: > Am 2021-01-07 um 4:23 a.m. schrieb Daniel Vetter: > > On Wed, Jan 06, 2021 at 10:00:52PM -0500, Felix Kuehling wrote: > >> This is the first version of our HMM based shared virtual memory > >> manager > >> for KFD. There are still a number of known issues that we're working > >> through > >> (see below). This will likely lead to some pretty significant changes > >> in > >> MMU notifier handling and locking on the migration code paths. So don't > >> get hung up on those details yet. > >> > >> But I think this is a good time to start getting feedback. We're pretty > >> confident about the ioctl API, which is both simple and extensible for > >> the > >> future. (see patches 4,16) The user mode side of the API can be found > >> here: > >> https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/fxkamd/hmm-wip/src/svm.c > >> > >> I'd also like another pair of eyes on how we're interfacing with the > >> GPU VM > >> code in amdgpu_vm.c (see patches 12,13), retry page fault handling > >> (24,25), > >> and some retry IRQ handling changes (32). > >> > >> > >> Known issues: > >> * won't work with IOMMU enabled, we need to dma_map all pages properly > >> * still working on some race conditions and random bugs > >> * performance is not great yet > > Still catching up, but I think there's another one for your list: > > > > * hmm gpu context preempt vs page fault handling. I've had a short > >discussion about this one with Christian before the holidays, and > > also > >some private chats with Jerome. It's nasty since no easy fix, much > > less > >a good idea what's the best approach here. > Do you have a pointer to that discussion or any more details? > >>> Essentially if you're handling an hmm page fault from the gpu, you can > >>> deadlock by calling dma_fence_wait on a (chain of, possibly) other command > >>> submissions or compute contexts with dma_fence_wait. Which deadlocks if > >>> you can't preempt while you have that page fault pending. Two solutions: > >>> > >>> - your hw can (at least for compute ctx) preempt even when a page fault is > >>> pending > >> Our GFXv9 GPUs can do this. GFXv10 cannot. > > Uh, why did your hw guys drop this :-/ > > > >>> - lots of screaming in trying to come up with an alternate solution. They > >>> all suck. > >> My idea for GFXv10 is to avoid preemption for memory management purposes > >> and rely 100% on page faults instead. That is, if the memory manager > >> needs to prevent GPU access to certain memory, just invalidate the GPU > >> page table entries pointing to that memory. No waiting for fences is > >> necessary, except for the SDMA job that invalidates the PTEs, which runs > >> on a special high-priority queue that should never deadlock. That should > >> prevent the CPU getting involved in deadlocks in kernel mode. But you > >> can still deadlock the GPU in user mode if all compute units get stuck > >> in page faults and can't switch to any useful work any more. So it's > >> possible that we won't be able to use GPU page faults on our GFXv10 GPUs. > > This only works if _everything_ in the system works like this, since > > you're defacto breaking the cross-driver contract. As soon as there's > > some legacy gl workload (userptr) or another driver involved, this > > approach falls apart. > > I think the scenario you have in mind involves a dma_fence that depends > on the resolution of a GPU page fault. With our user mode command > submission model for compute contexts, there are no DMA fences that get > signaled by compute jobs that could get stuck on page faults. > > The legacy GL workload would not get GPU page faults. The only way it > could get stuck is, if all CUs are stuck on page faults and the command > processor can't find any HW resources to execute it on. That's my user > mode deadlock scenario below. So yeah, you're right, kernel mode can't > avoid getting involved in that unless everything uses user mode command > submissions. > > If (big if) we switched to user mode command submission for all compute > and graphics contexts, and no longer use DMA fences to signal their > completion, I think that would solve the problem as far as the kernel is > concerned. We can't throw dma_fence away because it's uapi built into various compositor protocols. Otherwise we could pull a wddm2 like microsoft did on windows and do what you're describing. So completely getting rid of dma_fences (even just limited on newer gpus) is also a decadel effort at least, since that's roughly how long it'll take to
Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD
Am 2021-01-08 um 11:53 a.m. schrieb Daniel Vetter: > On Fri, Jan 8, 2021 at 5:36 PM Felix Kuehling wrote: >> >> Am 2021-01-08 um 11:06 a.m. schrieb Daniel Vetter: >>> On Fri, Jan 8, 2021 at 4:58 PM Felix Kuehling >>> wrote: Am 2021-01-08 um 9:40 a.m. schrieb Daniel Vetter: > On Thu, Jan 07, 2021 at 11:25:41AM -0500, Felix Kuehling wrote: >> Am 2021-01-07 um 4:23 a.m. schrieb Daniel Vetter: >>> On Wed, Jan 06, 2021 at 10:00:52PM -0500, Felix Kuehling wrote: This is the first version of our HMM based shared virtual memory manager for KFD. There are still a number of known issues that we're working through (see below). This will likely lead to some pretty significant changes in MMU notifier handling and locking on the migration code paths. So don't get hung up on those details yet. But I think this is a good time to start getting feedback. We're pretty confident about the ioctl API, which is both simple and extensible for the future. (see patches 4,16) The user mode side of the API can be found here: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/fxkamd/hmm-wip/src/svm.c I'd also like another pair of eyes on how we're interfacing with the GPU VM code in amdgpu_vm.c (see patches 12,13), retry page fault handling (24,25), and some retry IRQ handling changes (32). Known issues: * won't work with IOMMU enabled, we need to dma_map all pages properly * still working on some race conditions and random bugs * performance is not great yet >>> Still catching up, but I think there's another one for your list: >>> >>> * hmm gpu context preempt vs page fault handling. I've had a short >>>discussion about this one with Christian before the holidays, and >>> also >>>some private chats with Jerome. It's nasty since no easy fix, much >>> less >>>a good idea what's the best approach here. >> Do you have a pointer to that discussion or any more details? > Essentially if you're handling an hmm page fault from the gpu, you can > deadlock by calling dma_fence_wait on a (chain of, possibly) other command > submissions or compute contexts with dma_fence_wait. Which deadlocks if > you can't preempt while you have that page fault pending. Two solutions: > > - your hw can (at least for compute ctx) preempt even when a page fault is > pending Our GFXv9 GPUs can do this. GFXv10 cannot. >>> Uh, why did your hw guys drop this :-/ Performance. It's the same reason why the XNACK mode selection API exists (patch 16). When we enable recoverable page fault handling in the compute units on GFXv9, it costs some performance even when no page faults are happening. On GFXv10 that retry fault handling moved out of the compute units, so they don't take the performance hit. But that sacrificed the ability to preempt during page faults. We'll need to work with our hardware teams to restore that capability in a future generation. >>> > - lots of screaming in trying to come up with an alternate solution. They > all suck. My idea for GFXv10 is to avoid preemption for memory management purposes and rely 100% on page faults instead. That is, if the memory manager needs to prevent GPU access to certain memory, just invalidate the GPU page table entries pointing to that memory. No waiting for fences is necessary, except for the SDMA job that invalidates the PTEs, which runs on a special high-priority queue that should never deadlock. That should prevent the CPU getting involved in deadlocks in kernel mode. But you can still deadlock the GPU in user mode if all compute units get stuck in page faults and can't switch to any useful work any more. So it's possible that we won't be able to use GPU page faults on our GFXv10 GPUs. >>> This only works if _everything_ in the system works like this, since >>> you're defacto breaking the cross-driver contract. As soon as there's >>> some legacy gl workload (userptr) or another driver involved, this >>> approach falls apart. >> I think the scenario you have in mind involves a dma_fence that depends >> on the resolution of a GPU page fault. With our user mode command >> submission model for compute contexts, there are no DMA fences that get >> signaled by compute jobs that could get stuck on page faults. >> >> The legacy GL workload would not get GPU page faults. The only way it >> could get stuck is, if all CUs are stuck on page faults and the command >> processor can't find any HW resources to execute it on. That's my user >> mode deadlock scenario below. So yeah, you're right, kernel mode can't >> avoid getting involved in that unless everything uses user mode command >> submissions. >> >> If
[PATCH v4 1/2] drm/msm: Add speed-bin support to a618 gpu
Some GPUs support different max frequencies depending on the platform.
To identify the correct variant, we should check the gpu speedbin
fuse value. Add support for this speedbin detection to a6xx family
along with the required fuse details for a618 gpu.
Signed-off-by: Akhil P Oommen
---
Changes from v2:
1. Made the changes a6xx specific to save space.
Changes from v1:
1. Added the changes to support a618 sku to the series.
2. Avoid failing probe in case of an unsupported sku. (Rob)
Changes from v3:
1. Replace a618_speedbins[] with a function. (Jordan)
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 83 +++
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 +
2 files changed, 85 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 1306618..499d134 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#define GPU_PAS_ID 13
@@ -1208,6 +1209,10 @@ static void a6xx_destroy(struct msm_gpu *gpu)
a6xx_gmu_remove(a6xx_gpu);
adreno_gpu_cleanup(adreno_gpu);
+
+ if (a6xx_gpu->opp_table)
+ dev_pm_opp_put_supported_hw(a6xx_gpu->opp_table);
+
kfree(a6xx_gpu);
}
@@ -1264,6 +1269,78 @@ static uint32_t a6xx_get_rptr(struct msm_gpu *gpu,
struct msm_ringbuffer *ring)
return ring->memptrs->rptr = gpu_read(gpu, REG_A6XX_CP_RB_RPTR);
}
+static u32 a618_get_speed_bin(u32 fuse)
+{
+ if (fuse == 0)
+ return 0;
+ else if (fuse == 169)
+ return 1;
+ else if (fuse == 174)
+ return 2;
+
+ return UINT_MAX;
+}
+
+static u32 fuse_to_supp_hw(struct device *dev, u32 revn, u32 fuse)
+{
+ u32 val = UINT_MAX;
+
+ if (revn == 618)
+ val = a618_get_speed_bin(fuse);
+
+ if (val == UINT_MAX) {
+ DRM_DEV_ERROR(dev,
+ "missing support for speed-bin: %u. Some OPPs may not
be supported by hardware",
+ fuse);
+ return UINT_MAX;
+ }
+
+ return (1 << val);
+}
+
+static int a6xx_set_supported_hw(struct device *dev, struct a6xx_gpu *a6xx_gpu,
+ u32 revn)
+{
+ struct opp_table *opp_table;
+ struct nvmem_cell *cell;
+ u32 supp_hw = UINT_MAX;
+ void *buf;
+
+ cell = nvmem_cell_get(dev, "speed_bin");
+ /*
+* -ENOENT means that the platform doesn't support speedbin which is
+* fine
+*/
+ if (PTR_ERR(cell) == -ENOENT)
+ return 0;
+ else if (IS_ERR(cell)) {
+ DRM_DEV_ERROR(dev,
+ "failed to read speed-bin. Some OPPs may not be
supported by hardware");
+ goto done;
+ }
+
+ buf = nvmem_cell_read(cell, NULL);
+ if (IS_ERR(buf)) {
+ nvmem_cell_put(cell);
+ DRM_DEV_ERROR(dev,
+ "failed to read speed-bin. Some OPPs may not be
supported by hardware");
+ goto done;
+ }
+
+ supp_hw = fuse_to_supp_hw(dev, revn, *((u32 *) buf));
+
+ kfree(buf);
+ nvmem_cell_put(cell);
+
+done:
+ opp_table = dev_pm_opp_set_supported_hw(dev, &supp_hw, 1);
+ if (IS_ERR(opp_table))
+ return PTR_ERR(opp_table);
+
+ a6xx_gpu->opp_table = opp_table;
+ return 0;
+}
+
static const struct adreno_gpu_funcs funcs = {
.base = {
.get_param = adreno_get_param,
@@ -1325,6 +1402,12 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
a6xx_llc_slices_init(pdev, a6xx_gpu);
+ ret = a6xx_set_supported_hw(&pdev->dev, a6xx_gpu, info->revn);
+ if (ret) {
+ a6xx_destroy(&(a6xx_gpu->base.base));
+ return ERR_PTR(ret);
+ }
+
ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1);
if (ret) {
a6xx_destroy(&(a6xx_gpu->base.base));
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index e793d32..ce0610c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -33,6 +33,8 @@ struct a6xx_gpu {
void *llc_slice;
void *htw_llc_slice;
bool have_mmu500;
+
+ struct opp_table *opp_table;
};
#define to_a6xx_gpu(x) container_of(x, struct a6xx_gpu, base)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] arm: dts: sc7180: Add support for gpu fuse
Add support for gpu fuse to help identify the supported opps.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 6678f1e..8cae3eb 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -675,6 +675,11 @@
reg = <0x25b 0x1>;
bits = <1 3>;
};
+
+ gpu_speed_bin: gpu_speed_bin@1d2 {
+ reg = <0x1d2 0x2>;
+ bits = <5 8>;
+ };
};
sdhc_1: sdhci@7c4000 {
@@ -1907,52 +1912,69 @@
operating-points-v2 = <&gpu_opp_table>;
qcom,gmu = <&gmu>;
+ nvmem-cells = <&gpu_speed_bin>;
+ nvmem-cell-names = "speed_bin";
+
interconnects = <&gem_noc MASTER_GFX3D 0 &mc_virt
SLAVE_EBI1 0>;
interconnect-names = "gfx-mem";
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
+ opp-82500 {
+ opp-hz = /bits/ 64 <82500>;
+ opp-level =
;
+ opp-peak-kBps = <8532000>;
+ opp-supported-hw = <0x04>;
+ };
+
opp-8 {
opp-hz = /bits/ 64 <8>;
opp-level =
;
opp-peak-kBps = <8532000>;
+ opp-supported-hw = <0x07>;
};
opp-65000 {
opp-hz = /bits/ 64 <65000>;
opp-level =
;
opp-peak-kBps = <7216000>;
+ opp-supported-hw = <0x07>;
};
opp-56500 {
opp-hz = /bits/ 64 <56500>;
opp-level = ;
opp-peak-kBps = <5412000>;
+ opp-supported-hw = <0x07>;
};
opp-43000 {
opp-hz = /bits/ 64 <43000>;
opp-level =
;
opp-peak-kBps = <5412000>;
+ opp-supported-hw = <0x07>;
};
opp-35500 {
opp-hz = /bits/ 64 <35500>;
opp-level = ;
opp-peak-kBps = <3072000>;
+ opp-supported-hw = <0x07>;
};
opp-26700 {
opp-hz = /bits/ 64 <26700>;
opp-level =
;
opp-peak-kBps = <3072000>;
+ opp-supported-hw = <0x07>;
};
opp-18000 {
opp-hz = /bits/ 64 <18000>;
opp-level =
;
opp-peak-kBps = <1804000>;
+ opp-supported-hw = <0x07>;
};
};
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/imx: compile test fixes
Hi Dave, Daniel, this PR includes two fixes for x86_64 COMPILE_TEST builds with CONFIG_OF disabled. The following changes since commit 16da8e9a7767ac77720f49bfa870def61a250cda: drm/imx: ipuv3-crtc: use drm managed resources (2021-01-04 12:59:34 +0100) are available in the Git repository at: git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-next-2021-01-08 for you to fetch changes up to 82581fcf070b68a91fb3a3ade08d9a76380a4789: drm/modes: add non-OF stub for of_get_drm_display_mode (2021-01-08 19:42:14 +0100) drm/imx: compile test fixes - Fix COMPILE_TEST builds with CONFIG_OF disabled. Philipp Zabel (2): drm/imx: dw_hdmi-imx: depend on OF to fix randconfig compile tests on x86_64 drm/modes: add non-OF stub for of_get_drm_display_mode drivers/gpu/drm/imx/Kconfig | 2 +- include/drm/drm_modes.h | 10 ++ 2 files changed, 11 insertions(+), 1 deletion(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Remove pinned bos from LRU in ttm_bo_move_to_lru_tail() v2
Hi This breaks things for me on my Prime system https://gitlab.freedesktop.org/drm/misc/-/issues/23 Cheers Mike ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:topic/dp-hdmi-2.1-pcon 15/15] drivers/gpu/drm/i915/display/intel_dp.c:6909:42: error: use of logical '||' with constant operand
tree: git://anongit.freedesktop.org/drm-intel topic/dp-hdmi-2.1-pcon
head: 522508b665df3bbfdf40381d4e61777844b1703f
commit: 522508b665df3bbfdf40381d4e61777844b1703f [15/15] drm/i915/display: Let
PCON convert from RGB to YCbCr if it can
config: x86_64-randconfig-r011-20210108 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
5c951623bc8965fa1e89660f2f5f4a2944e4981a)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git remote add drm-intel git://anongit.freedesktop.org/drm-intel
git fetch --no-tags drm-intel topic/dp-hdmi-2.1-pcon
git checkout 522508b665df3bbfdf40381d4e61777844b1703f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/display/intel_dp.c:6909:42: error: use of logical '||'
>> with constant operand [-Werror,-Wconstant-logical-operand]
DP_DS_HDMI_BT601_RGB_YCBCR_CONV ||
^
drivers/gpu/drm/i915/display/intel_dp.c:6909:42: note: use '|' for a bitwise
operation
DP_DS_HDMI_BT601_RGB_YCBCR_CONV ||
^~
|
drivers/gpu/drm/i915/display/intel_dp.c:6910:42: error: use of logical '||'
with constant operand [-Werror,-Wconstant-logical-operand]
DP_DS_HDMI_BT709_RGB_YCBCR_CONV ||
^
drivers/gpu/drm/i915/display/intel_dp.c:6910:42: note: use '|' for a bitwise
operation
DP_DS_HDMI_BT709_RGB_YCBCR_CONV ||
^~
|
>> drivers/gpu/drm/i915/display/intel_dp.c:6911:10: error: converting the
>> result of '<<' to a boolean always evaluates to true
>> [-Werror,-Wtautological-constant-compare]
DP_DS_HDMI_BT2020_RGB_YCBCR_CONV);
^
include/drm/drm_dp_helper.h:444:48: note: expanded from macro
'DP_DS_HDMI_BT2020_RGB_YCBCR_CONV'
# define DP_DS_HDMI_BT2020_RGB_YCBCR_CONV (1 << 7)
^
drivers/gpu/drm/i915/display/intel_dp.c:6909:10: error: converting the
result of '<<' to a boolean always evaluates to true
[-Werror,-Wtautological-constant-compare]
DP_DS_HDMI_BT601_RGB_YCBCR_CONV ||
^
include/drm/drm_dp_helper.h:442:48: note: expanded from macro
'DP_DS_HDMI_BT601_RGB_YCBCR_CONV'
# define DP_DS_HDMI_BT601_RGB_YCBCR_CONV(1 << 5)
^
drivers/gpu/drm/i915/display/intel_dp.c:6910:10: error: converting the
result of '<<' to a boolean always evaluates to true
[-Werror,-Wtautological-constant-compare]
DP_DS_HDMI_BT709_RGB_YCBCR_CONV ||
^
include/drm/drm_dp_helper.h:443:48: note: expanded from macro
'DP_DS_HDMI_BT709_RGB_YCBCR_CONV'
# define DP_DS_HDMI_BT709_RGB_YCBCR_CONV(1 << 6)
^
5 errors generated.
vim +6909 drivers/gpu/drm/i915/display/intel_dp.c
6879
6880 static void
6881 intel_dp_update_420(struct intel_dp *intel_dp)
6882 {
6883 struct drm_i915_private *i915 = dp_to_i915(intel_dp);
6884 struct intel_connector *connector =
intel_dp->attached_connector;
6885 bool is_branch, ycbcr_420_passthrough, ycbcr_444_to_420,
rgb_to_ycbcr;
6886
6887 /* No YCbCr output support on gmch platform
Re: [PATCH] MAINTAINERS: update radeon/amdgpu/amdkfd git trees
On Tue, Jan 5, 2021 at 3:15 PM Alex Deucher wrote: > > FDO is out of space, so move to gitlab. > > Signed-off-by: Alex Deucher Ping? Any objections? Alex > --- > MAINTAINERS | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index eb18459c1d16..e2877be6b10d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -907,7 +907,7 @@ AMD KFD > M: Felix Kuehling > L: amd-...@lists.freedesktop.org > S: Supported > -T: git git://people.freedesktop.org/~agd5f/linux > +T: git https://gitlab.freedesktop.org/agd5f/linux.git > F: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd*.[ch] > F: drivers/gpu/drm/amd/amdkfd/ > F: drivers/gpu/drm/amd/include/cik_structs.h > @@ -14596,7 +14596,7 @@ M: Alex Deucher > M: Christian König > L: amd-...@lists.freedesktop.org > S: Supported > -T: git git://people.freedesktop.org/~agd5f/linux > +T: git https://gitlab.freedesktop.org/agd5f/linux.git > F: drivers/gpu/drm/amd/ > F: drivers/gpu/drm/radeon/ > F: include/uapi/drm/amdgpu_drm.h > -- > 2.29.2 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 1/2] dma-fence: allow signaling drivers to set fence timestamp
On Thu, Jan 7, 2021 at 12:53 AM Veera Sundaram Sankaran wrote: > > Some drivers have hardware capability to get the precise timestamp of > certain events based on which the fences are triggered. This allows it to > set accurate timestamp factoring out any software and IRQ latencies. Add > a timestamp variant of fence signal function, dma_fence_signal_timestamp > to allow drivers to update the precise timestamp for fences. > So, on quick review, this seems mostly sane. Though, it might be good to add some more detail about how the hardware timestamping fits into the kernel's CLOCK_MONOTONIC time domain. I just want to make sure this interface isn't abused to jam raw hardware-domain timestamps into the fence->timestamp, causing the meaning or time-domain of the fence->timestamp to be unclear or inconsistent. It may be useful to add an additional patch to the documentation around the dma_fence structure to make the timestamp field semantics more explicit and avoid confusion? thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive
Hi Sebatian,
On Fri, Jan 08, 2021 at 12:24:41PM +0100, Sebastian Reichel wrote:
> Standard DRM panel driver for DSI command mode panel used by omapfb2 is also
> available now. Just like the other panels its module name clashes with the
> module from drivers/video/fbdev/omap2/omapfb/displays, part of the deprecated
> omapfb2 fbdev driver. As omapfb2 can only be compiled when the omapdrm driver
> is disabled, and the DRM panel drivers are useless in that case, make the
> omapfb2 panel depend on the standard DRM panels being disabled to fix
> the name clash.
>
> Fixes: cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
> Reported-by: Stephen Rothwell
> Signed-off-by: Sebastian Reichel
For a backport this looks good:
Acked-by: Sam Ravnborg
But why is it it we need omapfb at all when we have omapdrm?
Can we sunset all or some parts of omap support in video/?
If not, what is missing to do so.
Sam
> ---
> Laurent introduced and fixed the same issue for the other panels and
> this simply replicates the same solution for DSI command mode panel.
> ---
> drivers/video/fbdev/omap2/omapfb/displays/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
> b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
> index 744416dc530e..384d74a126dc 100644
> --- a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
> +++ b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
> @@ -43,6 +43,7 @@ config FB_OMAP2_PANEL_DPI
> config FB_OMAP2_PANEL_DSI_CM
> tristate "Generic DSI Command Mode Panel"
> depends on BACKLIGHT_CLASS_DEVICE
> + depends on DRM_PANEL_DSI_CM = n
> help
> Driver for generic DSI command mode panels.
>
> --
> 2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 2/2] drm/drm_vblank: set the dma-fence timestamp during send_vblank_event
On Thu, Jan 7, 2021 at 12:54 AM Veera Sundaram Sankaran
wrote:
>
> The explicit out-fences in crtc are signaled as part of vblank event,
> indicating all framebuffers present on the Atomic Commit request are
> scanned out on the screen. Though the fence signal and the vblank event
> notification happens at the same time, triggered by the same hardware
> vsync event, the timestamp set in both are different. With drivers
> supporting precise vblank timestamp the difference between the two
> timestamps would be even higher. This might have an impact on use-mode
> frameworks using these fence timestamps for purposes other than simple
> buffer usage. For instance, the Android framework [1] uses the
> retire-fences as an alternative to vblank when frame-updates are in
> progress. Set the fence timestamp during send vblank event using a new
> drm_send_event_timestamp_locked variant to avoid discrepancies.
>
> [1] https://android.googlesource.com/platform/frameworks/native/+/master/
> services/surfaceflinger/Scheduler/Scheduler.cpp#397
>
> Changes in v2:
> - Use drm_send_event_timestamp_locked to update fence timestamp
> - add more information to commit text
Thanks for sending this out! One small note:
> @@ -775,6 +775,49 @@ void drm_event_cancel_free(struct drm_device *dev,
> EXPORT_SYMBOL(drm_event_cancel_free);
>
> /**
> + * drm_send_event_timestamp_locked - send DRM event to file descriptor
> + * @dev: DRM device
> + * @e: DRM event to deliver
> + * @timestamp: timestamp to set for the fence event
> + *
> + * This function sends the event @e, initialized with
> drm_event_reserve_init(),
> + * to its associated userspace DRM file. Callers must already hold
> + * &drm_device.event_lock, see drm_send_event() for the unlocked version.
> + *
> + * Note that the core will take care of unlinking and disarming events when
> the
> + * corresponding DRM file is closed. Drivers need not worry about whether the
> + * DRM file for this event still exists and can call this function upon
> + * completion of the asynchronous work unconditionally.
> + */
> +void drm_send_event_timestamp_locked(struct drm_device *dev,
> + struct drm_pending_event *e, ktime_t timestamp)
> +{
> + assert_spin_locked(&dev->event_lock);
> +
> + if (e->completion) {
> + complete_all(e->completion);
> + e->completion_release(e->completion);
> + e->completion = NULL;
> + }
> +
> + if (e->fence) {
> + dma_fence_signal_timestamp(e->fence, timestamp);
> + dma_fence_put(e->fence);
> + }
> +
> + if (!e->file_priv) {
> + kfree(e);
> + return;
> + }
> +
> + list_del(&e->pending_link);
> + list_add_tail(&e->link,
> + &e->file_priv->event_list);
> + wake_up_interruptible(&e->file_priv->event_wait);
> +}
> +EXPORT_SYMBOL(drm_send_event_timestamp_locked);
This seems to duplicate much of drm_send_event_locked(). Should a
common backend function be used between them?
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/40] [Set 11] Rid W=1 warnings from GPU
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. 300 out of 5000 left! Lee Jones (40): drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc drm/nouveau/dispnv50/disp: Remove unused variable 'ret' drm/msm/dp/dp_display: Remove unused variable 'hpd' drm/amd/amdgpu/amdgpu_ih: Update 'amdgpu_ih_decode_iv_helper()'s function header drm/amd/amdgpu/vega20_ih: Add missing descriptions for 'ih' and fix spelling error drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0: Provide description of 'call_back_func' drm/amd/pm/powerplay/hwmgr/ppatomctrl: Fix documentation for 'mpll_param' drm/amd/pm/powerplay/hwmgr/vega12_hwmgr: Fix legacy function header formatting drm/amd/pm/powerplay/hwmgr/vega20_hwmgr: Fix legacy function header formatting drm/amd/pm/powerplay/hwmgr/smu7_hwmgr: Fix formatting and spelling issues drm/amd/pm/powerplay/hwmgr/hwmgr: Move prototype into shared header drm/amd/pm/powerplay/hwmgr/vega10_hwmgr: Fix a bunch of kernel-doc formatting issues drm/amd/display/dc/basics/conversion: Demote obvious kernel-doc abuse drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs: Demote non-kernel-doc comment blocks drm/amd/display/dc/bios/command_table_helper: Fix kernel-doc formatting drm/amd/display/dc/bios/command_table_helper2: Fix legacy formatting problems drm/amd/display/dc/bios/bios_parser: Make local functions static drm/amd/display/dc/bios/bios_parser: Fix a whole bunch of legacy doc formatting drm/amd/display/dc/bios/command_table: Remove unused variable include: drm: drm_atomic: Make use of 'new_plane_state' drm/amd/display/dc/calcs/dce_calcs: Remove unused variables 'v_filter_init_mode' and 'sclk_lvl' drm/amd/display/dc/bios/bios_parser2: Fix some formatting issues and missing parameter docs drm/amd/display/dc/dce/dce_audio: Make function invoked by reference static drm/amd/display/dc/dce/dce_stream_encoder: Remove unused variable 'regval' drm/amd/display/dc/dce/dce_link_encoder: Make functions invoked by reference static drm/amd/display/dc/dce/dce_clock_source: Fix formatting/spelling of worthy function headers drm/amd/pm/powerplay/hwmgr/vega10_hwmgr: Fix worthy function headers, demote barely documented one drm/amd/display/dc/dce/dce_transform: Remove 3 unused/legacy variables drm/amd/display/dc/dce/dce_dmcu: Staticify local function call 'dce_dmcu_load_iram' drm/amd/display/dc/dce/dce_dmcu: Move 'abm_gain_stepsize' to only source file it's used in drm/amd/display/dc/dce/dce_opp: Make local functions and ones invoked by reference static drm/amd/display/dc/dce/dce_aux: Remove unused function 'get_engine_type' drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc headers drm/amd/display/dc/bios/bios_parser: Fix misspelling of function parameter drm/amd/display/dc/bios/command_table: Remove unused variable and associated comment drm/amd/display/dc/dce/dce_i2c_hw: Make functions called by reference static drm/amd/display/dc/dce/dce_i2c_sw: Make a bunch of local functions static drm/amd/display/dc/dce/dce_panel_cntl: Remove unused variables 'bl_pwm_cntl' and 'pwm_period_cntl' drm/amd/display/dc/dce/dmub_psr: Demote non-conformant kernel-doc headers drm/amd/display/dc/gpio/hw_factory: Delete unused function 'dal_hw_factory_destroy' drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c| 2 + drivers/gpu/drm/amd/amdgpu/vega20_ih.c| 5 +- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 +- .../drm/amd/display/dc/basics/conversion.c| 9 +- .../gpu/drm/amd/display/dc/bios/bios_parser.c | 119 +- .../drm/amd/display/dc/bios/bios_parser2.c| 29 ++- .../drm/amd/display/dc/bios/command_table.c | 16 +- .../display/dc/bios/command_table_helper.c| 20 +- .../display/dc/bios/command_table_helper2.c | 20 +- .../gpu/drm/amd/display/dc/calcs/dce_calcs.c | 8 +- .../gpu/drm/amd/display/dc/dce/dce_audio.c| 2 +- drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 6 - .../drm/amd/display/dc/dce/dce_clock_source.c | 57 +++-- drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c | 6 +- drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.h | 2 - .../gpu/drm/amd/display/dc/dce/dce_i2c_hw.c | 4 +- .../gpu/drm/amd/display/dc/dce/dce_i2c_sw.c | 9 +- .../drm/amd/display/dc/dce/dce_link_encoder.c | 6 +- drivers/gpu/drm/amd/display/dc/dce/dce_opp.c | 8 +- .../drm/amd/display/dc/dce/dce_panel_cntl.c | 8 +- .../amd/display/dc/dce/dce_stream_encoder.c | 3 +- .../drm/amd/display/dc/dce/dce_transform.c| 13 -- drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 22 +- .../gpu/drm/amd/display/dc/gpio/hw_factory.c | 14 -- .../gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c| 2 +- .../drm/amd/pm/powerplay/hwmgr/ppatomctrl.c | 4 +- .../powerplay/
[PATCH 01/40] drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function
parameter or member 'init' not described in 'init_reserved'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: Function
parameter or member 'init' not described in 'init_done'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:622: warning: Function
parameter or member 'init' not described in 'init_io_restrict_prog'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:659: warning: Function
parameter or member 'init' not described in 'init_repeat'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:685: warning: Function
parameter or member 'init' not described in 'init_io_restrict_pll'
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:725: warning: Function
parameter or member 'init' not described in 'init_end_repeat'
NB: Trimmed for brevity (lots of these!)
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
.../gpu/drm/nouveau/nvkm/subdev/bios/init.c | 204 ++
1 file changed, 68 insertions(+), 136 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index 9de74f41dcd2a..5a91dc4e5c8ec 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
@@ -575,9 +575,8 @@ init_tmds_reg(struct nvbios_init *init, u8 tmds)
* init opcode handlers
*/
-/**
+/*
* init_reserved - stub for various unknown/unused single-byte opcodes
- *
*/
static void
init_reserved(struct nvbios_init *init)
@@ -602,9 +601,8 @@ init_reserved(struct nvbios_init *init)
init->offset += length;
}
-/**
+/*
* INIT_DONE - opcode 0x71
- *
*/
static void
init_done(struct nvbios_init *init)
@@ -613,9 +611,8 @@ init_done(struct nvbios_init *init)
init->offset = 0x;
}
-/**
+/*
* INIT_IO_RESTRICT_PROG - opcode 0x32
- *
*/
static void
init_io_restrict_prog(struct nvbios_init *init)
@@ -650,9 +647,8 @@ init_io_restrict_prog(struct nvbios_init *init)
trace("}]\n");
}
-/**
+/*
* INIT_REPEAT - opcode 0x33
- *
*/
static void
init_repeat(struct nvbios_init *init)
@@ -676,9 +672,8 @@ init_repeat(struct nvbios_init *init)
init->repeat = repeat;
}
-/**
+/*
* INIT_IO_RESTRICT_PLL - opcode 0x34
- *
*/
static void
init_io_restrict_pll(struct nvbios_init *init)
@@ -716,9 +711,8 @@ init_io_restrict_pll(struct nvbios_init *init)
trace("}]\n");
}
-/**
+/*
* INIT_END_REPEAT - opcode 0x36
- *
*/
static void
init_end_repeat(struct nvbios_init *init)
@@ -732,9 +726,8 @@ init_end_repeat(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_COPY - opcode 0x37
- *
*/
static void
init_copy(struct nvbios_init *init)
@@ -759,9 +752,8 @@ init_copy(struct nvbios_init *init)
init_wrvgai(init, port, index, data);
}
-/**
+/*
* INIT_NOT - opcode 0x38
- *
*/
static void
init_not(struct nvbios_init *init)
@@ -771,9 +763,8 @@ init_not(struct nvbios_init *init)
init_exec_inv(init);
}
-/**
+/*
* INIT_IO_FLAG_CONDITION - opcode 0x39
- *
*/
static void
init_io_flag_condition(struct nvbios_init *init)
@@ -788,9 +779,8 @@ init_io_flag_condition(struct nvbios_init *init)
init_exec_set(init, false);
}
-/**
+/*
* INIT_GENERIC_CONDITION - opcode 0x3a
- *
*/
static void
init_generic_condition(struct nvbios_init *init)
@@ -840,9 +830,8 @@ init_generic_condition(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_IO_MASK_OR - opcode 0x3b
- *
*/
static void
init_io_mask_or(struct nvbios_init *init)
@@ -859,9 +848,8 @@ init_io_mask_or(struct nvbios_init *init)
init_wrvgai(init, 0x03d4, index, data &= ~(1 << or));
}
-/**
+/*
* INIT_IO_OR - opcode 0x3c
- *
*/
static void
init_io_or(struct nvbios_init *init)
@@ -878,9 +866,8 @@ init_io_or(struct nvbios_init *init)
init_wrvgai(init, 0x03d4, index, data | (1 << or));
}
-/**
+/*
* INIT_ANDN_REG - opcode 0x47
- *
*/
static void
init_andn_reg(struct nvbios_init *init)
@@ -895,9 +882,8 @@ init_andn_reg(struct nvbios_init *init)
init_mask(init, reg, mask, 0);
}
-/**
+/*
* INIT_OR_REG - opcode 0x48
- *
*/
static void
init_or_reg(struct nvbios_init *init)
@@ -912,9 +898,8 @@ init_or_reg(struct nvbios_init *init)
init_mask(init, reg, 0, mask);
}
-/**
+/*
* INIT_INDEX_ADDRESS_LATCHED - opcode 0x49
- *
*/
static void
init_idx_addr_latched(struct nvbios_init *init)
@@ -942,9 +927,8 @@ init_idx_addr_latched(struct nvbios_init *init)
}
}
-/**
+/*
* INIT_IO_RESTRICT_PLL2 - opcode 0x4a
- *
*/
static void
init_io_restrict_pll2(struct nvbios_init *init)
@@ -977,9 +961,8 @@ init_io_restrict_pll2(struct nvbios_init *init)
trace("}]\n");
}
-/**
+/*
* INIT_PL
[PATCH 02/40] drm/nouveau/dispnv50/disp: Remove unused variable 'ret'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/dispnv50/disp.c:1381:6: warning: variable ‘ret’ set
but not used [-Wunused-but-set-variable]
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 33fff388dd83c..b615204c2cba6 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1378,10 +1378,9 @@ nv50_mstm_prepare(struct nv50_mstm *mstm)
{
struct nouveau_drm *drm = nouveau_drm(mstm->outp->base.base.dev);
struct drm_encoder *encoder;
- int ret;
NV_ATOMIC(drm, "%s: mstm prepare\n", mstm->outp->base.base.name);
- ret = drm_dp_update_payload_part1(&mstm->mgr);
+ drm_dp_update_payload_part1(&mstm->mgr);
drm_for_each_encoder(encoder, mstm->outp->base.base.dev) {
if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST) {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/40] drm/msm/dp/dp_display: Remove unused variable 'hpd'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/dp/dp_display.c: In function
‘dp_display_usbpd_attention_cb’:
drivers/gpu/drm/msm/dp/dp_display.c:496:19: warning: variable ‘hpd’ set but
not used [-Wunused-but-set-variable]
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Kuogee Hsieh
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/msm/dp/dp_display.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 6e971d552911f..637a5585c2fd8 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -493,7 +493,6 @@ static int dp_display_usbpd_attention_cb(struct device *dev)
int rc = 0;
u32 sink_request;
struct dp_display_private *dp;
- struct dp_usbpd *hpd;
if (!dev) {
DRM_ERROR("invalid dev\n");
@@ -507,8 +506,6 @@ static int dp_display_usbpd_attention_cb(struct device *dev)
return -ENODEV;
}
- hpd = dp->usbpd;
-
/* check for any test request issued by sink */
rc = dp_link_process_request(dp->link);
if (!rc) {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/40] drm/amd/amdgpu/amdgpu_ih: Update 'amdgpu_ih_decode_iv_helper()'s function header
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c:220: warning: Function parameter or member 'ih' not described in 'amdgpu_ih_decode_iv_helper' drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c:220: warning: Function parameter or member 'entry' not described in 'amdgpu_ih_decode_iv_helper' Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: Felix Kuehling Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c index 725a9c73d51f0..dc852af4f3b76 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c @@ -209,6 +209,8 @@ int amdgpu_ih_process(struct amdgpu_device *adev, struct amdgpu_ih_ring *ih) * amdgpu_ih_decode_iv_helper - decode an interrupt vector * * @adev: amdgpu_device pointer + * @ih: ih ring to process + * @entry: IV entry * * Decodes the interrupt vector at the current rptr * position and also advance the position for for Vega10 -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/40] drm/amd/amdgpu/vega20_ih: Add missing descriptions for 'ih' and fix spelling error
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/vega20_ih.c:378: warning: Function parameter or member 'ih' not described in 'vega20_ih_get_wptr' drivers/gpu/drm/amd/amdgpu/vega20_ih.c:421: warning: Function parameter or member 'ih' not described in 'vega20_ih_irq_rearm' drivers/gpu/drm/amd/amdgpu/vega20_ih.c:447: warning: Function parameter or member 'ih' not described in 'vega20_ih_set_rptr' Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: Hawking Zhang Cc: Feifei Xu Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/vega20_ih.c b/drivers/gpu/drm/amd/amdgpu/vega20_ih.c index 42032ca380ccf..5a3c867d58811 100644 --- a/drivers/gpu/drm/amd/amdgpu/vega20_ih.c +++ b/drivers/gpu/drm/amd/amdgpu/vega20_ih.c @@ -88,7 +88,7 @@ static void vega20_ih_init_register_offset(struct amdgpu_device *adev) * vega20_ih_toggle_ring_interrupts - toggle the interrupt ring buffer * * @adev: amdgpu_device pointer - * @ih: amdgpu_ih_ring pointet + * @ih: amdgpu_ih_ring pointer * @enable: true - enable the interrupts, false - disable the interrupts * * Toggle the interrupt ring buffer (VEGA20) @@ -367,6 +367,7 @@ static void vega20_ih_irq_disable(struct amdgpu_device *adev) * vega20_ih_get_wptr - get the IH ring buffer wptr * * @adev: amdgpu_device pointer + * @ih: amdgpu_ih_ring pointer * * Get the IH ring buffer wptr from either the register * or the writeback memory buffer (VEGA20). Also check for @@ -414,6 +415,7 @@ static u32 vega20_ih_get_wptr(struct amdgpu_device *adev, * vega20_ih_irq_rearm - rearm IRQ if lost * * @adev: amdgpu_device pointer + * @ih: amdgpu_ih_ring pointer * */ static void vega20_ih_irq_rearm(struct amdgpu_device *adev, @@ -439,6 +441,7 @@ static void vega20_ih_irq_rearm(struct amdgpu_device *adev, * vega20_ih_set_rptr - set the IH ring buffer rptr * * @adev: amdgpu_device pointer + * @ih: amdgpu_ih_ring pointer * * Set the IH ring buffer rptr. */ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/40] drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0: Provide description of 'call_back_func'
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:1371: warning: Function parameter or member 'call_back_func' not described in 'get_powerplay_table_entry_v1_0' Cc: Evan Quan Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0.c index 741e03ad5311f..f2a55c1413f59 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0.c +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0.c @@ -1362,6 +1362,7 @@ static int ppt_get_vce_state_table_entry_v1_0(struct pp_hwmgr *hwmgr, uint32_t i * @hwmgr: Pointer to the hardware manager. * @entry_index: The index of the entry to be extracted from the table. * @power_state: The address of the PowerState instance being created. + * @call_back_func: The function to call into to fill power state * Return: -1 if the entry cannot be retrieved. */ int get_powerplay_table_entry_v1_0(struct pp_hwmgr *hwmgr, -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/40] drm/amd/pm/powerplay/hwmgr/vega12_hwmgr: Fix legacy function header formatting
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega12_hwmgr.c:728: warning:
Function parameter or member 'hwmgr' not described in 'vega12_init_smc_table'
Cc: Evan Quan
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_hwmgr.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_hwmgr.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_hwmgr.c
index dc206fa88c5e5..c0753029a8e2a 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega12_hwmgr.c
@@ -718,12 +718,11 @@ static int vega12_save_default_power_profile(struct
pp_hwmgr *hwmgr)
#endif
/**
-* Initializes the SMC table and uploads it
-*
-* @paramhwmgr the address of the powerplay hardware manager.
-* @parampInput the pointer to input data (PowerState)
-* @return always 0
-*/
+ * Initializes the SMC table and uploads it
+ *
+ * @hwmgr: the address of the powerplay hardware manager.
+ * return: always 0
+ */
static int vega12_init_smc_table(struct pp_hwmgr *hwmgr)
{
int result;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/40] drm/amd/pm/powerplay/hwmgr/vega10_hwmgr: Fix a bunch of kernel-doc formatting issues
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:5474:5:
warning: no previous prototype for ‘vega10_hwmgr_init’ [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:551: warning:
Function parameter or member 'hwmgr' not described in 'vega10_get_evv_voltages'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:609: warning:
Function parameter or member 'hwmgr' not described in
'vega10_patch_with_vdd_leakage'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:609: warning:
Function parameter or member 'voltage' not described in
'vega10_patch_with_vdd_leakage'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:609: warning:
Function parameter or member 'leakage_table' not described in
'vega10_patch_with_vdd_leakage'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:637: warning:
Function parameter or member 'hwmgr' not described in
'vega10_patch_lookup_table_with_leakage'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:637: warning:
Function parameter or member 'lookup_table' not described in
'vega10_patch_lookup_table_with_leakage'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:637: warning:
Function parameter or member 'leakage_table' not described in
'vega10_patch_lookup_table_with_leakage'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:1013: warning:
Function parameter or member 'hwmgr' not described in
'vega10_trim_voltage_table'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:1013: warning:
Function parameter or member 'vol_table' not described in
'vega10_trim_voltage_table'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:1160: warning:
Function parameter or member 'hwmgr' not described in
'vega10_construct_voltage_tables'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:1558: warning:
Function parameter or member 'hwmgr' not described in
'vega10_populate_single_gfx_level'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:1558: warning:
Function parameter or member 'gfx_clock' not described in
'vega10_populate_single_gfx_level'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:1558: warning:
Function parameter or member 'current_gfxclk_level' not described in
'vega10_populate_single_gfx_level'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:1558: warning:
Function parameter or member 'acg_freq' not described in
'vega10_populate_single_gfx_level'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:1613: warning:
Cannot understand * @brief Populates single SMC SOCCLK structure using the
provided clock.
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:1667: warning:
Function parameter or member 'hwmgr' not described in
'vega10_populate_all_graphic_levels'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:1750: warning:
Cannot understand * @brief Populates single SMC GFXCLK structure using the
provided clock.
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:1811: warning:
Cannot understand * @brief Populates all SMC MCLK levels' structure based on
the trimmed allowed dpm memory clock states.
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:2496: warning:
Function parameter or member 'hwmgr' not described in 'vega10_init_smc_table'
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:2867: warning:
Cannot understand * @brief Tell SMC to enabled the supported DPMs.
Cc: Evan Quan
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
.../drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c | 133 +-
1 file changed, 65 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c
index 1b47f94e03317..da470462d6e2c 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c
@@ -542,11 +542,11 @@ static int vega10_get_socclk_for_voltage_evv(struct
pp_hwmgr *hwmgr,
#define ATOM_VIRTUAL_VOLTAGE_ID0 0xff01
/**
-* Get Leakage VDDC based on leakage ID.
-*
-* @paramhwmgr the address of the powerplay hardware manager.
-* @return always 0.
-*/
+ * Get Leakage VDDC based on leakage ID.
+ *
+ * @hwmgr: the address of the powerplay hardware manager.
+ * return: always 0.
+ */
static int vega10_get_evv_voltages(struct pp_hwmgr *hwmgr)
{
struct vega10_hwmgr *data = hwmgr->backend;
@@ -600,9 +600,9 @@ static int vega10_get_evv_voltages(struct pp_hwmgr *hwmgr)
/**
* Change virtual leakage voltage to actual value.
*
- * @param hwmgr the address of the powerplay hardwar
[PATCH 13/40] drm/amd/display/dc/basics/conversion: Demote obvious kernel-doc abuse
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/basics/conversion.c:86: warning: Function parameter or member 'matrix' not described in 'convert_float_matrix' drivers/gpu/drm/amd/amdgpu/../display/dc/basics/conversion.c:86: warning: Function parameter or member 'flt' not described in 'convert_float_matrix' drivers/gpu/drm/amd/amdgpu/../display/dc/basics/conversion.c:86: warning: Function parameter or member 'buffer_size' not described in 'convert_float_matrix' drivers/gpu/drm/amd/amdgpu/../display/dc/basics/conversion.c:86: warning: Excess function parameter 'param' description in 'convert_float_matrix' Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: Lee Jones Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/display/dc/basics/conversion.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/basics/conversion.c b/drivers/gpu/drm/amd/display/dc/basics/conversion.c index 24ed03d8cda74..6767fab55c260 100644 --- a/drivers/gpu/drm/amd/display/dc/basics/conversion.c +++ b/drivers/gpu/drm/amd/display/dc/basics/conversion.c @@ -73,12 +73,9 @@ uint16_t fixed_point_to_int_frac( return result; } -/** -* convert_float_matrix -* This converts a double into HW register spec defined format S2D13. -* @param : -* @return None -*/ +/* + * convert_float_matrix - This converts a double into HW register spec defined format S2D13. + */ void convert_float_matrix( uint16_t *matrix, struct fixed31_32 *flt, -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/40] drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs: Demote non-kernel-doc comment blocks
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:699: warning: Function parameter or member 'm' not described in 'dmub_tracebuffer_show' drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:699: warning: Function parameter or member 'data' not described in 'dmub_tracebuffer_show' drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:743: warning: Function parameter or member 'm' not described in 'dmub_fw_state_show' drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:743: warning: Function parameter or member 'data' not described in 'dmub_fw_state_show' Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: Mikita Lipski Cc: Eryk Brol Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c index 11459fb09a372..d645f3e4610eb 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c @@ -691,7 +691,7 @@ static ssize_t dp_phy_test_pattern_debugfs_write(struct file *f, const char __us return size; } -/** +/* * Returns the DMCUB tracebuffer contents. * Example usage: cat /sys/kernel/debug/dri/0/amdgpu_dm_dmub_tracebuffer */ @@ -735,7 +735,7 @@ static int dmub_tracebuffer_show(struct seq_file *m, void *data) return 0; } -/** +/* * Returns the DMCUB firmware state contents. * Example usage: cat /sys/kernel/debug/dri/0/amdgpu_dm_dmub_fw_state */ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 16/40] drm/amd/display/dc/bios/command_table_helper2: Fix legacy formatting problems
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table_helper2.c:145:
warning: Function parameter or member 't' not described in
'dal_cmd_table_helper_transmitter_bp_to_atom2'
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
.../display/dc/bios/command_table_helper2.c | 20 ---
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table_helper2.c
b/drivers/gpu/drm/amd/display/dc/bios/command_table_helper2.c
index 7736c92d55c40..455ee2be15a36 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table_helper2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table_helper2.c
@@ -128,18 +128,14 @@ bool dal_cmd_table_helper_controller_id_to_atom2(
}
/**
-* translate_transmitter_bp_to_atom
-*
-* @brief
-* Translate the Transmitter to the corresponding ATOM BIOS value
-*
-* @param
-* input transmitter
-* output digitalTransmitter
-*// =00: Digital Transmitter1 ( UNIPHY linkAB )
-*// =01: Digital Transmitter2 ( UNIPHY linkCD )
-*// =02: Digital Transmitter3 ( UNIPHY linkEF )
-*/
+ * translate_transmitter_bp_to_atom2 - Translate the Transmitter to the
+ * corresponding ATOM BIOS value
+ * @t: transmitter
+ * returns: digitalTransmitter
+ *// =00: Digital Transmitter1 ( UNIPHY linkAB )
+ *// =01: Digital Transmitter2 ( UNIPHY linkCD )
+ *// =02: Digital Transmitter3 ( UNIPHY linkEF )
+ */
uint8_t dal_cmd_table_helper_transmitter_bp_to_atom2(
enum transmitter t)
{
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/40] drm/amd/display/dc/bios/command_table_helper: Fix kernel-doc formatting
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table_helper.c:131:
warning: Function parameter or member 't' not described in
'dal_cmd_table_helper_transmitter_bp_to_atom'
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Mauro Rossi
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
.../display/dc/bios/command_table_helper.c| 20 ---
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.c
b/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.c
index 48b4ef03fc8f8..5b77251e05909 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table_helper.c
@@ -114,18 +114,14 @@ bool dal_cmd_table_helper_controller_id_to_atom(
}
/**
-* translate_transmitter_bp_to_atom
-*
-* @brief
-* Translate the Transmitter to the corresponding ATOM BIOS value
-*
-* @param
-* input transmitter
-* output digitalTransmitter
-*// =00: Digital Transmitter1 ( UNIPHY linkAB )
-*// =01: Digital Transmitter2 ( UNIPHY linkCD )
-*// =02: Digital Transmitter3 ( UNIPHY linkEF )
-*/
+ * translate_transmitter_bp_to_atom - Translate the Transmitter to the
+ *corresponding ATOM BIOS value
+ * @t: transmitter
+ * returns: output digitalTransmitter
+ *// =00: Digital Transmitter1 ( UNIPHY linkAB )
+ *// =01: Digital Transmitter2 ( UNIPHY linkCD )
+ *// =02: Digital Transmitter3 ( UNIPHY linkEF )
+ */
uint8_t dal_cmd_table_helper_transmitter_bp_to_atom(
enum transmitter t)
{
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 17/40] drm/amd/display/dc/bios/bios_parser: Make local functions static
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:2588:16: warning: no previous prototype for ‘update_slot_layout_info’ [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:2692:16: warning: no previous prototype for ‘get_bracket_layout_record’ [-Wmissing-prototypes] Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: Igor Kravchenko Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/display/dc/bios/bios_parser.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c index 23a373ca94b5c..f054c5872c619 100644 --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c @@ -2585,7 +2585,7 @@ static struct integrated_info *bios_parser_create_integrated_info( return NULL; } -enum bp_result update_slot_layout_info( +static enum bp_result update_slot_layout_info( struct dc_bios *dcb, unsigned int i, struct slot_layout_info *slot_layout_info, @@ -2689,7 +2689,7 @@ enum bp_result update_slot_layout_info( } -enum bp_result get_bracket_layout_record( +static enum bp_result get_bracket_layout_record( struct dc_bios *dcb, unsigned int bracket_layout_id, struct slot_layout_info *slot_layout_info) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 18/40] drm/amd/display/dc/bios/bios_parser: Fix a whole bunch of legacy doc formatting
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:2588:16: warning: no previous prototype for ‘update_slot_layout_info’ [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:2692:16: warning: no previous prototype for ‘get_bracket_layout_record’ [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:925: warning: Function parameter or member 'dcb' not described in 'bios_parser_get_spread_spectrum_info' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:925: warning: Function parameter or member 'signal' not described in 'bios_parser_get_spread_spectrum_info' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:925: warning: Function parameter or member 'index' not described in 'bios_parser_get_spread_spectrum_info' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:925: warning: Function parameter or member 'ss_info' not described in 'bios_parser_get_spread_spectrum_info' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:997: warning: Function parameter or member 'bp' not described in 'get_ss_info_from_tbl' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:997: warning: Function parameter or member 'id' not described in 'get_ss_info_from_tbl' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:997: warning: Function parameter or member 'ss_info' not described in 'get_ss_info_from_tbl' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1022: warning: Function parameter or member 'bp' not described in 'get_ss_info_from_internal_ss_info_tbl_V2_1' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1022: warning: Function parameter or member 'id' not described in 'get_ss_info_from_internal_ss_info_tbl_V2_1' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1022: warning: Function parameter or member 'info' not described in 'get_ss_info_from_internal_ss_info_tbl_V2_1' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1087: warning: Function parameter or member 'bp' not described in 'get_ss_info_from_ss_info_table' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1087: warning: Function parameter or member 'id' not described in 'get_ss_info_from_ss_info_table' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1087: warning: Function parameter or member 'ss_info' not described in 'get_ss_info_from_ss_info_table' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1469: warning: Function parameter or member 'dcb' not described in 'bios_parser_get_encoder_cap_info' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1469: warning: Function parameter or member 'object_id' not described in 'bios_parser_get_encoder_cap_info' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1469: warning: Function parameter or member 'info' not described in 'bios_parser_get_encoder_cap_info' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1508: warning: Function parameter or member 'bp' not described in 'get_encoder_cap_record' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1508: warning: Function parameter or member 'object' not described in 'get_encoder_cap_record' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1566: warning: Function parameter or member 'dcb' not described in 'bios_parser_get_ss_entry_number' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1566: warning: Function parameter or member 'signal' not described in 'bios_parser_get_ss_entry_number' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1619: warning: Function parameter or member 'bp' not described in 'get_ss_entry_number_from_ss_info_tbl' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1619: warning: Function parameter or member 'id' not described in 'get_ss_entry_number_from_ss_info_tbl' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1686: warning: Function parameter or member 'bp' not described in 'get_ss_entry_number' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1686: warning: Function parameter or member 'id' not described in 'get_ss_entry_number' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1705: warning: Function parameter or member 'bp' not described in 'get_ss_entry_number_from_internal_ss_info_tbl_v2_1' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1705: warning: Function parameter or member 'id' not described in 'get_ss_entry_number_from_internal_ss_info_tbl_v2_1' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1740: warning: Function parameter or member 'bp' not described in 'get_ss_entry_number_from_internal_ss_info_tbl_V3_1' drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser.c:1740: warning: Function parameter or member 'id' not described in 'get_ss_entry_number_from_intern
[PATCH 07/40] drm/amd/pm/powerplay/hwmgr/ppatomctrl: Fix documentation for 'mpll_param'
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:290: warning: Function parameter or member 'mpll_param' not described in 'atomctrl_get_memory_pll_dividers_si' drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:290: warning: Excess function parameter 'dividers' description in 'atomctrl_get_memory_pll_dividers_si' drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:339: warning: Function parameter or member 'mpll_param' not described in 'atomctrl_get_memory_pll_dividers_vi' drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/ppatomctrl.c:339: warning: Excess function parameter 'dividers' description in 'atomctrl_get_memory_pll_dividers_vi' Cc: Evan Quan Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c index 83a6504e093cb..b1038d30c8dcc 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c @@ -279,7 +279,7 @@ static const ATOM_VOLTAGE_OBJECT_V3 *atomctrl_lookup_voltage_type_v3( * * @hwmgr: input parameter: pointer to HwMgr * @clock_value: input parameter: memory clock - * @dividers:output parameter: memory PLL dividers + * @mpll_param: output parameter: memory clock parameters * @strobe_mode: input parameter: 1 for strobe mode, 0 for performance mode */ int atomctrl_get_memory_pll_dividers_si( @@ -332,7 +332,7 @@ int atomctrl_get_memory_pll_dividers_si( * * @hwmgr: input parameter: pointer to HwMgr * @clock_value: input parameter: memory clock - * @dividers: output parameter: memory PLL dividers + * @mpll_param:output parameter: memory clock parameters */ int atomctrl_get_memory_pll_dividers_vi(struct pp_hwmgr *hwmgr, uint32_t clock_value, pp_atomctrl_memory_clock_param *mpll_param) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 23/40] drm/amd/display/dc/dce/dce_audio: Make function invoked by reference static
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_audio.c:871:6: warning: no previous prototype for ‘dce60_aud_wall_dto_setup’ [-Wmissing-prototypes] Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: Mauro Rossi Cc: Charlene Liu Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/display/dc/dce/dce_audio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c index 2a2a0fdb92539..7866cf2a668fa 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c @@ -868,7 +868,7 @@ void dce_aud_wall_dto_setup( } #if defined(CONFIG_DRM_AMD_DC_SI) -void dce60_aud_wall_dto_setup( +static void dce60_aud_wall_dto_setup( struct audio *audio, enum signal_type signal, const struct audio_crtc_info *crtc_info, -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/40] drm/amd/pm/powerplay/hwmgr/smu7_hwmgr: Fix formatting and spelling issues
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:242: warning: Function parameter or member 'hwmgr' not described in 'smu7_enable_smc_voltage_controller' drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:4508: warning: Function parameter or member 'us_max_fan_rpm' not described in 'smu7_set_max_fan_rpm_output' drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/smu7_hwmgr.c:4508: warning: Excess function parameter 'usMaxFanRpm' description in 'smu7_set_max_fan_rpm_output' Cc: Evan Quan Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c index 82676c086ce46..c57dc9ae81f2f 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c @@ -235,7 +235,7 @@ static int smu7_get_current_pcie_lane_number(struct pp_hwmgr *hwmgr) /** * smu7_enable_smc_voltage_controller - Enable voltage control * - * @hwmgr the address of the powerplay hardware manager. + * @hwmgr: the address of the powerplay hardware manager. * Return: always PP_Result_OK */ static int smu7_enable_smc_voltage_controller(struct pp_hwmgr *hwmgr) @@ -4501,7 +4501,7 @@ static int smu7_display_configuration_changed_task(struct pp_hwmgr *hwmgr) * smu7_set_max_fan_rpm_output - Set maximum target operating fan output RPM * * @hwmgr: the address of the powerplay hardware manager. - * @usMaxFanRpm: max operating fan RPM value. + * @us_max_fan_rpm: max operating fan RPM value. * Return: The response that came from the SMC. */ static int smu7_set_max_fan_rpm_output(struct pp_hwmgr *hwmgr, uint16_t us_max_fan_rpm) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/40] drm/amd/pm/powerplay/hwmgr/vega20_hwmgr: Fix legacy function header formatting
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega20_hwmgr.c:781: warning:
Function parameter or member 'hwmgr' not described in 'vega20_init_smc_table'
Cc: Evan Quan
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.c
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.c
index da84012b7fd51..87811b005b85f 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.c
@@ -771,12 +771,11 @@ static int vega20_setup_default_dpm_tables(struct
pp_hwmgr *hwmgr)
}
/**
-* Initializes the SMC table and uploads it
-*
-* @paramhwmgr the address of the powerplay hardware manager.
-* @parampInput the pointer to input data (PowerState)
-* @return always 0
-*/
+ * Initializes the SMC table and uploads it
+ *
+ * @hwmgr: the address of the powerplay hardware manager.
+ * return: always 0
+ */
static int vega20_init_smc_table(struct pp_hwmgr *hwmgr)
{
int result;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 25/40] drm/amd/display/dc/dce/dce_link_encoder: Make functions invoked by reference static
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_link_encoder.c:1200:6:
warning: no previous prototype for ‘dce60_link_encoder_enable_dp_output’
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_link_encoder.c:1239:6:
warning: no previous prototype for ‘dce60_link_encoder_enable_dp_mst_output’
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_link_encoder.c:1429:6:
warning: no previous prototype for ‘dce60_link_encoder_dp_set_phy_pattern’
[-Wmissing-prototypes]
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Mauro Rossi
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
index 210466b2d8631..0ef2f4d9d8bf3 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
@@ -1197,7 +1197,7 @@ void dce110_link_encoder_enable_dp_mst_output(
#if defined(CONFIG_DRM_AMD_DC_SI)
/* enables DP PHY output */
-void dce60_link_encoder_enable_dp_output(
+static void dce60_link_encoder_enable_dp_output(
struct link_encoder *enc,
const struct dc_link_settings *link_settings,
enum clock_source_id clock_source)
@@ -1236,7 +1236,7 @@ void dce60_link_encoder_enable_dp_output(
}
/* enables DP PHY output in MST mode */
-void dce60_link_encoder_enable_dp_mst_output(
+static void dce60_link_encoder_enable_dp_mst_output(
struct link_encoder *enc,
const struct dc_link_settings *link_settings,
enum clock_source_id clock_source)
@@ -1426,7 +1426,7 @@ void dce110_link_encoder_dp_set_phy_pattern(
#if defined(CONFIG_DRM_AMD_DC_SI)
/* set DP PHY test and training patterns */
-void dce60_link_encoder_dp_set_phy_pattern(
+static void dce60_link_encoder_dp_set_phy_pattern(
struct link_encoder *enc,
const struct encoder_set_dp_phy_pattern_param *param)
{
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 26/40] drm/amd/display/dc/dce/dce_clock_source: Fix formatting/spelling of worthy function headers
Demote the one that provides no param descriptions. Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:142: warning: Function parameter or member 'calc_pll_cs' not described in 'calculate_fb_and_fractional_fb_divider' drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:142: warning: Function parameter or member 'target_pix_clk_100hz' not described in 'calculate_fb_and_fractional_fb_divider' drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:142: warning: Function parameter or member 'ref_divider' not described in 'calculate_fb_and_fractional_fb_divider' drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:142: warning: Function parameter or member 'post_divider' not described in 'calculate_fb_and_fractional_fb_divider' drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:142: warning: Function parameter or member 'feedback_divider_param' not described in 'calculate_fb_and_fractional_fb_divider' drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:142: warning: Function parameter or member 'fract_feedback_divider_param' not described in 'calculate_fb_and_fractional_fb_divider' drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:200: warning: Function parameter or member 'calc_pll_cs' not described in 'calc_fb_divider_checking_tolerance' drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:200: warning: Function parameter or member 'pll_settings' not described in 'calc_fb_divider_checking_tolerance' drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:200: warning: Function parameter or member 'ref_divider' not described in 'calc_fb_divider_checking_tolerance' drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:200: warning: Function parameter or member 'post_divider' not described in 'calc_fb_divider_checking_tolerance' drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:200: warning: Function parameter or member 'tolerance' not described in 'calc_fb_divider_checking_tolerance' drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:478: warning: Function parameter or member 'clk_src' not described in 'dce110_get_pix_clk_dividers_helper' drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:478: warning: Function parameter or member 'pll_settings' not described in 'dce110_get_pix_clk_dividers_helper' drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:478: warning: Function parameter or member 'pix_clk_params' not described in 'dce110_get_pix_clk_dividers_helper' Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: Bhawanpreet Lakha Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- .../drm/amd/display/dc/dce/dce_clock_source.c | 57 +-- 1 file changed, 28 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c index fb733f573715e..10938a8c9500a 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c @@ -113,20 +113,19 @@ static const struct spread_spectrum_data *get_ss_data_entry( } /** - * Function: calculate_fb_and_fractional_fb_divider + * calculate_fb_and_fractional_fb_divider - Calculates feedback and fractional + * feedback dividers values * - * * DESCRIPTION: Calculates feedback and fractional feedback dividers values + * @calc_pll_cs: Pointer to clock source information + * @target_pix_clk_100hz: Desired frequency in 100 Hz + * @ref_divider:Reference divider (already known) + * @post_divider: Post Divider (already known) + * @feedback_divider_param: Pointer where to store + * calculated feedback divider value + * @fract_feedback_divider_param: Pointer where to store + * calculated fract feedback divider value * - *PARAMETERS: - * targetPixelClock Desired frequency in 100 Hz - * ref_divider Reference divider (already known) - * postDivider Post Divider (already known) - * feedback_divider_param Pointer where to store - * calculated feedback divider value - * fract_feedback_divider_param Pointer where to store - * calculated fract feedback divider value - * - *RETURNS: + * return: * It fills the locations pointed by feedback_divider_param * and fract_feedback_divider_param * It returns - true if feedback divider not 0 @@ -175,22 +174,22 @@ static bool calculate_fb_and_fractional_fb_divider( } /** -*calc_fb_divider_checking_tolerance -* -*DESCRIPTION: Calculates
[PATCH 11/40] drm/amd/pm/powerplay/hwmgr/hwmgr: Move prototype into shared header
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:5474:5: warning: no previous prototype for ‘vega10_hwmgr_init’ [-Wmissing-prototypes] Cc: Evan Quan Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c| 2 +- drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c index 6a7de8b898faf..f2cef0930aa96 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/hwmgr.c @@ -33,6 +33,7 @@ #include "ppsmc.h" #include "amd_acpi.h" #include "pp_psm.h" +#include "vega10_hwmgr.h" extern const struct pp_smumgr_func ci_smu_funcs; extern const struct pp_smumgr_func smu8_smu_funcs; @@ -46,7 +47,6 @@ extern const struct pp_smumgr_func vega12_smu_funcs; extern const struct pp_smumgr_func smu10_smu_funcs; extern const struct pp_smumgr_func vega20_smu_funcs; -extern int vega10_hwmgr_init(struct pp_hwmgr *hwmgr); extern int smu10_init_function_pointers(struct pp_hwmgr *hwmgr); static int polaris_set_asic_special_caps(struct pp_hwmgr *hwmgr); diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.h b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.h index f752b4ad0c8ae..07c06f8c90b09 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.h +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.h @@ -442,5 +442,6 @@ int vega10_update_uvd_dpm(struct pp_hwmgr *hwmgr, bool bgate); int vega10_update_samu_dpm(struct pp_hwmgr *hwmgr, bool bgate); int vega10_update_acp_dpm(struct pp_hwmgr *hwmgr, bool bgate); int vega10_enable_disable_vce_dpm(struct pp_hwmgr *hwmgr, bool enable); +int vega10_hwmgr_init(struct pp_hwmgr *hwmgr); #endif /* _VEGA10_HWMGR_H_ */ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 31/40] drm/amd/display/dc/dce/dce_opp: Make local functions and ones invoked by reference static
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_opp.c:427:6: warning: no
previous prototype for ‘dce60_opp_set_clamping’ [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_opp.c:548:6: warning: no
previous prototype for ‘dce60_opp_program_bit_depth_reduction’
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_opp.c:571:6: warning: no
previous prototype for ‘dce60_opp_program_clamping_and_pixel_encoding’
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_opp.c:681:6: warning: no
previous prototype for ‘dce60_opp_program_fmt’ [-Wmissing-prototypes]
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Mauro Rossi
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/display/dc/dce/dce_opp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c
index e459ae65aaf76..2bf8f5a2e0c22 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_opp.c
@@ -424,7 +424,7 @@ void dce110_opp_set_clamping(
* 7 for programable
* 2) Enable clamp if Limited range requested
*/
-void dce60_opp_set_clamping(
+static void dce60_opp_set_clamping(
struct dce110_opp *opp110,
const struct clamping_and_pixel_encoding_params *params)
{
@@ -545,7 +545,7 @@ void dce110_opp_program_bit_depth_reduction(
}
#if defined(CONFIG_DRM_AMD_DC_SI)
-void dce60_opp_program_bit_depth_reduction(
+static void dce60_opp_program_bit_depth_reduction(
struct output_pixel_processor *opp,
const struct bit_depth_reduction_params *params)
{
@@ -568,7 +568,7 @@ void dce110_opp_program_clamping_and_pixel_encoding(
}
#if defined(CONFIG_DRM_AMD_DC_SI)
-void dce60_opp_program_clamping_and_pixel_encoding(
+static void dce60_opp_program_clamping_and_pixel_encoding(
struct output_pixel_processor *opp,
const struct clamping_and_pixel_encoding_params *params)
{
@@ -678,7 +678,7 @@ void dce110_opp_program_fmt(
}
#if defined(CONFIG_DRM_AMD_DC_SI)
-void dce60_opp_program_fmt(
+static void dce60_opp_program_fmt(
struct output_pixel_processor *opp,
struct bit_depth_reduction_params *fmt_bit_depth,
struct clamping_and_pixel_encoding_params *clamping)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 29/40] drm/amd/display/dc/dce/dce_dmcu: Staticify local function call 'dce_dmcu_load_iram'
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_dmcu.c:74:6: warning: no previous prototype for ‘dce_dmcu_load_iram’ [-Wmissing-prototypes] In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_dmcu.c:31: Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: Krunoslav Kovac Cc: amd-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c b/drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c index f3ed8b619cafd..fa2b47d41ee2f 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c @@ -71,7 +71,7 @@ static bool dce_dmcu_init(struct dmcu *dmcu) return true; } -bool dce_dmcu_load_iram(struct dmcu *dmcu, +static bool dce_dmcu_load_iram(struct dmcu *dmcu, unsigned int start_offset, const char *src, unsigned int bytes) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 19/40] drm/amd/display/dc/bios/command_table: Remove unused variable
None of the surrounding code was removed just in case even a small
fraction of it was functional.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c: In function
‘adjust_display_pll_v2’:
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:1459:35:
warning: variable ‘params’ set but not used [-Wunused-but-set-variable]
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Qinglang Miao
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/display/dc/bios/command_table.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
index 070459e3e4070..dd893a1176979 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
@@ -1456,20 +1456,14 @@ static enum bp_result adjust_display_pll_v2(
struct bp_adjust_pixel_clock_parameters *bp_params)
{
enum bp_result result = BP_RESULT_FAILURE;
- ADJUST_DISPLAY_PLL_PS_ALLOCATION params = { 0 };
/* We need to convert from KHz units into 10KHz units and then convert
* output pixel clock back 10KHz-->KHz */
uint32_t pixel_clock_10KHz_in = bp_params->pixel_clock / 10;
- params.usPixelClock = cpu_to_le16((uint16_t)(pixel_clock_10KHz_in));
- params.ucTransmitterID =
- bp->cmd_helper->encoder_id_to_atom(
- dal_graphics_object_id_get_encoder_id(
-
bp_params->encoder_object_id));
- params.ucEncodeMode =
- (uint8_t)bp->cmd_helper->encoder_mode_bp_to_atom(
- bp_params->signal_type, false);
+ bp->cmd_helper->encoder_id_to_atom(
+
dal_graphics_object_id_get_encoder_id(bp_params->encoder_object_id));
+ bp->cmd_helper->encoder_mode_bp_to_atom(bp_params->signal_type, false);
return result;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 30/40] drm/amd/display/dc/dce/dce_dmcu: Move 'abm_gain_stepsize' to only source file it's used in
And only declare it if it's to be used.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_dmcu.h:320:23: warning:
‘abm_gain_stepsize’ defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_dmcu.h:320:23: warning:
‘abm_gain_stepsize’ defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_dmcu.h:320:23: warning:
‘abm_gain_stepsize’ defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_dmcu.h:320:23: warning:
‘abm_gain_stepsize’ defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_dmcu.h:320:23: warning:
‘abm_gain_stepsize’ defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_dmcu.h:320:23: warning:
‘abm_gain_stepsize’ defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_dmcu.h:320:23: warning:
‘abm_gain_stepsize’ defined but not used [-Wunused-const-variable=]
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Mauro Rossi
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c | 4
drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.h | 2 --
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c
index fa2b47d41ee2f..30264fc151a2b 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c
@@ -65,6 +65,10 @@
//Register access policy version
#define mmMP0_SMN_C2PMSG_910x1609B
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+static const uint32_t abm_gain_stepsize = 0x0060;
+#endif
+
static bool dce_dmcu_init(struct dmcu *dmcu)
{
// Do nothing
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.h
b/drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.h
index 93e7f34d4775e..cefb7f5bf42cc 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.h
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.h
@@ -317,6 +317,4 @@ struct dmcu *dcn21_dmcu_create(
void dce_dmcu_destroy(struct dmcu **dmcu);
-static const uint32_t abm_gain_stepsize = 0x0060;
-
#endif /* _DCE_ABM_H_ */
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
