RE: [PATCH v2] drm/amd/powerplay: return errno code to caller when error occur

2019-11-18 Thread Quan, Evan
Reviewed-by: Evan Quan 

> -Original Message-
> From: Chen Wandun 
> Sent: Monday, November 18, 2019 4:04 PM
> To: Quan, Evan ; Deucher, Alexander
> ; amd-...@lists.freedesktop.org; linux-
> ker...@vger.kernel.org; dri-devel@lists.freedesktop.org
> Cc: chenwan...@huawei.com
> Subject: [PATCH v2] drm/amd/powerplay: return errno code to caller when
> error occur
> 
> return errno code to caller when error occur, and meanwhile remove gcc '-
> Wunused-but-set-variable' warning.
> 
> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c: In
> function vegam_populate_smc_boot_level:
> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1364:
> 6: warning: variable result set but not used [-Wunused-but-set-variable]
> 
> Signed-off-by: Chen Wandun 
> ---
>  drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
> b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
> index 2068eb0..50896e9 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
> @@ -1371,11 +1371,16 @@ static int vegam_populate_smc_boot_level(struct
> pp_hwmgr *hwmgr,
>   result = phm_find_boot_level(&(data->dpm_table.sclk_table),
>   data->vbios_boot_state.sclk_bootup_value,
>   (uint32_t *)&(table->GraphicsBootLevel));
> + if (result)
> + return result;
> 
>   result = phm_find_boot_level(&(data->dpm_table.mclk_table),
>   data->vbios_boot_state.mclk_bootup_value,
>   (uint32_t *)&(table->MemoryBootLevel));
> 
> + if (result)
> + return result;
> +
>   table->BootVddc  = data->vbios_boot_state.vddc_bootup_value *
>   VOLTAGE_SCALE;
>   table->BootVddci = data->vbios_boot_state.vddci_bootup_value *
> --
> 2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amd/display: Fix error returned by program_hpd_filter

2019-11-18 Thread Aditya Pakki
program_hpd_filter() currently fails to check for the errors
returned in construct(). This patch returns error in
case of failure.

Signed-off-by: Aditya Pakki 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index ca20b150afcc..bbb648a50c41 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -1379,9 +1379,8 @@ static bool construct(
 * If GPIO isn't programmed correctly HPD might not rise or drain
 * fast enough, leading to bounces.
 */
-   program_hpd_filter(link);
+   return program_hpd_filter(link);
 
-   return true;
 device_tag_fail:
link->link_enc->funcs->destroy(&link->link_enc);
 link_enc_create_fail:
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] dt-bindings: drm/msm/gpu: document second interconnect

2019-11-18 Thread Brian Masney
Some A3xx and all A4xx Adreno GPUs do not have GMEM inside the GPU core
and must use the On Chip MEMory (OCMEM) in order to be functional.
There's a separate interconnect path that needs to be setup to OCMEM.
Let's document this second interconnect path that's available.

Signed-off-by: Brian Masney 
---
 Documentation/devicetree/bindings/display/msm/gpu.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 2b8fd26c43b0..3e6cd3f64a78 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -23,7 +23,10 @@ Required properties:
 - iommus: optional phandle to an adreno iommu instance
 - operating-points-v2: optional phandle to the OPP operating points
 - interconnects: optional phandle to an interconnect provider.  See
-  ../interconnect/interconnect.txt for details.
+  ../interconnect/interconnect.txt for details. Some A3xx and all A4xx 
platforms
+  will have two paths; all others will have one path.
+- interconnect-names: The names of the interconnect paths that correspond to 
the
+  interconnects property. Values must be gfx-mem and ocmem.
 - qcom,gmu: For GMU attached devices a phandle to the GMU device that will
   control the power for the GPU. Applicable targets:
 - qcom,adreno-630.2
@@ -76,6 +79,7 @@ Example a6xx (with GMU):
operating-points-v2 = <&gpu_opp_table>;
 
interconnects = <&rsc_hlos MASTER_GFX3D &rsc_hlos SLAVE_EBI1>;
+   interconnect-names = "gfx-mem";
 
qcom,gmu = <&gmu>;
 
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/v3d: add missed pm_runtime_disable

2019-11-18 Thread Chuhong Yuan
The driver forgets to call pm_runtime_disable in probe failure
and remove.
Add the missed calls to fix it.

Signed-off-by: Chuhong Yuan 
---
 drivers/gpu/drm/v3d/v3d_drv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 3506ae2723ae..e109bb8cd67d 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -333,6 +333,7 @@ static int v3d_platform_drm_probe(struct platform_device 
*pdev)
 dev_destroy:
drm_dev_put(drm);
 dma_free:
+   pm_runtime_disable(dev);
dma_free_wc(dev, 4096, v3d->mmu_scratch, v3d->mmu_scratch_paddr);
 dev_free:
kfree(v3d);
@@ -350,6 +351,8 @@ static int v3d_platform_drm_remove(struct platform_device 
*pdev)
 
drm_dev_put(drm);
 
+   pm_runtime_disable(v3d->dev);
+
dma_free_wc(v3d->dev, 4096, v3d->mmu_scratch, v3d->mmu_scratch_paddr);
 
return 0;
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] gpu: ipu-v3: prg: add missed operations in remove

2019-11-18 Thread Chuhong Yuan
This driver forgets to call pm_runtime_disable and clk_disable_unprepare
in remove.
Add the calls to fix it.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Add the missed pm_runtime_disable.

 drivers/gpu/ipu-v3/ipu-prg.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index 196797c1b4b3..897da605da55 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -430,6 +430,9 @@ static int ipu_prg_remove(struct platform_device *pdev)
list_del(&prg->list);
mutex_unlock(&ipu_prg_list_mutex);
 
+   pm_runtime_disable(&pdev->dev);
+   clk_disable_unprepare(prg->clk_axi);
+   clk_disable_unprepare(prg->clk_ipg);
return 0;
 }
 
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/1] drm: Prefer pcie_capability_read_word()

2019-11-18 Thread Frederick Lawler
Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
added accessors for the PCI Express Capability so that drivers didn't
need to be aware of differences between v1 and v2 of the PCI
Express Capability.

Replace pci_read_config_word() and pci_write_config_word() calls with
pcie_capability_read_word() and pcie_capability_write_word().

Signed-off-by: Frederick Lawler 

---
V2
- Squash both drm commits into one
- Rebase ontop of d46eac1e658b
---
 drivers/gpu/drm/amd/amdgpu/cik.c | 63 ---
 drivers/gpu/drm/amd/amdgpu/si.c  | 71 +++
 drivers/gpu/drm/radeon/cik.c | 70 ++
 drivers/gpu/drm/radeon/si.c  | 73 
 4 files changed, 174 insertions(+), 103 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c b/drivers/gpu/drm/amd/amdgpu/cik.c
index 3067bb874032..f369e3408ed2 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik.c
+++ b/drivers/gpu/drm/amd/amdgpu/cik.c
@@ -1384,7 +1384,6 @@ static int cik_set_vce_clocks(struct amdgpu_device *adev, 
u32 evclk, u32 ecclk)
 static void cik_pcie_gen3_enable(struct amdgpu_device *adev)
 {
struct pci_dev *root = adev->pdev->bus->self;
-   int bridge_pos, gpu_pos;
u32 speed_cntl, current_data_rate;
int i;
u16 tmp16;
@@ -1419,12 +1418,7 @@ static void cik_pcie_gen3_enable(struct amdgpu_device 
*adev)
DRM_INFO("enabling PCIE gen 2 link speeds, disable with 
amdgpu.pcie_gen2=0\n");
}
 
-   bridge_pos = pci_pcie_cap(root);
-   if (!bridge_pos)
-   return;
-
-   gpu_pos = pci_pcie_cap(adev->pdev);
-   if (!gpu_pos)
+   if (!pci_is_pcie(root) || !pci_is_pcie(adev->pdev))
return;
 
if (adev->pm.pcie_gen_mask & CAIL_PCIE_LINK_SPEED_SUPPORT_GEN3) {
@@ -1434,14 +1428,17 @@ static void cik_pcie_gen3_enable(struct amdgpu_device 
*adev)
u16 bridge_cfg2, gpu_cfg2;
u32 max_lw, current_lw, tmp;
 
-   pci_read_config_word(root, bridge_pos + PCI_EXP_LNKCTL, 
&bridge_cfg);
-   pci_read_config_word(adev->pdev, gpu_pos + 
PCI_EXP_LNKCTL, &gpu_cfg);
+   pcie_capability_read_word(root, PCI_EXP_LNKCTL,
+ &bridge_cfg);
+   pcie_capability_read_word(adev->pdev, PCI_EXP_LNKCTL,
+ &gpu_cfg);
 
tmp16 = bridge_cfg | PCI_EXP_LNKCTL_HAWD;
-   pci_write_config_word(root, bridge_pos + 
PCI_EXP_LNKCTL, tmp16);
+   pcie_capability_write_word(root, PCI_EXP_LNKCTL, tmp16);
 
tmp16 = gpu_cfg | PCI_EXP_LNKCTL_HAWD;
-   pci_write_config_word(adev->pdev, gpu_pos + 
PCI_EXP_LNKCTL, tmp16);
+   pcie_capability_write_word(adev->pdev, PCI_EXP_LNKCTL,
+  tmp16);
 
tmp = RREG32_PCIE(ixPCIE_LC_STATUS1);
max_lw = (tmp & 
PCIE_LC_STATUS1__LC_DETECTED_LINK_WIDTH_MASK) >>
@@ -1465,15 +1462,23 @@ static void cik_pcie_gen3_enable(struct amdgpu_device 
*adev)
 
for (i = 0; i < 10; i++) {
/* check status */
-   pci_read_config_word(adev->pdev, gpu_pos + 
PCI_EXP_DEVSTA, &tmp16);
+   pcie_capability_read_word(adev->pdev,
+ PCI_EXP_DEVSTA,
+ &tmp16);
if (tmp16 & PCI_EXP_DEVSTA_TRPND)
break;
 
-   pci_read_config_word(root, bridge_pos + 
PCI_EXP_LNKCTL, &bridge_cfg);
-   pci_read_config_word(adev->pdev, gpu_pos + 
PCI_EXP_LNKCTL, &gpu_cfg);
+   pcie_capability_read_word(root, PCI_EXP_LNKCTL,
+ &bridge_cfg);
+   pcie_capability_read_word(adev->pdev,
+ PCI_EXP_LNKCTL,
+ &gpu_cfg);
 
-   pci_read_config_word(root, bridge_pos + 
PCI_EXP_LNKCTL2, &bridge_cfg2);
-   pci_read_config_word(adev->pdev, gpu_pos + 
PCI_EXP_LNKCTL2, &gpu_cfg2);
+   pcie_capability_read_word(root, PCI_EXP_LNKCTL2,
+ &bridge_cfg2);
+   pcie_capability_read_word(adev->pdev,
+ PCI_EXP_LNKCTL2,
+ &gpu_cfg2);
 
tmp = 

Re: [RFCv1 32/42] drm/omap: dsi: convert to drm_panel

2019-11-18 Thread H. Nikolaus Schaller
Hi,

> Am 17.11.2019 um 03:40 schrieb Sebastian Reichel 
> :
> 
> This converts the DSI module to expect common drm_panel display
> drivers instead of dssdev based ones.
> 
> This commit is WIP. We somehow need to know the panels resolution
> in omap_dsi_host_attach(), so that we can properly configure the
> DSI bus clock before enabling the bus. The control bus must be
> enabled at this point, so that the panel can use it.
> 
> Other drivers run drm_panel_attach() in their dsi host attach,
> which makes it possible to call drm_panel_get_modes() afterwards
> and the get the correct mode from the connector.
> 
> Signed-off-by: Sebastian Reichel 
> ---
> .../gpu/drm/omapdrm/displays/panel-dsi-cm.c   | 217 +++---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 141 ++--
> .../gpu/drm/omapdrm/dss/omapdss-boot-init.c   |   1 -
> drivers/gpu/drm/omapdrm/dss/omapdss.h |  22 +-
> drivers/gpu/drm/omapdrm/omap_crtc.c   |  17 +-
> 5 files changed, 205 insertions(+), 193 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> index 18020ac43a83..84b0e79c025e 100644
> --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> @@ -6,8 +6,6 @@
>  * Author: Tomi Valkeinen 
>  */
> 
> -/* #define DEBUG */
> -
> #include 
> #include 
> #include 
> @@ -20,11 +18,14 @@
> #include 
> 
> #include 
> +#include 
> +#include 
> +#include 
> 
> +#include 
> #include 
> #include 
> -
> -#include "../dss/omapdss.h"
> +#include 
> 
> #define DCS_READ_NUM_ERRORS   0x05
> #define DCS_GET_ID1   0xda
> @@ -35,11 +36,8 @@
> 
> struct panel_drv_data {
>   struct mipi_dsi_device *dsi;
> -
> - struct omap_dss_device dssdev;
> - struct omap_dss_device *src;
> -
> - struct videomode vm;
> + struct drm_panel panel;
> + struct drm_display_mode mode;
> 
>   struct mutex lock;
> 
> @@ -71,7 +69,11 @@ struct panel_drv_data {
>   bool ulps_enabled;
> };
> 
> -#define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
> +
> +static inline struct panel_drv_data *panel_to_ddata(struct drm_panel *panel)
> +{
> + return container_of(panel, struct panel_drv_data, panel);
> +}
> 
> static int _dsicm_enable_te(struct panel_drv_data *ddata, bool enable);
> 
> @@ -285,10 +287,15 @@ static void dsicm_hw_reset(struct panel_drv_data *ddata)
> 
> static int dsicm_power_on(struct panel_drv_data *ddata)
> {
> - struct omap_dss_device *src = ddata->src;
>   u8 id1, id2, id3;
>   int r;
> 
> + r = regulator_bulk_enable(DCS_REGULATOR_SUPPLY_NUM, ddata->supplies);
> + if (r) {
> + dev_err(&ddata->dsi->dev, "failed to enable supplies: %d\n", r);
> + return r;
> + }
> +
>   dsicm_hw_reset(ddata);
> 
>   ddata->dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> @@ -322,10 +329,6 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
>   if (r)
>   goto err;
> 
> - r = src->ops->dsi.enable_video_output(src, ddata->dsi->channel);
> - if (r)
> - goto err;
> -
>   ddata->enabled = 1;
> 
>   if (!ddata->intro_printed) {
> @@ -342,18 +345,17 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
> 
>   dsicm_hw_reset(ddata);
> 
> + regulator_bulk_disable(DCS_REGULATOR_SUPPLY_NUM, ddata->supplies);
> +
>   return r;
> }
> 
> -static void dsicm_power_off(struct panel_drv_data *ddata)
> +static int dsicm_power_off(struct panel_drv_data *ddata)
> {
> - struct omap_dss_device *src = ddata->src;
>   int r;
> 
>   ddata->enabled = 0;
> 
> - src->ops->dsi.disable_video_output(src, ddata->dsi->channel);
> -
>   r = mipi_dsi_dcs_set_display_off(ddata->dsi);
>   if (!r)
>   r = dsicm_sleep_in(ddata);
> @@ -363,52 +365,17 @@ static void dsicm_power_off(struct panel_drv_data 
> *ddata)
>   "error disabling panel, issuing HW reset\n");
>   dsicm_hw_reset(ddata);
>   }
> -}
> 
> -static int dsicm_connect(struct omap_dss_device *src,
> -  struct omap_dss_device *dst)
> -{
> - struct panel_drv_data *ddata = to_panel_data(dst);
> -
> - ddata->src = src;
> - return 0;
> -}
> -
> -static void dsicm_disconnect(struct omap_dss_device *src,
> -  struct omap_dss_device *dst)
> -{
> - struct panel_drv_data *ddata = to_panel_data(dst);
> -
> - ddata->src = NULL;
> -}
> -
> -static void dsicm_pre_enable(struct omap_dss_device *dssdev)
> -{
> - struct panel_drv_data *ddata = to_panel_data(dssdev);
> - struct omap_dss_device *src = ddata->src;
> - int r;
> - struct omap_dss_dsi_config dsi_config = {
> - .vm = &ddata->vm,
> - .hs_clk_min = 15000,
> - .hs_clk_max = 3,
> - .lp_clk_min = 700,
> - .lp_clk_max = 1000,
> - };
> -
> - r = regul

[PATCH 2/4] drm/msm/gpu: add support for ocmem interconnect path

2019-11-18 Thread Brian Masney
Some A3xx and all A4xx Adreno GPUs do not have GMEM inside the GPU core
and must use the On Chip MEMory (OCMEM) in order to be functional.
There's a separate interconnect path that needs to be setup to OCMEM.
Add support for this second path to the GPU core.

In the downstream MSM 3.4 sources, the two interconnect paths for the
GPU are between:

  - MSM_BUS_MASTER_GRAPHICS_3D and MSM_BUS_SLAVE_EBI_CH0
  - MSM_BUS_MASTER_V_OCMEM_GFX3D and MSM_BUS_SLAVE_OCMEM

Signed-off-by: Brian Masney 
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c   |  6 +++---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 20 
 drivers/gpu/drm/msm/msm_gpu.h   |  3 ++-
 3 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 85f14feafdec..7885e382fb8f 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -132,7 +132,7 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int 
index)
 * Eventually we will want to scale the path vote with the frequency but
 * for now leave it at max so that the performance is nominal.
 */
-   icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+   icc_set_bw(gpu->gfx_mem_icc_path, 0, MBps_to_icc(7216));
 }
 
 void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
@@ -714,7 +714,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
}
 
/* Set the bus quota to a reasonable value for boot */
-   icc_set_bw(gpu->icc_path, 0, MBps_to_icc(3072));
+   icc_set_bw(gpu->gfx_mem_icc_path, 0, MBps_to_icc(3072));
 
/* Enable the GMU interrupt */
gmu_write(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_CLR, ~0);
@@ -858,7 +858,7 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
a6xx_gmu_shutdown(gmu);
 
/* Remove the bus vote */
-   icc_set_bw(gpu->icc_path, 0, 0);
+   icc_set_bw(gpu->gfx_mem_icc_path, 0, 0);
 
/*
 * Make sure the GX domain is off before turning off the GMU (CX)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 0783e4b5486a..d1cc021c012c 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -887,9 +887,20 @@ static int adreno_get_pwrlevels(struct device *dev,
DBG("fast_rate=%u, slow_rate=2700", gpu->fast_rate);
 
/* Check for an interconnect path for the bus */
-   gpu->icc_path = of_icc_get(dev, NULL);
-   if (IS_ERR(gpu->icc_path))
-   gpu->icc_path = NULL;
+   gpu->gfx_mem_icc_path = of_icc_get(dev, "gfx-mem");
+   if (!gpu->gfx_mem_icc_path) {
+   /*
+* Keep compatbility with device trees that don't have an
+* interconnect-names property.
+*/
+   gpu->gfx_mem_icc_path = of_icc_get(dev, NULL);
+   }
+   if (IS_ERR(gpu->gfx_mem_icc_path))
+   gpu->gfx_mem_icc_path = NULL;
+
+   gpu->ocmem_icc_path = of_icc_get(dev, "ocmem");
+   if (IS_ERR(gpu->ocmem_icc_path))
+   gpu->ocmem_icc_path = NULL;
 
return 0;
 }
@@ -976,7 +987,8 @@ void adreno_gpu_cleanup(struct adreno_gpu *adreno_gpu)
for (i = 0; i < ARRAY_SIZE(adreno_gpu->info->fw); i++)
release_firmware(adreno_gpu->fw[i]);
 
-   icc_put(gpu->icc_path);
+   icc_put(gpu->gfx_mem_icc_path);
+   icc_put(gpu->ocmem_icc_path);
 
msm_gpu_cleanup(&adreno_gpu->base);
 }
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index ab8f0f9c9dc8..e72e56f7b0ef 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -111,7 +111,8 @@ struct msm_gpu {
struct clk *ebi1_clk, *core_clk, *rbbmtimer_clk;
uint32_t fast_rate;
 
-   struct icc_path *icc_path;
+   struct icc_path *gfx_mem_icc_path;
+   struct icc_path *ocmem_icc_path;
 
/* Hang and Inactivity Detection:
 */
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] drm/msm/a4xx: set interconnect bandwidth vote

2019-11-18 Thread Brian Masney
Set the two interconnect paths for the GPU to maximum speed for now to
work towards getting the GPU working upstream. We can revisit a later
time to optimize this for battery life.

Signed-off-by: Brian Masney 
---
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index b01388a9e89e..c631d1df7751 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -591,6 +591,14 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
goto fail;
}
 
+   /*
+* Set the ICC path to maximum speed for now by multiplying the fastest
+* frequency by the bus width (8). We'll want to scale this later on to
+* improve battery life.
+*/
+   icc_set_bw(gpu->gfx_mem_icc_path, 0, Bps_to_icc(gpu->fast_rate) * 8);
+   icc_set_bw(gpu->ocmem_icc_path, 0, Bps_to_icc(gpu->fast_rate) * 8);
+
return gpu;
 
 fail:
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/4] drm/msm/gpu: add support for ocmem interconnect

2019-11-18 Thread Brian Masney
Some A3xx and all A4xx Adreno GPUs do not have GMEM inside the GPU core
and must use the On Chip MEMory (OCMEM) in order to be functional.
There's a separate interconnect path that needs to be setup to OCMEM.
This patch series adds support for that path, and sets the votes for the
two interconnect paths to the highest speed for a3xx and a4xx-based
platforms.

Brian Masney (4):
  dt-bindings: drm/msm/gpu: document second interconnect
  drm/msm/gpu: add support for ocmem interconnect path
  drm/msm/a3xx: set interconnect bandwidth vote
  drm/msm/a4xx: set interconnect bandwidth vote

 .../devicetree/bindings/display/msm/gpu.txt   |  6 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c |  8 
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c |  8 
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c |  6 +++---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   | 20 +++
 drivers/gpu/drm/msm/msm_gpu.h |  3 ++-
 6 files changed, 42 insertions(+), 9 deletions(-)

-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/amd/powerplay: return errno code to caller when error occur

2019-11-18 Thread Chen Wandun
return errno code to caller when error occur, and meanwhile
remove gcc '-Wunused-but-set-variable' warning.

drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c: In function 
vegam_populate_smc_boot_level:
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1364:6: warning: 
variable result set but not used [-Wunused-but-set-variable]

Signed-off-by: Chen Wandun 
---
 drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
index 2068eb0..50896e9 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
@@ -1371,11 +1371,16 @@ static int vegam_populate_smc_boot_level(struct 
pp_hwmgr *hwmgr,
result = phm_find_boot_level(&(data->dpm_table.sclk_table),
data->vbios_boot_state.sclk_bootup_value,
(uint32_t *)&(table->GraphicsBootLevel));
+   if (result)
+   return result;
 
result = phm_find_boot_level(&(data->dpm_table.mclk_table),
data->vbios_boot_state.mclk_bootup_value,
(uint32_t *)&(table->MemoryBootLevel));
 
+   if (result)
+   return result;
+
table->BootVddc  = data->vbios_boot_state.vddc_bootup_value *
VOLTAGE_SCALE;
table->BootVddci = data->vbios_boot_state.vddci_bootup_value *
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/powerplay: remove variable 'result' set but not used

2019-11-18 Thread Chen Wandun

OK, it indeed should return the 'result' to caller,
I will make a modification and repost the patch.

Thanks
Chen Wandun

On 2019/11/18 14:50, Quan, Evan wrote:

Thanks. But it's better to return the 'result' out on 'result != 0'.

Regards,
Evan
-Original Message-
From: Chen Wandun 
Sent: Saturday, November 16, 2019 11:43 AM
To: Deucher, Alexander ; Quan, Evan 
; amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
linux-ker...@vger.kernel.org
Cc: chenwan...@huawei.com
Subject: [PATCH] drm/amd/powerplay: remove variable 'result' set but not used

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c: In function 
vegam_populate_smc_boot_level:
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1364:6: warning: 
variable result set but not used [-Wunused-but-set-variable]

Signed-off-by: Chen Wandun 
---
  drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 13 ++---
  1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
index 2068eb0..fad78bf 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
@@ -1361,20 +1361,19 @@ static int vegam_populate_smc_uvd_level(struct pp_hwmgr 
*hwmgr,
  static int vegam_populate_smc_boot_level(struct pp_hwmgr *hwmgr,
struct SMU75_Discrete_DpmTable *table)
  {
-   int result = 0;
struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
  
  	table->GraphicsBootLevel = 0;

table->MemoryBootLevel = 0;
  
  	/* find boot level from dpm table */

-   result = phm_find_boot_level(&(data->dpm_table.sclk_table),
-   data->vbios_boot_state.sclk_bootup_value,
-   (uint32_t *)&(table->GraphicsBootLevel));
+   phm_find_boot_level(&(data->dpm_table.sclk_table),
+   data->vbios_boot_state.sclk_bootup_value,
+   (uint32_t *)&(table->GraphicsBootLevel));
  
-	result = phm_find_boot_level(&(data->dpm_table.mclk_table),

-   data->vbios_boot_state.mclk_bootup_value,
-   (uint32_t *)&(table->MemoryBootLevel));
+   phm_find_boot_level(&(data->dpm_table.mclk_table),
+   data->vbios_boot_state.mclk_bootup_value,
+   (uint32_t *)&(table->MemoryBootLevel));
  
  	table->BootVddc  = data->vbios_boot_state.vddc_bootup_value *

VOLTAGE_SCALE;



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/4] drm/msm/a3xx: set interconnect bandwidth vote

2019-11-18 Thread Brian Masney
Set the two interconnect paths for the GPU to maximum speed for now to
work towards getting the GPU working upstream. We can revisit a later
time to optimize this for battery life.

Signed-off-by: Brian Masney 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 07ddcc529573..f05adf9bc752 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -504,6 +504,14 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
DRM_DEV_ERROR(dev->dev, "No memory protection without IOMMU\n");
}
 
+   /*
+* Set the ICC path to maximum speed for now by multiplying the fastest
+* frequency by the bus width (8). We'll want to scale this later on to
+* improve battery life.
+*/
+   icc_set_bw(gpu->gfx_mem_icc_path, 0, Bps_to_icc(gpu->fast_rate) * 8);
+   icc_set_bw(gpu->ocmem_icc_path, 0, Bps_to_icc(gpu->fast_rate) * 8);
+
return gpu;
 
 fail:
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] fbdev: s1d13xxxfb: add missed unregister_framebuffer in remove

2019-11-18 Thread Chuhong Yuan
The driver calls register_framebuffer in probe but does not call
unregister_framebuffer in remove.
Add the missed call to fix it.

Signed-off-by: Chuhong Yuan 
---
 drivers/video/fbdev/s1d13xxxfb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/s1d13xxxfb.c b/drivers/video/fbdev/s1d13xxxfb.c
index e04efb567b5c..162003ea6b79 100644
--- a/drivers/video/fbdev/s1d13xxxfb.c
+++ b/drivers/video/fbdev/s1d13xxxfb.c
@@ -729,6 +729,7 @@ s1d13xxxfb_remove(struct platform_device *pdev)
struct s1d13xxxfb_par *par = NULL;
 
if (info) {
+   unregister_framebuffer(info);
par = info->par;
if (par && par->regs) {
/* disable output & enable powersave */
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/mediatek: Check return value of mtk_drm_ddp_comp_for_plane.

2019-11-18 Thread Pi-Hsun Shih
The mtk_drm_ddp_comp_for_plane can return NULL, but the usage doesn't
check for it. Add check for it.

Fixes: d6b53f68356f ("drm/mediatek: Add helper to get component for a plane")
Signed-off-by: Pi-Hsun Shih 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index f80a8ba75977..4c4f976c994e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -310,7 +310,9 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
*mtk_crtc)
 
plane_state = to_mtk_plane_state(plane->state);
comp = mtk_drm_ddp_comp_for_plane(crtc, plane, &local_layer);
-   mtk_ddp_comp_layer_config(comp, local_layer, plane_state);
+   if (comp)
+   mtk_ddp_comp_layer_config(comp, local_layer,
+ plane_state);
}
 
return 0;
@@ -386,8 +388,9 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
comp = mtk_drm_ddp_comp_for_plane(crtc, plane,
  &local_layer);
 
-   mtk_ddp_comp_layer_config(comp, local_layer,
- plane_state);
+   if (comp)
+   mtk_ddp_comp_layer_config(comp, local_layer,
+ plane_state);
plane_state->pending.config = false;
}
mtk_crtc->pending_planes = false;
@@ -401,7 +404,9 @@ int mtk_drm_crtc_plane_check(struct drm_crtc *crtc, struct 
drm_plane *plane,
struct mtk_ddp_comp *comp;
 
comp = mtk_drm_ddp_comp_for_plane(crtc, plane, &local_layer);
-   return mtk_ddp_comp_layer_check(comp, local_layer, state);
+   if (comp)
+   return mtk_ddp_comp_layer_check(comp, local_layer, state);
+   return 0;
 }
 
 static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,

base-commit: 5a6fcbeabe3e20459ed8504690b2515dacc5246f
-- 
2.24.0.432.g9d3f5f5b63-goog

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 3/4] drm/komeda: use afbc helpers

2019-11-18 Thread Daniel Vetter
On Mon, Nov 18, 2019 at 07:09:56AM +, james qian wang (Arm Technology 
China) wrote:
> On Thu, Nov 14, 2019 at 11:12:13AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 14, 2019 at 2:52 AM james qian wang (Arm Technology China)
> >  wrote:
> > > On Wed, Nov 13, 2019 at 12:39:54PM +0100, Daniel Vetter wrote:
> > > > On Wed, Nov 13, 2019 at 02:01:53AM +, james qian wang (Arm 
> > > > Technology China) wrote:
> > > > > On Fri, Nov 08, 2019 at 04:09:54PM +, Ayan Halder wrote:
> > > > > > On Mon, Nov 04, 2019 at 11:12:27PM +0100, Andrzej Pietrasiewicz 
> > > > > > wrote:
> > > > > > > There are afbc helpers available.
> > > > > > >
> > > > > > > Signed-off-by: Andrzej Pietrasiewicz 
> > > > > > > ---
> > > > > > >  .../arm/display/komeda/komeda_format_caps.h   |  1 -
> > > > > > >  .../arm/display/komeda/komeda_framebuffer.c   | 44 
> > > > > > > +++
> > > > > > >  2 files changed, 17 insertions(+), 28 deletions(-)
> > > > > > >
> > > > > > > diff --git 
> > > > > > > a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h 
> > > > > > > b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
> > > > > > > index 32273cf18f7c..607eea80e60c 100644
> > > > > > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
> > > > > > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
> > > > > > > @@ -33,7 +33,6 @@
> > > > > > >
> > > > > > >  #define AFBC_TH_LAYOUT_ALIGNMENT   8
> > > > > > >  #define AFBC_HEADER_SIZE   16
> > > > > > > -#define AFBC_SUPERBLK_ALIGNMENT128
> > > > > > >  #define AFBC_SUPERBLK_PIXELS   256
> > > > > > >  #define AFBC_BODY_START_ALIGNMENT  1024
> > > > > > >  #define AFBC_TH_BODY_START_ALIGNMENT   4096
> > > > > > > diff --git 
> > > > > > > a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c 
> > > > > > > b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
> > > > > > > index 1b01a625f40e..e9c87551a5b8 100644
> > > > > > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
> > > > > > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
> > > > > > > @@ -4,6 +4,7 @@
> > > > > > >   * Author: James.Qian.Wang 
> > > > > > >   *
> > > > > > >   */
> > > > > > > +#include 
> > > > > > >  #include 
> > > > > > >  #include 
> > > > > > >  #include 
> > > > > > > @@ -43,8 +44,7 @@ komeda_fb_afbc_size_check(struct komeda_fb 
> > > > > > > *kfb, struct drm_file *file,
> > > > > > > struct drm_framebuffer *fb = &kfb->base;
> > > > > > > const struct drm_format_info *info = fb->format;
> > > > > > > struct drm_gem_object *obj;
> > > > > > > -   u32 alignment_w = 0, alignment_h = 0, alignment_header, 
> > > > > > > n_blocks, bpp;
> > > > > > > -   u64 min_size;
> > > > > > > +   u32 alignment_w = 0, alignment_h = 0, alignment_header, 
> > > > > > > bpp;
> > > > > > >
> > > > > > > obj = drm_gem_object_lookup(file, mode_cmd->handles[0]);
> > > > > > > if (!obj) {
> > > > > > > @@ -52,19 +52,15 @@ komeda_fb_afbc_size_check(struct komeda_fb 
> > > > > > > *kfb, struct drm_file *file,
> > > > > > > return -ENOENT;
> > > > > > > }
> > > > > > >
> > > > > > > -   switch (fb->modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> > > > > > > -   case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
> > > > > > > -   alignment_w = 32;
> > > > > > > -   alignment_h = 8;
> > > > > > > -   break;
> > > > > > > -   case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> > > > > > > -   alignment_w = 16;
> > > > > > > -   alignment_h = 16;
> > > > > > > -   break;
> > > > > > > -   default:
> > > > > > > -   WARN(1, "Invalid AFBC_FORMAT_MOD_BLOCK_SIZE: 
> > > > > > > %lld.\n",
> > > > > > > -fb->modifier & 
> > > > > > > AFBC_FORMAT_MOD_BLOCK_SIZE_MASK);
> > > > > > > -   break;
> > > > > > > +   if (!drm_afbc_get_superblk_wh(fb->modifier, &alignment_w, 
> > > > > > > &alignment_h))
> > > > > > > +   return -EINVAL;
> > > > > > > +
> > > > > > > +   if ((alignment_w != 16 || alignment_h != 16) &&
> > > > > > > +   (alignment_w != 32 || alignment_h != 8)) {
> > > > > > > +   DRM_DEBUG_KMS("Unsupported afbc tile w/h 
> > > > > > > [%d/%d]\n",
> > > > > > > + alignment_w, alignment_h);
> > > > > > > +
> > > > > > > +   return -EINVAL;
> > > > > > To be honest, the previous code looks much more readable
> > > > > > > }
> > > > > > >
> > > > > > > /* tiled header afbc */
> > > > > > > @@ -84,20 +80,14 @@ komeda_fb_afbc_size_check(struct komeda_fb 
> > > > > > > *kfb, struct drm_file *file,
> > > > > > > goto check_failed;
> > > > > > > }
> > > > > > >
> > > > > > > -   n_blocks = (kfb->aligned_w * kfb->aligned_h) / 
> > > > > > > AFBC_SUPERBLK_PIXELS;
> > > > > > > -   kfb->offset_payload = ALIGN(n_

Re: [PATCH] drm/gma500: remove set but not used variable 'channel_eq'

2019-11-18 Thread Daniel Vetter
On Sat, Nov 16, 2019 at 07:04:28PM +0800, zhengbin wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/gpu/drm/gma500/cdv_intel_dp.c: In function 
> cdv_intel_dp_complete_link_train:
> drivers/gpu/drm/gma500/cdv_intel_dp.c:1596:7: warning: variable channel_eq 
> set but not used [-Wunused-but-set-variable]
> 
> It is never used, so remove it.
> 
> Reported-by: Hulk Robot 
> Signed-off-by: zhengbin 

Queued for 5.6 thanks for your patch.
-Daniel

> ---
>  drivers/gpu/drm/gma500/cdv_intel_dp.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c 
> b/drivers/gpu/drm/gma500/cdv_intel_dp.c
> index 570b595..5772b2d 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
> @@ -1594,7 +1594,6 @@ cdv_intel_dp_complete_link_train(struct gma_encoder 
> *encoder)
>  {
>   struct drm_device *dev = encoder->base.dev;
>   struct cdv_intel_dp *intel_dp = encoder->dev_priv;
> - bool channel_eq = false;
>   int tries, cr_tries;
>   u32 reg;
>   uint32_t DP = intel_dp->DP;
> @@ -1602,7 +1601,6 @@ cdv_intel_dp_complete_link_train(struct gma_encoder 
> *encoder)
>   /* channel equalization */
>   tries = 0;
>   cr_tries = 0;
> - channel_eq = false;
> 
>   DRM_DEBUG_KMS("\n");
>   reg = DP | DP_LINK_TRAIN_PAT_2;
> @@ -1648,7 +1646,6 @@ cdv_intel_dp_complete_link_train(struct gma_encoder 
> *encoder)
> 
>   if (cdv_intel_channel_eq_ok(encoder)) {
>   DRM_DEBUG_KMS("PT2 train is done\n");
> - channel_eq = true;
>   break;
>   }
> 
> --
> 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

[PATCH V2 1/2] drm/edid: Add aspect ratios to HDMI 4K modes

2019-11-18 Thread Wayne Lin
[Why]
HDMI 2.0 adds aspect ratio attribute to distinguish different
4k modes. According to Appendix E of HDMI 2.0 spec, source should
use VSIF to indicate video mode only when the mode is one defined
in HDMI 1.4b 4K modes. Otherwise, use AVI infoframes to convey VIC.

Current code doesn't take aspect ratio into consideration while
constructing avi infoframe. Should modify that.

[How]
Inherit Ville Syrjälä's work
"drm/edid: Prep for HDMI VIC aspect ratio" at
https://patchwork.kernel.org/patch/11174639/

Add picture_aspect_ratio attributes to edid_4k_modes[] and
construct VIC and HDMI_VIC by taking aspect ratio into
consideration.

v2: Correct missing initializer error at adding aspect ratio of 
SMPTE mode.

Signed-off-by: Wayne Lin 
---
 drivers/gpu/drm/drm_edid.c | 45 +-
 1 file changed, 35 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 77a39fc76045..0307cad36f14 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1288,25 +1288,25 @@ static const struct drm_display_mode edid_4k_modes[] = {
   3840, 4016, 4104, 4400, 0,
   2160, 2168, 2178, 2250, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
- .vrefresh = 30, },
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
/* 2 - 3840x2160@25Hz */
{ DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000,
   3840, 4896, 4984, 5280, 0,
   2160, 2168, 2178, 2250, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
- .vrefresh = 25, },
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
/* 3 - 3840x2160@24Hz */
{ DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000,
   3840, 5116, 5204, 5500, 0,
   2160, 2168, 2178, 2250, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
- .vrefresh = 24, },
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
/* 4 - 4096x2160@24Hz (SMPTE) */
{ DRM_MODE("4096x2160", DRM_MODE_TYPE_DRIVER, 297000,
   4096, 5116, 5204, 5500, 0,
   2160, 2168, 2178, 2250, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
- .vrefresh = 24, },
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_256_135, 
},
 };
 
 /*** DDC fetch and block validation ***/
@@ -3110,6 +3110,11 @@ static enum hdmi_picture_aspect 
drm_get_cea_aspect_ratio(const u8 video_code)
return edid_cea_modes[video_code].picture_aspect_ratio;
 }
 
+static enum hdmi_picture_aspect drm_get_hdmi_aspect_ratio(const u8 video_code)
+{
+   return edid_4k_modes[video_code].picture_aspect_ratio;
+}
+
 /*
  * Calculate the alternate clock for HDMI modes (those from the HDMI vendor
  * specific block).
@@ -3136,6 +3141,9 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
const struct drm_display_mode *hdmi_mode = &edid_4k_modes[vic];
unsigned int clock1, clock2;
@@ -3171,6 +3179,9 @@ static u8 drm_match_hdmi_mode(const struct 
drm_display_mode *to_match)
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
const struct drm_display_mode *hdmi_mode = &edid_4k_modes[vic];
unsigned int clock1, clock2;
@@ -5118,6 +5129,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode)
 {
enum hdmi_picture_aspect picture_aspect;
+   u8 vic, hdmi_vic;
int err;
 
if (!frame || !mode)
@@ -5130,7 +5142,8 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
frame->pixel_repeat = 1;
 
-   frame->video_code = drm_mode_cea_vic(connector, mode);
+   vic = drm_mode_cea_vic(connector, mode);
+   hdmi_vic = drm_mode_hdmi_vic(connector, mode);
 
frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
 
@@ -5144,11 +5157,15 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 
/*
 * Populate picture aspect ratio from either
-* user input (if specified) or from the CEA mode list.
+* user input (if specified) or from the CEA/HDMI mode lists.
 */
picture_aspect = mode->picture_aspect_ratio;
-   if (picture_aspect == HDMI_PICTURE_ASPECT_NONE

[PATCH V2 2/2] drm/edid: Add alternate clock for SMPTE 4K

2019-11-18 Thread Wayne Lin
[Why]
In hdmi_mode_alternate_clock(), it adds an exception for VIC 4
mode (4096x2160@24) due to there is no alternate clock defined for
that mode in HDMI1.4b. But HDMI2.0 adds 23.98Hz for that mode.

[How]
Remove the exception

v2: Adjust the comment description of hdmi_mode_alternate_clock()
due to there is no more exception for VIC 4 mode.

Signed-off-by: Wayne Lin 
---
 drivers/gpu/drm/drm_edid.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0307cad36f14..e6368c3c4471 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3118,17 +3118,10 @@ static enum hdmi_picture_aspect 
drm_get_hdmi_aspect_ratio(const u8 video_code)
 /*
  * Calculate the alternate clock for HDMI modes (those from the HDMI vendor
  * specific block).
- *
- * It's almost like cea_mode_alternate_clock(), we just need to add an
- * exception for the VIC 4 mode (4096x2160@24Hz): no alternate clock for this
- * one.
  */
 static unsigned int
 hdmi_mode_alternate_clock(const struct drm_display_mode *hdmi_mode)
 {
-   if (hdmi_mode->vdisplay == 4096 && hdmi_mode->hdisplay == 2160)
-   return hdmi_mode->clock;
-
return cea_mode_alternate_clock(hdmi_mode);
 }
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation

2019-11-18 Thread Daniel Vetter
There's no callers in-tree anymore.

For merging probably best to stuff this into drm-misc, since that's
where the dma-buf heaps will land too. And the resulting conflict
hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
implemenation.

Signed-off-by: Daniel Vetter 
Cc: Laura Abbott 
Cc: Sumit Semwal 
Cc: de...@driverdev.osuosl.org
Cc: linaro-mm-...@lists.linaro.org
---
 drivers/staging/android/ion/ion.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index e6b1ca141b93..bb4ededc1150 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -274,18 +274,6 @@ static void ion_dma_buf_release(struct dma_buf *dmabuf)
_ion_buffer_destroy(buffer);
 }
 
-static void *ion_dma_buf_kmap(struct dma_buf *dmabuf, unsigned long offset)
-{
-   struct ion_buffer *buffer = dmabuf->priv;
-
-   return buffer->vaddr + offset * PAGE_SIZE;
-}
-
-static void ion_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
-  void *ptr)
-{
-}
-
 static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
enum dma_data_direction direction)
 {
@@ -349,8 +337,6 @@ static const struct dma_buf_ops dma_buf_ops = {
.detach = ion_dma_buf_detatch,
.begin_cpu_access = ion_dma_buf_begin_cpu_access,
.end_cpu_access = ion_dma_buf_end_cpu_access,
-   .map = ion_dma_buf_kmap,
-   .unmap = ion_dma_buf_kunmap,
 };
 
 static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/15] Retire dma_buf_k(un)map

2019-11-18 Thread Daniel Vetter
Hi all,

Way back when we created the dma-buf spec it made sense to have kmap/unmap
interfaces, since 32bit kernels with limited vmalloc space were still
rather ubiquitous. But that idea (like many others) never caught on, was
quickly replaced by vmaps covering the entire buffer for all real uses,
and nowadays 64bit kernels rule the world. Currently merged upstream
drivers (and we have a pile now) don't even bother to kmap for their
private buffers, much less for anything shared.

So since it was never used, and this idea's time is clearly over, let's
remove it all.

Only real change I had to do (aside from deleting lots of dead code) was
in the tegra driver. But even there I suspect the dma-buf kmap path has
never been run in anger anywhere, it just doesn't make sense to put relocs
into a dma-buf (as opposed to using a dma-buf for the target address of a
reloc).

Comments, reviews and testing very much appreciated.

Cheers, Daniel

Daniel Vetter (15):
  drm/tegra: Map cmdbuf once for reloc processing
  drm/tegra: Delete host1x_bo_ops->k(un)map
  drm/i915: Remove dma_buf_kmap selftest
  staging/android/ion: delete dma_buf->kmap/unmap implemenation
  drm/armada: Delete dma_buf->k(un)map implemenation
  drm/i915: Drop dma_buf->k(un)map
  drm/omapdrm: Drop dma_buf->k(un)map
  drm/tegra: Remove dma_buf->k(un)map
  dma-buf: Drop dma_buf_k(un)map
  drm/vmwgfx: Delete mmaping functions
  media/videobuf2: Drop dma_buf->k(un)map support
  drm/tee_shm: Drop dma_buf_k(unmap) support
  xen/gntdev-dmabuf: Ditch dummy map functions
  sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support
  dma-buf: Remove kernel map/unmap hooks

 drivers/dma-buf/dma-buf.c |  63 +--
 drivers/gpu/drm/armada/armada_gem.c   |  12 ---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|  36 ---
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 101 --
 .../gpu/drm/i915/gem/selftests/mock_dmabuf.c  |  16 ---
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |  21 
 drivers/gpu/drm/tegra/gem.c   |  40 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c |  33 --
 drivers/gpu/host1x/job.c  |  21 ++--
 .../common/videobuf2/videobuf2-dma-contig.c   |   8 --
 .../media/common/videobuf2/videobuf2-dma-sg.c |   8 --
 .../common/videobuf2/videobuf2-vmalloc.c  |   8 --
 drivers/misc/fastrpc.c|   8 --
 drivers/staging/android/ion/ion.c |  14 ---
 drivers/tee/tee_shm.c |   6 --
 drivers/xen/gntdev-dmabuf.c   |  23 
 include/linux/dma-buf.h   |  27 -
 include/linux/host1x.h|  13 ---
 samples/vfio-mdev/mbochs.c|  16 ---
 19 files changed, 10 insertions(+), 464 deletions(-)

-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

2019-11-18 Thread Daniel Vetter
A few reasons to drop kmap:

- For native objects all we do is look at obj->vaddr anyway, so might
  as well not call functions for every page.

- Reloc-processing on dma-buf is ... questionable.

- Plus most dma-buf that bother kernel cpu mmaps give you at least
  vmap, much less kmaps. And all the ones relevant for arm-soc are
  again doing a obj->vaddr game anyway, there's no real kmap going on
  on arm it seems.

Plus this seems to be the only real in-tree user of dma_buf_kmap, and
I'd like to get rid of that.

Signed-off-by: Daniel Vetter 
Cc: Thierry Reding 
Cc: linux-te...@vger.kernel.org
---
 drivers/gpu/host1x/job.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 25ca54de8fc5..60b2fedd0061 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -244,8 +244,7 @@ static unsigned int pin_job(struct host1x *host, struct 
host1x_job *job)
 
 static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
 {
-   u32 last_page = ~0;
-   void *cmdbuf_page_addr = NULL;
+   void *cmdbuf_addr = NULL;
struct host1x_bo *cmdbuf = g->bo;
unsigned int i;
 
@@ -267,28 +266,22 @@ static int do_relocs(struct host1x_job *job, struct 
host1x_job_gather *g)
goto patch_reloc;
}
 
-   if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
-   if (cmdbuf_page_addr)
-   host1x_bo_kunmap(cmdbuf, last_page,
-cmdbuf_page_addr);
+   if (!cmdbuf_addr) {
+   cmdbuf_addr = host1x_bo_mmap(cmdbuf);
 
-   cmdbuf_page_addr = host1x_bo_kmap(cmdbuf,
-   reloc->cmdbuf.offset >> PAGE_SHIFT);
-   last_page = reloc->cmdbuf.offset >> PAGE_SHIFT;
-
-   if (unlikely(!cmdbuf_page_addr)) {
+   if (unlikely(!cmdbuf_addr)) {
pr_err("Could not map cmdbuf for relocation\n");
return -ENOMEM;
}
}
 
-   target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
+   target = cmdbuf_addr + reloc->cmdbuf.offset;
 patch_reloc:
*target = reloc_addr;
}
 
-   if (cmdbuf_page_addr)
-   host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
+   if (cmdbuf_addr)
+   host1x_bo_munmap(cmdbuf, cmdbuf_addr);
 
return 0;
 }
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

2019-11-18 Thread Daniel Vetter
All implementations are gone now.

Signed-off-by: Daniel Vetter 
Cc: Sumit Semwal 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
 include/linux/dma-buf.h | 25 -
 1 file changed, 25 deletions(-)

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 7feb9c3805ae..abf5459a5b9d 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -249,31 +249,6 @@ struct dma_buf_ops {
 */
int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
 
-   /**
-* @map:
-*
-* Maps a page from the buffer into kernel address space. The page is
-* specified by offset into the buffer in PAGE_SIZE units.
-*
-* This callback is optional.
-*
-* Returns:
-*
-* Virtual address pointer where requested page can be accessed. NULL
-* on error or when this function is unimplemented by the exporter.
-*/
-   void *(*map)(struct dma_buf *, unsigned long);
-
-   /**
-* @unmap:
-*
-* Unmaps a page from the buffer. Page offset and address pointer should
-* be the same as the one passed to and returned by matching call to 
map.
-*
-* This callback is optional.
-*/
-   void (*unmap)(struct dma_buf *, unsigned long, void *);
-
void *(*vmap)(struct dma_buf *);
void (*vunmap)(struct dma_buf *, void *vaddr);
 };
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 12/15] drm/tee_shm: Drop dma_buf_k(unmap) support

2019-11-18 Thread Daniel Vetter
There's no in-tree users anymore.

Signed-off-by: Daniel Vetter 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Jens Wiklander 
Cc: tee-...@lists.linaro.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 drivers/misc/fastrpc.c | 8 
 drivers/tee/tee_shm.c  | 6 --
 2 files changed, 14 deletions(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 1b1a794d639d..d0cbef9ec28a 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -555,13 +555,6 @@ static void fastrpc_dma_buf_detatch(struct dma_buf *dmabuf,
kfree(a);
 }
 
-static void *fastrpc_kmap(struct dma_buf *dmabuf, unsigned long pgnum)
-{
-   struct fastrpc_buf *buf = dmabuf->priv;
-
-   return buf->virt ? buf->virt + pgnum * PAGE_SIZE : NULL;
-}
-
 static void *fastrpc_vmap(struct dma_buf *dmabuf)
 {
struct fastrpc_buf *buf = dmabuf->priv;
@@ -585,7 +578,6 @@ static const struct dma_buf_ops fastrpc_dma_buf_ops = {
.map_dma_buf = fastrpc_map_dma_buf,
.unmap_dma_buf = fastrpc_unmap_dma_buf,
.mmap = fastrpc_mmap,
-   .map = fastrpc_kmap,
.vmap = fastrpc_vmap,
.release = fastrpc_release,
 };
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
index 09ddcd06c715..937ac5aaa6d8 100644
--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -71,11 +71,6 @@ static void tee_shm_op_release(struct dma_buf *dmabuf)
tee_shm_release(shm);
 }
 
-static void *tee_shm_op_map(struct dma_buf *dmabuf, unsigned long pgnum)
-{
-   return NULL;
-}
-
 static int tee_shm_op_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
struct tee_shm *shm = dmabuf->priv;
@@ -93,7 +88,6 @@ static const struct dma_buf_ops tee_shm_dma_buf_ops = {
.map_dma_buf = tee_shm_op_map_dma_buf,
.unmap_dma_buf = tee_shm_op_unmap_dma_buf,
.release = tee_shm_op_release,
-   .map = tee_shm_op_map,
.mmap = tee_shm_op_mmap,
 };
 
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/15] drm/tegra: Remove dma_buf->k(un)map

2019-11-18 Thread Daniel Vetter
No in-tree users left.

Signed-off-by: Daniel Vetter 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: linux-te...@vger.kernel.org
---
 drivers/gpu/drm/tegra/gem.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 662cb7c87ef5..84bb29070536 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -585,16 +585,6 @@ static int tegra_gem_prime_end_cpu_access(struct dma_buf 
*buf,
return 0;
 }
 
-static void *tegra_gem_prime_kmap(struct dma_buf *buf, unsigned long page)
-{
-   return NULL;
-}
-
-static void tegra_gem_prime_kunmap(struct dma_buf *buf, unsigned long page,
-  void *addr)
-{
-}
-
 static int tegra_gem_prime_mmap(struct dma_buf *buf, struct vm_area_struct 
*vma)
 {
struct drm_gem_object *gem = buf->priv;
@@ -625,8 +615,6 @@ static const struct dma_buf_ops tegra_gem_prime_dmabuf_ops 
= {
.release = tegra_gem_prime_release,
.begin_cpu_access = tegra_gem_prime_begin_cpu_access,
.end_cpu_access = tegra_gem_prime_end_cpu_access,
-   .map = tegra_gem_prime_kmap,
-   .unmap = tegra_gem_prime_kunmap,
.mmap = tegra_gem_prime_mmap,
.vmap = tegra_gem_prime_vmap,
.vunmap = tegra_gem_prime_vunmap,
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/15] dma-buf: Drop dma_buf_k(un)map

2019-11-18 Thread Daniel Vetter
It's unused.

10 years ago, back when 32bit was still fairly common and trying to
not exhaust vmalloc space sounded like a worthwhile goal, adding these
to dma_buf made sense.

Reality is that they simply never caught on, and nowadays everyone who
needs plenty of buffers will run in 64bit mode anyway.

Also update the docs in this area to adjust them to reality.

The actual hooks in dma_buf_ops will be removed once all the
implementations are gone.

Signed-off-by: Daniel Vetter 
Cc: Sumit Semwal 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
 drivers/dma-buf/dma-buf.c | 63 ++-
 include/linux/dma-buf.h   |  2 --
 2 files changed, 3 insertions(+), 62 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d377b4ca66bf..97988ce1d2dc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -880,29 +880,9 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
  *   with calls to dma_buf_begin_cpu_access() and dma_buf_end_cpu_access()
  *   access.
  *
- *   To support dma_buf objects residing in highmem cpu access is page-based
- *   using an api similar to kmap. Accessing a dma_buf is done in aligned 
chunks
- *   of PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which
- *   returns a pointer in kernel virtual address space. Afterwards the chunk
- *   needs to be unmapped again. There is no limit on how often a given chunk
- *   can be mapped and unmapped, i.e. the importer does not need to call
- *   begin_cpu_access again before mapping the same chunk again.
- *
- *   Interfaces::
- *  void \*dma_buf_kmap(struct dma_buf \*, unsigned long);
- *  void dma_buf_kunmap(struct dma_buf \*, unsigned long, void \*);
- *
- *   Implementing the functions is optional for exporters and for importers all
- *   the restrictions of using kmap apply.
- *
- *   dma_buf kmap calls outside of the range specified in begin_cpu_access are
- *   undefined. If the range is not PAGE_SIZE aligned, kmap needs to succeed on
- *   the partial chunks at the beginning and end but may return stale or bogus
- *   data outside of the range (in these partial chunks).
- *
- *   For some cases the overhead of kmap can be too high, a vmap interface
- *   is introduced. This interface should be used very carefully, as vmalloc
- *   space is a limited resources on many architectures.
+ *   Since for most kernel internal dma-buf accesses need the entire buffer, a
+ *   vmap interface is introduced. Note that on very old 32-bit architectures
+ *   vmalloc space might be limited and result in vmap calls failing.
  *
  *   Interfaces::
  *  void \*dma_buf_vmap(struct dma_buf \*dmabuf)
@@ -1052,43 +1032,6 @@ int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
 }
 EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
 
-/**
- * dma_buf_kmap - Map a page of the buffer object into kernel address space. 
The
- * same restrictions as for kmap and friends apply.
- * @dmabuf:[in]buffer to map page from.
- * @page_num:  [in]page in PAGE_SIZE units to map.
- *
- * This call must always succeed, any necessary preparations that might fail
- * need to be done in begin_cpu_access.
- */
-void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long page_num)
-{
-   WARN_ON(!dmabuf);
-
-   if (!dmabuf->ops->map)
-   return NULL;
-   return dmabuf->ops->map(dmabuf, page_num);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kmap);
-
-/**
- * dma_buf_kunmap - Unmap a page obtained by dma_buf_kmap.
- * @dmabuf:[in]buffer to unmap page from.
- * @page_num:  [in]page in PAGE_SIZE units to unmap.
- * @vaddr: [in]kernel space pointer obtained from dma_buf_kmap.
- *
- * This call must always succeed.
- */
-void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num,
-   void *vaddr)
-{
-   WARN_ON(!dmabuf);
-
-   if (dmabuf->ops->unmap)
-   dmabuf->ops->unmap(dmabuf, page_num, vaddr);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kunmap);
-
 
 /**
  * dma_buf_mmap - Setup up a userspace mmap with the given vma
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index af73f835c51c..7feb9c3805ae 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -464,8 +464,6 @@ int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
 enum dma_data_direction dir);
 int dma_buf_end_cpu_access(struct dma_buf *dma_buf,
   enum dma_data_direction dir);
-void *dma_buf_kmap(struct dma_buf *, unsigned long);
-void dma_buf_kunmap(struct dma_buf *, unsigned long, void *);
 
 int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
 unsigned long);
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/15] drm/tegra: Delete host1x_bo_ops->k(un)map

2019-11-18 Thread Daniel Vetter
It doesn't have any callers anymore.

Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't
do userspace mmaps, but a kernel vmap. I think most places use vmap
for this, except ttm, which uses kmap for vmap for added confusion.
mmap seems entirely for userspace mappings set up through mmap(2)
syscall.

Signed-off-by: Daniel Vetter 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: linux-te...@vger.kernel.org
---
 drivers/gpu/drm/tegra/gem.c | 28 
 include/linux/host1x.h  | 13 -
 2 files changed, 41 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 746dae32c484..662cb7c87ef5 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -103,32 +103,6 @@ static void tegra_bo_munmap(struct host1x_bo *bo, void 
*addr)
vunmap(addr);
 }
 
-static void *tegra_bo_kmap(struct host1x_bo *bo, unsigned int page)
-{
-   struct tegra_bo *obj = host1x_to_tegra_bo(bo);
-
-   if (obj->vaddr)
-   return obj->vaddr + page * PAGE_SIZE;
-   else if (obj->gem.import_attach)
-   return dma_buf_kmap(obj->gem.import_attach->dmabuf, page);
-   else
-   return vmap(obj->pages + page, 1, VM_MAP,
-   pgprot_writecombine(PAGE_KERNEL));
-}
-
-static void tegra_bo_kunmap(struct host1x_bo *bo, unsigned int page,
-   void *addr)
-{
-   struct tegra_bo *obj = host1x_to_tegra_bo(bo);
-
-   if (obj->vaddr)
-   return;
-   else if (obj->gem.import_attach)
-   dma_buf_kunmap(obj->gem.import_attach->dmabuf, page, addr);
-   else
-   vunmap(addr);
-}
-
 static struct host1x_bo *tegra_bo_get(struct host1x_bo *bo)
 {
struct tegra_bo *obj = host1x_to_tegra_bo(bo);
@@ -145,8 +119,6 @@ static const struct host1x_bo_ops tegra_bo_ops = {
.unpin = tegra_bo_unpin,
.mmap = tegra_bo_mmap,
.munmap = tegra_bo_munmap,
-   .kmap = tegra_bo_kmap,
-   .kunmap = tegra_bo_kunmap,
 };
 
 static int tegra_bo_iommu_map(struct tegra_drm *tegra, struct tegra_bo *bo)
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index 6f8d772591ba..6edeb9228c4e 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -72,8 +72,6 @@ struct host1x_bo_ops {
void (*unpin)(struct device *dev, struct sg_table *sgt);
void *(*mmap)(struct host1x_bo *bo);
void (*munmap)(struct host1x_bo *bo, void *addr);
-   void *(*kmap)(struct host1x_bo *bo, unsigned int pagenum);
-   void (*kunmap)(struct host1x_bo *bo, unsigned int pagenum, void *addr);
 };
 
 struct host1x_bo {
@@ -119,17 +117,6 @@ static inline void host1x_bo_munmap(struct host1x_bo *bo, 
void *addr)
bo->ops->munmap(bo, addr);
 }
 
-static inline void *host1x_bo_kmap(struct host1x_bo *bo, unsigned int pagenum)
-{
-   return bo->ops->kmap(bo, pagenum);
-}
-
-static inline void host1x_bo_kunmap(struct host1x_bo *bo,
-   unsigned int pagenum, void *addr)
-{
-   bo->ops->kunmap(bo, pagenum, addr);
-}
-
 /*
  * host1x syncpoints
  */
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 14/15] sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support

2019-11-18 Thread Daniel Vetter
No in-tree users left.

Signed-off-by: Daniel Vetter 
Cc: Kirti Wankhede 
Cc: k...@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 samples/vfio-mdev/mbochs.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index ac5c8c17b1ff..3cc5e5921682 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -891,26 +891,10 @@ static void mbochs_release_dmabuf(struct dma_buf *buf)
mutex_unlock(&mdev_state->ops_lock);
 }
 
-static void *mbochs_kmap_dmabuf(struct dma_buf *buf, unsigned long page_num)
-{
-   struct mbochs_dmabuf *dmabuf = buf->priv;
-   struct page *page = dmabuf->pages[page_num];
-
-   return kmap(page);
-}
-
-static void mbochs_kunmap_dmabuf(struct dma_buf *buf, unsigned long page_num,
-void *vaddr)
-{
-   kunmap(vaddr);
-}
-
 static struct dma_buf_ops mbochs_dmabuf_ops = {
.map_dma_buf  = mbochs_map_dmabuf,
.unmap_dma_buf= mbochs_unmap_dmabuf,
.release  = mbochs_release_dmabuf,
-   .map  = mbochs_kmap_dmabuf,
-   .unmap= mbochs_kunmap_dmabuf,
.mmap = mbochs_mmap_dmabuf,
 };
 
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 06/15] drm/i915: Drop dma_buf->k(un)map

2019-11-18 Thread Daniel Vetter
No in-tree users left.

Aside, I think mock_dmabuf would be a nice addition to drm
mock/selftest helpers (we have some already), with an
EXPORT_SYMBOL_FOR_TESTS_ONLY.

Signed-off-by: Daniel Vetter 
Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sam Ravnborg 
Cc: "Christian König" 
---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 36 ---
 .../gpu/drm/i915/gem/selftests/mock_dmabuf.c  | 16 -
 2 files changed, 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index eaea49d08eb5..372b57ca0efc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -93,40 +93,6 @@ static void i915_gem_dmabuf_vunmap(struct dma_buf *dma_buf, 
void *vaddr)
i915_gem_object_unpin_map(obj);
 }
 
-static void *i915_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long 
page_num)
-{
-   struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
-   struct page *page;
-
-   if (page_num >= obj->base.size >> PAGE_SHIFT)
-   return NULL;
-
-   if (!i915_gem_object_has_struct_page(obj))
-   return NULL;
-
-   if (i915_gem_object_pin_pages(obj))
-   return NULL;
-
-   /* Synchronisation is left to the caller (via .begin_cpu_access()) */
-   page = i915_gem_object_get_page(obj, page_num);
-   if (IS_ERR(page))
-   goto err_unpin;
-
-   return kmap(page);
-
-err_unpin:
-   i915_gem_object_unpin_pages(obj);
-   return NULL;
-}
-
-static void i915_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long 
page_num, void *addr)
-{
-   struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
-
-   kunmap(virt_to_page(addr));
-   i915_gem_object_unpin_pages(obj);
-}
-
 static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct 
*vma)
 {
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
@@ -195,8 +161,6 @@ static const struct dma_buf_ops i915_dmabuf_ops =  {
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
-   .map = i915_gem_dmabuf_kmap,
-   .unmap = i915_gem_dmabuf_kunmap,
.mmap = i915_gem_dmabuf_mmap,
.vmap = i915_gem_dmabuf_vmap,
.vunmap = i915_gem_dmabuf_vunmap,
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c 
b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
index b9e059d4328a..9272bef57092 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
@@ -76,20 +76,6 @@ static void mock_dmabuf_vunmap(struct dma_buf *dma_buf, void 
*vaddr)
vm_unmap_ram(vaddr, mock->npages);
 }
 
-static void *mock_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
-{
-   struct mock_dmabuf *mock = to_mock(dma_buf);
-
-   return kmap(mock->pages[page_num]);
-}
-
-static void mock_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long 
page_num, void *addr)
-{
-   struct mock_dmabuf *mock = to_mock(dma_buf);
-
-   return kunmap(mock->pages[page_num]);
-}
-
 static int mock_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct 
*vma)
 {
return -ENODEV;
@@ -99,8 +85,6 @@ static const struct dma_buf_ops mock_dmabuf_ops =  {
.map_dma_buf = mock_map_dma_buf,
.unmap_dma_buf = mock_unmap_dma_buf,
.release = mock_dmabuf_release,
-   .map = mock_dmabuf_kmap,
-   .unmap = mock_dmabuf_kunmap,
.mmap = mock_dmabuf_mmap,
.vmap = mock_dmabuf_vmap,
.vunmap = mock_dmabuf_vunmap,
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation

2019-11-18 Thread Daniel Vetter
It's a dummy anyway.

Signed-off-by: Daniel Vetter 
Cc: Russell King 
---
 drivers/gpu/drm/armada/armada_gem.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 93cf8b8bfcff..976685f2939e 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -461,16 +461,6 @@ static void armada_gem_prime_unmap_dma_buf(struct 
dma_buf_attachment *attach,
kfree(sgt);
 }
 
-static void *armada_gem_dmabuf_no_kmap(struct dma_buf *buf, unsigned long n)
-{
-   return NULL;
-}
-
-static void
-armada_gem_dmabuf_no_kunmap(struct dma_buf *buf, unsigned long n, void *addr)
-{
-}
-
 static int
 armada_gem_dmabuf_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
 {
@@ -481,8 +471,6 @@ static const struct dma_buf_ops armada_gem_prime_dmabuf_ops 
= {
.map_dma_buf= armada_gem_prime_map_dma_buf,
.unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
.release= drm_gem_dmabuf_release,
-   .map= armada_gem_dmabuf_no_kmap,
-   .unmap  = armada_gem_dmabuf_no_kunmap,
.mmap   = armada_gem_dmabuf_mmap,
 };
 
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

2019-11-18 Thread Daniel Vetter
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.

Signed-off-by: Daniel Vetter 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: xen-de...@lists.xenproject.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 drivers/xen/gntdev-dmabuf.c | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 2c4f324f8626..fe7bd69d6955 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -342,35 +342,12 @@ static void dmabuf_exp_ops_release(struct dma_buf 
*dma_buf)
mutex_unlock(&priv->lock);
 }
 
-static void *dmabuf_exp_ops_kmap(struct dma_buf *dma_buf,
-unsigned long page_num)
-{
-   /* Not implemented. */
-   return NULL;
-}
-
-static void dmabuf_exp_ops_kunmap(struct dma_buf *dma_buf,
- unsigned long page_num, void *addr)
-{
-   /* Not implemented. */
-}
-
-static int dmabuf_exp_ops_mmap(struct dma_buf *dma_buf,
-  struct vm_area_struct *vma)
-{
-   /* Not implemented. */
-   return 0;
-}
-
 static const struct dma_buf_ops dmabuf_exp_ops =  {
.attach = dmabuf_exp_ops_attach,
.detach = dmabuf_exp_ops_detach,
.map_dma_buf = dmabuf_exp_ops_map_dma_buf,
.unmap_dma_buf = dmabuf_exp_ops_unmap_dma_buf,
.release = dmabuf_exp_ops_release,
-   .map = dmabuf_exp_ops_kmap,
-   .unmap = dmabuf_exp_ops_kunmap,
-   .mmap = dmabuf_exp_ops_mmap,
 };
 
 struct gntdev_dmabuf_export_args {
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/15] drm/i915: Remove dma_buf_kmap selftest

2019-11-18 Thread Daniel Vetter
It's the only user left in the entire kernel for dma_buf_kmap/_kunmap.
Delete it, before we start garbage-collecting the various
implementations.

Signed-off-by: Daniel Vetter 
Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Daniel Vetter 
Cc: Mika Kuoppala 
Cc: Dave Airlie 
---
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 101 --
 1 file changed, 101 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index d85d1ce273ca..2a52b92586b9 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -254,106 +254,6 @@ static int igt_dmabuf_export_vmap(void *arg)
return err;
 }
 
-static int igt_dmabuf_export_kmap(void *arg)
-{
-   struct drm_i915_private *i915 = arg;
-   struct drm_i915_gem_object *obj;
-   struct dma_buf *dmabuf;
-   void *ptr;
-   int err;
-
-   obj = i915_gem_object_create_shmem(i915, 2 * PAGE_SIZE);
-   if (IS_ERR(obj))
-   return PTR_ERR(obj);
-
-   dmabuf = i915_gem_prime_export(&obj->base, 0);
-   i915_gem_object_put(obj);
-   if (IS_ERR(dmabuf)) {
-   err = PTR_ERR(dmabuf);
-   pr_err("i915_gem_prime_export failed with err=%d\n", err);
-   return err;
-   }
-
-   ptr = dma_buf_kmap(dmabuf, 0);
-   if (!ptr) {
-   pr_err("dma_buf_kmap failed\n");
-   err = -ENOMEM;
-   goto err;
-   }
-
-   if (memchr_inv(ptr, 0, PAGE_SIZE)) {
-   dma_buf_kunmap(dmabuf, 0, ptr);
-   pr_err("Exported page[0] not initialiased to zero!\n");
-   err = -EINVAL;
-   goto err;
-   }
-
-   memset(ptr, 0xc5, PAGE_SIZE);
-   dma_buf_kunmap(dmabuf, 0, ptr);
-
-   ptr = i915_gem_object_pin_map(obj, I915_MAP_WB);
-   if (IS_ERR(ptr)) {
-   err = PTR_ERR(ptr);
-   pr_err("i915_gem_object_pin_map failed with err=%d\n", err);
-   goto err;
-   }
-   memset(ptr + PAGE_SIZE, 0xaa, PAGE_SIZE);
-   i915_gem_object_flush_map(obj);
-   i915_gem_object_unpin_map(obj);
-
-   ptr = dma_buf_kmap(dmabuf, 1);
-   if (!ptr) {
-   pr_err("dma_buf_kmap failed\n");
-   err = -ENOMEM;
-   goto err;
-   }
-
-   if (memchr_inv(ptr, 0xaa, PAGE_SIZE)) {
-   dma_buf_kunmap(dmabuf, 1, ptr);
-   pr_err("Exported page[1] not set to 0xaa!\n");
-   err = -EINVAL;
-   goto err;
-   }
-
-   memset(ptr, 0xc5, PAGE_SIZE);
-   dma_buf_kunmap(dmabuf, 1, ptr);
-
-   ptr = dma_buf_kmap(dmabuf, 0);
-   if (!ptr) {
-   pr_err("dma_buf_kmap failed\n");
-   err = -ENOMEM;
-   goto err;
-   }
-   if (memchr_inv(ptr, 0xc5, PAGE_SIZE)) {
-   dma_buf_kunmap(dmabuf, 0, ptr);
-   pr_err("Exported page[0] did not retain 0xc5!\n");
-   err = -EINVAL;
-   goto err;
-   }
-   dma_buf_kunmap(dmabuf, 0, ptr);
-
-   ptr = dma_buf_kmap(dmabuf, 2);
-   if (ptr) {
-   pr_err("Erroneously kmapped beyond the end of the object!\n");
-   dma_buf_kunmap(dmabuf, 2, ptr);
-   err = -EINVAL;
-   goto err;
-   }
-
-   ptr = dma_buf_kmap(dmabuf, -1);
-   if (ptr) {
-   pr_err("Erroneously kmapped before the start of the object!\n");
-   dma_buf_kunmap(dmabuf, -1, ptr);
-   err = -EINVAL;
-   goto err;
-   }
-
-   err = 0;
-err:
-   dma_buf_put(dmabuf);
-   return err;
-}
-
 int i915_gem_dmabuf_mock_selftests(void)
 {
static const struct i915_subtest tests[] = {
@@ -362,7 +262,6 @@ int i915_gem_dmabuf_mock_selftests(void)
SUBTEST(igt_dmabuf_import),
SUBTEST(igt_dmabuf_import_ownership),
SUBTEST(igt_dmabuf_export_vmap),
-   SUBTEST(igt_dmabuf_export_kmap),
};
struct drm_i915_private *i915;
int err;
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

2019-11-18 Thread Daniel Vetter
No in-tree users left.

Signed-off-by: Daniel Vetter 
Cc: Pawel Osciak 
Cc: Marek Szyprowski 
Cc: Kyungmin Park 
Cc: Tomasz Figa 
Cc: linux-me...@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
 drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 
 drivers/media/common/videobuf2/videobuf2-dma-sg.c | 8 
 drivers/media/common/videobuf2/videobuf2-vmalloc.c| 8 
 3 files changed, 24 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c 
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 44cd0e530bbd..d0c9dffe49e5 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
vb2_dc_put(dbuf->priv);
 }
 
-static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
-{
-   struct vb2_dc_buf *buf = dbuf->priv;
-
-   return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
-}
-
 static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
struct vb2_dc_buf *buf = dbuf->priv;
@@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
.detach = vb2_dc_dmabuf_ops_detach,
.map_dma_buf = vb2_dc_dmabuf_ops_map,
.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
-   .map = vb2_dc_dmabuf_ops_kmap,
.vmap = vb2_dc_dmabuf_ops_vmap,
.mmap = vb2_dc_dmabuf_ops_mmap,
.release = vb2_dc_dmabuf_ops_release,
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c 
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index ed706b2a263c..6db60e9d5183 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf 
*dbuf)
vb2_dma_sg_put(dbuf->priv);
 }
 
-static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long 
pgnum)
-{
-   struct vb2_dma_sg_buf *buf = dbuf->priv;
-
-   return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
-}
-
 static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
struct vb2_dma_sg_buf *buf = dbuf->priv;
@@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
.detach = vb2_dma_sg_dmabuf_ops_detach,
.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
.unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
-   .map = vb2_dma_sg_dmabuf_ops_kmap,
.vmap = vb2_dma_sg_dmabuf_ops_vmap,
.mmap = vb2_dma_sg_dmabuf_ops_mmap,
.release = vb2_dma_sg_dmabuf_ops_release,
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c 
b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index 04d51ca63223..4d5af352e249 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct dma_buf 
*dbuf)
vb2_vmalloc_put(dbuf->priv);
 }
 
-static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long 
pgnum)
-{
-   struct vb2_vmalloc_buf *buf = dbuf->priv;
-
-   return buf->vaddr + pgnum * PAGE_SIZE;
-}
-
 static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
 {
struct vb2_vmalloc_buf *buf = dbuf->priv;
@@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
.detach = vb2_vmalloc_dmabuf_ops_detach,
.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
.unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
-   .map = vb2_vmalloc_dmabuf_ops_kmap,
.vmap = vb2_vmalloc_dmabuf_ops_vmap,
.mmap = vb2_vmalloc_dmabuf_ops_mmap,
.release = vb2_vmalloc_dmabuf_ops_release,
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/15] drm/omapdrm: Drop dma_buf->k(un)map

2019-11-18 Thread Daniel Vetter
No in-tree users left.

Note that this is one of the few (if only) implementations of dma-buf
that provided a kmap, but not a vmap implemenation. Given that the
only real user (in-tree at least) of kmap was tegra, and it's
impossible to buy a chip with tegra host1x and ompadrm on the same
SoC, there's no problem here.

Signed-off-by: Daniel Vetter 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 21 -
 1 file changed, 21 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c 
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 7344bb61936c..b319fe7f2371 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -85,25 +85,6 @@ static int omap_gem_dmabuf_end_cpu_access(struct dma_buf 
*buffer,
return 0;
 }
 
-static void *omap_gem_dmabuf_kmap(struct dma_buf *buffer,
-   unsigned long page_num)
-{
-   struct drm_gem_object *obj = buffer->priv;
-   struct page **pages;
-   omap_gem_get_pages(obj, &pages, false);
-   omap_gem_cpu_sync_page(obj, page_num);
-   return kmap(pages[page_num]);
-}
-
-static void omap_gem_dmabuf_kunmap(struct dma_buf *buffer,
-   unsigned long page_num, void *addr)
-{
-   struct drm_gem_object *obj = buffer->priv;
-   struct page **pages;
-   omap_gem_get_pages(obj, &pages, false);
-   kunmap(pages[page_num]);
-}
-
 static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
struct vm_area_struct *vma)
 {
@@ -123,8 +104,6 @@ static const struct dma_buf_ops omap_dmabuf_ops = {
.release = drm_gem_dmabuf_release,
.begin_cpu_access = omap_gem_dmabuf_begin_cpu_access,
.end_cpu_access = omap_gem_dmabuf_end_cpu_access,
-   .map = omap_gem_dmabuf_kmap,
-   .unmap = omap_gem_dmabuf_kunmap,
.mmap = omap_gem_dmabuf_mmap,
 };
 
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 10/15] drm/vmwgfx: Delete mmaping functions

2019-11-18 Thread Daniel Vetter
No need for stubs, dma-buf.c takes care of that.

Aside, not having a ->release callback smelled like refcounting leak
somewhere. It will also score you a WARN_ON backtrace in dma-buf.c on
every export. But then I found that ttm_device_object_init overwrites
it. Overwriting const memory is not going to go down well in recent
kernels.

One more aside: The (un)map_dma_buf can't ever be called because
->attach rejects everything. Might want to drop a BUG_ON(1) in there.
Same for ->detach.

Signed-off-by: Daniel Vetter 
Cc: VMware Graphics 
Cc: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 33 ---
 1 file changed, 33 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
index e420675e8db3..d9552a1efd13 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
@@ -62,45 +62,12 @@ static void vmw_prime_unmap_dma_buf(struct 
dma_buf_attachment *attach,
 {
 }
 
-static void *vmw_prime_dmabuf_vmap(struct dma_buf *dma_buf)
-{
-   return NULL;
-}
-
-static void vmw_prime_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
-{
-}
-
-static void *vmw_prime_dmabuf_kmap(struct dma_buf *dma_buf,
-   unsigned long page_num)
-{
-   return NULL;
-}
-
-static void vmw_prime_dmabuf_kunmap(struct dma_buf *dma_buf,
-   unsigned long page_num, void *addr)
-{
-
-}
-
-static int vmw_prime_dmabuf_mmap(struct dma_buf *dma_buf,
-struct vm_area_struct *vma)
-{
-   WARN_ONCE(true, "Attempted use of dmabuf mmap. Bad.\n");
-   return -ENOSYS;
-}
-
 const struct dma_buf_ops vmw_prime_dmabuf_ops =  {
.attach = vmw_prime_map_attach,
.detach = vmw_prime_map_detach,
.map_dma_buf = vmw_prime_map_dma_buf,
.unmap_dma_buf = vmw_prime_unmap_dma_buf,
.release = NULL,
-   .map = vmw_prime_dmabuf_kmap,
-   .unmap = vmw_prime_dmabuf_kunmap,
-   .mmap = vmw_prime_dmabuf_mmap,
-   .vmap = vmw_prime_dmabuf_vmap,
-   .vunmap = vmw_prime_dmabuf_vunmap,
 };
 
 int vmw_prime_fd_to_handle(struct drm_device *dev,
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] MAINTAINERS: Remove myself from drm-misc entry

2019-11-18 Thread Daniel Vetter
On Fri, Nov 15, 2019 at 03:52:36PM -0500, Sean Paul wrote:
> Cc: Dave Airlie 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Signed-off-by: Sean Paul 
> ---
> 
> I need to step away from -misc to prioritize other work that I have on
> my plate. It's been great fun (most of the time) and very rewarding
> doing this job. I will really miss it!
> 
> I plan on the 5.5 release being my last one before transitioning to my
> new role as committer :-)

Thanks a lot for your service as maintainer!

Acked-by: Daniel Vetter 

Cheers, Daniel

> 
> Sean
> 
> 
>  MAINTAINERS | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b63c291ad029..c2b89453805f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5362,7 +5362,6 @@ F:  include/linux/vga*
>  DRM DRIVERS AND MISC GPU PATCHES
>  M:   Maarten Lankhorst 
>  M:   Maxime Ripard 
> -M:   Sean Paul 
>  W:   https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html
>  S:   Maintained
>  T:   git git://anongit.freedesktop.org/drm/drm-misc
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS
> 

-- 
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] drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap

2019-11-18 Thread Gerd Hoffmann
  Hi,

> > > > Is any move buffer good enough to trigger this, i.e. will SYSTEM -> VRAM
> > > > work too?  That'll be easier because all I need to do is map the buffer
> > > > to a crtc to force pinning to vram, then check if the mappings are
> > > > intact still ...
> > >
> > > I think that should work too.
> >
> > Seems to work ok for ttm/vram.
> >
> > Test code:
> >   
> > https://git.kraxel.org/cgit/drminfo/commit/?id=a9eb96504dc17376e07b5c6edf5296b41a48bbfe
> 
> I think that's not nasty enough. If the mappings aren't updated, then
> you'll still see the the same old pages with the right contents. You
> need to change them somehow after they migrated (with vram eviction
> that happens automatically since there'll b another object in the same
> spot, for system memory I think you need the shrinker to kick in and
> free the pages first). Easiest probably to wait for a key press so you
> can appreciate the color, then write a different color (full screen)
> when the buffer is in vram.

update-object-after-move works fine.

try zap mappings with madvise(dontneed) has no bad effects (after vram
move, trying to force re-creating the ptes).

didn't try the memory pressure thing yet.

> You'd need to check the ptes themselves. Which I think not even proc
> shows by default (only the file that's supposed to be mapped). But
> good to confirm that the buffer moved at least.

One reproducable glitch found:  fork() while having a dma-buf mapped
triggers the WARN_ON in ttm_bo_vm_open().  Both old & new mmap code
paths, so this isn't something new coming from the
drm_gem_object_funcs.mmap switch.  Instead it is an old issue coming
from the address space handling being different in drm mmap and dmabuf
mmap code paths.

I can see now why you want a private address space for each object.
Does that imply we need an anon_inode for each gem object?  Or is
there some more lightweight way to do this?

cheers,
  Gerd

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V12 0/6] mdev based hardware virtio offloading support

2019-11-18 Thread Jason Wang


On 2019/11/18 下午2:16, Jason Wang wrote:

Hi all:

There are hardwares that can do virtio datapath offloading while
having its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and register itself as a new kind of mdev driver. Then
it provides a unified way for kernel virtio driver to talk with mdev
device implementation.

Though the series only contains kernel driver support, the goal is to
make the transport generic enough to support userspace drivers. This
means vhost-mdev[1] could be built on top as well by resuing the
transport.

A sample driver is also implemented which simulate a virito-net
loopback ethernet device on top of vringh + workqueue. This could be
used as a reference implementation for real hardware driver.

Also a real IFC VF driver was also posted here[2] which is a good
reference for vendors who is interested in their own virtio datapath
offloading product.

Consider mdev framework only support VFIO device and driver right now,
this series also extend it to support other types. This is done
through decoupling VFIO specific bits out of mdev core and make mdev
an independent module that allows to be used by multiple types of
buses.

Pktgen test was done with virito-net + mvnet loop back device.

Please review.

[1] https://lkml.org/lkml/2019/11/5/424
[2] https://lkml.org/lkml/2019/11/5/227

Changes from V11:
- decouple VFIO specific bits out of mdev core
- make mdev an indepdent module to allow buses other than VFIO mdev
- allow structure composition of mdev through specifiy the size of
   mdev structure
- introduce mdev_vfio structure and store the VFIO specific callbacks
   there
- don't use "mdev" bus for virtio, use a new "mdev_virtio" bus, and
   store the virtio specific callbacks in mdev_virtio structure.
- do the class_id, matching on top of "mdev_virtio" bus



It looks to me this series get some conflicts with gvt-linux.git. Will 
fix them and post v13.


Thanks




Changes from V10:
- rename mvnet to mvnet_loopback
- fix typo in the help text for sample Kconfig

Changes from V9:
- Tweak the help text for virito-mdev kconfig

Changes from V8:
- try silent checkpatch, some are still there becuase they were inherited
   from virtio_config_ops which needs to be resolved in an independent series
- tweak on the comment and doc
- remove VIRTIO_MDEV_F_VERSION_1 completely
- rename CONFIG_VIRTIO_MDEV_DEVICE to CONFIG_VIRTIO_MDEV

Changes from V7:
- drop {set|get}_mdev_features for virtio
- typo and comment style fixes

Changes from V6:
- rename ops files and compile guard

Changes from V5:
- use dev_warn() instead of WARN(1) when class id is not set
- validate id_table before trying to do matching between device and
   driver
- add wildcard for modpost script
- use unique name for id_table
- move get_mdev_features() to be the first member of virtio_device_ops
   and more comments for it
- typo fixes for the comments above virtio_mdev_ops

Changes from V4:
- keep mdev_set_class() for the device that doesn't use device ops
- use union for device ops pointer in mdev_device
- introduce class specific helper for getting is device ops
- use WARN_ON instead of BUG_ON in mdev_set_virtio_ops
- explain details of get_mdev_features() and get_vendor_id()
- distinguish the optional virito device ops from mandatory ones and
   make get_generation() optional
- rename vfio_mdev.h to vfio_mdev_ops.h, rename virito_mdev.h to
   virtio_mdev_ops.h
- don't abuse version fileds in virtio_mdev structure, use features
   instead
- fix warning during device remove
- style & docs tweaks and typo fixes

Changes from V3:
- document that class id (device ops) must be specified in create()
- add WARN() when trying to set class_id when it has already set
- add WARN() when class_id is not specified in create() and correctly
   return an error in this case
- correct the prototype of mdev_set_class() in the doc
- add documention of mdev_set_class()
- remove the unnecessary "class_id_fail" label when class id is not
   specified in create()
- convert id_table in vfio_mdev to const
- move mdev_set_class and its friends after mdev_uuid()
- suqash the patch of bus uevent into patch of introducing class id
- tweak the words in the docs per Cornelia suggestion
- tie class_id and device ops through class specific initialization
   routine like mdev_set_vfio_ops()
- typos fixes in the docs of virtio-mdev callbacks
- document the usage of virtqueues in struct virtio_mdev_device
- remove the useless vqs array in struct virtio_mdev_device
- rename MDEV_ID_XXX to MDEV_CLASS_ID_XXX

Changes from V2:
- fail when class_id is not specified
- drop the vringh patch
- match the doc to the code
- tweak the commit log
- move device_ops from parent to mdev device
- remove the unused MDEV_ID_VHOST

Changes from V1:
- move virtio_mdev.c to drivers/virtio
- store class_id in mdev_device 

Re: [PATCH V12 5/6] virtio: introduce a mdev based transport

2019-11-18 Thread Michael S. Tsirkin
On Mon, Nov 18, 2019 at 02:17:02PM +0800, Jason Wang wrote:
> This patch introduces a new mdev transport for virtio. This is used to
> use kernel virtio driver to drive the mediated device that is capable
> of populating virtqueue directly.
> 
> A new virtio-mdev driver will be registered to the mdev bus, when a
> new virtio-mdev device is probed, it will register the device with
> mdev based config ops. This means it is a software transport between
> mdev driver and mdev device. The transport was implemented through
> bus_ops of mdev parent.
> 
> Signed-off-by: Jason Wang 
> ---
>  drivers/virtio/Kconfig   |  13 ++
>  drivers/virtio/Makefile  |   1 +
>  drivers/virtio/virtio_mdev.c | 409 +++
>  include/linux/mdev_virtio.h  |   5 +
>  4 files changed, 428 insertions(+)
>  create mode 100644 drivers/virtio/virtio_mdev.c
> 
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 078615cf2afc..6a89b3de97d3 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -43,6 +43,19 @@ config VIRTIO_PCI_LEGACY
>  
> If unsure, say Y.
>  
> +config VIRTIO_MDEV
> + tristate "MDEV driver for virtio devices"
> + depends on MDEV_VIRTIO
> + default n
> + help
> +   This driver provides support for virtio based paravirtual
> +   device driver over MDEV bus. For this to be useful, you need
> +   an appropriate virtio mdev device implementation that
> +   operates on a physical device to allow the datapath of virtio
> +   to be offloaded to hardware.
> +
> +   If unsure, say M.
> +
>  config VIRTIO_PMEM
>   tristate "Support for virtio pmem driver"
>   depends on VIRTIO
> diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> index 3a2b5c5dcf46..f2997b6c812f 100644
> --- a/drivers/virtio/Makefile
> +++ b/drivers/virtio/Makefile
> @@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
>  virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
>  obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
>  obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
> +obj-$(CONFIG_VIRTIO_MDEV) += virtio_mdev.o
> diff --git a/drivers/virtio/virtio_mdev.c b/drivers/virtio/virtio_mdev.c
> new file mode 100644
> index ..7fdb42f055df
> --- /dev/null
> +++ b/drivers/virtio/virtio_mdev.c
> @@ -0,0 +1,409 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * VIRTIO based driver for Mediated device
> + *
> + * Copyright (c) 2019, Red Hat. All rights reserved.
> + * Author: Jason Wang 
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_VERSION  "0.1"
> +#define DRIVER_AUTHOR   "Red Hat Corporation"
> +#define DRIVER_DESC "VIRTIO based driver for Mediated device"
> +
> +#define to_virtio_mdev_device(dev) \
> + container_of(dev, struct virtio_mdev_device, vdev)
> +
> +struct virtio_mdev_device {
> + struct virtio_device vdev;
> + struct mdev_device *mdev;
> + u64 features;
> +
> + /* The lock to protect virtqueue list */
> + spinlock_t lock;
> + /* List of virtio_mdev_vq_info */
> + struct list_head virtqueues;
> +};
> +
> +struct virtio_mdev_vq_info {
> + /* the actual virtqueue */
> + struct virtqueue *vq;
> +
> + /* the list node for the virtqueues list */
> + struct list_head node;
> +};
> +
> +static struct mdev_device *vm_get_mdev(struct virtio_device *vdev)
> +{
> + struct virtio_mdev_device *vm_dev = to_virtio_mdev_device(vdev);
> + struct mdev_device *mdev = vm_dev->mdev;
> +
> + return mdev;
> +}
> +
> +static void virtio_mdev_get(struct virtio_device *vdev, unsigned offset,
> + void *buf, unsigned len)
> +{
> + struct mdev_device *mdev = vm_get_mdev(vdev);
> + const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
> +
> + ops->get_config(mdev, offset, buf, len);
> +}
> +
> +static void virtio_mdev_set(struct virtio_device *vdev, unsigned offset,
> + const void *buf, unsigned len)
> +{
> + struct mdev_device *mdev = vm_get_mdev(vdev);
> + const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
> +
> + ops->set_config(mdev, offset, buf, len);
> +}
> +
> +static u32 virtio_mdev_generation(struct virtio_device *vdev)
> +{
> + struct mdev_device *mdev = vm_get_mdev(vdev);
> + const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
> +
> +
> + if (ops->get_generation)
> + return ops->get_generation(mdev);
> +
> + return 0;
> +}
> +
> +static u8 virtio_mdev_get_status(struct virtio_device *vdev)
> +{
> + struct mdev_device *mdev = vm_get_mdev(vdev);
> + const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
> +
> + return ops->get_status(mdev);
> +}
> +
> +static void virtio_mdev_set_status(struct virtio_device *vdev, u8 status)
> +{
> + struct mdev_device *m

Re: [Xen-devel] [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

2019-11-18 Thread Oleksandr Andrushchenko

On 11/18/19 12:35 PM, Daniel Vetter wrote:

There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.

Signed-off-by: Daniel Vetter 

Reviewed-by: Oleksandr Andrushchenko 

Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: xen-de...@lists.xenproject.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
  drivers/xen/gntdev-dmabuf.c | 23 ---
  1 file changed, 23 deletions(-)

diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 2c4f324f8626..fe7bd69d6955 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -342,35 +342,12 @@ static void dmabuf_exp_ops_release(struct dma_buf 
*dma_buf)
mutex_unlock(&priv->lock);
  }
  
-static void *dmabuf_exp_ops_kmap(struct dma_buf *dma_buf,

-unsigned long page_num)
-{
-   /* Not implemented. */
-   return NULL;
-}
-
-static void dmabuf_exp_ops_kunmap(struct dma_buf *dma_buf,
- unsigned long page_num, void *addr)
-{
-   /* Not implemented. */
-}
-
-static int dmabuf_exp_ops_mmap(struct dma_buf *dma_buf,
-  struct vm_area_struct *vma)
-{
-   /* Not implemented. */
-   return 0;
-}
-
  static const struct dma_buf_ops dmabuf_exp_ops =  {
.attach = dmabuf_exp_ops_attach,
.detach = dmabuf_exp_ops_detach,
.map_dma_buf = dmabuf_exp_ops_map_dma_buf,
.unmap_dma_buf = dmabuf_exp_ops_unmap_dma_buf,
.release = dmabuf_exp_ops_release,
-   .map = dmabuf_exp_ops_kmap,
-   .unmap = dmabuf_exp_ops_kunmap,
-   .mmap = dmabuf_exp_ops_mmap,
  };
  
  struct gntdev_dmabuf_export_args {


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

2019-11-18 Thread Jürgen Groß

On 18.11.19 11:35, Daniel Vetter wrote:

There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.

Signed-off-by: Daniel Vetter 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: xen-de...@lists.xenproject.org


Reviewed-by: Juergen Gross 


--
Ack for merging this through drm trees very much appreciated.


Yes, I'm fine with that.


Juergen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V12 5/6] virtio: introduce a mdev based transport

2019-11-18 Thread Jason Wang


On 2019/11/18 下午6:44, Michael S. Tsirkin wrote:

+static const struct mdev_virtio_class_id virtio_id_table[] = {
+   { MDEV_VIRTIO_CLASS_ID_VIRTIO },
+   { 0 },
+};
+

Do we still need the class ID? It's a virtio mdev bus,
do we need a virtio class as well?



If we want to have auto match between vhost-mdev driver and vhost-mdev 
device, we need this.


Otherwise, user need to manually probe or bind driver to the device.

Thanks

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

2019-11-18 Thread Marek Szyprowski

On 18.11.2019 11:35, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter 
> Cc: Pawel Osciak 
> Cc: Marek Szyprowski 
> Cc: Kyungmin Park 
> Cc: Tomasz Figa 
> Cc: linux-me...@vger.kernel.org

Acked-by: Marek Szyprowski 

> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
>   drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 
>   drivers/media/common/videobuf2/videobuf2-dma-sg.c | 8 
>   drivers/media/common/videobuf2/videobuf2-vmalloc.c| 8 
>   3 files changed, 24 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c 
> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 44cd0e530bbd..d0c9dffe49e5 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf 
> *dbuf)
>   vb2_dc_put(dbuf->priv);
>   }
>   
> -static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long 
> pgnum)
> -{
> - struct vb2_dc_buf *buf = dbuf->priv;
> -
> - return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>   static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   struct vb2_dc_buf *buf = dbuf->priv;
> @@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
>   .detach = vb2_dc_dmabuf_ops_detach,
>   .map_dma_buf = vb2_dc_dmabuf_ops_map,
>   .unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
> - .map = vb2_dc_dmabuf_ops_kmap,
>   .vmap = vb2_dc_dmabuf_ops_vmap,
>   .mmap = vb2_dc_dmabuf_ops_mmap,
>   .release = vb2_dc_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c 
> b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index ed706b2a263c..6db60e9d5183 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf 
> *dbuf)
>   vb2_dma_sg_put(dbuf->priv);
>   }
>   
> -static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long 
> pgnum)
> -{
> - struct vb2_dma_sg_buf *buf = dbuf->priv;
> -
> - return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>   static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   struct vb2_dma_sg_buf *buf = dbuf->priv;
> @@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
>   .detach = vb2_dma_sg_dmabuf_ops_detach,
>   .map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
>   .unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
> - .map = vb2_dma_sg_dmabuf_ops_kmap,
>   .vmap = vb2_dma_sg_dmabuf_ops_vmap,
>   .mmap = vb2_dma_sg_dmabuf_ops_mmap,
>   .release = vb2_dma_sg_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c 
> b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 04d51ca63223..4d5af352e249 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct 
> dma_buf *dbuf)
>   vb2_vmalloc_put(dbuf->priv);
>   }
>   
> -static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long 
> pgnum)
> -{
> - struct vb2_vmalloc_buf *buf = dbuf->priv;
> -
> - return buf->vaddr + pgnum * PAGE_SIZE;
> -}
> -
>   static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>   {
>   struct vb2_vmalloc_buf *buf = dbuf->priv;
> @@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
>   .detach = vb2_vmalloc_dmabuf_ops_detach,
>   .map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
>   .unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
> - .map = vb2_vmalloc_dmabuf_ops_kmap,
>   .vmap = vb2_vmalloc_dmabuf_ops_vmap,
>   .mmap = vb2_vmalloc_dmabuf_ops_mmap,
>   .release = vb2_vmalloc_dmabuf_ops_release,

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V13 0/6] mdev based hardware virtio offloading support

2019-11-18 Thread Jason Wang
Hi all:

There are hardwares that can do virtio datapath offloading while
having its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and register itself as a new kind of mdev driver. Then
it provides a unified way for kernel virtio driver to talk with mdev
device implementation.

Though the series only contains kernel driver support, the goal is to
make the transport generic enough to support userspace drivers. This
means vhost-mdev[1] could be built on top as well by resuing the
transport.

A sample driver is also implemented which simulate a virito-net
loopback ethernet device on top of vringh + workqueue. This could be
used as a reference implementation for real hardware driver.

Also a real IFC VF driver was also posted here[2] which is a good
reference for vendors who is interested in their own virtio datapath
offloading product.

Consider mdev framework only support VFIO device and driver right now,
this series also extend it to support other types. This is done
through decoupling VFIO specific bits out of mdev core and make mdev
an independent module that allows to be used by multiple types of
buses.

Pktgen test was done with virito-net + mvnet loop back device.

Please review.

[1] https://lkml.org/lkml/2019/11/7/62
[2] https://lkml.org/lkml/2019/11/12/215

Changes from V12:
- rebase on top of gvt-linux.git

Changes from V11:
- decouple VFIO specific bits out of mdev core
- make mdev an indepdent module to allow buses other than VFIO mdev
- allow structure composition of mdev through specifiy the size of
  mdev structure
- introduce mdev_vfio structure and store the VFIO specific callbacks
  there
- don't use "mdev" bus for virtio, use a new "mdev_virtio" bus, and
  store the virtio specific callbacks in mdev_virtio structure.
- do the class_id, matching on top of "mdev_virtio" bus

Changes from V10:
- rename mvnet to mvnet_loopback
- fix typo in the help text for sample Kconfig

Changes from V9:
- Tweak the help text for virito-mdev kconfig

Changes from V8:
- try silent checkpatch, some are still there becuase they were inherited
  from virtio_config_ops which needs to be resolved in an independent series
- tweak on the comment and doc
- remove VIRTIO_MDEV_F_VERSION_1 completely
- rename CONFIG_VIRTIO_MDEV_DEVICE to CONFIG_VIRTIO_MDEV

Changes from V7:
- drop {set|get}_mdev_features for virtio
- typo and comment style fixes

Changes from V6:
- rename ops files and compile guard

Changes from V5:
- use dev_warn() instead of WARN(1) when class id is not set
- validate id_table before trying to do matching between device and
  driver
- add wildcard for modpost script
- use unique name for id_table
- move get_mdev_features() to be the first member of virtio_device_ops
  and more comments for it
- typo fixes for the comments above virtio_mdev_ops

Changes from V4:
- keep mdev_set_class() for the device that doesn't use device ops
- use union for device ops pointer in mdev_device
- introduce class specific helper for getting is device ops
- use WARN_ON instead of BUG_ON in mdev_set_virtio_ops
- explain details of get_mdev_features() and get_vendor_id()
- distinguish the optional virito device ops from mandatory ones and
  make get_generation() optional
- rename vfio_mdev.h to vfio_mdev_ops.h, rename virito_mdev.h to
  virtio_mdev_ops.h
- don't abuse version fileds in virtio_mdev structure, use features
  instead
- fix warning during device remove
- style & docs tweaks and typo fixes

Changes from V3:
- document that class id (device ops) must be specified in create()
- add WARN() when trying to set class_id when it has already set
- add WARN() when class_id is not specified in create() and correctly
  return an error in this case
- correct the prototype of mdev_set_class() in the doc
- add documention of mdev_set_class()
- remove the unnecessary "class_id_fail" label when class id is not
  specified in create()
- convert id_table in vfio_mdev to const
- move mdev_set_class and its friends after mdev_uuid()
- suqash the patch of bus uevent into patch of introducing class id
- tweak the words in the docs per Cornelia suggestion
- tie class_id and device ops through class specific initialization
  routine like mdev_set_vfio_ops()
- typos fixes in the docs of virtio-mdev callbacks
- document the usage of virtqueues in struct virtio_mdev_device
- remove the useless vqs array in struct virtio_mdev_device
- rename MDEV_ID_XXX to MDEV_CLASS_ID_XXX

Changes from V2:
- fail when class_id is not specified
- drop the vringh patch
- match the doc to the code
- tweak the commit log
- move device_ops from parent to mdev device
- remove the unused MDEV_ID_VHOST

Changes from V1:
- move virtio_mdev.c to drivers/virtio
- store class_id in mdev_device instead of mdev_parent
- store device_ops in mdev_device instead of mdev_parent
- reorder the patch, vringh fix c

[PATCH V13 1/6] mdev: make mdev bus agnostic

2019-11-18 Thread Jason Wang
Current mdev is tied to a VFIO specific "mdev" bus. This prevent mdev
from being used by other types of API/buses. So this patch tries to make
mdev bus agnostic through making a mdev core a thin module:

- decouple VFIO bus specific bits from mdev_core.c to mdev_vfio.c and
  introduce mdev_vfio module
- require to specify the type of bus when registering mdev device and
  mdev driver

With those modifications mdev become a generic module that could be
used by multiple types of virtual buses and devices.

Signed-off-by: Jason Wang 
---
 .../driver-api/vfio-mediated-device.rst   |  68 ++--
 MAINTAINERS   |   1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c  |   8 +-
 drivers/s390/cio/vfio_ccw_ops.c   |   6 +-
 drivers/s390/crypto/vfio_ap_ops.c |  21 ++--
 drivers/s390/crypto/vfio_ap_private.h |   2 +-
 drivers/vfio/mdev/Kconfig |  17 ++-
 drivers/vfio/mdev/Makefile|   4 +-
 drivers/vfio/mdev/mdev_core.c | 104 +-
 drivers/vfio/mdev/mdev_driver.c   |  29 ++---
 drivers/vfio/mdev/mdev_private.h  |  13 ++-
 drivers/vfio/mdev/mdev_vfio.c |  48 
 drivers/vfio/mdev/vfio_mdev.c |   5 +-
 drivers/vfio/vfio_iommu_type1.c   |   6 +-
 include/linux/mdev.h  |  16 ++-
 include/linux/mdev_vfio.h |  25 +
 samples/vfio-mdev/mbochs.c|   8 +-
 samples/vfio-mdev/mdpy.c  |   8 +-
 samples/vfio-mdev/mtty.c  |   8 +-
 19 files changed, 269 insertions(+), 128 deletions(-)
 create mode 100644 drivers/vfio/mdev/mdev_vfio.c
 create mode 100644 include/linux/mdev_vfio.h

diff --git a/Documentation/driver-api/vfio-mediated-device.rst 
b/Documentation/driver-api/vfio-mediated-device.rst
index 25eb7d5b834b..1887d27a565e 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -49,35 +49,37 @@ devices as examples, as these devices are the first devices 
to use this module::
 
  +---+
  |   |
- | +---+ |  mdev_register_driver() +--+
- | |   | +<+  |
- | |  mdev | | |  |
- | |  bus  | +>+ vfio_mdev.ko |<-> VFIO user
- | |  driver   | | probe()/remove()|  |APIs
- | |   | | +--+
- | +---+ |
+ |   MDEV CORE   |  mdev_register_driver() +--+
+ |MODULE +<+  |
+ |mdev.ko| |  |
+ |   +>+ vfio_mdev.ko |<-> VFIO user
+ |   | probe()/remove()|  |APIs
+ |   | +--+
+ +---+---+---+
+ |  /|\
+ |   |
+callbacks|   | mdev_register_device()
+ |   | mdev_register_bus()
+\|/  |
+ +---+---+---+
+ |   |  mdev_vfio_register_device() +--+
+ |   +<-+  |
+ |   |  |  nvidia.ko   |<-> 
physical
+ |   +->+  |device
+ |   MDEV VFIO   |callbacks +--+
+ |   Physical|
+ |device |  mdev_vfio_register_device() +--+
+ |   interface   |<-+  |
+ |   |  |  i915.ko |<-> 
physical
+ | mdev_vfio.ko  +->+  |device
+ |   |callbacks +--+
+ |   |
+ |   |  mdev_vfio_register_device() +--+
+ |   +<-+  |
+ |   |  | ccw_device.ko|<-> 
physical
+ |   +->+  |device
+ |   |callbacks +--+
  |   |
- |  MDEV CORE|
- |   MODULE  |
- |   mdev.ko |
- | +---+ |  mdev_register_device() +--+
- | |   | +<+  |
- | |   | | |  nvidia.ko   |<-> physical
- | |   | +>+  |device
- | |   | |callbacks+--+
- | | Physical  | |
- | |  device   | |  mdev_register_device() +--+
- | | interface | |<---

[PATCH V13 3/6] mdev: move to drivers/

2019-11-18 Thread Jason Wang
Mdev now is nothing VFIO specific, let's move it to upper
directory.

Signed-off-by: Jason Wang 
---
 MAINTAINERS   |  7 +--
 drivers/Kconfig   |  2 ++
 drivers/Makefile  |  1 +
 drivers/mdev/Kconfig  | 19 ++
 drivers/mdev/Makefile |  5 +
 drivers/{vfio => }/mdev/mdev_core.c   |  0
 drivers/{vfio => }/mdev/mdev_driver.c |  0
 drivers/{vfio => }/mdev/mdev_private.h|  0
 drivers/{vfio => }/mdev/mdev_sysfs.c  |  0
 .../{vfio/mdev/mdev_vfio.c => mdev/vfio.c}|  0
 drivers/vfio/mdev/Kconfig | 20 ---
 drivers/vfio/mdev/Makefile|  4 
 drivers/vfio/mdev/vfio_mdev.c |  2 --
 13 files changed, 32 insertions(+), 28 deletions(-)
 create mode 100644 drivers/mdev/Kconfig
 create mode 100644 drivers/mdev/Makefile
 rename drivers/{vfio => }/mdev/mdev_core.c (100%)
 rename drivers/{vfio => }/mdev/mdev_driver.c (100%)
 rename drivers/{vfio => }/mdev/mdev_private.h (100%)
 rename drivers/{vfio => }/mdev/mdev_sysfs.c (100%)
 rename drivers/{vfio/mdev/mdev_vfio.c => mdev/vfio.c} (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6d590afb62c3..5d7e8badf58c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17129,15 +17129,18 @@ T:git git://github.com/awilliam/linux-vfio.git
 S: Maintained
 F: Documentation/driver-api/vfio.rst
 F: drivers/vfio/
+F: drivers/mdev/vfio.c
 F: include/linux/vfio.h
 F: include/uapi/linux/vfio.h
 
-VFIO MEDIATED DEVICE DRIVERS
+MEDIATED DEVICE DRIVERS
+M: Alex Williamson 
 M: Kirti Wankhede 
+R: Cornelia Huck 
 L: k...@vger.kernel.org
 S: Maintained
 F: Documentation/driver-api/vfio-mediated-device.rst
-F: drivers/vfio/mdev/
+F: drivers/mdev
 F: include/linux/mdev.h
 F: include/linux/mdev_vfio.h
 F: samples/vfio-mdev/
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 8befa53f43be..3e2839048fe6 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -228,4 +228,6 @@ source "drivers/interconnect/Kconfig"
 
 source "drivers/counter/Kconfig"
 
+source "drivers/mdev/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index aaef17cc6512..592e23f2e629 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -186,3 +186,4 @@ obj-$(CONFIG_SIOX)  += siox/
 obj-$(CONFIG_GNSS) += gnss/
 obj-$(CONFIG_INTERCONNECT) += interconnect/
 obj-$(CONFIG_COUNTER)  += counter/
+obj-$(CONFIG_MDEV) += mdev/
diff --git a/drivers/mdev/Kconfig b/drivers/mdev/Kconfig
new file mode 100644
index ..4561f2d4178f
--- /dev/null
+++ b/drivers/mdev/Kconfig
@@ -0,0 +1,19 @@
+
+config MDEV
+   tristate "Mediated device driver framework"
+   default n
+   help
+ Provides a framework to virtualize devices.
+
+ If you don't know what do here, say N.
+
+config VFIO_MDEV
+   tristate "VFIO Mediated device driver"
+depends on VFIO && MDEV
+default n
+   help
+ Proivdes a mediated BUS for userspace driver through VFIO
+ framework. See Documentation/vfio-mediated-device.txt for
+ more details.
+
+ If you don't know what do here, say N.
diff --git a/drivers/mdev/Makefile b/drivers/mdev/Makefile
new file mode 100644
index ..0b749e7f8ff4
--- /dev/null
+++ b/drivers/mdev/Makefile
@@ -0,0 +1,5 @@
+
+mdev-y := mdev_core.o mdev_sysfs.o mdev_driver.o
+mdev_vfio-y := vfio.o
+obj-$(CONFIG_MDEV) += mdev.o
+obj-$(CONFIG_VFIO_MDEV) += mdev_vfio.o
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/mdev/mdev_core.c
similarity index 100%
rename from drivers/vfio/mdev/mdev_core.c
rename to drivers/mdev/mdev_core.c
diff --git a/drivers/vfio/mdev/mdev_driver.c b/drivers/mdev/mdev_driver.c
similarity index 100%
rename from drivers/vfio/mdev/mdev_driver.c
rename to drivers/mdev/mdev_driver.c
diff --git a/drivers/vfio/mdev/mdev_private.h b/drivers/mdev/mdev_private.h
similarity index 100%
rename from drivers/vfio/mdev/mdev_private.h
rename to drivers/mdev/mdev_private.h
diff --git a/drivers/vfio/mdev/mdev_sysfs.c b/drivers/mdev/mdev_sysfs.c
similarity index 100%
rename from drivers/vfio/mdev/mdev_sysfs.c
rename to drivers/mdev/mdev_sysfs.c
diff --git a/drivers/vfio/mdev/mdev_vfio.c b/drivers/mdev/vfio.c
similarity index 100%
rename from drivers/vfio/mdev/mdev_vfio.c
rename to drivers/mdev/vfio.c
diff --git a/drivers/vfio/mdev/Kconfig b/drivers/vfio/mdev/Kconfig
index 2e07ca915a96..9a9234c3e00e 100644
--- a/drivers/vfio/mdev/Kconfig
+++ b/drivers/vfio/mdev/Kconfig
@@ -1,24 +1,4 @@
 
-config MDEV
-   tristate "Mediated device driver framework"
-   default n
-   help
- Provides a framework to virtualize devices.
-
- If you don't know what do here, say N.
-
-config VFIO_MDEV
-   tristate "VFIO Mediated device driver"
-depends on VFIO

[PATCH V13 2/6] mdev: split out VFIO bus specific parent ops

2019-11-18 Thread Jason Wang
The only thing left for generalizing mdev is the VFIO specific parent
ops. This is basically the open/release/read/write/ioctl/mmap.

To support this, mdev core is extend to support a specific size
of structure during create, this will allow to compose mdev structure
into mdev vfio structure and place the VFIO specific callbacks there
like:

struct mdev_vfio {
   struct mdev_device mdev;
   const struct mdev_vfio_ops *ops;
};

Helpers for setting and getting the ops were introduced to support
mdev vfio device to set ops and vfio mdev driver to use the ops.

Signed-off-by: Jason Wang 
---
 .../driver-api/vfio-mediated-device.rst   | 34 +--
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 16 ---
 drivers/s390/cio/vfio_ccw_ops.c   | 17 +---
 drivers/s390/crypto/vfio_ap_ops.c | 13 --
 drivers/vfio/mdev/mdev_core.c |  5 ++-
 drivers/vfio/mdev/mdev_private.h  |  5 +++
 drivers/vfio/mdev/mdev_vfio.c | 30 -
 drivers/vfio/mdev/vfio_mdev.c | 38 
 include/linux/mdev.h  | 37 
 include/linux/mdev_vfio.h | 43 +++
 samples/vfio-mdev/mbochs.c| 18 +---
 samples/vfio-mdev/mdpy.c  | 19 +---
 samples/vfio-mdev/mtty.c  | 16 ---
 13 files changed, 189 insertions(+), 102 deletions(-)

diff --git a/Documentation/driver-api/vfio-mediated-device.rst 
b/Documentation/driver-api/vfio-mediated-device.rst
index 1887d27a565e..9045584e4ea3 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -153,26 +153,36 @@ callbacks per mdev parent device, per mdev type, or any 
other categorization.
 Vendor drivers are expected to be fully asynchronous in this respect or
 provide their own internal resource protection.)
 
-The callbacks in the mdev_parent_ops structure are as follows:
+A driver should use the mdev_parent_ops structure in the function call
+to register itself with the mdev core driver::
 
-* open: open callback of mediated device
-* close: close callback of mediated device
-* ioctl: ioctl callback of mediated device
+   extern int mdev_vfio_register_device(struct device *dev,
+ const struct mdev_parent_ops 
*ops);
+
+However, the mdev_parent_ops structure is not required in the function call
+that a driver should use to unregister itself with the mdev core driver::
+
+   extern void mdev_vfio_unregister_device(struct device *dev);
+
+The VFIO specific callbacks is abstracted in mdev_vfio_ops structure
+are as follows:
+
+* open: open callback of VFIO mediated device
+* close: close callback of VFIO mediated device
+* ioctl: ioctl callback of VFIO mediated device
 * read : read emulation callback
 * write: write emulation callback
 * mmap: mmap emulation callback
 
-A driver should use the mdev_parent_ops structure and bus type in the
-function call to register itself with the mdev core driver::
+During the creation of VFIO mediated device, mdev_vfio_ops need to be
+specified::
 
-   extern int  mdev_register_device(struct device *dev,
-const struct mdev_parent_ops *ops,
- struct bus_type *bus);
+void mdev_vfio_set_ops(struct mdev_device *mdev,
+const struct mdev_vfio_ops *ops);
 
-However, the mdev_parent_ops structure is not required in the function call
-that a driver should use to unregister itself with the mdev core driver::
+Those callbacks could be fetched by drivers through::
 
-   extern void mdev_unregister_device(struct device *dev);
+const struct mdev_vfio_ops *mdev_vfio_get_ops(struct mdev_device 
*mdev);
 
 
 Mediated Device Management Interface Through sysfs
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index afdb3de5ce2f..e72c36174035 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -643,6 +643,8 @@ static void kvmgt_put_vfio_device(void *vgpu)
vfio_device_put(((struct intel_vgpu *)vgpu)->vdev.vfio_device);
 }
 
+static const struct mdev_vfio_ops intel_mdev_vfio_ops;
+
 static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
 {
struct intel_vgpu *vgpu = NULL;
@@ -678,6 +680,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct 
mdev_device *mdev)
 dev_name(mdev_dev(mdev)));
ret = 0;
 
+   mdev_vfio_set_ops(mdev, &intel_mdev_vfio_ops);
 out:
return ret;
 }
@@ -1581,20 +1584,21 @@ static const struct attribute_group 
*intel_vgpu_groups[] = {
NULL,
 };
 
-static struct mdev_parent_ops intel_vgpu_ops = {
-   .mdev_attr_groups   = intel_vgpu_groups,
-   .create = intel_vgpu_create,
-  

Re: [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

2019-11-18 Thread Hans Verkuil
On 11/18/19 11:35 AM, Daniel Vetter wrote:
> No in-tree users left.
> 
> Signed-off-by: Daniel Vetter 

Acked-by: Hans Verkuil 

Thanks!

Hans

> Cc: Pawel Osciak 
> Cc: Marek Szyprowski 
> Cc: Kyungmin Park 
> Cc: Tomasz Figa 
> Cc: linux-me...@vger.kernel.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
>  drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8 
>  drivers/media/common/videobuf2/videobuf2-dma-sg.c | 8 
>  drivers/media/common/videobuf2/videobuf2-vmalloc.c| 8 
>  3 files changed, 24 deletions(-)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c 
> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 44cd0e530bbd..d0c9dffe49e5 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf 
> *dbuf)
>   vb2_dc_put(dbuf->priv);
>  }
>  
> -static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long 
> pgnum)
> -{
> - struct vb2_dc_buf *buf = dbuf->priv;
> -
> - return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>  static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>  {
>   struct vb2_dc_buf *buf = dbuf->priv;
> @@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
>   .detach = vb2_dc_dmabuf_ops_detach,
>   .map_dma_buf = vb2_dc_dmabuf_ops_map,
>   .unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
> - .map = vb2_dc_dmabuf_ops_kmap,
>   .vmap = vb2_dc_dmabuf_ops_vmap,
>   .mmap = vb2_dc_dmabuf_ops_mmap,
>   .release = vb2_dc_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c 
> b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index ed706b2a263c..6db60e9d5183 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf 
> *dbuf)
>   vb2_dma_sg_put(dbuf->priv);
>  }
>  
> -static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long 
> pgnum)
> -{
> - struct vb2_dma_sg_buf *buf = dbuf->priv;
> -
> - return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
>  static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
>  {
>   struct vb2_dma_sg_buf *buf = dbuf->priv;
> @@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
>   .detach = vb2_dma_sg_dmabuf_ops_detach,
>   .map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
>   .unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
> - .map = vb2_dma_sg_dmabuf_ops_kmap,
>   .vmap = vb2_dma_sg_dmabuf_ops_vmap,
>   .mmap = vb2_dma_sg_dmabuf_ops_mmap,
>   .release = vb2_dma_sg_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c 
> b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 04d51ca63223..4d5af352e249 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct 
> dma_buf *dbuf)
>   vb2_vmalloc_put(dbuf->priv);
>  }
>  
> -static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long 
> pgnum)
> -{
> - struct vb2_vmalloc_buf *buf = dbuf->priv;
> -
> - return buf->vaddr + pgnum * PAGE_SIZE;
> -}
> -
>  static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
>  {
>   struct vb2_vmalloc_buf *buf = dbuf->priv;
> @@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
>   .detach = vb2_vmalloc_dmabuf_ops_detach,
>   .map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
>   .unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
> - .map = vb2_vmalloc_dmabuf_ops_kmap,
>   .vmap = vb2_vmalloc_dmabuf_ops_vmap,
>   .mmap = vb2_vmalloc_dmabuf_ops_mmap,
>   .release = vb2_vmalloc_dmabuf_ops_release,
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V13 4/6] mdev: introduce mediated virtio bus

2019-11-18 Thread Jason Wang
This patch implements a mediated virtio bus over mdev framework. This
will be used by the future virtio-mdev and vhost-mdev on top to allow
driver from either userspace or kernel to control the device which is
capable of offloading virtio datapath.

Signed-off-by: Jason Wang 
---
 MAINTAINERS   |   2 +
 drivers/mdev/Kconfig  |  10 ++
 drivers/mdev/Makefile |   2 +
 drivers/mdev/virtio.c | 126 +++
 include/linux/mdev_virtio.h   | 163 ++
 include/linux/mod_devicetable.h   |   8 ++
 scripts/mod/devicetable-offsets.c |   3 +
 scripts/mod/file2alias.c  |  12 +++
 8 files changed, 326 insertions(+)
 create mode 100644 drivers/mdev/virtio.c
 create mode 100644 include/linux/mdev_virtio.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 5d7e8badf58c..e1b57c84f249 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17269,6 +17269,8 @@ F:  include/linux/virtio*.h
 F: include/uapi/linux/virtio_*.h
 F: drivers/crypto/virtio/
 F: mm/balloon_compaction.c
+F: include/linux/mdev_virtio.h
+F: drivers/mdev/virtio.c
 
 VIRTIO BLOCK AND SCSI DRIVERS
 M: "Michael S. Tsirkin" 
diff --git a/drivers/mdev/Kconfig b/drivers/mdev/Kconfig
index 4561f2d4178f..cd84d4670552 100644
--- a/drivers/mdev/Kconfig
+++ b/drivers/mdev/Kconfig
@@ -17,3 +17,13 @@ config VFIO_MDEV
  more details.
 
  If you don't know what do here, say N.
+
+config MDEV_VIRTIO
+   tristate "Mediated VIRTIO bus"
+   depends on VIRTIO && MDEV
+   default n
+   help
+ Proivdes a mediated BUS for virtio. It could be used by
+  either kenrel driver or userspace driver.
+
+ If you don't know what do here, say N.
diff --git a/drivers/mdev/Makefile b/drivers/mdev/Makefile
index 0b749e7f8ff4..eb14031c9944 100644
--- a/drivers/mdev/Makefile
+++ b/drivers/mdev/Makefile
@@ -1,5 +1,7 @@
 
 mdev-y := mdev_core.o mdev_sysfs.o mdev_driver.o
 mdev_vfio-y := vfio.o
+mdev_virtio-y := virtio.o
 obj-$(CONFIG_MDEV) += mdev.o
 obj-$(CONFIG_VFIO_MDEV) += mdev_vfio.o
+obj-$(CONFIG_MDEV_VIRTIO) += mdev_virtio.o
diff --git a/drivers/mdev/virtio.c b/drivers/mdev/virtio.c
new file mode 100644
index ..25de329615c4
--- /dev/null
+++ b/drivers/mdev/virtio.c
@@ -0,0 +1,126 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Mediated VIRTIO bus
+ *
+ * Copyright (c) 2019, Red Hat. All rights reserved.
+ * Author: Jason Wang 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mdev_private.h"
+
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR  "Jason Wang"
+#define DRIVER_DESC"Mediated VIRTIO bus"
+
+struct bus_type mdev_virtio_bus_type;
+
+struct mdev_virtio_device {
+   struct mdev_device mdev;
+   const struct mdev_virtio_ops *ops;
+   u16 class_id;
+};
+
+#define to_mdev_virtio(mdev) container_of(mdev, \
+ struct mdev_virtio_device, mdev)
+#define to_mdev_virtio_drv(mdrv) container_of(mdrv, \
+ struct mdev_virtio_driver, drv)
+
+static int mdev_virtio_match(struct device *dev, struct device_driver *drv)
+{
+   unsigned int i;
+   struct mdev_device *mdev = mdev_from_dev(dev, &mdev_virtio_bus_type);
+   struct mdev_virtio_device *mdev_virtio = to_mdev_virtio(mdev);
+   struct mdev_driver *mdrv = to_mdev_driver(drv);
+   struct mdev_virtio_driver *mdrv_virtio = to_mdev_virtio_drv(mdrv);
+   const struct mdev_virtio_class_id *ids = mdrv_virtio->id_table;
+
+   if (!ids)
+   return 0;
+
+   for (i = 0; ids[i].id; i++)
+   if (ids[i].id == mdev_virtio->class_id)
+   return 1;
+   return 0;
+}
+
+static int mdev_virtio_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+   struct mdev_device *mdev = mdev_from_dev(dev, &mdev_virtio_bus_type);
+   struct mdev_virtio_device *mdev_virtio = to_mdev_virtio(mdev);
+
+   return add_uevent_var(env, "MODALIAS=mdev_virtio:c%02X",
+ mdev_virtio->class_id);
+}
+
+struct bus_type mdev_virtio_bus_type = {
+   .name   = "mdev_virtio",
+   .probe  = mdev_probe,
+   .remove = mdev_remove,
+   .match  = mdev_virtio_match,
+   .uevent = mdev_virtio_uevent,
+};
+EXPORT_SYMBOL(mdev_virtio_bus_type);
+
+void mdev_virtio_set_class_id(struct mdev_device *mdev, u16 class_id)
+{
+   struct mdev_virtio_device *mdev_virtio = to_mdev_virtio(mdev);
+
+   mdev_virtio->class_id = class_id;
+}
+EXPORT_SYMBOL(mdev_virtio_set_class_id);
+
+int mdev_virtio_register_device(struct device *dev,
+   const struct mdev_parent_ops *ops)
+{
+   return mdev_register_device(dev, ops, &mdev_virtio_bus_type,
+   sizeof(struct mdev_virtio_device));
+}
+EXPORT_SYMBOL(mdev_virtio_reg

[PATCH V13 5/6] virtio: introduce a mdev based transport

2019-11-18 Thread Jason Wang
This patch introduces a new mdev transport for virtio. This is used to
use kernel virtio driver to drive the mediated device that is capable
of populating virtqueue directly.

A new virtio-mdev driver will be registered to the mdev bus, when a
new virtio-mdev device is probed, it will register the device with
mdev based config ops. This means it is a software transport between
mdev driver and mdev device. The transport was implemented through
bus_ops of mdev parent.

Signed-off-by: Jason Wang 
---
 drivers/virtio/Kconfig   |  13 ++
 drivers/virtio/Makefile  |   1 +
 drivers/virtio/virtio_mdev.c | 409 +++
 include/linux/mdev_virtio.h  |   5 +
 4 files changed, 428 insertions(+)
 create mode 100644 drivers/virtio/virtio_mdev.c

diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 078615cf2afc..6a89b3de97d3 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -43,6 +43,19 @@ config VIRTIO_PCI_LEGACY
 
  If unsure, say Y.
 
+config VIRTIO_MDEV
+   tristate "MDEV driver for virtio devices"
+   depends on MDEV_VIRTIO
+   default n
+   help
+ This driver provides support for virtio based paravirtual
+ device driver over MDEV bus. For this to be useful, you need
+ an appropriate virtio mdev device implementation that
+ operates on a physical device to allow the datapath of virtio
+ to be offloaded to hardware.
+
+ If unsure, say M.
+
 config VIRTIO_PMEM
tristate "Support for virtio pmem driver"
depends on VIRTIO
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 3a2b5c5dcf46..f2997b6c812f 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
 virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
 obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
 obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
+obj-$(CONFIG_VIRTIO_MDEV) += virtio_mdev.o
diff --git a/drivers/virtio/virtio_mdev.c b/drivers/virtio/virtio_mdev.c
new file mode 100644
index ..7fdb42f055df
--- /dev/null
+++ b/drivers/virtio/virtio_mdev.c
@@ -0,0 +1,409 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * VIRTIO based driver for Mediated device
+ *
+ * Copyright (c) 2019, Red Hat. All rights reserved.
+ * Author: Jason Wang 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_VERSION  "0.1"
+#define DRIVER_AUTHOR   "Red Hat Corporation"
+#define DRIVER_DESC "VIRTIO based driver for Mediated device"
+
+#define to_virtio_mdev_device(dev) \
+   container_of(dev, struct virtio_mdev_device, vdev)
+
+struct virtio_mdev_device {
+   struct virtio_device vdev;
+   struct mdev_device *mdev;
+   u64 features;
+
+   /* The lock to protect virtqueue list */
+   spinlock_t lock;
+   /* List of virtio_mdev_vq_info */
+   struct list_head virtqueues;
+};
+
+struct virtio_mdev_vq_info {
+   /* the actual virtqueue */
+   struct virtqueue *vq;
+
+   /* the list node for the virtqueues list */
+   struct list_head node;
+};
+
+static struct mdev_device *vm_get_mdev(struct virtio_device *vdev)
+{
+   struct virtio_mdev_device *vm_dev = to_virtio_mdev_device(vdev);
+   struct mdev_device *mdev = vm_dev->mdev;
+
+   return mdev;
+}
+
+static void virtio_mdev_get(struct virtio_device *vdev, unsigned offset,
+   void *buf, unsigned len)
+{
+   struct mdev_device *mdev = vm_get_mdev(vdev);
+   const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
+
+   ops->get_config(mdev, offset, buf, len);
+}
+
+static void virtio_mdev_set(struct virtio_device *vdev, unsigned offset,
+   const void *buf, unsigned len)
+{
+   struct mdev_device *mdev = vm_get_mdev(vdev);
+   const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
+
+   ops->set_config(mdev, offset, buf, len);
+}
+
+static u32 virtio_mdev_generation(struct virtio_device *vdev)
+{
+   struct mdev_device *mdev = vm_get_mdev(vdev);
+   const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
+
+
+   if (ops->get_generation)
+   return ops->get_generation(mdev);
+
+   return 0;
+}
+
+static u8 virtio_mdev_get_status(struct virtio_device *vdev)
+{
+   struct mdev_device *mdev = vm_get_mdev(vdev);
+   const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
+
+   return ops->get_status(mdev);
+}
+
+static void virtio_mdev_set_status(struct virtio_device *vdev, u8 status)
+{
+   struct mdev_device *mdev = vm_get_mdev(vdev);
+   const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
+
+   return ops->set_status(mdev, status);
+}
+
+static void virtio_mdev_reset(struct virtio_device *vdev)
+{
+   struct mdev_device *mdev = vm_get_mdev(vdev);
+   con

[PATCH V13 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework

2019-11-18 Thread Jason Wang
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to make sure HVA is used
directly as the IOVA. This should be sufficient for kernel virtio
driver to work.

Only 'virtio' type is supported right now. I plan to add 'vhost' type
on top which requires some virtual IOMMU implemented in this sample
driver.

Signed-off-by: Jason Wang 
---
 MAINTAINERS|   1 +
 samples/Kconfig|  10 +
 samples/vfio-mdev/Makefile |   1 +
 samples/vfio-mdev/mvnet_loopback.c | 690 +
 4 files changed, 702 insertions(+)
 create mode 100644 samples/vfio-mdev/mvnet_loopback.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e1b57c84f249..36f9fe9034be 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17246,6 +17246,7 @@ F:  net/vmw_vsock/virtio_transport.c
 F: drivers/net/vsockmon.c
 F: drivers/vhost/vsock.c
 F: tools/testing/vsock/
+F: samples/vfio-mdev/mvnet_loopback.c
 
 VIRTIO CONSOLE DRIVER
 M: Amit Shah 
diff --git a/samples/Kconfig b/samples/Kconfig
index c8dacb4dda80..1bef029cc977 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -131,6 +131,16 @@ config SAMPLE_VFIO_MDEV_MDPY
  mediated device.  It is a simple framebuffer and supports
  the region display interface (VFIO_GFX_PLANE_TYPE_REGION).
 
+config SAMPLE_VIRTIO_MDEV_NET_LOOPBACK
+   tristate "Build loopback VIRTIO net example mediated device sample code 
-- loadable modules only"
+   depends on MDEV_VIRTIO && VHOST_RING && m
+   help
+ Build a networking sample device for use as a virtio
+ mediated device. The device cooperates with virtio-mdev bus
+ driver to present an virtio ethernet driver for
+ kernel. It simply loopbacks all packets from its TX
+ virtqueue to its RX virtqueue.
+
 config SAMPLE_VFIO_MDEV_MDPY_FB
tristate "Build VFIO mdpy example guest fbdev driver -- loadable module 
only"
depends on FB && m
diff --git a/samples/vfio-mdev/Makefile b/samples/vfio-mdev/Makefile
index 10d179c4fdeb..817618569848 100644
--- a/samples/vfio-mdev/Makefile
+++ b/samples/vfio-mdev/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_SAMPLE_VFIO_MDEV_MTTY) += mtty.o
 obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY) += mdpy.o
 obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY_FB) += mdpy-fb.o
 obj-$(CONFIG_SAMPLE_VFIO_MDEV_MBOCHS) += mbochs.o
+obj-$(CONFIG_SAMPLE_VIRTIO_MDEV_NET_LOOPBACK) += mvnet_loopback.o
diff --git a/samples/vfio-mdev/mvnet_loopback.c 
b/samples/vfio-mdev/mvnet_loopback.c
new file mode 100644
index ..79059a177f39
--- /dev/null
+++ b/samples/vfio-mdev/mvnet_loopback.c
@@ -0,0 +1,690 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Mediated virtual virtio-net device driver.
+ *
+ * Copyright (c) 2019, Red Hat Inc. All rights reserved.
+ * Author: Jason Wang 
+ *
+ * Sample driver that creates mdev device that simulates ethernet loopback
+ * device.
+ *
+ * Usage:
+ *
+ * # modprobe virtio_mdev
+ * # modprobe mvnet_loopback
+ * # cd /sys/devices/virtual/mvnet_loopback/mvnet_loopback/ \
+ *  mdev_supported_types/mvnet_loopback-virtio
+ * # echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > ./create
+ * # cd devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1001
+ * # ls -d virtio0
+ * virtio0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define VERSION_STRING  "0.1"
+#define DRIVER_AUTHOR   "Red Hat Corporation"
+
+#define MVNET_CLASS_NAME "mvnet_loopback"
+#define MVNET_NAME   "mvnet_loopback"
+
+#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev"
+
+/*
+ * Global Structures
+ */
+
+static struct mvnet_dev {
+   struct class*vd_class;
+   struct idr  vd_idr;
+   struct device   dev;
+} mvnet_dev;
+
+struct mvnet_virtqueue {
+   struct vringh vring;
+   struct vringh_kiov iov;
+   unsigned short head;
+   bool ready;
+   u64 desc_addr;
+   u64 device_addr;
+   u64 driver_addr;
+   u32 num;
+   void *private;
+   irqreturn_t (*cb)(void *data);
+};
+
+#define MVNET_QUEUE_ALIGN PAGE_SIZE
+#define MVNET_QUEUE_MAX 256
+#define MVNET_DEVICE_ID 0x1
+#define MVNET_VENDOR_ID 0
+
+u64 mvnet_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
+(1ULL << VIRTIO_F_VERSION_1) |
+(1ULL << VIRTIO_F_IOMMU_PLATFORM);
+
+/* State of each mdev device */
+struct mvnet_state {
+   struct mvnet_virtqueue vqs[2];
+   struct work_struct work;
+   /* spinlock to synchronize virtqueue state */
+   spinlock_t lock;
+   struct mdev_device *mdev;
+   struct virtio_net_config config;
+   void *buffer;
+   u32 status;
+   u32 generation;
+   u64 features;
+   struct list_head next;
+};
+
+static struct mutex 

Re: [PATCH 12/15] drm/tee_shm: Drop dma_buf_k(unmap) support

2019-11-18 Thread Greg Kroah-Hartman
On Mon, Nov 18, 2019 at 11:35:33AM +0100, Daniel Vetter wrote:
> There's no in-tree users anymore.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Cc: Jens Wiklander 
> Cc: tee-...@lists.linaro.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel

Acked-by: Greg Kroah-Hartman 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation

2019-11-18 Thread Greg KH
On Mon, Nov 18, 2019 at 11:35:25AM +0100, Daniel Vetter wrote:
> There's no callers in-tree anymore.
> 
> For merging probably best to stuff this into drm-misc, since that's
> where the dma-buf heaps will land too. And the resulting conflict
> hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
> implemenation.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Laura Abbott 
> Cc: Sumit Semwal 
> Cc: de...@driverdev.osuosl.org
> Cc: linaro-mm-...@lists.linaro.org
> ---
>  drivers/staging/android/ion/ion.c | 14 --
>  1 file changed, 14 deletions(-)

Acked-by: Greg Kroah-Hartman 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/15] drm/i915: Drop dma_buf->k(un)map

2019-11-18 Thread Christian König

Am 18.11.19 um 11:35 schrieb Daniel Vetter:

No in-tree users left.


Good to know, thanks.



Aside, I think mock_dmabuf would be a nice addition to drm
mock/selftest helpers (we have some already), with an
EXPORT_SYMBOL_FOR_TESTS_ONLY.

Signed-off-by: Daniel Vetter 
Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sam Ravnborg 
Cc: "Christian König" 


Acked-by: Christian König 


---
  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 36 ---
  .../gpu/drm/i915/gem/selftests/mock_dmabuf.c  | 16 -
  2 files changed, 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index eaea49d08eb5..372b57ca0efc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -93,40 +93,6 @@ static void i915_gem_dmabuf_vunmap(struct dma_buf *dma_buf, 
void *vaddr)
i915_gem_object_unpin_map(obj);
  }
  
-static void *i915_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)

-{
-   struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
-   struct page *page;
-
-   if (page_num >= obj->base.size >> PAGE_SHIFT)
-   return NULL;
-
-   if (!i915_gem_object_has_struct_page(obj))
-   return NULL;
-
-   if (i915_gem_object_pin_pages(obj))
-   return NULL;
-
-   /* Synchronisation is left to the caller (via .begin_cpu_access()) */
-   page = i915_gem_object_get_page(obj, page_num);
-   if (IS_ERR(page))
-   goto err_unpin;
-
-   return kmap(page);
-
-err_unpin:
-   i915_gem_object_unpin_pages(obj);
-   return NULL;
-}
-
-static void i915_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long 
page_num, void *addr)
-{
-   struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
-
-   kunmap(virt_to_page(addr));
-   i915_gem_object_unpin_pages(obj);
-}
-
  static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct 
vm_area_struct *vma)
  {
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
@@ -195,8 +161,6 @@ static const struct dma_buf_ops i915_dmabuf_ops =  {
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
-   .map = i915_gem_dmabuf_kmap,
-   .unmap = i915_gem_dmabuf_kunmap,
.mmap = i915_gem_dmabuf_mmap,
.vmap = i915_gem_dmabuf_vmap,
.vunmap = i915_gem_dmabuf_vunmap,
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c 
b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
index b9e059d4328a..9272bef57092 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
@@ -76,20 +76,6 @@ static void mock_dmabuf_vunmap(struct dma_buf *dma_buf, void 
*vaddr)
vm_unmap_ram(vaddr, mock->npages);
  }
  
-static void *mock_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)

-{
-   struct mock_dmabuf *mock = to_mock(dma_buf);
-
-   return kmap(mock->pages[page_num]);
-}
-
-static void mock_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long 
page_num, void *addr)
-{
-   struct mock_dmabuf *mock = to_mock(dma_buf);
-
-   return kunmap(mock->pages[page_num]);
-}
-
  static int mock_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct 
*vma)
  {
return -ENODEV;
@@ -99,8 +85,6 @@ static const struct dma_buf_ops mock_dmabuf_ops =  {
.map_dma_buf = mock_map_dma_buf,
.unmap_dma_buf = mock_unmap_dma_buf,
.release = mock_dmabuf_release,
-   .map = mock_dmabuf_kmap,
-   .unmap = mock_dmabuf_kunmap,
.mmap = mock_dmabuf_mmap,
.vmap = mock_dmabuf_vmap,
.vunmap = mock_dmabuf_vunmap,


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 14/15] sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support

2019-11-18 Thread Gerd Hoffmann
On Mon, Nov 18, 2019 at 11:35:35AM +0100, Daniel Vetter wrote:
> No in-tree users left.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Kirti Wankhede 
> Cc: k...@vger.kernel.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel

Acked-by: Gerd Hoffmann 

cheers,
  Gerd

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 17/24] mm/gup: track FOLL_PIN pages

2019-11-18 Thread Jan Kara
On Thu 14-11-19 21:53:33, John Hubbard wrote:
> Add tracking of pages that were pinned via FOLL_PIN.
> 
> As mentioned in the FOLL_PIN documentation, callers who effectively set
> FOLL_PIN are required to ultimately free such pages via put_user_page().
> The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
> for DIO and/or RDMA use".
> 
> Pages that have been pinned via FOLL_PIN are identifiable via a
> new function call:
> 
>bool page_dma_pinned(struct page *page);
> 
> What to do in response to encountering such a page, is left to later
> patchsets. There is discussion about this in [1].
^^ missing this reference
in the changelog...

> This also changes a BUG_ON(), to a WARN_ON(), in follow_page_mask().
> 
> Suggested-by: Jan Kara 
> Suggested-by: Jérôme Glisse 
> Signed-off-by: John Hubbard 
> ---
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 6588d2e02628..db872766480f 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1054,6 +1054,8 @@ static inline __must_check bool try_get_page(struct 
> page *page)
>   return true;
>  }
>  
> +__must_check bool user_page_ref_inc(struct page *page);
> +
>  static inline void put_page(struct page *page)
>  {
>   page = compound_head(page);
> @@ -1071,29 +1073,70 @@ static inline void put_page(struct page *page)
>   __put_page(page);
>  }
>  
> -/**
> - * put_user_page() - release a gup-pinned page
> - * @page:pointer to page to be released
> +/*
> + * GUP_PIN_COUNTING_BIAS, and the associated functions that use it, overload
> + * the page's refcount so that two separate items are tracked: the original 
> page
> + * reference count, and also a new count of how many get_user_pages() calls 
> were
^^ pin_user_pages()

> + * made against the page. ("gup-pinned" is another term for the latter).
> + *
> + * With this scheme, get_user_pages() becomes special: such pages are marked
^^^ pin_user_pages()

> + * as distinct from normal pages. As such, the put_user_page() call (and its
> + * variants) must be used in order to release gup-pinned pages.
> + *
> + * Choice of value:
>   *
> - * Pages that were pinned via pin_user_pages*() must be released via either
> - * put_user_page(), or one of the put_user_pages*() routines. This is so that
> - * eventually such pages can be separately tracked and uniquely handled. In
> - * particular, interactions with RDMA and filesystems need special handling.
> + * By making GUP_PIN_COUNTING_BIAS a power of two, debugging of page 
> reference
> + * counts with respect to get_user_pages() and put_user_page() becomes 
> simpler,
^^^ pin_user_pages()

> + * due to the fact that adding an even power of two to the page refcount has
> + * the effect of using only the upper N bits, for the code that counts up 
> using
> + * the bias value. This means that the lower bits are left for the exclusive
> + * use of the original code that increments and decrements by one (or at 
> least,
> + * by much smaller values than the bias value).
>   *
> - * put_user_page() and put_page() are not interchangeable, despite this early
> - * implementation that makes them look the same. put_user_page() calls must
> - * be perfectly matched up with pin*() calls.
> + * Of course, once the lower bits overflow into the upper bits (and this is
> + * OK, because subtraction recovers the original values), then visual 
> inspection
> + * no longer suffices to directly view the separate counts. However, for 
> normal
> + * applications that don't have huge page reference counts, this won't be an
> + * issue.
> + *
> + * Locking: the lockless algorithm described in page_cache_get_speculative()
> + * and page_cache_gup_pin_speculative() provides safe operation for
> + * get_user_pages and page_mkclean and other calls that race to set up page
> + * table entries.
>   */
...
> @@ -2070,9 +2191,16 @@ static int gup_hugepte(pte_t *ptep, unsigned long sz, 
> unsigned long addr,
>   page = head + ((addr & (sz-1)) >> PAGE_SHIFT);
>   refs = __record_subpages(page, addr, end, pages + *nr);
>  
> - head = try_get_compound_head(head, refs);
> - if (!head)
> - return 0;
> + if (flags & FOLL_PIN) {
> + head = page;
> + if (unlikely(!user_page_ref_inc(head)))
> + return 0;
> + head = page;

Why do you assign 'head' twice? Also the refcounting logic is repeated
several times so perhaps you can factor it out in to a helper function or
even move it to __record_subpages()?

> + } else {
> + head = try_get_compound_head(head, refs);
> + if (!head)
> + return 0;
> + }
>  
>   if (unlikely(pte_val(pte) != pte_val(*ptep))) {
>   put_compound_head(head, refs);

So this will do the wrong thing for FOLL_PIN

Re: [PATCH v5 15/24] fs/io_uring: set FOLL_PIN via pin_user_pages()

2019-11-18 Thread Jan Kara
On Thu 14-11-19 21:53:31, John Hubbard wrote:
> Convert fs/io_uring to use the new pin_user_pages() call, which sets
> FOLL_PIN. Setting FOLL_PIN is now required for code that requires
> tracking of pinned pages, and therefore for any code that calls
> put_user_page().
> 
> In partial anticipation of this work, the io_uring code was already
> calling put_user_page() instead of put_page(). Therefore, in order to
> convert from the get_user_pages()/put_page() model, to the
> pin_user_pages()/put_user_page() model, the only change required
> here is to change get_user_pages() to pin_user_pages().
> 
> Signed-off-by: John Hubbard 

Looks good to me. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  fs/io_uring.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index f9a38998f2fc..cff64bd00db9 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -3433,7 +3433,7 @@ static int io_sqe_buffer_register(struct io_ring_ctx 
> *ctx, void __user *arg,
>  
>   ret = 0;
>   down_read(¤t->mm->mmap_sem);
> - pret = get_user_pages(ubuf, nr_pages,
> + pret = pin_user_pages(ubuf, nr_pages,
> FOLL_WRITE | FOLL_LONGTERM,
> pages, vmas);
>   if (pret == nr_pages) {
> -- 
> 2.24.0
> 
-- 
Jan Kara 
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 10/24] mm/gup: introduce pin_user_pages*() and FOLL_PIN

2019-11-18 Thread Jan Kara
On Thu 14-11-19 21:53:26, John Hubbard wrote:
>  /*
> - * NOTE on FOLL_LONGTERM:
> + * FOLL_PIN and FOLL_LONGTERM may be used in various combinations with each
> + * other. Here is what they mean, and how to use them:
>   *
>   * FOLL_LONGTERM indicates that the page will be held for an indefinite time
> - * period _often_ under userspace control.  This is contrasted with
> - * iov_iter_get_pages() where usages which are transient.
> + * period _often_ under userspace control.  This is in contrast to
> + * iov_iter_get_pages(), where usages which are transient.
  ^^^ when you touch this, please fix also the
second sentense. It doesn't quite make sense to me... I'd probably write
there "whose usages are transient" but maybe you can come up with something
even better.

Otherwise the patch looks good to me so feel free to add:

Reviewed-by: Jan Kara 

Honza
-- 
Jan Kara 
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 02/24] mm/gup: factor out duplicate code from four routines

2019-11-18 Thread Jan Kara
On Thu 14-11-19 21:53:18, John Hubbard wrote:
> There are four locations in gup.c that have a fair amount of code
> duplication. This means that changing one requires making the same
> changes in four places, not to mention reading the same code four
> times, and wondering if there are subtle differences.
> 
> Factor out the common code into static functions, thus reducing the
> overall line count and the code's complexity.
> 
> Also, take the opportunity to slightly improve the efficiency of the
> error cases, by doing a mass subtraction of the refcount, surrounded
> by get_page()/put_page().
> 
> Also, further simplify (slightly), by waiting until the the successful
> end of each routine, to increment *nr.
> 
> Reviewed-by: Jérôme Glisse 
> Cc: Jan Kara 
> Cc: Ira Weiny 
> Cc: Christoph Hellwig 
> Cc: Aneesh Kumar K.V 
> Signed-off-by: John Hubbard 
> ---
>  mm/gup.c | 95 
>  1 file changed, 40 insertions(+), 55 deletions(-)
> 
> diff --git a/mm/gup.c b/mm/gup.c
> index 85caf76b3012..858541ea30ce 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1969,6 +1969,29 @@ static int __gup_device_huge_pud(pud_t pud, pud_t 
> *pudp, unsigned long addr,
>  }
>  #endif
>  
> +static int __record_subpages(struct page *page, unsigned long addr,
> +  unsigned long end, struct page **pages)
> +{
> + int nr = 0;
> + int nr_recorded_pages = 0;
> +
> + do {
> + pages[nr] = page;
> + nr++;
> + page++;
> + nr_recorded_pages++;
> + } while (addr += PAGE_SIZE, addr != end);
> + return nr_recorded_pages;

nr == nr_recorded_pages so no need for both... BTW, structuring this as a
for loop would be probably more logical and shorter now:

for (nr = 0; addr != end; addr += PAGE_SIZE)
pages[nr++] = page++;
return nr;

The rest of the patch looks good to me.

Honza

-- 
Jan Kara 
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 11/24] goldish_pipe: convert to pin_user_pages() and put_user_page()

2019-11-18 Thread Jan Kara
On Thu 14-11-19 21:53:27, John Hubbard wrote:
> 1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages().
> 
> 2. As required by pin_user_pages(), release these pages via
> put_user_page(). In this case, do so via put_user_pages_dirty_lock().
> 
> That has the side effect of calling set_page_dirty_lock(), instead
> of set_page_dirty(). This is probably more accurate.
> 
> As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
> dealing with a file backed page where we have reference on the inode it
> hangs off." [1]
> 
> Another side effect is that the release code is simplified because
> the page[] loop is now in gup.c instead of here, so just delete the
> local release_user_pages() entirely, and call
> put_user_pages_dirty_lock() directly, instead.
> 
> [1] https://lore.kernel.org/r/20190723153640.gb...@lst.de
> 
> Reviewed-by: Ira Weiny 
> Signed-off-by: John Hubbard 

Looks good to me. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  drivers/platform/goldfish/goldfish_pipe.c | 17 +++--
>  1 file changed, 3 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/platform/goldfish/goldfish_pipe.c 
> b/drivers/platform/goldfish/goldfish_pipe.c
> index 7ed2a21a0bac..635a8bc1b480 100644
> --- a/drivers/platform/goldfish/goldfish_pipe.c
> +++ b/drivers/platform/goldfish/goldfish_pipe.c
> @@ -274,7 +274,7 @@ static int pin_goldfish_pages(unsigned long first_page,
>   *iter_last_page_size = last_page_size;
>   }
>  
> - ret = get_user_pages_fast(first_page, requested_pages,
> + ret = pin_user_pages_fast(first_page, requested_pages,
> !is_write ? FOLL_WRITE : 0,
> pages);
>   if (ret <= 0)
> @@ -285,18 +285,6 @@ static int pin_goldfish_pages(unsigned long first_page,
>   return ret;
>  }
>  
> -static void release_user_pages(struct page **pages, int pages_count,
> -int is_write, s32 consumed_size)
> -{
> - int i;
> -
> - for (i = 0; i < pages_count; i++) {
> - if (!is_write && consumed_size > 0)
> - set_page_dirty(pages[i]);
> - put_page(pages[i]);
> - }
> -}
> -
>  /* Populate the call parameters, merging adjacent pages together */
>  static void populate_rw_params(struct page **pages,
>  int pages_count,
> @@ -372,7 +360,8 @@ static int transfer_max_buffers(struct goldfish_pipe 
> *pipe,
>  
>   *consumed_size = pipe->command_buffer->rw_params.consumed_size;
>  
> - release_user_pages(pipe->pages, pages_count, is_write, *consumed_size);
> + put_user_pages_dirty_lock(pipe->pages, pages_count,
> +   !is_write && *consumed_size > 0);
>  
>   mutex_unlock(&pipe->lock);
>   return 0;
> -- 
> 2.24.0
> 
-- 
Jan Kara 
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 13/24] mm/process_vm_access: set FOLL_PIN via pin_user_pages_remote()

2019-11-18 Thread Jan Kara
On Thu 14-11-19 21:53:29, John Hubbard wrote:
> Convert process_vm_access to use the new pin_user_pages_remote()
> call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
> code that requires tracking of pinned pages.
> 
> Also, release the pages via put_user_page*().
> 
> Also, rename "pages" to "pinned_pages", as this makes for
> easier reading of process_vm_rw_single_vec().
> 
> Reviewed-by: Jérôme Glisse 
> Reviewed-by: Ira Weiny 
> Signed-off-by: John Hubbard 
> ---
>  mm/process_vm_access.c | 28 +++-
>  1 file changed, 15 insertions(+), 13 deletions(-)

The patch looks good to me. You can add:

Reviewed-by: Jan Kara 

Honza

-- 
Jan Kara 
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 06/24] goldish_pipe: rename local pin_user_pages() routine

2019-11-18 Thread Jan Kara
On Thu 14-11-19 21:53:22, John Hubbard wrote:
> 1. Avoid naming conflicts: rename local static function from
> "pin_user_pages()" to "pin_goldfish_pages()".
> 
> An upcoming patch will introduce a global pin_user_pages()
> function.
> 
> Reviewed-by: Jérôme Glisse 
> Reviewed-by: Ira Weiny 
> Signed-off-by: John Hubbard 

Looks good to me. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  drivers/platform/goldfish/goldfish_pipe.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/platform/goldfish/goldfish_pipe.c 
> b/drivers/platform/goldfish/goldfish_pipe.c
> index cef0133aa47a..7ed2a21a0bac 100644
> --- a/drivers/platform/goldfish/goldfish_pipe.c
> +++ b/drivers/platform/goldfish/goldfish_pipe.c
> @@ -257,12 +257,12 @@ static int goldfish_pipe_error_convert(int status)
>   }
>  }
>  
> -static int pin_user_pages(unsigned long first_page,
> -   unsigned long last_page,
> -   unsigned int last_page_size,
> -   int is_write,
> -   struct page *pages[MAX_BUFFERS_PER_COMMAND],
> -   unsigned int *iter_last_page_size)
> +static int pin_goldfish_pages(unsigned long first_page,
> +   unsigned long last_page,
> +   unsigned int last_page_size,
> +   int is_write,
> +   struct page *pages[MAX_BUFFERS_PER_COMMAND],
> +   unsigned int *iter_last_page_size)
>  {
>   int ret;
>   int requested_pages = ((last_page - first_page) >> PAGE_SHIFT) + 1;
> @@ -354,9 +354,9 @@ static int transfer_max_buffers(struct goldfish_pipe 
> *pipe,
>   if (mutex_lock_interruptible(&pipe->lock))
>   return -ERESTARTSYS;
>  
> - pages_count = pin_user_pages(first_page, last_page,
> -  last_page_size, is_write,
> -  pipe->pages, &iter_last_page_size);
> + pages_count = pin_goldfish_pages(first_page, last_page,
> +  last_page_size, is_write,
> +  pipe->pages, &iter_last_page_size);
>   if (pages_count < 0) {
>   mutex_unlock(&pipe->lock);
>   return pages_count;
> -- 
> 2.24.0
> 
-- 
Jan Kara 
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 07/24] IB/umem: use get_user_pages_fast() to pin DMA pages

2019-11-18 Thread Jan Kara
On Thu 14-11-19 21:53:23, John Hubbard wrote:
> And get rid of the mmap_sem calls, as part of that. Note
> that get_user_pages_fast() will, if necessary, fall back to
> __gup_longterm_unlocked(), which takes the mmap_sem as needed.
> 
> Reviewed-by: Jason Gunthorpe 
> Reviewed-by: Ira Weiny 
> Signed-off-by: John Hubbard 

Looks good to me. You can add:

Reviewed-by: Jan Kara 

Honza


> ---
>  drivers/infiniband/core/umem.c | 17 ++---
>  1 file changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index 24244a2f68cc..3d664a2539eb 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -271,16 +271,13 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata, 
> unsigned long addr,
>   sg = umem->sg_head.sgl;
>  
>   while (npages) {
> - down_read(&mm->mmap_sem);
> - ret = get_user_pages(cur_base,
> -  min_t(unsigned long, npages,
> -PAGE_SIZE / sizeof (struct page *)),
> -  gup_flags | FOLL_LONGTERM,
> -  page_list, NULL);
> - if (ret < 0) {
> - up_read(&mm->mmap_sem);
> + ret = get_user_pages_fast(cur_base,
> +   min_t(unsigned long, npages,
> + PAGE_SIZE /
> + sizeof(struct page *)),
> +   gup_flags | FOLL_LONGTERM, page_list);
> + if (ret < 0)
>   goto umem_release;
> - }
>  
>   cur_base += ret * PAGE_SIZE;
>   npages   -= ret;
> @@ -288,8 +285,6 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata, 
> unsigned long addr,
>   sg = ib_umem_add_sg_table(sg, page_list, ret,
>   dma_get_max_seg_size(context->device->dma_device),
>   &umem->sg_nents);
> -
> - up_read(&mm->mmap_sem);
>   }
>  
>   sg_mark_end(sg);
> -- 
> 2.24.0
> 
-- 
Jan Kara 
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] drm/omap: dss: Use PTR_ERR_OR_ZERO() to simplify code

2019-11-18 Thread Tomi Valkeinen

Hi zhengbin,

On 18/11/2019 14:07, zhengbin wrote:

zhengbin (4):
   drm/omap: dss: Use PTR_ERR_OR_ZERO() to simplify code in
 hdmi_audio_register
   drm/omap: dss: Use PTR_ERR_OR_ZERO() to simplify code in
 hdmi4_core_init
   drm/omap: dss: Use PTR_ERR_OR_ZERO() to simplify code in
 hdmi5_core_init
   drm/omap: dss: Use PTR_ERR_OR_ZERO() to simplify code in hdmi_phy_init

  drivers/gpu/drm/omapdrm/dss/hdmi4.c  | 5 +
  drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 5 +
  drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 5 +
  drivers/gpu/drm/omapdrm/dss/hdmi_phy.c   | 5 +
  4 files changed, 4 insertions(+), 16 deletions(-)


Thanks, but I don't like PTR_ERR_OR_ZERO, I think it makes the code more 
difficult to read and manage.


 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 13/13] drm/connector: Hookup the new drm_cmdline_mode panel_orientation member

2019-11-18 Thread Maxime Ripard
On Wed, Nov 13, 2019 at 05:44:34PM +0100, Hans de Goede wrote:
> If the new video=... panel_orientation option is set for a connector, honor
> it and setup a matching "panel orientation" property on the connector.
>
> BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
> Signed-off-by: Hans de Goede 

Acked-by: Maxime Ripard 

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 10/13] drm/modes: parse_cmdline: Remove some unnecessary code (v2)

2019-11-18 Thread Maxime Ripard
On Wed, Nov 13, 2019 at 05:44:31PM +0100, Hans de Goede wrote:
> fb_get_options() will return fb_mode_option if no video=
> argument is present on the kernel commandline, so there is no need to also
> do this in drm_mode_parse_command_line_for_connector() as our only caller
> uses fb_get_options() to get the mode_option argument.
>
> Changes in v2:
> -Split out the changes dealing with the initialization of the mode struct
>  into a separate patch
>
> Signed-off-by: Hans de Goede 

Acked-by: Maxime Ripard 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 09/13] drm/modes: parse_cmdline: Add support for specifying panel_orientation (v2)

2019-11-18 Thread Maxime Ripard
On Wed, Nov 13, 2019 at 05:44:30PM +0100, Hans de Goede wrote:
> Sometimes we want to override a connector's panel_orientation from the
> kernel commandline. Either for testing and for special cases, e.g. a kiosk
> like setup which uses a TV mounted in portrait mode.
>
> Users can already specify a "rotate" option through a video= kernel cmdline
> option. But that only supports 0/180 degrees (see drm_client_modeset TODO)
> and only works for in kernel modeset clients, not for userspace kms users.
>
> The "panel-orientation" connector property OTOH does support 90/270 degrees
> as it leaves dealing with the rotation up to userspace and this does work
> for userspace kms clients (at least those which support this property).
>
> Changes in v2:
> -Add missing ':' after @panel_orientation (reported by kbuild test robot)
>
> BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
> Signed-off-by: Hans de Goede 

Acked-by: Maxime Ripard 

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 11/13] drm/modes: parse_cmdline: Explicitly memset the passed in drm_cmdline_mode struct

2019-11-18 Thread Maxime Ripard
On Wed, Nov 13, 2019 at 05:44:32PM +0100, Hans de Goede wrote:
> Instead of only setting mode->specified on false on an early exit and
> leaving e.g. mode->bpp_specified and mode->refresh_specified as is,
> lets be consistent and just zero out the entire passed in struct at
> the top of drm_mode_parse_command_line_for_connector()
>
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/drm_modes.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index beb764efe6b3..1fee4a71eff7 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1745,12 +1745,11 @@ bool drm_mode_parse_command_line_for_connector(const 
> char *mode_option,
>   char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
>   int i, len, ret;
>
> + memset(mode, 0, sizeof(*mode));
>   mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;

The reported error by kbuild rings a bell. I think I tried to do this,
saw that error, and then forgot about it.

Looking more at the code now, I don't see any in bochs that looks
really wrong. Either way, we should either fix bochs, or add a
unit-test to have a test for the bochs case so that we don't have that
issue sneaking around.

(btw, thanks for adding more tests, that's really appreciated)

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 11/13] drm/modes: parse_cmdline: Explicitly memset the passed in drm_cmdline_mode struct

2019-11-18 Thread Hans de Goede

Hi,

On 18-11-2019 13:28, Maxime Ripard wrote:

On Wed, Nov 13, 2019 at 05:44:32PM +0100, Hans de Goede wrote:

Instead of only setting mode->specified on false on an early exit and
leaving e.g. mode->bpp_specified and mode->refresh_specified as is,
lets be consistent and just zero out the entire passed in struct at
the top of drm_mode_parse_command_line_for_connector()

Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/drm_modes.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index beb764efe6b3..1fee4a71eff7 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1745,12 +1745,11 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
int i, len, ret;

+   memset(mode, 0, sizeof(*mode));
mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;


The reported error by kbuild rings a bell. I think I tried to do this,
saw that error, and then forgot about it.


kbuild(bot) error ? I did not see any messages about that for this patch,
nor do I see any mails about this in the archives?


Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 07/15] drm/omapdrm: Drop dma_buf->k(un)map

2019-11-18 Thread Tomi Valkeinen
On 18/11/2019 12:35, Daniel Vetter wrote:
> No in-tree users left.
> 
> Note that this is one of the few (if only) implementations of dma-buf
> that provided a kmap, but not a vmap implemenation. Given that the
> only real user (in-tree at least) of kmap was tegra, and it's
> impossible to buy a chip with tegra host1x and ompadrm on the same
> SoC, there's no problem here.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Tomi Valkeinen 
> ---
>   drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 21 -
>   1 file changed, 21 deletions(-)

We're using dma_buf_kmap in TI kernel, in some rpmsg code:

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/rpmsg/rpmsg_rpc_dmabuf.c?h=ti-linux-4.19.y

I'm not familiar with the code, Cc'ing Suman.

In any case, if no one else needs dmabuf kmap, I would guess that TI doesn't 
need it either... Presuming that's the case, for the omapdrm part:

Acked-by: Tomi Valkeinen 

Also, don't downplay the 32bit kernels, there are still plenty of users for 
arm32, and will be for a long time =)

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/15] drm/i915: Drop dma_buf->k(un)map

2019-11-18 Thread Chris Wilson
Quoting Daniel Vetter (2019-11-18 10:35:27)
> No in-tree users left.

Fair enough then,
Reviewed-by: Chris Wilson 

> Aside, I think mock_dmabuf would be a nice addition to drm
> mock/selftest helpers (we have some already), with an
> EXPORT_SYMBOL_FOR_TESTS_ONLY.

We've also started on some dmabuf selftests, so maybe we can go further
and make mock objects and EXPORT_SYMBOL_FOR_TESTS_ONLY global. And of
course, make sure the efforts align with kunit...
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 11/13] drm/modes: parse_cmdline: Explicitly memset the passed in drm_cmdline_mode struct

2019-11-18 Thread Maxime Ripard
On Mon, Nov 18, 2019 at 01:33:55PM +0100, Hans de Goede wrote:
> Hi,
>
> On 18-11-2019 13:28, Maxime Ripard wrote:
> > On Wed, Nov 13, 2019 at 05:44:32PM +0100, Hans de Goede wrote:
> > > Instead of only setting mode->specified on false on an early exit and
> > > leaving e.g. mode->bpp_specified and mode->refresh_specified as is,
> > > lets be consistent and just zero out the entire passed in struct at
> > > the top of drm_mode_parse_command_line_for_connector()
> > >
> > > Signed-off-by: Hans de Goede 
> > > ---
> > >   drivers/gpu/drm/drm_modes.c | 5 ++---
> > >   1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > > index beb764efe6b3..1fee4a71eff7 100644
> > > --- a/drivers/gpu/drm/drm_modes.c
> > > +++ b/drivers/gpu/drm/drm_modes.c
> > > @@ -1745,12 +1745,11 @@ bool 
> > > drm_mode_parse_command_line_for_connector(const char *mode_option,
> > >   char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
> > >   int i, len, ret;
> > >
> > > + memset(mode, 0, sizeof(*mode));
> > >   mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> >
> > The reported error by kbuild rings a bell. I think I tried to do this,
> > saw that error, and then forgot about it.
>
> kbuild(bot) error ? I did not see any messages about that for this patch,
> nor do I see any mails about this in the archives?

It was sent today at 8:28 UTC, subject "[drm/modes] 1ea4d22f11:
BUG:kernel_NULL_pointer_dereference,address". I'll bounce it to you,
but you were among the recipients, maybe it ended up in your spams?

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/15] drm/i915: Remove dma_buf_kmap selftest

2019-11-18 Thread Chris Wilson
Quoting Daniel Vetter (2019-11-18 10:35:24)
> It's the only user left in the entire kernel for dma_buf_kmap/_kunmap.
> Delete it, before we start garbage-collecting the various
> implementations.

Ok then, I'm still mourning the loss of kmap. I definitely do not think
we should _only_ have a whole-object-at-a-time interface as we may have
to deal with objects larger than the aperture, or even larger than
system memory. I feel we have a bridge to cross in future...

Reviewed-by: Chris Wilson 
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/sun4i: Use PTR_ERR_OR_ZERO() to simplify code in sun4i_hdmi_init_regmap_fields

2019-11-18 Thread Maxime Ripard
On Mon, Nov 18, 2019 at 08:34:40PM +0800, zhengbin wrote:
> Fixes coccicheck warning:
>
> drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c:281:1-3: WARNING: PTR_ERR_OR_ZERO can 
> be used
>
> Reported-by: Hulk Robot 
> Signed-off-by: zhengbin 
> ---
>  drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c 
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c
> index b66fa27..ac435e5 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c
> @@ -278,10 +278,7 @@ static int sun4i_hdmi_init_regmap_fields(struct 
> sun4i_hdmi *hdmi)
>   hdmi->field_ddc_sck_en =
>   devm_regmap_field_alloc(hdmi->dev, hdmi->regmap,
>   hdmi->variant->field_ddc_sck_en);
> - if (IS_ERR(hdmi->field_ddc_sck_en))
> - return PTR_ERR(hdmi->field_ddc_sck_en);
> -
> - return 0;
> + return PTR_ERR_OR_ZERO(hdmi->field_ddc_sck_en);

These 5 patches are not clearer and just make it more difficult to
maintain. I guess we should just get rid of the coccinelle rule here,
there's a lot of false positive with it.

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/mcde: dsi: Fix invalid pointer dereference if panel cannot be found

2019-11-18 Thread Stephan Gerhold
The "panel" pointer is not reset to NULL if of_drm_find_panel()
returns an error. Therefore we later assume that a panel was found,
and try to dereference the error pointer, resulting in:

mcde-dsi a0351000.dsi: failed to find panel try bridge (4294966779)
Unable to handle kernel paging request at virtual address fe03
PC is at drm_panel_bridge_add.part.0+0x10/0x5c
LR is at mcde_dsi_bind+0x120/0x464
...

Reset "panel" to NULL to avoid this problem.
Also change the format string of the error to %ld to print
the negative errors correctly. The crash above then becomes:

mcde-dsi a0351000.dsi: failed to find panel try bridge (-517)
mcde-dsi a0351000.dsi: no panel or bridge
...

Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
Signed-off-by: Stephan Gerhold 
---
 drivers/gpu/drm/mcde/mcde_dsi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index 03896a1f339a..eb3a855aef9a 100644
--- a/drivers/gpu/drm/mcde/mcde_dsi.c
+++ b/drivers/gpu/drm/mcde/mcde_dsi.c
@@ -924,11 +924,13 @@ static int mcde_dsi_bind(struct device *dev, struct 
device *master,
for_each_available_child_of_node(dev->of_node, child) {
panel = of_drm_find_panel(child);
if (IS_ERR(panel)) {
-   dev_err(dev, "failed to find panel try bridge (%lu)\n",
+   dev_err(dev, "failed to find panel try bridge (%ld)\n",
PTR_ERR(panel));
+   panel = NULL;
+
bridge = of_drm_find_bridge(child);
if (IS_ERR(bridge)) {
-   dev_err(dev, "failed to find bridge (%lu)\n",
+   dev_err(dev, "failed to find bridge (%ld)\n",
PTR_ERR(bridge));
return PTR_ERR(bridge);
}
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFCv1 11/42] ARM: dts: omap: add channel to DSI panels

2019-11-18 Thread Tomi Valkeinen

On 17/11/2019 04:39, Sebastian Reichel wrote:

The standard binding for DSI requires, that the channel number
of the panel is encoded in DT. This adds the channel number in
all OMAP3-5 boards, in preparation for using common infrastructure.

Signed-off-by: Sebastian Reichel 
---
  .../devicetree/bindings/display/panel/panel-dsi-cm.txt  | 4 +++-
  arch/arm/boot/dts/omap3-n950.dts| 3 ++-
  arch/arm/boot/dts/omap3.dtsi| 3 +++
  arch/arm/boot/dts/omap4-droid4-xt894.dts| 3 ++-
  arch/arm/boot/dts/omap4-sdp.dts | 6 --
  arch/arm/boot/dts/omap4.dtsi| 6 ++
  arch/arm/boot/dts/omap5.dtsi| 6 ++
  7 files changed, 26 insertions(+), 5 deletions(-)


Is this required only in the .txt, or also by the driver? This does 
break backward compatibility with the dtbs, and there's always someone 
who won't like it.


 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] drm/tegra: Use PTR_ERR_OR_ZERO() to simplify code

2019-11-18 Thread Thierry Reding
On Mon, Nov 18, 2019 at 07:46:10PM +0800, zhengbin wrote:
> zhengbin (2):
>   drm/tegra: Use PTR_ERR_OR_ZERO() to simplify code in
> tegra_bo_dumb_create
>   drm/tegra: Use PTR_ERR_OR_ZERO() to simplify code in tegra_gem_create
> 
>  drivers/gpu/drm/tegra/drm.c | 5 +
>  drivers/gpu/drm/tegra/gem.c | 5 +
>  2 files changed, 2 insertions(+), 8 deletions(-)

As I explained in response to the same patches sent for other drivers
already, I don't think this has any merit.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Store the bpc we're using in nv50_head_atom

2019-11-18 Thread Thierry Reding
On Fri, Nov 15, 2019 at 04:07:19PM -0500, Lyude Paul wrote:
> In order to be able to use bpc values that are different from what the
> connector reports, we want to be able to store the bpc value we decide
> on using for an atomic state in nv50_head_atom and refer to that instead
> of simply using the value that the connector reports throughout the
> whole atomic check phase and commit phase. This will let us (eventually)
> implement the max bpc connector property, and will also be needed for
> limiting the bpc we use on MST displays to 8 in the next commit.
> 
> Signed-off-by: Lyude Paul 
> Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
> Cc: Ben Skeggs 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jerry Zuo 
> Cc: Harry Wentland 
> Cc: Juston Li 
> Cc: Sean Paul 
> Cc: Laurent Pinchart 
> Cc:  # v5.1+
> ---
>  drivers/gpu/drm/nouveau/dispnv50/atom.h |  1 +
>  drivers/gpu/drm/nouveau/dispnv50/disp.c | 57 ++---
>  drivers/gpu/drm/nouveau/dispnv50/head.c |  5 +--
>  3 files changed, 36 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/atom.h 
> b/drivers/gpu/drm/nouveau/dispnv50/atom.h
> index 43df86c38f58..24f7700768da 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/atom.h
> +++ b/drivers/gpu/drm/nouveau/dispnv50/atom.h
> @@ -114,6 +114,7 @@ struct nv50_head_atom {
>   u8 nhsync:1;
>   u8 nvsync:1;
>   u8 depth:4;
> + u8 bpc;
>   } or;
>  
>   /* Currently only used for MST */
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 6327aaf37c08..93665aecce57 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -353,10 +353,20 @@ nv50_outp_atomic_check(struct drm_encoder *encoder,
>  struct drm_crtc_state *crtc_state,
>  struct drm_connector_state *conn_state)
>  {
> - struct nouveau_connector *nv_connector =
> - nouveau_connector(conn_state->connector);
> - return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
> -nv_connector->native_mode);
> + struct drm_connector *connector = conn_state->connector;
> + struct nouveau_connector *nv_connector = nouveau_connector(connector);
> + struct nv50_head_atom *asyh = nv50_head_atom(crtc_state);
> + int ret;
> +
> + ret = nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
> +   nv_connector->native_mode);
> + if (ret)
> + return ret;
> +
> + if (crtc_state->mode_changed || crtc_state->connectors_changed)
> + asyh->or.bpc = connector->display_info.bpc;
> +
> + return 0;
>  }
>  
>  
> /**
> @@ -786,10 +796,10 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
>* may have changed after the state was duplicated
>*/
>   if (!state->duplicated) {
> - const int bpp = connector->display_info.bpc * 3;
>   const int clock = crtc_state->adjusted_mode.clock;
>  
> - asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, bpp);
> + asyh->or.bpc = connector->display_info.bpc;
> + asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, asyh->or.bpc * 3);
>   }
>  
>   slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr, mstc->port,
> @@ -802,6 +812,17 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
>   return 0;
>  }
>  
> +static u8
> +nv50_dp_bpc_to_depth(unsigned int bpc)
> +{
> + switch (bpc) {
> + case  6: return 0x2;
> + case  8: return 0x5;
> + case 10: /* fall-through */
> + default: return 0x6;
> + }

This is obviously just refactored from the code below, so this is
probably fine for now. But what about BPC > 10? The OR here seems to be
very similar to what's used on Tegra where the same values are used in
the SOR_STATE1 register, see:

drivers/gpu/drm/tegra/sor.h

There are additional values for 12 and 16 BPC (see the definitions for
SOR_STATE_ASY_PIXELDEPTH_BPP_*). With the above anything higher than 10
BPC will be treated the same and likely lead to wrong results. So I
think either a WARN for the "default" case or additional cases for the
other values would be good to have.

Like I said, if this even is problematic (and given that userspace does
not really support > 8 BPC yet, it probably isn't) it's a preexisting
problem, so can be done in a different patch.

Other than that this looks good, so:

Reviewed-by: Thierry Reding 

> +}
> +
>  static void
>  nv50_msto_enable(struct drm_encoder *encoder)
>  {
> @@ -812,7 +833,7 @@ nv50_msto_enable(struct drm_encoder *encoder)
>   struct nv50_mstm *mstm = NULL;
>   struct drm_connector *connector;
>   struct drm_connector_list_iter conn_iter;
> - u8 proto, depth;
> + u8 prot

Re: [Nouveau] [PATCH 3/3] drm/nouveau/kms/nv50-: Limit MST BPC to 8

2019-11-18 Thread Thierry Reding
On Fri, Nov 15, 2019 at 04:07:20PM -0500, Lyude Paul wrote:
> Noticed this while working on some unrelated CRC stuff. Currently,
> userspace has very little support for BPCs higher than 8. While this
> doesn't matter for most things, on MST topologies we need to be careful
> about ensuring that we do our best to make any given display
> configuration fit within the bandwidth restraints of the topology, since
> otherwise less people's monitor configurations will work.
> 
> Allowing for BPC settings higher than 8 dramatically increases the
> required bandwidth for displays in most configurations, and consequently
> makes it a lot less likely that said display configurations will pass
> the atomic check.
> 
> In the future we want to fix this correctly by making it so that we
> adjust the bpp for each display in a topology to be as high as possible,
> while making sure to lower the bpp of each display in the event that we
> run out of bandwidth and need to rerun our atomic check. But for now,
> follow the behavior that both i915 and amdgpu are sticking to.
> 
> Signed-off-by: Lyude Paul 
> Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
> Cc: Ben Skeggs 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jerry Zuo 
> Cc: Harry Wentland 
> Cc: Juston Li 
> Cc: Sam Ravnborg 
> Cc: Sean Paul 
> Cc:  # v5.1+
> ---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)

Reviewed-by: Thierry Reding 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 1/3] drm/nouveau/kms/nv50-: Call outp_atomic_check_view() before handling PBN

2019-11-18 Thread Thierry Reding
On Fri, Nov 15, 2019 at 04:07:18PM -0500, Lyude Paul wrote:
> Since nv50_outp_atomic_check_view() can set crtc_state->mode_changed, we
> probably should be calling it before handling any PBN changes. Just a
> precaution.
> 
> Signed-off-by: Lyude Paul 
> Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST")
> Cc: Ben Skeggs 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jerry Zuo 
> Cc: Harry Wentland 
> Cc: Juston Li 
> Cc: Sean Paul 
> Cc: Laurent Pinchart 
> Cc:  # v5.1+
> ---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c | 44 ++---
>  1 file changed, 24 insertions(+), 20 deletions(-)

Looks reasonable:

Reviewed-by: Thierry Reding 

> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 549486f1d937..6327aaf37c08 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -770,32 +770,36 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
>   struct nv50_mstm *mstm = mstc->mstm;
>   struct nv50_head_atom *asyh = nv50_head_atom(crtc_state);
>   int slots;
> + int ret;
>  
> - if (crtc_state->mode_changed || crtc_state->connectors_changed) {
> - /*
> -  * When restoring duplicated states, we need to make sure that
> -  * the bw remains the same and avoid recalculating it, as the
> -  * connector's bpc may have changed after the state was
> -  * duplicated
> -  */
> - if (!state->duplicated) {
> - const int bpp = connector->display_info.bpc * 3;
> - const int clock = crtc_state->adjusted_mode.clock;
> + ret = nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
> +   mstc->native);
> + if (ret)
> + return ret;
>  
> - asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, bpp);
> - }
> + if (!crtc_state->mode_changed && !crtc_state->connectors_changed)
> + return 0;
>  
> - slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr,
> -   mstc->port,
> -   asyh->dp.pbn);
> - if (slots < 0)
> - return slots;
> + /*
> +  * When restoring duplicated states, we need to make sure that the bw
> +  * remains the same and avoid recalculating it, as the connector's bpc
> +  * may have changed after the state was duplicated
> +  */
> + if (!state->duplicated) {
> + const int bpp = connector->display_info.bpc * 3;
> + const int clock = crtc_state->adjusted_mode.clock;
>  
> - asyh->dp.tu = slots;
> + asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, bpp);
>   }
>  
> - return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
> -mstc->native);
> + slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr, mstc->port,
> +   asyh->dp.pbn);
> + if (slots < 0)
> + return slots;
> +
> + asyh->dp.tu = slots;
> +
> + return 0;
>  }
>  
>  static void
> -- 
> 2.21.0
> 
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/9] drm/nouveau: Various fixes for GP10B

2019-11-18 Thread Thierry Reding
On Sat, Nov 02, 2019 at 06:56:28PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Hi Ben,
> 
> here's a revised subset of the patches I had sent out a couple of weeks
> ago. I've reworked the BAR2 accesses in the way that you had suggested,
> which at least for GP10B turned out to be fairly trivial to do. I have
> not looked in detail at this for GV11B yet, but a cursory look showed
> that BAR2 is accessed in more places, so the equivalent for GV11B might
> be a bit more involved.
> 
> Other than that, not a lot has changed since then. I've added a couple
> of precursory patches to add IOMMU helper dummies for the case where
> IOMMU is disabled (as suggested by Ben Dooks).
> 
> Joerg, it'd be great if you could give an Acked-by on those two patches
> so that Ben can pick them both up into the Nouveau tree. Alternatively I
> can put them both into a stable branch and send a pull request to both
> of you. Or yet another alternative would be for Joerg to apply them now
> and Ben to wait for v5.5-rc1 until he picks up the rest. All of those
> work for me.

Hi Joerg, Ben,

do you guys have any further comments on this series? I've got an
updated patch to silence the warning that the kbuild robot flagged, so
if there are no other comments I can send a final v3 of the series.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 11/13] drm/modes: parse_cmdline: Explicitly memset the passed in drm_cmdline_mode struct

2019-11-18 Thread Hans de Goede

Hi,

On 18-11-2019 13:28, Maxime Ripard wrote:

On Wed, Nov 13, 2019 at 05:44:32PM +0100, Hans de Goede wrote:

Instead of only setting mode->specified on false on an early exit and
leaving e.g. mode->bpp_specified and mode->refresh_specified as is,
lets be consistent and just zero out the entire passed in struct at
the top of drm_mode_parse_command_line_for_connector()

Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/drm_modes.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index beb764efe6b3..1fee4a71eff7 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1745,12 +1745,11 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
int i, len, ret;

+   memset(mode, 0, sizeof(*mode));
mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;


The reported error by kbuild rings a bell. I think I tried to do this,
saw that error, and then forgot about it.

Looking more at the code now, I don't see any in bochs that looks
really wrong. Either way, we should either fix bochs, or add a
unit-test to have a test for the bochs case so that we don't have that
issue sneaking around.


Ok, for those reading along, for some reason Red Hat's mails server
has eaten the kbuild report. in case this has happened to more people
we are talking about this report:

https://lists.freedesktop.org/archives/dri-devel/2019-November/244541.html

Maxime, looking at this closer, the bochs driver indeed does not do
anything wrong, my patch does. Instead of that I deleted the:

mode->specified = false;

line, I deleted the:

return false;

line instead, so the null-ptr deref is on the mode_option. No idea
why this is not crashing things everywhere, as I've run a kernel with
these patches, also without a video= option on several devices...

Anyways let me send out a v3 of the set with this patcch fixed and
thank you for the reviews.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation

2019-11-18 Thread Laura Abbott

On 11/18/19 5:35 AM, Daniel Vetter wrote:

There's no callers in-tree anymore.

For merging probably best to stuff this into drm-misc, since that's
where the dma-buf heaps will land too. And the resulting conflict
hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
implemenation.

Signed-off-by: Daniel Vetter 
Cc: Laura Abbott 
Cc: Sumit Semwal 
Cc: de...@driverdev.osuosl.org
Cc: linaro-mm-...@lists.linaro.org
---
  drivers/staging/android/ion/ion.c | 14 --
  1 file changed, 14 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index e6b1ca141b93..bb4ededc1150 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -274,18 +274,6 @@ static void ion_dma_buf_release(struct dma_buf *dmabuf)
_ion_buffer_destroy(buffer);
  }
  
-static void *ion_dma_buf_kmap(struct dma_buf *dmabuf, unsigned long offset)

-{
-   struct ion_buffer *buffer = dmabuf->priv;
-
-   return buffer->vaddr + offset * PAGE_SIZE;
-}
-
-static void ion_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
-  void *ptr)
-{
-}
-
  static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
enum dma_data_direction direction)
  {
@@ -349,8 +337,6 @@ static const struct dma_buf_ops dma_buf_ops = {
.detach = ion_dma_buf_detatch,
.begin_cpu_access = ion_dma_buf_begin_cpu_access,
.end_cpu_access = ion_dma_buf_end_cpu_access,
-   .map = ion_dma_buf_kmap,
-   .unmap = ion_dma_buf_kunmap,
  };
  
  static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)




Acked-by: Laura Abbott 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9

2019-11-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=111481

--- Comment #236 from Alex Deucher  ---
(In reply to Marko Popovic from comment #235)
> (In reply to Alex Deucher from comment #233)
> > Does attachment 145971 [details] [review] [review] help?
> 
> No, this is for flip hangs that only happen in some games, random SDMA hangs
> are still present, but SDMA is disabled in MESA20 so for the timebeing it
> should be more stable.

They may be related. If the SDMA is waiting on a fence from the display engine
it would time out if that display fence never triggers.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 205497] Attempt to read amd gpu id causes a freeze

2019-11-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=205497

--- Comment #19 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Luya Tshimbalanga from comment #18)
> Reading another bug report on
> https://bugzilla.kernel.org/show_bug.cgi?id=204689 taken from amdgfx mailing
> list, could that issue related?

Not likely.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V13 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework

2019-11-18 Thread Greg KH
On Mon, Nov 18, 2019 at 06:59:23PM +0800, Jason Wang wrote:
> +static void mvnet_device_release(struct device *dev)
> +{
> + dev_dbg(dev, "mvnet: released\n");
> +}

We used to have documentation in the kernel source tree that said that
whenever anyone did this, I got to make fun of them.  Unfortunately that
has been removed.

Think about what you did right here.  You silenced a kernel runtime
warning that said something like "ERROR! NO RELEASE FUNCTION FOUND!" by
doing the above because "I am smarter than the kernel, I will silence it
by putting an empty release function in there."

{sigh}

Did you ever think _why_ we took the time and effort to add that warning
there?  It wasn't just so that people can circumvent it, it is to
PREVENT A MAJOR BUG IN YOUR DESIGN!  We are trying to be nice here and
give people a _chance_ to get things right instead of having you just
live with a silent memory leak.

After 13 versions of this series, basic things like this are still here?
Who is reviewing this thing?

{ugh}

Also, see the other conversations we are having about a "virtual" bus
and devices.  I do not want to have two different ways of doing the same
thing in the kernel at the same time please.  Please work together with
the Intel developers to solve this in a unified way, as you both
need/want the same thing here.

Neither this, nor the other proposal can be accepted until you all agree
on the design and implementation.

/me goes off to find a nice fruity drink with an umbrella.

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 112303] [LENOVO E595] Black screen on resume!

2019-11-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=112303

--- Comment #1 from Alex Deucher  ---
Does it work with kernel 5.4?  There were several fixes for resume that were
added (which will be making their way back to stable kernels).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm core/helpers and MIT license

2019-11-18 Thread Daniel Vetter
On Fri, Nov 15, 2019 at 1:34 PM Ville Syrjälä
 wrote:
>
> On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote:
> > Hi Daniel,
> >
> > I don't think we can make any complaints about GPL being more widely
> > used in the DRM code. It's nice to have the code at all, the MIT license
> > is a bonus. Thanks for writing it and bearing with us.
> >
> > Would rewrites done purely for licensing reasons be accepted upstream?
>
> Rewrite should be the last resort. I think a lot of the GPL only stuff
> is quite recent so there's a good chance the author(s) are still around
> to discuss relicensing.

The trouble is this stuff is mostly coming from refactorings of
gpl-only drivers, and quick chat with Dave looks like some of that
code comes from gpl-only fbdev drivers. Doing the relicensing properly
will be some work I think.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

2019-11-18 Thread kbuild test robot
Hi Daniel,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.4-rc8 next-20191115]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=m68k 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

>> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no 
>> member named 'map'; did you mean 'mmap'?
 .map= kmap_udmabuf,
  ^~~
  mmap
>> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible 
>> pointer type [-Werror=incompatible-pointer-types]
 .map= kmap_udmabuf,
   ^~~~
   drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for 
'udmabuf_ops.begin_cpu_access')
>> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no 
>> member named 'unmap'; did you mean 'vunmap'?
 .unmap= kunmap_udmabuf,
  ^
  vunmap
   drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible 
pointer type [-Werror=incompatible-pointer-types]
 .unmap= kunmap_udmabuf,
 ^~
   drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for 
'udmabuf_ops.end_cpu_access')
   cc1: some warnings being treated as errors
--
>> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops' 
>> has no member named 'map'; did you mean 'mmap'?
 .map   = udl_dmabuf_kmap,
  ^~~
  mmap
>> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
 .map   = udl_dmabuf_kmap,
  ^~~
   drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for 
'udl_dmabuf_ops.release')
>> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops' 
>> has no member named 'unmap'; did you mean 'vunmap'?
 .unmap   = udl_dmabuf_kunmap,
  ^
  vunmap
   drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from 
incompatible pointer type [-Werror=incompatible-pointer-types]
 .unmap   = udl_dmabuf_kunmap,
^
   drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for 
'udl_dmabuf_ops.begin_cpu_access')
   cc1: some warnings being treated as errors

vim +114 drivers/dma-buf/udmabuf.c

fbb0de79507819 Gerd Hoffmann 2018-08-27  109  
a34852891ba45d Gerd Hoffmann 2018-09-11  110  static const struct dma_buf_ops 
udmabuf_ops = {
fbb0de79507819 Gerd Hoffmann 2018-08-27  111.map_dma_buf  = map_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  112.unmap_dma_buf= 
unmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  113.release  = 
release_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 @114.map  = 
kmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 @115.unmap= 
kunmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  116.mmap = 
mmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27  117  };
fbb0de79507819 Gerd Hoffmann 2018-08-27  118  

:: The code at line 114 was first introduced by commit
:: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device

:: TO: Gerd Hoffmann 
:: CC: Gerd Hoffmann 

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/4] Genericize DW MIPI DSI bridge and add i.MX 6 driver

2019-11-18 Thread Adrian Ratiu
Having a generic Synopsis DesignWare MIPI-DSI host controller bridge
driver is a very good idea, however the current implementation has
hardcoded quite a lot of the register layouts used by the two supported
SoC vendors, STM and Rockchip, which use IP cores v1.30 and v1.31.

This makes it hard to support other SoC vendors like the FSL/NXP i.MX 6
which use older v1.01 cores or future versions because, based on history,
layout changes should also be expected in new DSI versions / SoCs.

This patch series converts the bridge and platform drivers to access
registers via generic regmap APIs and allows each platform driver to
configure its register layout via struct reg_fields, then adds support
for the host controller found on i.MX 6.

I only have i.MX hardware with MIPI-DSI panel and relevant documentation
available for testing so I'll really appreciate it if someone could test
the series on Rockchip and STM... eyeballing register fields could only
get me so far, so sorry in advance for any breakage!

Many thanks to Boris Brezillon  for
suggesting the regmap solution and to Liu Ying 
for doing the initial i.MX platform driver implementation.

This series applies on top of latest linux-next tree, next-20191118.

v2 -> v3:
  * Added const declarations to dw-mipi-dsi.c structs (Emil)
  * Fixed Reviewed-by tags and cc'd some more relevant ML (Emil)

v1 -> v2:
  * Moved register definitions & regmap initialization into bridge
  module. Platform drivers get the regmap via plat_data after calling
  the bridge probe (Emil).

Adrian Ratiu (4):
  drm: bridge: dw_mipi_dsi: access registers via a regmap
  drm: bridge: dw_mipi_dsi: abstract register access using reg_fields
  drm: imx: Add i.MX 6 MIPI DSI host driver
  dt-bindings: display: add IMX MIPI DSI host controller doc

 .../bindings/display/imx/mipi-dsi.txt |  56 ++
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 699 +-
 drivers/gpu/drm/imx/Kconfig   |   7 +
 drivers/gpu/drm/imx/Makefile  |   1 +
 drivers/gpu/drm/imx/dw_mipi_dsi-imx.c | 378 ++
 .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c   |  17 +-
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c |  34 +-
 include/drm/bridge/dw_mipi_dsi.h  |   2 +-
 8 files changed, 987 insertions(+), 207 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
 create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx.c

-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/4] drm: bridge: dw_mipi_dsi: abstract register access using reg_fields

2019-11-18 Thread Adrian Ratiu
Register existence, address/offsets, field layouts, reserved bits and
so on differ between MIPI-DSI versions and between SoC vendor boards.
Despite these differences the hw IP and protocols are mostly the same
so the generic driver can be made to compensate these differences.

The current Rockchip and STM drivers hardcoded a lot of their common
definitions in the bridge code because they're based on DSI v1.30 and
1.31 which are relatively close, but in order to support older/future
versions with more diverging layouts like the v1.01 present on imx6,
we abstract some of the register accesses via the regmap field APIs.

The bridge detects the DSI core version and initializes the required
regmap register layout, so platform drivers will continue to use the
regmap as before. Other DSI versions / register layouts can easily be
added in the future by only changing the bridge code.

An additional benefit of using the reg_field API is that much of the
bit-shifting and masking boilerplate is removed because it's now
handled automatically by the regmap subsystem.

Not all register accesses have been converted: only the minimum diff
between the three host controller versions supported by the current
vendor platform drivers (rockchip, stm and now imx), more can be added
in the future as needed.

Suggested-by: Boris Brezillon 
Reviewed-by: Emil Velikov 
Signed-off-by: Adrian Ratiu 
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 504 --
 1 file changed, 346 insertions(+), 158 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 6cb57807f3f9..a41a630302b6 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -47,7 +47,6 @@
 #define DPI_VCID(vcid) ((vcid) & 0x3)
 
 #define DSI_DPI_COLOR_CODING   0x10
-#define LOOSELY18_EN   BIT(8)
 #define DPI_COLOR_CODING_16BIT_1   0x0
 #define DPI_COLOR_CODING_16BIT_2   0x1
 #define DPI_COLOR_CODING_16BIT_3   0x2
@@ -56,11 +55,6 @@
 #define DPI_COLOR_CODING_24BIT 0x5
 
 #define DSI_DPI_CFG_POL0x14
-#define COLORM_ACTIVE_LOW  BIT(4)
-#define SHUTD_ACTIVE_LOW   BIT(3)
-#define HSYNC_ACTIVE_LOW   BIT(2)
-#define VSYNC_ACTIVE_LOW   BIT(1)
-#define DATAEN_ACTIVE_LOW  BIT(0)
 
 #define DSI_DPI_LP_CMD_TIM 0x18
 #define OUTVACT_LPCMD_TIME(p)  (((p) & 0xff) << 16)
@@ -81,27 +75,19 @@
 #define DSI_GEN_VCID   0x30
 
 #define DSI_MODE_CFG   0x34
-#define ENABLE_VIDEO_MODE  0
-#define ENABLE_CMD_MODEBIT(0)
 
 #define DSI_VID_MODE_CFG   0x38
-#define ENABLE_LOW_POWER   (0x3f << 8)
-#define ENABLE_LOW_POWER_MASK  (0x3f << 8)
+#define ENABLE_LOW_POWER   0x3f
+
 #define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0
 #define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
 #define VID_MODE_TYPE_BURST0x2
-#define VID_MODE_TYPE_MASK 0x3
-#define VID_MODE_VPG_ENABLEBIT(16)
-#define VID_MODE_VPG_HORIZONTALBIT(24)
 
 #define DSI_VID_PKT_SIZE   0x3c
-#define VID_PKT_SIZE(p)((p) & 0x3fff)
 
 #define DSI_VID_NUM_CHUNKS 0x40
-#define VID_NUM_CHUNKS(c)  ((c) & 0x1fff)
 
 #define DSI_VID_NULL_SIZE  0x44
-#define VID_NULL_SIZE(b)   ((b) & 0x1fff)
 
 #define DSI_VID_HSA_TIME   0x48
 #define DSI_VID_HBP_TIME   0x4c
@@ -125,7 +111,6 @@
 #define GEN_SW_2P_TX_LPBIT(10)
 #define GEN_SW_1P_TX_LPBIT(9)
 #define GEN_SW_0P_TX_LPBIT(8)
-#define ACK_RQST_ENBIT(1)
 #define TEAR_FX_EN BIT(0)
 
 #define CMD_MODE_ALL_LP(MAX_RD_PKT_SIZE_LP | \
@@ -154,8 +139,6 @@
 #define GEN_CMD_EMPTY  BIT(0)
 
 #define DSI_TO_CNT_CFG 0x78
-#define HSTX_TO_CNT(p) (((p) & 0x) << 16)
-#define LPRX_TO_CNT(p) ((p) & 0x)
 
 #define DSI_HS_RD_TO_CNT   0x7c
 #define DSI_LP_RD_TO_CNT   0x80
@@ -164,52 +147,17 @@
 #define DSI_BTA_TO_CNT 0x8c
 
 #define DSI_LPCLK_CTRL 0x94
-#define AUTO_CLKLANE_CTRL  BIT(1)
-#define PHY_TXREQUESTCLKHS BIT(0)
-
 #define DSI_PHY_TMR_LPCLK_CFG  0x98
-#define PHY_CLKHS2LP_TIME(lbcc)(((lbcc) & 0x3ff) << 16)
-#define PHY_CLKLP2HS_TIME(lbcc)((lbcc) & 0x3ff)
-
 #define DSI_PHY_TMR_CFG0x9c
-#define PHY_HS2LP_TIME(lbcc)   (((lbcc) & 0xff) << 24)
-#define PHY_LP2HS_TIME(lbcc)   (((lbcc) & 0xff) << 16)
-#define MAX_RD_TIME(lbcc)  ((lbcc) & 0x7fff)
-#define PHY_HS2LP_TIME_V131

[PATCH v3 3/4] drm: imx: Add i.MX 6 MIPI DSI host driver

2019-11-18 Thread Adrian Ratiu
This adds support for the Synopsis DesignWare MIPI DSI v1.01 host
controller which is embedded in i.MX 6 SoCs.

Based on following patches, but updated/extended to work with existing
support found in the kernel:

- drm: imx: Support Synopsys DesignWare MIPI DSI host controller
  Signed-off-by: Liu Ying 

- ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller
  Signed-off-by: Liu Ying 

Reviewed-by: Emil Velikov 
Signed-off-by: Sjoerd Simons 
Signed-off-by: Martyn Welch 
Signed-off-by: Adrian Ratiu 
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 146 ++-
 drivers/gpu/drm/imx/Kconfig   |   7 +
 drivers/gpu/drm/imx/Makefile  |   1 +
 drivers/gpu/drm/imx/dw_mipi_dsi-imx.c | 378 ++
 4 files changed, 523 insertions(+), 9 deletions(-)
 create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx.c

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index a41a630302b6..5f2fa467734c 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -31,6 +31,8 @@
 #include 
 
 #define HWVER_131  0x31333100  /* IP version 1.31 */
+#define HWVER_130  0x31333000  /* IP version 1.30 */
+#define HWVER_101  0x31303000  /* IP version 1.01 */
 
 #define DSI_VERSION0x00
 #define VERSIONGENMASK(31, 8)
@@ -99,6 +101,25 @@
 #define DSI_EDPI_CMD_SIZE  0x64
 
 #define DSI_CMD_MODE_CFG   0x68
+
+#define DSI_DPI_CFG0x0c
+#define DSI_TMR_LINE_CFG   0x28
+#define DSI_VTIMING_CFG0x2c
+#define DSI_PHY_TMR_CFG_V101   0x30
+#define DSI_PHY_IF_CFG_V1010x58
+#define DSI_PHY_IF_CTRL0x5c
+#define DSI_PHY_RSTZ_V101  0x54
+#define DSI_PHY_STATUS_V1010x60
+#define DSI_PHY_TST_CTRL0_V101 0x64
+#define DSI_GEN_HDR_V101   0x34
+#define DSI_GEN_PLD_DATA_V101  0x38
+#define DSI_CMD_MODE_CFG_V101  0x24
+#define DSI_CMD_PKT_STATUS_V1010x3c
+#define DSI_VID_PKT_CFG0x20
+#define DSI_VID_MODE_CFG_V101  0x1c
+#define DSI_TO_CNT_CFG_V1010x40
+#define DSI_PCKHDL_CFG_V1010x18
+
 #define MAX_RD_PKT_SIZE_LP BIT(24)
 #define DCS_LW_TX_LP   BIT(19)
 #define DCS_SR_0P_TX_LPBIT(18)
@@ -126,6 +147,33 @@
 GEN_SW_1P_TX_LP | \
 GEN_SW_0P_TX_LP)
 
+#define EN_TEAR_FX_V101BIT(14)
+#define DCS_LW_TX_LP_V101  BIT(12)
+#define GEN_LW_TX_LP_V101  BIT(11)
+#define MAX_RD_PKT_SIZE_LP_V101BIT(10)
+#define DCS_SW_2P_TX_LP_V101   BIT(9)
+#define DCS_SW_1P_TX_LP_V101   BIT(8)
+#define DCS_SW_0P_TX_LP_V101   BIT(7)
+#define GEN_SR_2P_TX_LP_V101   BIT(6)
+#define GEN_SR_1P_TX_LP_V101   BIT(5)
+#define GEN_SR_0P_TX_LP_V101   BIT(4)
+#define GEN_SW_2P_TX_LP_V101   BIT(3)
+#define GEN_SW_1P_TX_LP_V101   BIT(2)
+#define GEN_SW_0P_TX_LP_V101   BIT(1)
+
+#define CMD_MODE_ALL_LP_V101   (DCS_LW_TX_LP_V101 | \
+GEN_LW_TX_LP_V101 | \
+MAX_RD_PKT_SIZE_LP_V101 | \
+DCS_SW_2P_TX_LP_V101 | \
+DCS_SW_1P_TX_LP_V101 | \
+DCS_SW_0P_TX_LP_V101 | \
+GEN_SR_2P_TX_LP_V101 | \
+GEN_SR_1P_TX_LP_V101 | \
+GEN_SR_0P_TX_LP_V101 | \
+GEN_SW_2P_TX_LP_V101 | \
+GEN_SW_1P_TX_LP_V101 | \
+GEN_SW_0P_TX_LP_V101)
+
 #define DSI_GEN_HDR0x6c
 #define DSI_GEN_PLD_DATA   0x70
 
@@ -164,6 +212,11 @@
 #define DSI_INT_MSK0   0xc4
 #define DSI_INT_MSK1   0xc8
 
+#define DSI_ERROR_ST0_V101 0x44
+#define DSI_ERROR_ST1_V101 0x48
+#define DSI_ERROR_MSK0_V1010x4c
+#define DSI_ERROR_MSK1_V1010x50
+
 #define DSI_PHY_TMR_RD_CFG 0xf4
 
 #define PHY_STATUS_TIMEOUT_US  1
@@ -357,6 +410,49 @@ static const struct dw_mipi_dsi_variant 
dw_mipi_dsi_v130_v131_layout = {
.cfg_gen_payload =  REG_FIELD(DSI_GEN_PLD_DATA, 0, 31),
 };
 
+static const struct dw_mipi_dsi_variant dw_mipi_dsi_v101_layout = {
+   .cfg_dpi_vid =  REG_FIELD(DSI_DPI_CFG, 0, 1),
+   .cfg_dpi_color_coding = REG_FIELD(DSI_DPI_CFG, 2, 4),
+   

[PATCH v3 1/4] drm: bridge: dw_mipi_dsi: access registers via a regmap

2019-11-18 Thread Adrian Ratiu
Convert the common bridge code and the two rockchip & stm drivers
which currently use it to the regmap API in anticipation for further
changes to make it more generic and add older DSI host controller
support as found on i.mx6 based devices.

The regmap becomes an internal state of the bridge. No functional
changes other than requiring the platform drivers to use the
pre-configured regmap supplied by the bridge after its probe() call
instead of ioremp'ing the registers themselves.

In subsequent commits the bridge will become able to detect the
DSI host core version and init the regmap with different register
layouts. The platform drivers will continue to use the regmap without
modifications or worrying about the specific layout in use (in other
words the layout is abstracted away via the regmap).

Suggested-by: Boris Brezillon 
Reviewed-by: Neil Armstrong 
Reviewed-by: Emil Velikov 
Signed-off-by: Adrian Ratiu 
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 215 ++
 .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c   |  17 +-
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c |  34 ++-
 include/drm/bridge/dw_mipi_dsi.h  |   2 +-
 4 files changed, 145 insertions(+), 123 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index b6e793bb653c..6cb57807f3f9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -226,7 +227,7 @@ struct dw_mipi_dsi {
struct mipi_dsi_host dsi_host;
struct drm_bridge *panel_bridge;
struct device *dev;
-   void __iomem *base;
+   struct regmap *regs;
 
struct clk *pclk;
 
@@ -249,6 +250,13 @@ struct dw_mipi_dsi {
const struct dw_mipi_dsi_plat_data *plat_data;
 };
 
+static const struct regmap_config dw_mipi_dsi_regmap_cfg = {
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = 4,
+   .name = "dw-mipi-dsi",
+};
+
 /*
  * Check if either a link to a master or slave is present
  */
@@ -280,16 +288,6 @@ static inline struct dw_mipi_dsi *bridge_to_dsi(struct 
drm_bridge *bridge)
return container_of(bridge, struct dw_mipi_dsi, bridge);
 }
 
-static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
-{
-   writel(val, dsi->base + reg);
-}
-
-static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg)
-{
-   return readl(dsi->base + reg);
-}
-
 static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
   struct mipi_dsi_device *device)
 {
@@ -366,29 +364,29 @@ static void dw_mipi_message_config(struct dw_mipi_dsi 
*dsi,
if (lpm)
val |= CMD_MODE_ALL_LP;
 
-   dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
-   dsi_write(dsi, DSI_CMD_MODE_CFG, val);
+   regmap_write(dsi->regs, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
+   regmap_write(dsi->regs, DSI_CMD_MODE_CFG, val);
 }
 
 static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val)
 {
int ret;
-   u32 val, mask;
+   u32 val = 0, mask;
 
-   ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
-val, !(val & GEN_CMD_FULL), 1000,
-CMD_PKT_STATUS_TIMEOUT_US);
+   ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
+  val, !(val & GEN_CMD_FULL), 1000,
+  CMD_PKT_STATUS_TIMEOUT_US);
if (ret) {
dev_err(dsi->dev, "failed to get available command FIFO\n");
return ret;
}
 
-   dsi_write(dsi, DSI_GEN_HDR, hdr_val);
+   regmap_write(dsi->regs, DSI_GEN_HDR, hdr_val);
 
mask = GEN_CMD_EMPTY | GEN_PLD_W_EMPTY;
-   ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
-val, (val & mask) == mask,
-1000, CMD_PKT_STATUS_TIMEOUT_US);
+   ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
+  val, (val & mask) == mask,
+  1000, CMD_PKT_STATUS_TIMEOUT_US);
if (ret) {
dev_err(dsi->dev, "failed to write command FIFO\n");
return ret;
@@ -403,24 +401,26 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
const u8 *tx_buf = packet->payload;
int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
__le32 word;
-   u32 val;
+   u32 val = 0;
 
while (len) {
if (len < pld_data_bytes) {
word = 0;
memcpy(&word, tx_buf, len);
-   dsi_write(dsi, DSI_GEN_PLD_DATA, le32_to_cpu(word));
+   regmap_write(dsi->regs, DSI_GEN_PLD_DATA,
+   

[PATCH v3 4/4] dt-bindings: display: add IMX MIPI DSI host controller doc

2019-11-18 Thread Adrian Ratiu
Signed-off-by: Sjoerd Simons 
Signed-off-by: Martyn Welch 
Signed-off-by: Adrian Ratiu 
---
 .../bindings/display/imx/mipi-dsi.txt | 56 +++
 1 file changed, 56 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/imx/mipi-dsi.txt

diff --git a/Documentation/devicetree/bindings/display/imx/mipi-dsi.txt 
b/Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
new file mode 100644
index ..3f05c32ef963
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
@@ -0,0 +1,56 @@
+Freescale i.MX6 DW MIPI DSI Host Controller
+===
+
+The DSI host controller is a Synopsys DesignWare MIPI DSI v1.01 IP
+with a companion PHY IP.
+
+These DT bindings follow the Synopsys DW MIPI DSI bindings defined in
+Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt with
+the following device-specific properties.
+
+Required properties:
+
+- #address-cells: Should be <1>.
+- #size-cells: Should be <0>.
+- compatible: "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi".
+- reg: See dw_mipi_dsi.txt.
+- interrupts: The controller's CPU interrupt.
+- clocks, clock-names: Phandles to the controller's pll reference
+  clock(ref) and APB clock(pclk), as described in [1].
+- ports: a port node with endpoint definitions as defined in [2].
+- gpr: Should be <&gpr>.
+   Phandle to the iomuxc-gpr region containing the multiplexer
+   control register.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+   mipi_dsi: mipi@21e {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi";
+   reg = <0x021e 0x4000>;
+   interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+   gpr = <&gpr>;
+   clocks = <&clks IMX6QDL_CLK_MIPI_CORE_CFG>,
+<&clks IMX6QDL_CLK_MIPI_IPG>;
+   clock-names = "ref", "pclk";
+   status = "okay";
+
+   ports {
+   port@0 {
+   reg = <0>;
+   mipi_mux_0: endpoint {
+   remote-endpoint = <&ipu1_di0_mipi>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   mipi_mux_1: endpoint {
+   remote-endpoint = <&ipu1_di1_mipi>;
+   };
+   };
+   };
+};
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V13 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework

2019-11-18 Thread Cornelia Huck
On Mon, 18 Nov 2019 18:59:23 +0800
Jason Wang  wrote:

[Note: I have not looked into the reworked architecture of this *at all*
so far; just something that I noted...]

> This sample driver creates mdev device that simulate virtio net device
> over virtio mdev transport. The device is implemented through vringh
> and workqueue. A device specific dma ops is to make sure HVA is used
> directly as the IOVA. This should be sufficient for kernel virtio
> driver to work.
> 
> Only 'virtio' type is supported right now. I plan to add 'vhost' type
> on top which requires some virtual IOMMU implemented in this sample
> driver.
> 
> Signed-off-by: Jason Wang 
> ---
>  MAINTAINERS|   1 +
>  samples/Kconfig|  10 +
>  samples/vfio-mdev/Makefile |   1 +
>  samples/vfio-mdev/mvnet_loopback.c | 690 +
>  4 files changed, 702 insertions(+)
>  create mode 100644 samples/vfio-mdev/mvnet_loopback.c
> 

> +static struct mvnet_dev {
> + struct class*vd_class;
> + struct idr  vd_idr;
> + struct device   dev;
> +} mvnet_dev;

This structure embeds a struct device (a reference-counted structure),
yet it is a static variable. This is giving a bad example to potential
implementers; just allocate it dynamically.

> +static void mvnet_device_release(struct device *dev)
> +{
> + dev_dbg(dev, "mvnet: released\n");

And that also means you need a proper release function here, of
course.

> +}

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 08/13] drm/modes: parse_cmdline: Allow specifying stand-alone options

2019-11-18 Thread Hans de Goede
Some options which can be specified on the commandline, such as
margin_right=..., margin_left=..., etc. are applied not only to the
specified mode, but to all modes. As such it would be nice if the user
can simply say e.g.
video=HDMI-1:margin_right=14,margin_left=24,margin_bottom=36,margin_top=42

This commit refactors drm_mode_parse_command_line_for_connector() to
add support for this, and as a nice side effect also cleans up the
function a bit.

Acked-by: Maxime Ripard 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_modes.c   | 92 +++
 .../gpu/drm/selftests/drm_cmdline_selftests.h |  2 +
 .../drm/selftests/test-drm_cmdline_parser.c   | 50 ++
 3 files changed, 86 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 72828fa9fc91..2e82603f5d0a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1677,17 +1677,6 @@ static const char * const drm_named_modes_whitelist[] = {
"PAL",
 };
 
-static bool drm_named_mode_is_in_whitelist(const char *mode, unsigned int size)
-{
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++)
-   if (!strncmp(mode, drm_named_modes_whitelist[i], size))
-   return true;
-
-   return false;
-}
-
 /**
  * drm_mode_parse_command_line_for_connector - parse command line modeline for 
connector
  * @mode_option: optional per connector mode option
@@ -1718,7 +1707,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
   struct drm_cmdline_mode *mode)
 {
const char *name;
-   bool named_mode = false, parse_extras = false;
+   bool freestanding = false, parse_extras = false;
unsigned int bpp_off = 0, refresh_off = 0, options_off = 0;
unsigned int mode_end = 0;
const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
@@ -1738,49 +1727,14 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
 
name = mode_option;
 
-   /*
-* This is a bit convoluted. To differentiate between the
-* named modes and poorly formatted resolutions, we need a
-* bunch of things:
-*   - We need to make sure that the first character (which
-* would be our resolution in X) is a digit.
-*   - If not, then it's either a named mode or a force on/off.
-* To distinguish between the two, we need to run the
-* extra parsing function, and if not, then we consider it
-* a named mode.
-*
-* If this isn't enough, we should add more heuristics here,
-* and matching unit-tests.
-*/
-   if (!isdigit(name[0]) && name[0] != 'x') {
-   unsigned int namelen = strlen(name);
-
-   /*
-* Only the force on/off options can be in that case,
-* and they all take a single character.
-*/
-   if (namelen == 1) {
-   ret = drm_mode_parse_cmdline_extra(name, namelen, true,
-  connector, mode);
-   if (!ret)
-   return true;
-   }
-
-   named_mode = true;
-   }
-
/* Try to locate the bpp and refresh specifiers, if any */
bpp_ptr = strchr(name, '-');
if (bpp_ptr)
bpp_off = bpp_ptr - name;
 
refresh_ptr = strchr(name, '@');
-   if (refresh_ptr) {
-   if (named_mode)
-   return false;
-
+   if (refresh_ptr)
refresh_off = refresh_ptr - name;
-   }
 
/* Locate the start of named options */
options_ptr = strchr(name, ',');
@@ -1800,23 +1754,45 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
parse_extras = true;
}
 
-   if (named_mode) {
-   if (mode_end + 1 > DRM_DISPLAY_MODE_LEN)
-   return false;
+   /* First check for a named mode */
+   for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
+   ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
+   if (ret == mode_end) {
+   if (refresh_ptr)
+   return false; /* named + refresh is invalid */
 
-   if (!drm_named_mode_is_in_whitelist(name, mode_end))
-   return false;
+   strcpy(mode->name, drm_named_modes_whitelist[i]);
+   mode->specified = true;
+   break;
+   }
+   }
 
-   strscpy(mode->name, name, mode_end + 1);
-   } else {
+   /* No named mode? Check for a normal mode argument, e.g. 1024x768 */
+   if (!mode->specified && isdigit(name[0])) {
ret 

[PATCH v3 07/13] drm/modes: parse_cmdline: Set bpp/refresh_specified after successful parsing

2019-11-18 Thread Hans de Goede
drm_connector_get_cmdline_mode() calls
drm_mode_parse_command_line_for_connector() with &connector->cmdline_mode
as mode argument, so anything which we store in the mode arguments gets
kept even if we return false.

Avoid storing a possibly false-postive bpp/refresh_specified setting
in connector->cmdline_mode by moving the setting of these to after
successful parsing of the bpp/refresh parts of the video= argument.

Acked-by: Maxime Ripard 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_modes.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 80cb247c83c7..72828fa9fc91 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1771,10 +1771,8 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
 
/* Try to locate the bpp and refresh specifiers, if any */
bpp_ptr = strchr(name, '-');
-   if (bpp_ptr) {
+   if (bpp_ptr)
bpp_off = bpp_ptr - name;
-   mode->bpp_specified = true;
-   }
 
refresh_ptr = strchr(name, '@');
if (refresh_ptr) {
@@ -1782,7 +1780,6 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
return false;
 
refresh_off = refresh_ptr - name;
-   mode->refresh_specified = true;
}
 
/* Locate the start of named options */
@@ -1825,6 +1822,8 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
ret = drm_mode_parse_cmdline_bpp(bpp_ptr, &bpp_end_ptr, mode);
if (ret)
return false;
+
+   mode->bpp_specified = true;
}
 
if (refresh_ptr) {
@@ -1832,6 +1831,8 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
 &refresh_end_ptr, mode);
if (ret)
return false;
+
+   mode->refresh_specified = true;
}
 
/*
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 04/13] drm/modes: parse_cmdline: Accept extras directly after mode combined with options

2019-11-18 Thread Hans de Goede
Before this commit it was impossible to combine an extra mode argument
specified directly after the resolution with an option, e.g.
video=HDMI-1:720x480e,rotate=180 would not work, either the "e" to force
enable would need to be dropped or the ",rotate=180", otherwise the
mode_option would not be accepted.

This commit fixes this by setting parse_extras to true in this case, so
that drm_mode_parse_cmdline_res_mode() parses the extra arguments directly
after the resolution.

Acked-by: Maxime Ripard 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_modes.c   |  1 +
 .../gpu/drm/selftests/drm_cmdline_selftests.h |  1 +
 .../drm/selftests/test-drm_cmdline_parser.c   | 24 +++
 3 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a8aa7955fd45..f49401124727 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1794,6 +1794,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
mode_end = refresh_off;
} else if (options_ptr) {
mode_end = options_off;
+   parse_extras = true;
} else {
mode_end = strlen(name);
parse_extras = true;
diff --git a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h 
b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
index ca1fc7a78953..003e2c3ffc39 100644
--- a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
@@ -61,3 +61,4 @@ cmdline_test(drm_cmdline_test_margin_options)
 cmdline_test(drm_cmdline_test_multiple_options)
 cmdline_test(drm_cmdline_test_invalid_option)
 cmdline_test(drm_cmdline_test_bpp_extra_and_option)
+cmdline_test(drm_cmdline_test_extra_and_option)
diff --git a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c 
b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
index 5b8dea922257..bc4db017e993 100644
--- a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
+++ b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
@@ -1018,6 +1018,30 @@ static int drm_cmdline_test_bpp_extra_and_option(void 
*ignored)
return 0;
 }
 
+static int drm_cmdline_test_extra_and_option(void *ignored)
+{
+   struct drm_cmdline_mode mode = { };
+
+   
FAIL_ON(!drm_mode_parse_command_line_for_connector("720x480e,rotate=180",
+  &no_connector,
+  &mode));
+   FAIL_ON(!mode.specified);
+   FAIL_ON(mode.xres != 720);
+   FAIL_ON(mode.yres != 480);
+   FAIL_ON(mode.rotation_reflection != DRM_MODE_ROTATE_180);
+
+   FAIL_ON(mode.refresh_specified);
+   FAIL_ON(mode.bpp_specified);
+
+   FAIL_ON(mode.rb);
+   FAIL_ON(mode.cvt);
+   FAIL_ON(mode.interlace);
+   FAIL_ON(mode.margins);
+   FAIL_ON(mode.force != DRM_FORCE_ON);
+
+   return 0;
+}
+
 #include "drm_selftest.c"
 
 static int __init test_drm_cmdline_init(void)
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 06/13] drm/modes: parse_cmdline: Add freestanding argument to drm_mode_parse_cmdline_options()

2019-11-18 Thread Hans de Goede
Add a freestanding function argument to drm_mode_parse_cmdline_options()
similar to how drm_mode_parse_cmdline_extra() already has this.

This is a preparation patch for allowing parsing of stand-alone options
without a mode before them, e.g.: video=HDMI-1:margin_right=14,...

Acked-by: Maxime Ripard 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_modes.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 25e8edf4cfb8..80cb247c83c7 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1592,6 +1592,7 @@ static int drm_mode_parse_cmdline_int(const char *delim, 
unsigned int *int_ret)
 }
 
 static int drm_mode_parse_cmdline_options(const char *str,
+ bool freestanding,
  const struct drm_connector *connector,
  struct drm_cmdline_mode *mode)
 {
@@ -1663,6 +1664,9 @@ static int drm_mode_parse_cmdline_options(const char *str,
option = sep + 1;
} while (sep);
 
+   if (rotation && freestanding)
+   return -EINVAL;
+
mode->rotation_reflection = rotation;
 
return 0;
@@ -1855,6 +1859,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
 
if (options_ptr) {
ret = drm_mode_parse_cmdline_options(options_ptr + 1,
+false,
 connector, mode);
if (ret)
return false;
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 02/13] drm/modes: parse_cmdline: Make various char pointers const

2019-11-18 Thread Hans de Goede
We are not supposed to modify the passed in string, make char pointers
used in drm_mode_parse_cmdline_options() const char * where possible.

Acked-by: Maxime Ripard 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_modes.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 3c3c7435225f..654d4b6fecb3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1591,15 +1591,15 @@ static int drm_mode_parse_cmdline_int(const char 
*delim, unsigned int *int_ret)
return 0;
 }
 
-static int drm_mode_parse_cmdline_options(char *str, size_t len,
+static int drm_mode_parse_cmdline_options(const char *str, size_t len,
  const struct drm_connector *connector,
  struct drm_cmdline_mode *mode)
 {
unsigned int deg, margin, rotation = 0;
-   char *sep = str;
+   const char *sep = str;
 
while ((sep = strchr(sep, ','))) {
-   char *delim, *option;
+   const char *delim, *option;
 
option = sep + 1;
delim = strchr(option, '=');
@@ -1718,8 +1718,8 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
bool named_mode = false, parse_extras = false;
unsigned int bpp_off = 0, refresh_off = 0, options_off = 0;
unsigned int mode_end = 0;
-   char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
-   char *options_ptr = NULL;
+   const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
+   const char *options_ptr = NULL;
char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
int ret;
 
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  1   2   3   >