RE: [Intel-gfx] [PATCH 2/2] drm/hdcp: DP HDCP2.2 errata LC_Send_L_Prime=16
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Wednesday, March 24, 2021 10:16 AM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/2] drm/hdcp: DP HDCP2.2 errata
> LC_Send_L_Prime=16
>
> Change is as per the errata. LGTM.
>
> Reviewed-by: Ankit Nautiyal
Hi Maarten ,
Could you please provide your Ack to merge it via drm-intel-next, since it is
a small change.
Thanks,
Anshuman Gupta.
>
> On 1/27/2021 1:54 PM, Anshuman Gupta wrote:
> > Fix LC_Send_L_Prime message timeout to 16 as documented in DP HDCP 2.2
> > errata page 3.
> >
> > https://www.digital-cp.com/sites/default/files/HDCP%202_2_DisplayPort_
> > Errata_v3_0.pdf
> >
> > Cc: Ramalingam C
> > Signed-off-by: Anshuman Gupta
> > ---
> > include/drm/drm_hdcp.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index
> > 2b165a0f434f..0be3228e 100644
> > --- a/include/drm/drm_hdcp.h
> > +++ b/include/drm/drm_hdcp.h
> > @@ -231,7 +231,7 @@ struct hdcp2_rep_stream_ready {
> > #define HDCP_2_2_PAIRING_TIMEOUT_MS 200
> > #define HDCP_2_2_DP_PAIRING_READ_TIMEOUT_MS 5
> > #define HDCP_2_2_HDMI_LPRIME_TIMEOUT_MS 20
> > -#define HDCP_2_2_DP_LPRIME_TIMEOUT_MS 7
> > +#define HDCP_2_2_DP_LPRIME_TIMEOUT_MS 16
> > #define HDCP_2_2_RECVID_LIST_TIMEOUT_MS 3000
> > #define HDCP_2_2_STREAM_READY_TIMEOUT_MS 100
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: mmp: Few typo fixes
On Mon, 2021-03-22 at 12:36 -0700, Randy Dunlap wrote:
> On 3/22/21 6:02 AM, Bhaskar Chowdhury wrote:
> >
> > s/configed/configured/
> > s/registed/registered/
> > s/defintions/definitions/
> >
> > Signed-off-by: Bhaskar Chowdhury
>
> Acked-by: Randy Dunlap
[]
> > diff --git a/include/video/mmp_disp.h b/include/video/mmp_disp.h
> > index 77252cb46361..ea8b4331b7a1 100644
> > --- a/include/video/mmp_disp.h
> > +++ b/include/video/mmp_disp.h
> > @@ -172,7 +172,7 @@ struct mmp_panel {
> > /* use node to register to list */
> > struct list_head node;
> > const char *name;
> > - /* path name used to connect to proper path configed */
> > + /* path name used to connect to proper path configured */
The spelling is now correct, but the word order doesn't make much sense.
> > @@ -291,7 +291,7 @@ static inline int mmp_overlay_set_addr(struct
> > mmp_overlay *overlay,
> > * it defined a common interface that plat driver need to implement
> > */
> > struct mmp_path_info {
> > - /* driver data, set when registed*/
> > + /* driver data, set when registered*/
should have a space before */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, amdkfd, radeon drm-next-5.13
Hi Dave, Daniel, Same as the last one, but with typo in one of the sign offs fixed. The following changes since commit 6e80fb8ab04f6c4f377e2fd422bdd1855beb7371: drm/amdgpu: Set reference clock to 100Mhz on Renoir (v2) (2021-02-18 16:43:09 -0500) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-5.13-2021-03-23 for you to fetch changes up to 8c44390d8872ebf3a28558b59a0074df39b3da8f: drm/amdkfd: Bump KFD API version (2021-03-23 23:40:55 -0400) amd-drm-next-5.13-2021-03-23: amdgpu: - Debugfs cleanup - Various cleanups and spelling fixes - Flexible array cleanups - Initial AMD Freesync HDMI - Display fixes - 10bpc dithering improvements - Display ASSR support - Clean up and unify powerplay and swsmu interfaces - Vangogh fixes - Add SMU gfx busy queues for RV/PCO - PCIE DPM fixes - S0ix fixes - GPU metrics data fixes - DCN secure display support - Backlight type override - Add initial support for Aldebaran - RAS fixes - Prime fixes for A+A systems - Reset fixes - Initial resource cursor support - Drop legacy IO BAR requirements - Various power fixes amdkfd: - MMU notifier fixes - APU fixes radeon: - Debugfs cleanups - Flexible array cleanups UAPI: - amdgpu: Add a new INFO ioctl interface to query video capabilities rather than hardcoding them in userspace. This allows us to provide fine grained asic capabilities (e.g., if a particular part is bandwidth limited, we can limit the capabilities). Proposed userspace: https://gitlab.freedesktop.org/leoliu/drm/-/commits/info_video_caps https://gitlab.freedesktop.org/leoliu/mesa/-/commits/info_video_caps - amdkfd: bump the driver version. There was a problem with reporting some RAS features on older versions of the driver. Proposed userspace: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/commit/7cdd63475c36bb9f49bb960f90f9a8cdb7e80a21 Alex Deucher (21): drm/amdgpu: add asic callback for querying video codec info (v3) drm/amdgpu: add video decode/encode cap tables and asic callbacks (v3) drm/amdgpu: add INFO ioctl support for querying video caps (v4) drm/amdgpu: bump driver version for new video codec INFO ioctl query drm/amdgpu/codec: drop the internal codec index drm/amdgpu/pm: make unsupported power profile messages debug drm/amdgpu/swsmu/vangogh: Only use RLCPowerNotify msg for disable drm/amdgpu: Only check for S0ix if AMD_PMC is configured drm/amdgpu: enable BACO runpm by default on sienna cichlid and navy flounder drm/amdgpu: enable TMZ by default on Raven asics drm/amdgpu/dc: fill in missing call to atom cmd table for pll adjust v2 drm/amdgpu/display: simplify backlight setting drm/amdgpu/display: don't assert in set backlight function drm/amdgpu/display: handle aux backlight in backlight_get_brightness drm/amdgpu: add mmhub client ids for aldebaran drm/amdgpu: fix S0ix handling when the CONFIG_AMD_PMC=m drm/amdgpu/powerplay/smu10: add support for gpu busy query (v2) drm/amdgpu/smu8: return an error rather than 50% if busy query fails drm/amdgpu: drop legacy IO bar support drm/amdgpu: drop extraneous hw_status update drm/amdgpu/display: properly guard dc_dsc_stream_bandwidth_in_kbps Alex Sierra (4): drm/amdgpu: UTLC1 RB SDMA timeout on Aldebaran drm/amdgpu: enable 48-bit IH timestamp counter drm/amdgpu: update mmhub client ids for Aldebaran drm/amdgpu: use pd addr based on gart level page table Amber Lin (1): drm/amdgpu: Aldebaran doesn't use semaphore Anson Jacob (5): Revert "drm/amd/display: reuse current context instead of recreating one" drm/amdkfd: Fix UBSAN shift-out-of-bounds warning Revert "drm/amd/display: remove duplicate include in amdgpu_dm.c" drm/amd/display: remove duplicate include in amdgpu_dm.c drm/amd/display: Fix UBSAN warning for not a valid value for type '_Bool' Anthony Koo (5): drm/amd/display: [FW Promotion] Release 0.0.52 drm/amd/display: [FW Promotion] Release 0.0.53 drm/amd/display: [FW Promotion] Release 0.0.54 drm/amd/display: [FW Promotion] Release 0.0.55 drm/amd/display: [FW Promotion] Release 0.0.56 Anthony Wang (2): drm/amd/display: disable seamless boot for DP MST drm/amd/display: enable audio on DP seamless boot Aric Cyr (10): drm/amd/display: 3.2.123 drm/amd/display: Don't optimize bandwidth before disabling planes drm/amd/display: reduce scope for local var drm/amd/display: 3.2.124 drm/amd/display: 3.2.125 drm/amd/display: 3.2.126 drm/amd/display: 3.2.126.1 drm/amd/display: System black screen hangs on driver load drm/amd/display: DCHUB underflow counter increasing in some scenarios drm/amd/display:
Re: [PATCH] drm/imx: fix out of bounds array access warning
Hi Arnd,
Thanks for your patch.
It would be good to improve the patch's head line to something like:
drm/imx: imx-ldb: fix out of bounds array access warning
Regards,
Liu Ying
On Tue, 2021-03-23 at 14:05 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When CONFIG_OF is disabled, building with 'make W=1' produces warnings
> about out of bounds array access:
>
> drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
> drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below
> array bounds of 'struct clk *[4]' [-Werror=array-bounds]
>
> Add an error check before the index is used, which helps with the
> warning, as well as any possible other error condition that may be
> triggered at runtime.
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/imx/imx-ldb.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
> index dbfe39e2f7f6..1210360cec8a 100644
> --- a/drivers/gpu/drm/imx/imx-ldb.c
> +++ b/drivers/gpu/drm/imx/imx-ldb.c
> @@ -197,6 +197,12 @@ static void imx_ldb_encoder_enable(struct drm_encoder
> *encoder)
> int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
> int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
>
> + if (mux < 0) {
> + dev_warn(ldb->dev,
> + "%s: invalid mux\n", __func__);
> + return;
> + }
> +
> drm_panel_prepare(imx_ldb_ch->panel);
>
> if (dual) {
> @@ -255,6 +261,12 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder
> *encoder,
> int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
> u32 bus_format = imx_ldb_ch->bus_format;
>
> + if (mux < 0) {
> + dev_warn(ldb->dev,
> + "%s: invalid mux\n", __func__);
> + return;
> + }
> +
> if (mode->clock > 17) {
> dev_warn(ldb->dev,
>"%s: mode exceeds 170 MHz pixel clock\n", __func__);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [V2][PATCH] drm: xlnx: zynqmp: release reset to DP controller before accessing DP registers
Hi Quanyang,
Thank you for the patch.
On Tue, Mar 23, 2021 at 10:55:01AM +0800, quanyang.w...@windriver.com wrote:
> From: Quanyang Wang
>
> When insmod zynqmp-dpsub.ko after rmmod it, system will hang with the
> error log as below:
>
> root@xilinx-zynqmp:~# insmod zynqmp-dpsub.ko
> [ 88.391289] [drm] Initialized zynqmp-dpsub 1.0.0 20130509 for
> fd4a.display on minor 0
> [ 88.529906] Console: switching to colour frame buffer device 128x48
> [ 88.549402] zynqmp-dpsub fd4a.display: [drm] fb0: zynqmp-dpsubdrm
> frame buffer device
> [ 88.571624] zynqmp-dpsub fd4a.display: ZynqMP DisplayPort Subsystem
> driver probed
> root@xilinx-zynqmp:~# rmmod zynqmp_dpsub
> [ 94.023404] Console: switching to colour dummy device 80x25
> root@xilinx-zynqmp:~# insmod zynqmp-dpsub.ko
>
>
> This is because that in zynqmp_dp_probe it tries to access some DP
> registers while the DP controller is still in the reset state. When
> running "rmmod zynqmp_dpsub", zynqmp_dp_reset(dp, true) in
> zynqmp_dp_phy_exit is called to force the DP controller into the reset
> state. Then insmod will call zynqmp_dp_probe to program the DP registers,
> but at this moment the DP controller hasn't been brought out of the reset
> state yet since the function zynqmp_dp_reset(dp, false) is called later and
> this will result the system hang.
>
> Releasing the reset to DP controller before any read/write operation to it
> will fix this issue. And for symmetry, move zynqmp_dp_reset() call from
> zynqmp_dp_phy_exit() to zynqmp_dp_remove().
>
> Signed-off-by: Quanyang Wang
Reviewed-by: Laurent Pinchart
> ---
>
> V2:
> According to Laurent's comments:
> - add zynqmp_dp_reset(dp, true) in error path in zynqmp_dp_probe
> - move the zynqmp_dp_reset() call from zynqmp_dp_phy_exit() to
> zynqmp_dp_remove()
>
> ---
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 22 --
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 99158ee67d02..337adf0769ad 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -402,10 +402,6 @@ static int zynqmp_dp_phy_init(struct zynqmp_dp *dp)
> }
> }
>
> - ret = zynqmp_dp_reset(dp, false);
> - if (ret < 0)
> - return ret;
> -
> zynqmp_dp_clr(dp, ZYNQMP_DP_PHY_RESET, ZYNQMP_DP_PHY_RESET_ALL_RESET);
>
> /*
> @@ -441,8 +437,6 @@ static void zynqmp_dp_phy_exit(struct zynqmp_dp *dp)
> ret);
> }
>
> - zynqmp_dp_reset(dp, true);
> -
> for (i = 0; i < dp->num_lanes; i++) {
> ret = phy_exit(dp->phy[i]);
> if (ret)
> @@ -1682,9 +1676,13 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub, struct
> drm_device *drm)
> return PTR_ERR(dp->reset);
> }
>
> + ret = zynqmp_dp_reset(dp, false);
> + if (ret < 0)
> + return ret;
> +
> ret = zynqmp_dp_phy_probe(dp);
> if (ret)
> - return ret;
> + goto err_reset;
>
> /* Initialize the hardware. */
> zynqmp_dp_write(dp, ZYNQMP_DP_TX_PHY_POWER_DOWN,
> @@ -1696,7 +1694,7 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub, struct
> drm_device *drm)
>
> ret = zynqmp_dp_phy_init(dp);
> if (ret)
> - return ret;
> + goto err_reset;
>
> zynqmp_dp_write(dp, ZYNQMP_DP_TRANSMITTER_ENABLE, 1);
>
> @@ -1708,15 +1706,18 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub,
> struct drm_device *drm)
> zynqmp_dp_irq_handler, IRQF_ONESHOT,
> dev_name(dp->dev), dp);
> if (ret < 0)
> - goto error;
> + goto err_phy_exit;
>
> dev_dbg(dp->dev, "ZynqMP DisplayPort Tx probed with %u lanes\n",
> dp->num_lanes);
>
> return 0;
>
> -error:
> +err_phy_exit:
> zynqmp_dp_phy_exit(dp);
> +err_reset:
> + zynqmp_dp_reset(dp, true);
> +
> return ret;
> }
>
> @@ -1734,4 +1735,5 @@ void zynqmp_dp_remove(struct zynqmp_dpsub *dpsub)
> zynqmp_dp_write(dp, ZYNQMP_DP_INT_DS, 0x);
>
> zynqmp_dp_phy_exit(dp);
> + zynqmp_dp_reset(dp, true);
> }
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: fix out of bounds array access warning
Hi Fabio, On Tue, 2021-03-23 at 11:02 -0300, Fabio Estevam wrote: > Hi Arnd, > > On Tue, Mar 23, 2021 at 10:05 AM Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > When CONFIG_OF is disabled, building with 'make W=1' produces warnings > > about out of bounds array access: > > > > drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop': > > drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below > > array bounds of 'struct clk *[4]' [-Werror=array-bounds] > > What about making the driver depend on OF instead (like it is done in > DRM_IMX_HDMI) ? The below patch made DRM_IMX_HDMI depend on OF, because of_drm_find_bridge() is not defined when OF is disabled. drm/imx: dw_hdmi-imx: depend on OF to fix randconfig compile tests on x86_64 It doesn't look like DRM_IMX_LDB is in the same case. Moreover, even if OF is enabled, drm_of_encoder_active_endpoint() is likely to return -EINVAL. So, it looks ok to add an error check. Regards, Liu Ying > > --- a/drivers/gpu/drm/imx/Kconfig > +++ b/drivers/gpu/drm/imx/Kconfig > @@ -27,7 +27,7 @@ config DRM_IMX_TVE > > config DRM_IMX_LDB > tristate "Support for LVDS displays" > - depends on DRM_IMX && MFD_SYSCON > + depends on DRM_IMX && MFD_SYSCON && OF > depends on COMMON_CLK > select DRM_PANEL > help ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: fix out of bounds array access warning
On Tue, 2021-03-23 at 07:19 -0700, Joe Perches wrote:
> On Tue, 2021-03-23 at 14:05 +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > When CONFIG_OF is disabled, building with 'make W=1' produces warnings
> > about out of bounds array access:
> >
> > drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
> > drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below
> > array bounds of 'struct clk *[4]' [-Werror=array-bounds]
> >
> > Add an error check before the index is used, which helps with the
> > warning, as well as any possible other error condition that may be
> > triggered at runtime.
> []
> > diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
> []
> > @@ -197,6 +197,12 @@ static void imx_ldb_encoder_enable(struct drm_encoder
> > *encoder)
> > int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
> > int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
> >
> > + if (mux < 0) {
> > + dev_warn(ldb->dev,
> > +"%s: invalid mux\n", __func__);
>
> trivia:
>
> Any real reason to make this 2 lines? It fits nicely in 80 chars. Maybe:
>
> dev_warn(ldb->dev, "%s: invalid mux: %d\n", __func__, mux);
>
> or maybe:
>
> dev_warn(ldb->dev, "%s: invalid mux: %pe\n",
>__func__, ERR_PTR(mux));
+1
The second one looks better as it's more informative.
Regards,
Liu Ying
>
> > @@ -255,6 +261,12 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder
> > *encoder,
> []
> > + if (mux < 0) {
> > + dev_warn(ldb->dev,
> > +"%s: invalid mux\n", __func__);
>
> etc...
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/4] Fixes to bridge/panel and ingenic-drm
On Tue, Mar 23, 2021 at 04:03:00PM +, Paul Cercueil wrote: > Le mer. 24 févr. 2021 à 13:44, Paul Cercueil a écrit : > > Hi, > > > > Some feedback for patches 1-3? Laurent? > > 1-month anniversary ping :) Haaappy birth-day t youuu :-) Patches reviewed. > > Le dim. 24 janv. 2021 à 8:55, Paul Cercueil a écrit : > >> Hi, > >> > >> Here are three independent fixes. The first one addresses a > >> use-after-free in bridge/panel.c; the second one addresses a > >> use-after-free in the ingenic-drm driver; finally, the third one makes > >> the ingenic-drm driver work again on older Ingenic SoCs. > >> > >> Changes from v2: > >> - patch [1/4] added a FIXME. > >> - patch [2/4] is new. It introduces a drmm_plain_simple_encoder_alloc() > >> macro that will be used in patch [3/4]. > >> - patch [3/4] uses the macro introduced in patch [2/4]. > >> - patch [4/4] is unmodified. > >> > >> Note to linux-stable guys: patch [v2 2/3] will only apply on the current > >> drm-misc-next branch, to fix it for v5.11 and older kernels, use the V1 > >> of that patch. > >> > >> Cheers, > >> -Paul > >> > >> Paul Cercueil (4): > >> drm: bridge/panel: Cleanup connector on bridge detach > >> drm/simple_kms_helper: Add macro drmm_plain_simple_encoder_alloc() > >> drm/ingenic: Register devm action to cleanup encoders > >> drm/ingenic: Fix non-OSD mode > >> > >> drivers/gpu/drm/bridge/panel.c| 12 +++ > >> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 26 +++ > >> include/drm/drm_simple_kms_helper.h | 17 +++ > >> 3 files changed, 42 insertions(+), 13 deletions(-) > >> -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] drm/ingenic: Fix non-OSD mode
Hi Paul,
Thank you for the patch.
On Sun, Jan 24, 2021 at 08:55:52AM +, Paul Cercueil wrote:
> Even though the JZ4740 did not have the OSD mode, it had (according to
> the documentation) two DMA channels, but there is absolutely no
> information about how to select the second DMA channel.
>
> Make the ingenic-drm driver work in non-OSD mode by using the
> foreground0 plane (which is bound to the DMA0 channel) as the primary
> plane, instead of the foreground1 plane, which is the primary plane
> when in OSD mode.
>
> Fixes: 3c9bea4ef32b ("drm/ingenic: Add support for OSD mode")
> Cc: # v5.8+
> Signed-off-by: Paul Cercueil
> Acked-by: Daniel Vetter
I don't have much knowledge about this platform, but the change looks
reasonable to me.
Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index b23011c1c5d9..59ce43862e16 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -554,7 +554,7 @@ static void ingenic_drm_plane_atomic_update(struct
> drm_plane *plane,
> height = state->src_h >> 16;
> cpp = state->fb->format->cpp[0];
>
> - if (priv->soc_info->has_osd && plane->type ==
> DRM_PLANE_TYPE_OVERLAY)
> + if (!priv->soc_info->has_osd || plane->type ==
> DRM_PLANE_TYPE_OVERLAY)
> hwdesc = >dma_hwdescs->hwdesc_f0;
> else
> hwdesc = >dma_hwdescs->hwdesc_f1;
> @@ -826,6 +826,7 @@ static int ingenic_drm_bind(struct device *dev, bool
> has_components)
> const struct jz_soc_info *soc_info;
> struct ingenic_drm *priv;
> struct clk *parent_clk;
> + struct drm_plane *primary;
> struct drm_bridge *bridge;
> struct drm_panel *panel;
> struct drm_encoder *encoder;
> @@ -940,9 +941,11 @@ static int ingenic_drm_bind(struct device *dev, bool
> has_components)
> if (soc_info->has_osd)
> priv->ipu_plane = drm_plane_from_index(drm, 0);
>
> - drm_plane_helper_add(>f1, _drm_plane_helper_funcs);
> + primary = priv->soc_info->has_osd ? >f1 : >f0;
>
> - ret = drm_universal_plane_init(drm, >f1, 1,
> + drm_plane_helper_add(primary, _drm_plane_helper_funcs);
> +
> + ret = drm_universal_plane_init(drm, primary, 1,
> _drm_primary_plane_funcs,
> priv->soc_info->formats_f1,
> priv->soc_info->num_formats_f1,
> @@ -954,7 +957,7 @@ static int ingenic_drm_bind(struct device *dev, bool
> has_components)
>
> drm_crtc_helper_add(>crtc, _drm_crtc_helper_funcs);
>
> - ret = drm_crtc_init_with_planes(drm, >crtc, >f1,
> + ret = drm_crtc_init_with_planes(drm, >crtc, primary,
> NULL, _drm_crtc_funcs, NULL);
> if (ret) {
> dev_err(dev, "Failed to init CRTC: %i\n", ret);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] drm/ingenic: Register devm action to cleanup encoders
Hi Paul,
Thank you for the patch.
On Sun, Jan 24, 2021 at 08:55:51AM +, Paul Cercueil wrote:
> Since the encoders have been devm-allocated, they will be freed way
> before drm_mode_config_cleanup() is called. To avoid use-after-free
> conditions, we then must ensure that drm_encoder_cleanup() is called
> before the encoders are freed.
>
> v2: Use the new __drmm_simple_encoder_alloc() function
>
> v3: Use the new drmm_plain_simple_encoder_alloc() macro
>
> Fixes: c369cb27c267 ("drm/ingenic: Support multiple panels/bridges")
> Cc: # 5.8+
> Signed-off-by: Paul Cercueil
Reviewed-by: Laurent Pinchart
> ---
>
> Notes:
> Use the V1 of this patch to fix v5.11 and older kernels. This V3 only
> applies on the current drm-misc-next branch.
>
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 15 ++-
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index 7bb31fbee29d..b23011c1c5d9 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -1014,20 +1014,17 @@ static int ingenic_drm_bind(struct device *dev, bool
> has_components)
> bridge = devm_drm_panel_bridge_add_typed(dev, panel,
>
> DRM_MODE_CONNECTOR_DPI);
>
> - encoder = devm_kzalloc(dev, sizeof(*encoder), GFP_KERNEL);
> - if (!encoder)
> - return -ENOMEM;
> + encoder = drmm_plain_simple_encoder_alloc(drm,
> DRM_MODE_ENCODER_DPI);
> + if (IS_ERR(encoder)) {
> + ret = PTR_ERR(encoder);
> + dev_err(dev, "Failed to init encoder: %d\n", ret);
> + return ret;
> + }
>
> encoder->possible_crtcs = 1;
>
> drm_encoder_helper_add(encoder,
> _drm_encoder_helper_funcs);
>
> - ret = drm_simple_encoder_init(drm, encoder,
> DRM_MODE_ENCODER_DPI);
> - if (ret) {
> - dev_err(dev, "Failed to init encoder: %d\n", ret);
> - return ret;
> - }
> -
> ret = drm_bridge_attach(encoder, bridge, NULL, 0);
> if (ret) {
> dev_err(dev, "Unable to attach bridge\n");
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] drm/simple_kms_helper: Add macro drmm_plain_simple_encoder_alloc()
Hi Paul, Thank you for the patch. On Sun, Jan 24, 2021 at 08:55:50AM +, Paul Cercueil wrote: > This performs the same operation as drmm_simple_encoder_alloc(), but > only allocates and returns a struct drm_encoder instance. > > Signed-off-by: Paul Cercueil > --- > include/drm/drm_simple_kms_helper.h | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/include/drm/drm_simple_kms_helper.h > b/include/drm/drm_simple_kms_helper.h > index e6dbf3161c2f..f07e70303cfb 100644 > --- a/include/drm/drm_simple_kms_helper.h > +++ b/include/drm/drm_simple_kms_helper.h > @@ -209,4 +209,21 @@ void *__drmm_simple_encoder_alloc(struct drm_device > *dev, size_t size, >offsetof(type, member), \ >encoder_type)) > > +/** > + * drmm_plain_simple_encoder_alloc - Allocate and initialize a drm_encoder > + * struct with basic functionality. > + * @dev: drm device > + * @encoder_type: user visible type of the encoder > + * > + * This performs the same operation as drmm_simple_encoder_alloc(), but > + * only allocates and returns a struct drm_encoder instance. > + * > + * Returns: > + * Pointer to the new drm_encoder struct, or ERR_PTR on failure. > + */ > +#define drmm_plain_simple_encoder_alloc(dev, encoder_type) \ > + ((struct drm_encoder *) \ > + __drmm_simple_encoder_alloc(dev, sizeof(struct drm_encoder), \ > + 0, encoder_type)) > + As this isn't related to the simple encoder helper anymore, how about using __drmm_encoder_alloc instead ? #define drmm_plain_simple_encoder_alloc(dev, encoder_type) \ ((struct drm_encoder *) \ __drmm_encoder_alloc(dev, sizeof(struct drm_encoder), 0, NULL, \ encoder_type, NULL)) I'd also rename the macro to drmm_plain_encoder_alloc(), and move it to drm_encoder.h. That way drivers that don't need the simple KMS helper won't have to select it just for this. > #endif /* __LINUX_DRM_SIMPLE_KMS_HELPER_H */ -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] drm: bridge/panel: Cleanup connector on bridge detach
Hi Paul,
Thank you for the patch.
On Sun, Jan 24, 2021 at 08:55:49AM +, Paul Cercueil wrote:
> If we don't call drm_connector_cleanup() manually in
> panel_bridge_detach(), the connector will be cleaned up with the other
> DRM objects in the call to drm_mode_config_cleanup(). However, since our
> drm_connector is devm-allocated, by the time drm_mode_config_cleanup()
> will be called, our connector will be long gone. Therefore, the
> connector must be cleaned up when the bridge is detached to avoid
> use-after-free conditions.
>
> v2: Cleanup connector only if it was created
>
> v3: Add FIXME
>
> Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the
> lvds-encoder bridge.")
> Cc: # 4.12+
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/drm/bridge/panel.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index 0ddc37551194..5959e8183cd0 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -87,6 +87,18 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
>
> static void panel_bridge_detach(struct drm_bridge *bridge)
> {
> + struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> + struct drm_connector *connector = _bridge->connector;
> +
> + /*
> + * Cleanup the connector if we know it was initialized.
> + *
> + * FIXME: This wouldn't be needed if the panel_bridge structure was
> + * allocated with drmm_kzalloc(). This might be tricky since the
> + * drm_device pointer can only be retrieved when the bridge is attached.
> + */
> + if (!!panel_bridge->connector.dev)
How about simply
if (connector->dev)
? With this change,
Reviewed-by: Laurent Pinchart
> + drm_connector_cleanup(connector);
> }
>
> static void panel_bridge_pre_enable(struct drm_bridge *bridge)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: bridge/panel: Cleanup connector on bridge detach
On Wed, Jan 20, 2021 at 06:38:03PM +0100, Daniel Vetter wrote:
> On Wed, Jan 20, 2021 at 6:12 PM Paul Cercueil wrote:
> > Le mer. 20 janv. 2021 à 17:03, Daniel Vetter a écrit :
> > > On Wed, Jan 20, 2021 at 1:35 PM Paul Cercueil wrote:
> > >>
> > >> If we don't call drm_connector_cleanup() manually in
> > >> panel_bridge_detach(), the connector will be cleaned up with the other
> > >> DRM objects in the call to drm_mode_config_cleanup(). However, since our
> > >> drm_connector is devm-allocated, by the time drm_mode_config_cleanup()
> > >> will be called, our connector will be long gone. Therefore, the
> > >> connector must be cleaned up when the bridge is detached to avoid
> > >> use-after-free conditions.
> > >
> > > For -fixes this sounds ok, but for -next I think switching to drmm_
> > > would be much better.
> >
> > The API would need to change to have access to the drm_device struct,
> > though. That would be quite a big patch, there are a few dozens source
> > files that use this API already.
>
> Hm right pure drmm_ doesn't work for panel or bridge since it's
> usually a separate driver. But devm_ also doesn't work. I think what
> we need here is two-stage: first kmalloc the panel (or bridge, it's
> really the same) in the panel/bridge driver load. Then when we bind it
> to the drm_device we can tie it into the managed resources with
> drmm_add_action_or_reset. Passing the drm_device to the point where we
> allocate the panel/bridge doesn't work for these.
>
> I think minimally we need a FIXME here and ack from Laurent on how
> this should be solved at least, since panel bridge is used rather
> widely.
Bridge removal is completely broken. If you unbind a bridge driver from
the device, the bridge will be unregistered and resources freed, without
the display driver knowing about this. The lifetime of the drm_bridge
structure itself isn't the only issue to be addressed here, it's broader
than that, and needs to consider that the display driver could be
calling the bridge operations concurrently to the removal.
We need a volunteer with enough motivation to solve this subsystem-wide
:-) In the meantime, whatever shortcut addresses immediate issues is
probably fine, as yak-shaving in this area would definitely not be
reasonable.
> > >> v2: Cleanup connector only if it was created
> > >>
> > >> Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from
> > >> the lvds-encoder bridge.")
> > >> Cc: # 4.12+
> > >> Cc: Andrzej Hajda
> > >> Cc: Neil Armstrong
> > >> Cc: Laurent Pinchart
> > >> Cc: Jonas Karlman
> > >> Cc: Jernej Skrabec
> > >> Signed-off-by: Paul Cercueil
> > >> ---
> > >> drivers/gpu/drm/bridge/panel.c | 6 ++
> > >> 1 file changed, 6 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/bridge/panel.c
> > >> b/drivers/gpu/drm/bridge/panel.c
> > >> index 0ddc37551194..df86b0ee0549 100644
> > >> --- a/drivers/gpu/drm/bridge/panel.c
> > >> +++ b/drivers/gpu/drm/bridge/panel.c
> > >> @@ -87,6 +87,12 @@ static int panel_bridge_attach(struct drm_bridge
> > >> *bridge,
> > >>
> > >> static void panel_bridge_detach(struct drm_bridge *bridge)
> > >> {
> > >> +struct panel_bridge *panel_bridge =
> > >> drm_bridge_to_panel_bridge(bridge);
> > >> +struct drm_connector *connector = _bridge->connector;
> > >> +
> > >> +/* Cleanup the connector if we know it was initialized */
> > >> +if (!!panel_bridge->connector.dev)
> > >> +drm_connector_cleanup(connector);
> > >> }
> > >>
> > >> static void panel_bridge_pre_enable(struct drm_bridge *bridge)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/4] drm: sun4i: dsi: Convert to bridge driver
Hi Jagan,
Thank you for the patch.
On Mon, Mar 22, 2021 at 07:31:51PM +0530, Jagan Teki wrote:
> DRM bridge drivers have build-in handling of treating all display
> pipeline components as bridges.
>
> So, convert the existing to a drm bridge driver with a built-in
> encoder support for compatibility with existing component drivers.
It would be best if possible to move this patch before 2/4, to first
convert to the bridge model, and then build on top of it.
> Signed-off-by: Jagan Teki
> ---
> Changes for v4:
> - none
> Changes for v3:
> - new patch
>
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 75 --
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 6 +++
> 2 files changed, 54 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 39321299dc27..6f3c5330a468 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -714,10 +714,10 @@ static int sun6i_dsi_start(struct sun6i_dsi *dsi,
> return 0;
> }
>
> -static void sun6i_dsi_encoder_enable(struct drm_encoder *encoder)
> +static void sun6i_dsi_bridge_enable(struct drm_bridge *bridge)
> {
> - struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> + struct drm_display_mode *mode =
> >encoder->crtc->state->adjusted_mode;
> + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> struct mipi_dsi_device *device = dsi->device;
> union phy_configure_opts opts = { };
> struct phy_configure_opts_mipi_dphy *cfg = _dphy;
> @@ -801,9 +801,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder
> *encoder)
> sun6i_dsi_start(dsi, DSI_START_HSD);
> }
>
> -static void sun6i_dsi_encoder_disable(struct drm_encoder *encoder)
> +static void sun6i_dsi_bridge_disable(struct drm_bridge *bridge)
> {
> - struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
>
> DRM_DEBUG_DRIVER("Disabling DSI output\n");
>
> @@ -852,9 +852,40 @@ static const struct drm_connector_funcs
> sun6i_dsi_connector_funcs = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> -static const struct drm_encoder_helper_funcs sun6i_dsi_enc_helper_funcs = {
> - .disable= sun6i_dsi_encoder_disable,
> - .enable = sun6i_dsi_encoder_enable,
> +static int sun6i_dsi_bridge_attach(struct drm_bridge *bridge,
> +enum drm_bridge_attach_flags flags)
> +{
> + struct sun6i_dsi *dsi = bridge_to_sun6i_dsi(bridge);
> + int ret;
> +
> + if (dsi->panel_bridge)
> + return drm_bridge_attach(bridge->encoder, dsi->panel_bridge,
> NULL, 0);
> +
> + if (dsi->panel) {
> + drm_connector_helper_add(>connector,
> + _dsi_connector_helper_funcs);
> + ret = drm_connector_init(bridge->dev, >connector,
> + _dsi_connector_funcs,
> + DRM_MODE_CONNECTOR_DSI);
> + if (ret) {
> + dev_err(dsi->dev, "Couldn't initialise the DSI
> connector\n");
> + goto err_cleanup_connector;
> + }
> +
> + drm_connector_attach_encoder(>connector, >encoder);
> + }
> +
> + return 0;
> +
> +err_cleanup_connector:
> + drm_encoder_cleanup(>encoder);
> + return ret;
> +}
> +
> +static const struct drm_bridge_funcs sun6i_dsi_bridge_funcs = {
> + .enable = sun6i_dsi_bridge_enable,
> + .disable= sun6i_dsi_bridge_disable,
> + .attach = sun6i_dsi_bridge_attach,
> };
>
> static u32 sun6i_dsi_dcs_build_pkt_hdr(struct sun6i_dsi *dsi,
> @@ -1063,8 +1094,6 @@ static int sun6i_dsi_bind(struct device *dev, struct
> device *master,
> struct sun6i_dsi *dsi = dev_get_drvdata(dev);
> int ret;
>
> - drm_encoder_helper_add(>encoder,
> -_dsi_enc_helper_funcs);
> ret = drm_simple_encoder_init(drm, >encoder,
> DRM_MODE_ENCODER_DSI);
> if (ret) {
> @@ -1073,27 +1102,12 @@ static int sun6i_dsi_bind(struct device *dev, struct
> device *master,
> }
> dsi->encoder.possible_crtcs = BIT(0);
>
> - drm_connector_helper_add(>connector,
> - _dsi_connector_helper_funcs);
> - ret = drm_connector_init(drm, >connector,
> - _dsi_connector_funcs,
> - DRM_MODE_CONNECTOR_DSI);
> + ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
> if (ret) {
> - dev_err(dsi->dev,
> - "Couldn't initialise the DSI connector\n");
> + dev_err(dsi->dev, "Couldn't attach drm bridge\n");
> goto err_cleanup_connector;
> }
Re: [PATCH v4 2/4] drm: sun4i: dsi: Add bridge support
Hi Jagan,
Thank you for the patch.
On Mon, Mar 22, 2021 at 07:31:50PM +0530, Jagan Teki wrote:
> Some display panels would come up with a non-DSI output which
Did you mean input instead of output ?
> can have an option to connect DSI interface by means of bridge
> converter.
>
> This DSI to non-DSI bridge converter would require a bridge
> driver that would communicate the DSI controller for bridge
> functionalities.
>
> So, add support for bridge functionalities in Allwinner DSI
> controller.
>
> Cc: Samuel Holland
> Signed-off-by: Jagan Teki
> ---
> Note:
> Samuel Holland, The existing kms hotplug dropped in order to
> attach the bridge properly.
>
> However, I did try several ways to support hotplug with the
> bridge but it's resulting in a deadlock where bind never attach
> bridge until bridge pointer found and bridge pointer cannot
> found until bind finishes. Any inputs on this would be appreciated.
>
> Changes for v4:
> - none
> Changes for v3:
> - updated with new API's
>
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 34 +-
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 +-
> 2 files changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 2e9e7b2d4145..39321299dc27 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -773,6 +773,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder
> *encoder)
> if (dsi->panel)
> drm_panel_prepare(dsi->panel);
>
> + if (dsi->panel_bridge)
> + dsi->panel_bridge->funcs->pre_enable(dsi->panel_bridge);
> +
> /*
>* FIXME: This should be moved after the switch to HS mode.
>*
> @@ -788,6 +791,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder
> *encoder)
> if (dsi->panel)
> drm_panel_enable(dsi->panel);
>
> + if (dsi->panel_bridge)
> + dsi->panel_bridge->funcs->enable(dsi->panel_bridge);
> +
> sun6i_dsi_start(dsi, DSI_START_HSC);
>
> udelay(1000);
> @@ -804,6 +810,9 @@ static void sun6i_dsi_encoder_disable(struct drm_encoder
> *encoder)
> if (dsi->panel) {
> drm_panel_disable(dsi->panel);
> drm_panel_unprepare(dsi->panel);
> + } else if (dsi->panel_bridge) {
> + dsi->panel_bridge->funcs->disable(dsi->panel_bridge);
> + dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
> }
Instead of having code paths that depend on whether you have a panel or
a bridge, it would be better to wrap the panel a bridge (using
drivers/gpu/drm/bridge/panel.c). The dsi->panel_bridge pointer should be
renamed to next_bridge, and all the code (except in probe) can the use
next_bridge without caring if it's a direct connection to a panel or
another bridge.
Furthermore, the encoder should call bridge functions explicitly, this
should be handled by the DRM core.
>
> phy_power_off(dsi->dphy);
> @@ -964,23 +973,17 @@ static int sun6i_dsi_attach(struct mipi_dsi_host *host,
> struct mipi_dsi_device *device)
> {
> struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
> - struct drm_panel *panel;
> int ret;
>
> ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 0, 0,
> - , NULL);
> + >panel, >panel_bridge);
> if (ret)
> return ret;
>
> - if (!dsi->drm || !dsi->drm->registered)
> - return -EPROBE_DEFER;
> -
> - dsi->panel = panel;
> dsi->device = device;
>
> - drm_kms_helper_hotplug_event(dsi->drm);
> -
> - dev_info(host->dev, "Attached device %s\n", device->name);
> + dev_info(host->dev, "Attached %s %s\n",
> + device->name, dsi->panel ? "panel" : "bridge");
>
> return 0;
> }
> @@ -991,9 +994,10 @@ static int sun6i_dsi_detach(struct mipi_dsi_host *host,
> struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
>
> dsi->panel = NULL;
> + dsi->panel_bridge = NULL;
> dsi->device = NULL;
>
> - drm_kms_helper_hotplug_event(dsi->drm);
> + drm_of_panel_bridge_remove(dsi->dev->of_node, 0, 0);
>
> return 0;
> }
> @@ -1082,7 +1086,13 @@ static int sun6i_dsi_bind(struct device *dev, struct
> device *master,
>
> drm_connector_attach_encoder(>connector, >encoder);
>
> - dsi->drm = drm;
> + if (dsi->panel_bridge) {
> + ret = drm_bridge_attach(>encoder, dsi->panel_bridge, NULL,
> 0);
> + if (ret) {
> + dev_err(dsi->dev, "Couldn't attach drm bridge\n");
> + goto err_cleanup_connector;
> + }
> + }
>
> return 0;
>
> @@ -1096,7 +1106,7 @@ static void sun6i_dsi_unbind(struct device *dev, struct
> device *master,
> {
> struct sun6i_dsi *dsi = dev_get_drvdata(dev);
>
>
RE: [PATCH] video/fbdev: Fix a double free in hvfb_probe
From: Lv Yunlong Sent: Tuesday, March 23, 2021 12:34
AM
>
> In function hvfb_probe in hyperv_fb.c, it calls hvfb_getmem(hdev, info)
> and return err when info->apertures is freed.
>
> In the error1 label of hvfb_probe, info->apertures will be freed twice
> by framebuffer_release(info).
>
> My patch sets info->apertures to NULL after it was freed to avoid
> double free.
>
> Signed-off-by: Lv Yunlong
> ---
> drivers/video/fbdev/hyperv_fb.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> index c8b0ae676809..2fc9b507e73a 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -1032,6 +1032,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct
> fb_info
> *info)
> if (!pdev) {
> pr_err("Unable to find PCI Hyper-V video\n");
> kfree(info->apertures);
> + info->apertures = NULL;
> return -ENODEV;
> }
>
> @@ -1130,6 +1131,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct
> fb_info
> *info)
> pci_dev_put(pdev);
> }
> kfree(info->apertures);
> + info->apertures = NULL;
>
> return 0;
>
> @@ -1142,6 +1144,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct
> fb_info
> *info)
> if (!gen2vm)
> pci_dev_put(pdev);
> kfree(info->apertures);
> + info->apertures = NULL;
>
> return -ENOMEM;
> }
> --
> 2.25.1
>
While I think this works, a slightly better solution might be to remove
all calls to kfree(info->apertures) in hvfb_getmem(), and just let
framebuffer_release() handle freeing the memory. That's what is
done in other drivers that follow the fbdev pattern, and it's less
code overall.
Michael
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 03/11] drm/bridge: ti-sn65dsi86: Unregister AUX adapter in remove()
Hi Doug,
On Tue, Mar 23, 2021 at 03:55:05PM -0700, Doug Anderson wrote:
> On Tue, Mar 23, 2021 at 2:42 PM Laurent Pinchart wrote:
> > On Tue, Mar 23, 2021 at 02:08:42PM -0700, Doug Anderson wrote:
> > > On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart wrote:
> > > >
> > > > The AUX adapter registered in probe() need to be unregistered in
> > > > remove(). Do so.
> > > >
> > > > Fixes: b814ec6d4535 ("drm/bridge: ti-sn65dsi86: Implement AUX channel")
> > > > Signed-off-by: Laurent Pinchart
> > > >
> > > > ---
> > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > index da78a12e58b5..c45420a50e73 100644
> > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > @@ -1307,6 +1307,9 @@ static int ti_sn_bridge_remove(struct i2c_client
> > > > *client)
> > > > return -EINVAL;
> > > >
> > > > kfree(pdata->edid);
> > > > +
> > > > + drm_dp_aux_unregister(>aux);
> > > > +
> > > > ti_sn_debugfs_remove(pdata);
> > > >
> > > > of_node_put(pdata->host_node);
> > >
> > > Good catch. One question, though. I know DRM sometimes has different
> > > conventions than the rest of the kernel, but I always look for the
> > > "remove" to be backwards of probe. That means that your code (and
> > > probably most of the remove function) should come _after_ the
> > > drm_bridge_remove(), right? ...since drm_bridge_add() was the last
> > > thing in probe then drm_bridge_remove() should be the first thing in
> > > remove?
> >
> > I agree in theory, yes. However, in practice, if you remove a bridge
> > that is currently in use, all hell will break lose. And if the bridge
> > isn't being used, it makes no difference. Still, it's worth changing the
> > order of operations to move drm_bridge_remove() first, as it won't hurt
> > in any case and is logically better. It's not an issue introduced by
> > this series though, so how how about it on top, or in parallel ?
>
> Sure, it can be a separate patch. I'd kinda prefer it be a patch
> _before_ ${SUBJECT} patch, though. Specifically it's harder for me to
> reason about whether your new function call is in the right place and
> won't cause any problems with the order being all jumbled. If we fix
> the order first then it's easy to reason about your patch.
>
> > You can
> > even submit a patch if you want :-)
>
> Happy to post it up if it won't cause more confusion w/ you posting
> your next version and trying to figure out what to base it on (since
> it will definitely conflict with your series).
I'll need quite a bit of time before v2, as I'd like to test it, and
that requires finishing support for the DSI bridge and the display
controller :-) Please feel free to post a patch if you have time, I
think it could get merged in drm-misc quite quickly.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 03/11] drm/bridge: ti-sn65dsi86: Unregister AUX adapter in remove()
Hi,
On Tue, Mar 23, 2021 at 2:42 PM Laurent Pinchart
wrote:
>
> Hi Doug,
>
> On Tue, Mar 23, 2021 at 02:08:42PM -0700, Doug Anderson wrote:
> > On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart wrote:
> > >
> > > The AUX adapter registered in probe() need to be unregistered in
> > > remove(). Do so.
> > >
> > > Fixes: b814ec6d4535 ("drm/bridge: ti-sn65dsi86: Implement AUX channel")
> > > Signed-off-by: Laurent Pinchart
> > >
> > > ---
> > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > index da78a12e58b5..c45420a50e73 100644
> > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > @@ -1307,6 +1307,9 @@ static int ti_sn_bridge_remove(struct i2c_client
> > > *client)
> > > return -EINVAL;
> > >
> > > kfree(pdata->edid);
> > > +
> > > + drm_dp_aux_unregister(>aux);
> > > +
> > > ti_sn_debugfs_remove(pdata);
> > >
> > > of_node_put(pdata->host_node);
> >
> > Good catch. One question, though. I know DRM sometimes has different
> > conventions than the rest of the kernel, but I always look for the
> > "remove" to be backwards of probe. That means that your code (and
> > probably most of the remove function) should come _after_ the
> > drm_bridge_remove(), right? ...since drm_bridge_add() was the last
> > thing in probe then drm_bridge_remove() should be the first thing in
> > remove?
>
> I agree in theory, yes. However, in practice, if you remove a bridge
> that is currently in use, all hell will break lose. And if the bridge
> isn't being used, it makes no difference. Still, it's worth changing the
> order of operations to move drm_bridge_remove() first, as it won't hurt
> in any case and is logically better. It's not an issue introduced by
> this series though, so how how about it on top, or in parallel ?
Sure, it can be a separate patch. I'd kinda prefer it be a patch
_before_ ${SUBJECT} patch, though. Specifically it's harder for me to
reason about whether your new function call is in the right place and
won't cause any problems with the order being all jumbled. If we fix
the order first then it's easy to reason about your patch.
> You can
> even submit a patch if you want :-)
Happy to post it up if it won't cause more confusion w/ you posting
your next version and trying to figure out what to base it on (since
it will definitely conflict with your series).
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/4] drm: sun4i: dsi: Use drm_of_find_panel_or_bridge
Hi Jagan,
Thank you for the patch.
On Mon, Mar 22, 2021 at 07:31:49PM +0530, Jagan Teki wrote:
> Replace of_drm_find_panel with drm_of_find_panel_or_bridge
> for finding panel, this indeed help to find the bridge if
> bridge support added.
>
> Added NULL in bridge argument, same will replace with bridge
> parameter once bridge supported.
>
> Signed-off-by: Jagan Teki
Looks good, there should be no functional change.
Reviewed-by: Laurent Pinchart
> ---
> Changes for v4, v3:
> - none
>
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 4f5efcace68e..2e9e7b2d4145 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -21,6 +21,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -963,10 +964,14 @@ static int sun6i_dsi_attach(struct mipi_dsi_host *host,
> struct mipi_dsi_device *device)
> {
> struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
> - struct drm_panel *panel = of_drm_find_panel(device->dev.of_node);
> + struct drm_panel *panel;
> + int ret;
> +
> + ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 0, 0,
> + , NULL);
> + if (ret)
> + return ret;
>
> - if (IS_ERR(panel))
> - return PTR_ERR(panel);
> if (!dsi->drm || !dsi->drm->registered)
> return -EPROBE_DEFER;
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 04/11] drm/bridge: ti-sn65dsi86: Use bitmask to store valid rates
Hi, On Tue, Mar 23, 2021 at 2:46 PM Laurent Pinchart wrote: > > Hi Doug, > > On Tue, Mar 23, 2021 at 02:08:55PM -0700, Doug Anderson wrote: > > On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart wrote: > > > > > > The valid rates are stored in an array of 8 booleans. Replace it with a > > > bitmask to save space. > > > > I'm curious: do you have evidence that this does anything useful? I > > guess you're expecting it to save .text space, right? Stack usage and > > execution time differences should be irrelevant--it's not in a > > critical section and the difference should be tiny anyway. As far as > > .text segment goes, it's not obvious to me that the compiler will use > > fewer instructions to manipulate bits compared to booleans. > > > > Doing a super simple "ls -ah" on vmlinux (unstripped): > > > > Before: 224820232 bytes > > After: 224820376 bytes > > > > ...so your change made it _bigger_. OK, so running "strip > > --strip-debug" on those: > > > > Before: 26599464 bytes > > After: 26599464 bytes > > > > ...so exactly the same. I tried finding some evidence using "readelf -ah": > > > > Before: > > [ 2] .text PROGBITS ffc01001 0002 > >00b03508 WAX 0 0 65536 > > [ 3] .rodata PROGBITS ffc010b2 00b3 > >002e84b3 WAMS 0 0 4096 > > > > After: > > [ 2] .text PROGBITS ffc01001 0002 > >00b03508 WAX 0 0 65536 > > [ 3] .rodata PROGBITS ffc010b2 00b3 > >002e84b3 WAMS 0 0 4096 > > > > Maybe you have some evidence showing an improvement? Ah, OK. I > > disassembled ti_sn_bridge_enable() and your patch saves 12 bytes, but > > I guess maybe alignment washes it out in reality... > > > > > > In terms of readability / conventions, I personally find this change a > > bit of a wash. I mean, I guess I originally implemented it as an array > > and I thought that was the most readable, but I like bitfields fine > > too. If everyone loves it then I won't object, but to me it feels like > > touching lines of code for something that's personal preference. ;-) > > You're right that the .text and CPU time improvements were not my > target. I was focussed on stack usage, as that's a limited resource in > the kernel. I don't have any evidence that we would be close to any > limit, so it's tiny, and if you or anyone else have a strong opinion > that an array of booleans is better due to readability concerns, I can > drop this change. I only thought about those poor 7 bits in every bool > that sat there unused, feeling useless :-) LOL. Thinking about it a bit more, I guess I feel a bit lame saying that the array of booleans is more readable. I guess I'd call them equivalently readable. So I guess the downside of this patch is just churn. If someone is maintaining a downstream kernel, it's an extra patch to take. If someone is running "git blame" it's an extra layer to walk back to find the history of the code. That being said, it's really not a big deal. I'll leave it up to you if you want to include the patch in your next version or if my arguments have convinced you. ;-) -Doug ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP
On Fri, Mar 19, 2021 at 10:38:29AM +0100, Parshuram Thombare wrote:
> Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding.
>
> Signed-off-by: Parshuram Thombare
> ---
> .../display/bridge/cdns,mhdp8546.yaml | 34 ---
> 1 file changed, 21 insertions(+), 13 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> index 63427878715e..d571f4bb6b16 100644
> --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> @@ -17,8 +17,8 @@ properties:
>- ti,j721e-mhdp8546
>
>reg:
> -minItems: 1
> -maxItems: 2
> +minItems: 2
> +maxItems: 3
1 entry was valid and now it is not? That's not a compatible change and
needs an explanation at a minimum.
> items:
>- description:
>Register block of mhdptx apb registers up to PHY mapped area
> (AUX_CONFIG_P).
> @@ -26,13 +26,20 @@ properties:
>included in the associated PHY.
>- description:
>Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7
> SoCs.
> + - description:
> + Register block of mhdptx sapb registers.
>
>reg-names:
> -minItems: 1
> -maxItems: 2
> -items:
> - - const: mhdptx
> - - const: j721e-intg
> +minItems: 2
> +maxItems: 3
> +oneOf:
> + - items:
> + - const: mhdptx
> + - const: j721e-intg
> + - const: mhdptx-sapb
> + - items:
> + - const: mhdptx
> + - const: mhdptx-sapb
>
>clocks:
> maxItems: 1
> @@ -98,15 +105,15 @@ allOf:
> then:
>properties:
> reg:
> - minItems: 2
> + minItems: 3
> reg-names:
> - minItems: 2
> + minItems: 3
> else:
>properties:
> reg:
> - maxItems: 1
> + maxItems: 2
> reg-names:
> - maxItems: 1
> + maxItems: 2
>
> required:
>- compatible
> @@ -129,8 +136,9 @@ examples:
>
> mhdp: dp-bridge@f0fb00 {
> compatible = "cdns,mhdp8546";
> -reg = <0xf0 0xfb00 0x0 0x100>;
> -reg-names = "mhdptx";
> +reg = <0xf0 0xfb00 0x0 0x100>,
> + <0x0 0x4f48000 0x0 0x74>;
> +reg-names = "mhdptx", "mhdptx-sapb";
> clocks = <_clock>;
> phys = <_phy>;
> phy-names = "dpphy";
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 07/14] dt-bindings: mfd: Add i.MX8qm/qxp Control and Status Registers module binding
On Wed, 17 Mar 2021 11:42:42 +0800, Liu Ying wrote: > This patch adds bindings for i.MX8qm/qxp Control and Status Registers module. > > Signed-off-by: Liu Ying > --- > v5->v6: > * Drop 'select' schema. (Rob) > > v4->v5: > * Newly introduced in v5. (Rob) > > .../devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml | 192 > + > 1 file changed, 192 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 05/11] drm/bridge: ti-sn65dsi86: Wrap panel with panel-bridge
Hi Stephen,
On Tue, Mar 23, 2021 at 12:14:04AM -0700, Stephen Boyd wrote:
> Quoting Laurent Pinchart (2021-03-21 20:01:22)
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index 1d1be791d5ba..c21a7f7d452b 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -418,8 +420,18 @@ static int ti_sn_bridge_attach(struct drm_bridge
> > *bridge,
> > }
> > pdata->dsi = dsi;
> >
> > + /* Attach the next bridge */
> > + ret = drm_bridge_attach(bridge->encoder, pdata->next_bridge,
> > + >bridge, flags);
> > + if (ret < 0) {
> > + DRM_ERROR("failed to attach next bridge\n");
>
> Can this be pushed into drm_bridge_attach() instead of in each caller?
Good idea.
> > + goto err_dsi_detach;
> > + }
> > +
> > return 0;
> >
> > +err_dsi_detach:
> > + mipi_dsi_detach(dsi);
> > err_dsi_attach:
> > mipi_dsi_device_unregister(dsi);
> > err_dsi_host:
> > static void ti_sn_bridge_post_disable(struct drm_bridge *bridge)
> > @@ -1245,6 +1249,14 @@ static int ti_sn_bridge_probe(struct i2c_client
> > *client,
> > return ret;
> > }
> >
> > + pdata->next_bridge = devm_drm_panel_bridge_add(pdata->dev,
> > + pdata->panel);
> > + if (IS_ERR(pdata->next_bridge)) {
> > + DRM_ERROR("failed to create panel bridge\n");
> > + ret = PTR_ERR(pdata->next_bridge);
> > + return ret;
>
> Just return PTR_ERR(pdata->next_bridge)?
Indeed. Bad copy and paste.
> > + }
> > +
> > dev_set_drvdata(>dev, pdata);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 04/11] drm/bridge: ti-sn65dsi86: Use bitmask to store valid rates
Hi Doug,
On Tue, Mar 23, 2021 at 02:08:55PM -0700, Doug Anderson wrote:
> On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart wrote:
> >
> > The valid rates are stored in an array of 8 booleans. Replace it with a
> > bitmask to save space.
>
> I'm curious: do you have evidence that this does anything useful? I
> guess you're expecting it to save .text space, right? Stack usage and
> execution time differences should be irrelevant--it's not in a
> critical section and the difference should be tiny anyway. As far as
> .text segment goes, it's not obvious to me that the compiler will use
> fewer instructions to manipulate bits compared to booleans.
>
> Doing a super simple "ls -ah" on vmlinux (unstripped):
>
> Before: 224820232 bytes
> After: 224820376 bytes
>
> ...so your change made it _bigger_. OK, so running "strip
> --strip-debug" on those:
>
> Before: 26599464 bytes
> After: 26599464 bytes
>
> ...so exactly the same. I tried finding some evidence using "readelf -ah":
>
> Before:
> [ 2] .text PROGBITS ffc01001 0002
>00b03508 WAX 0 0 65536
> [ 3] .rodata PROGBITS ffc010b2 00b3
>002e84b3 WAMS 0 0 4096
>
> After:
> [ 2] .text PROGBITS ffc01001 0002
>00b03508 WAX 0 0 65536
> [ 3] .rodata PROGBITS ffc010b2 00b3
>002e84b3 WAMS 0 0 4096
>
> Maybe you have some evidence showing an improvement? Ah, OK. I
> disassembled ti_sn_bridge_enable() and your patch saves 12 bytes, but
> I guess maybe alignment washes it out in reality...
>
>
> In terms of readability / conventions, I personally find this change a
> bit of a wash. I mean, I guess I originally implemented it as an array
> and I thought that was the most readable, but I like bitfields fine
> too. If everyone loves it then I won't object, but to me it feels like
> touching lines of code for something that's personal preference. ;-)
You're right that the .text and CPU time improvements were not my
target. I was focussed on stack usage, as that's a limited resource in
the kernel. I don't have any evidence that we would be close to any
limit, so it's tiny, and if you or anyone else have a strong opinion
that an array of booleans is better due to readability concerns, I can
drop this change. I only thought about those poor 7 bits in every bool
that sat there unused, feeling useless :-)
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 24 +---
> > 1 file changed, 13 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index c45420a50e73..1d1be791d5ba 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -557,9 +557,9 @@ static int ti_sn_bridge_calc_min_dp_rate_idx(struct
> > ti_sn_bridge *pdata)
> > return i;
> > }
> >
> > -static void ti_sn_bridge_read_valid_rates(struct ti_sn_bridge *pdata,
> > - bool rate_valid[])
> > +static unsigned int ti_sn_bridge_read_valid_rates(struct ti_sn_bridge
> > *pdata)
> > {
> > + unsigned int valid_rates = 0;
> > unsigned int rate_per_200khz;
> > unsigned int rate_mhz;
> > u8 dpcd_val;
> > @@ -599,13 +599,13 @@ static void ti_sn_bridge_read_valid_rates(struct
> > ti_sn_bridge *pdata,
> > j < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut);
> > j++) {
> > if (ti_sn_bridge_dp_rate_lut[j] == rate_mhz)
> > - rate_valid[j] = true;
> > + valid_rates |= BIT(j);
> > }
> > }
> >
> > for (i = 0; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut); i++) {
> > - if (rate_valid[i])
> > - return;
> > + if (valid_rates & BIT(i))
> > + return valid_rates;
> > }
> > DRM_DEV_ERROR(pdata->dev,
> > "No matching eDP rates in table; falling
> > back\n");
> > @@ -627,15 +627,17 @@ static void ti_sn_bridge_read_valid_rates(struct
> > ti_sn_bridge *pdata,
> > (int)dpcd_val);
> > fallthrough;
> > case DP_LINK_BW_5_4:
> > - rate_valid[7] = 1;
> > + valid_rates |= BIT(7);
> > fallthrough;
> > case DP_LINK_BW_2_7:
> > - rate_valid[4] = 1;
> > + valid_rates |= BIT(4);
> > fallthrough;
> > case DP_LINK_BW_1_62:
> > -
Re: [RFC PATCH 03/11] drm/bridge: ti-sn65dsi86: Unregister AUX adapter in remove()
Hi Doug,
On Tue, Mar 23, 2021 at 02:08:42PM -0700, Doug Anderson wrote:
> On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart wrote:
> >
> > The AUX adapter registered in probe() need to be unregistered in
> > remove(). Do so.
> >
> > Fixes: b814ec6d4535 ("drm/bridge: ti-sn65dsi86: Implement AUX channel")
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index da78a12e58b5..c45420a50e73 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -1307,6 +1307,9 @@ static int ti_sn_bridge_remove(struct i2c_client
> > *client)
> > return -EINVAL;
> >
> > kfree(pdata->edid);
> > +
> > + drm_dp_aux_unregister(>aux);
> > +
> > ti_sn_debugfs_remove(pdata);
> >
> > of_node_put(pdata->host_node);
>
> Good catch. One question, though. I know DRM sometimes has different
> conventions than the rest of the kernel, but I always look for the
> "remove" to be backwards of probe. That means that your code (and
> probably most of the remove function) should come _after_ the
> drm_bridge_remove(), right? ...since drm_bridge_add() was the last
> thing in probe then drm_bridge_remove() should be the first thing in
> remove?
I agree in theory, yes. However, in practice, if you remove a bridge
that is currently in use, all hell will break lose. And if the bridge
isn't being used, it makes no difference. Still, it's worth changing the
order of operations to move drm_bridge_remove() first, as it won't hurt
in any case and is logically better. It's not an issue introduced by
this series though, so how how about it on top, or in parallel ? You can
even submit a patch if you want :-)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 04/11] drm/bridge: ti-sn65dsi86: Use bitmask to store valid rates
Hi,
On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart
wrote:
>
> The valid rates are stored in an array of 8 booleans. Replace it with a
> bitmask to save space.
I'm curious: do you have evidence that this does anything useful? I
guess you're expecting it to save .text space, right? Stack usage and
execution time differences should be irrelevant--it's not in a
critical section and the difference should be tiny anyway. As far as
.text segment goes, it's not obvious to me that the compiler will use
fewer instructions to manipulate bits compared to booleans.
Doing a super simple "ls -ah" on vmlinux (unstripped):
Before: 224820232 bytes
After: 224820376 bytes
...so your change made it _bigger_. OK, so running "strip
--strip-debug" on those:
Before: 26599464 bytes
After: 26599464 bytes
...so exactly the same. I tried finding some evidence using "readelf -ah":
Before:
[ 2] .text PROGBITS ffc01001 0002
00b03508 WAX 0 0 65536
[ 3] .rodata PROGBITS ffc010b2 00b3
002e84b3 WAMS 0 0 4096
After:
[ 2] .text PROGBITS ffc01001 0002
00b03508 WAX 0 0 65536
[ 3] .rodata PROGBITS ffc010b2 00b3
002e84b3 WAMS 0 0 4096
Maybe you have some evidence showing an improvement? Ah, OK. I
disassembled ti_sn_bridge_enable() and your patch saves 12 bytes, but
I guess maybe alignment washes it out in reality...
In terms of readability / conventions, I personally find this change a
bit of a wash. I mean, I guess I originally implemented it as an array
and I thought that was the most readable, but I like bitfields fine
too. If everyone loves it then I won't object, but to me it feels like
touching lines of code for something that's personal preference. ;-)
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 24 +---
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index c45420a50e73..1d1be791d5ba 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -557,9 +557,9 @@ static int ti_sn_bridge_calc_min_dp_rate_idx(struct
> ti_sn_bridge *pdata)
> return i;
> }
>
> -static void ti_sn_bridge_read_valid_rates(struct ti_sn_bridge *pdata,
> - bool rate_valid[])
> +static unsigned int ti_sn_bridge_read_valid_rates(struct ti_sn_bridge *pdata)
> {
> + unsigned int valid_rates = 0;
> unsigned int rate_per_200khz;
> unsigned int rate_mhz;
> u8 dpcd_val;
> @@ -599,13 +599,13 @@ static void ti_sn_bridge_read_valid_rates(struct
> ti_sn_bridge *pdata,
> j < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut);
> j++) {
> if (ti_sn_bridge_dp_rate_lut[j] == rate_mhz)
> - rate_valid[j] = true;
> + valid_rates |= BIT(j);
> }
> }
>
> for (i = 0; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut); i++) {
> - if (rate_valid[i])
> - return;
> + if (valid_rates & BIT(i))
> + return valid_rates;
> }
> DRM_DEV_ERROR(pdata->dev,
> "No matching eDP rates in table; falling
> back\n");
> @@ -627,15 +627,17 @@ static void ti_sn_bridge_read_valid_rates(struct
> ti_sn_bridge *pdata,
> (int)dpcd_val);
> fallthrough;
> case DP_LINK_BW_5_4:
> - rate_valid[7] = 1;
> + valid_rates |= BIT(7);
> fallthrough;
> case DP_LINK_BW_2_7:
> - rate_valid[4] = 1;
> + valid_rates |= BIT(4);
> fallthrough;
> case DP_LINK_BW_1_62:
> - rate_valid[1] = 1;
> + valid_rates |= BIT(1);
> break;
> }
> +
> + return valid_rates;
> }
>
> static void ti_sn_bridge_set_video_timings(struct ti_sn_bridge *pdata)
> @@ -753,8 +755,8 @@ static int ti_sn_link_training(struct ti_sn_bridge
> *pdata, int dp_rate_idx,
> static void ti_sn_bridge_enable(struct drm_bridge *bridge)
> {
> struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> - bool rate_valid[ARRAY_SIZE(ti_sn_bridge_dp_rate_lut)] = { };
> const char *last_err_str = "No supported DP rate";
> + unsigned int valid_rates;
> int dp_rate_idx;
> unsigned int val;
> int ret = -EINVAL;
> @@ -793,13 +795,13 @@ static
Re: [RFC PATCH 03/11] drm/bridge: ti-sn65dsi86: Unregister AUX adapter in remove()
Hi,
On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart
wrote:
>
> The AUX adapter registered in probe() need to be unregistered in
> remove(). Do so.
>
> Fixes: b814ec6d4535 ("drm/bridge: ti-sn65dsi86: Implement AUX channel")
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index da78a12e58b5..c45420a50e73 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -1307,6 +1307,9 @@ static int ti_sn_bridge_remove(struct i2c_client
> *client)
> return -EINVAL;
>
> kfree(pdata->edid);
> +
> + drm_dp_aux_unregister(>aux);
> +
> ti_sn_debugfs_remove(pdata);
>
> of_node_put(pdata->host_node);
Good catch. One question, though. I know DRM sometimes has different
conventions than the rest of the kernel, but I always look for the
"remove" to be backwards of probe. That means that your code (and
probably most of the remove function) should come _after_ the
drm_bridge_remove(), right? ...since drm_bridge_add() was the last
thing in probe then drm_bridge_remove() should be the first thing in
remove?
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 02/11] drm/bridge: ti-sn65dsi86: Make enable GPIO optional
Hi, On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart wrote: > > The enable signal may not be controllable by the kernel. Make it > optional. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Douglas Anderson ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 01/11] dt-bindings: drm/bridge: ti-sn65dsi8: Make enable GPIO optional
Hi, On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart wrote: > > The SN65DSI86 EN pin can be hardwired to a high level, or connected to a > global reset signal, not controllable by the kernel. Make it optional in > those cases. > > Signed-off-by: Laurent Pinchart > --- > .../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Douglas Anderson ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages
On 3/23/21 8:52 PM, Williams, Dan J wrote:
On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellström (Intel) wrote:
TTM sets up huge page-table-entries both to system- and device
memory,
and we don't want gup to assume there are always valid backing struct
pages for these. For PTEs this is handled by setting the pte_special
bit,
but for the huge PUDs and PMDs, we have neither pmd_special nor
pud_special. Normally, huge TTM entries are identified by looking at
vma_is_special_huge(), but fast gup can't do that, so as an
alternative
define _devmap entries for which there are no backing dev_pagemap as
special, update documentation and make huge TTM entries _devmap,
after
verifying that there is no backing dev_pagemap.
Please do not abuse p{m,u}d_devmap like this. I'm in the process of
removing get_devpagemap() from the gup-fast path [1]. Instead there
should be space for p{m,u}d_special in the page table entries (at least
for x86-64). So the fix is to remove that old assumption that huge
pages can never be special.
[1]:
http://lore.kernel.org/r/161604050866.1463742.7759521510383551055.st...@dwillia2-desk3.amr.corp.intel.com
Hmm, yes with that patch it will obviously not work as intended.
Given that, I think we'll need to disable the TTM huge pages for now
until we can sort out and agree on using a page table entry bit.
Thanks,
/Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v9 32/70] drm/i915: Prepare for obj->mm.lock removal, v2.
On Tue, 2021-03-23 at 16:18 +, Matthew Auld wrote:
> On Tue, 23 Mar 2021 at 15:52, Maarten Lankhorst
> wrote:
> >
> > From: Thomas Hellström
> >
> > Stolen objects need to lock, and we may call put_pages when
> > refcount drops to 0, ensure all calls are handled correctly.
> >
> > Changes since v1:
> > - Rebase on top of upstream changes.
> >
> > Idea-from: Thomas Hellström
> > Signed-off-by: Maarten Lankhorst
> >
> > Signed-off-by: Thomas Hellström
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_object.h | 14 ++
> > drivers/gpu/drm/i915/gem/i915_gem_pages.c | 14 --
> > drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 12 +++-
> > 3 files changed, 33 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > index 983f2d4b2a85..74de195b57de 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > @@ -144,6 +144,20 @@ i915_gem_object_put(struct drm_i915_gem_object
> > *obj)
> >
> > #define assert_object_held(obj) dma_resv_assert_held((obj)-
> > >base.resv)
> >
> > +/*
> > + * If more than one potential simultaneous locker, assert held.
> > + */
> > +static inline void assert_object_held_shared(struct
> > drm_i915_gem_object *obj)
> > +{
> > + /*
> > + * Note mm list lookup is protected by
>
> What is meant with mm list here? Maybe just a stale comment?
That would be the i915->mm lists, (shrink and purge).
>
> > + * kref_get_unless_zero().
> > + */
> > + if (IS_ENABLED(CONFIG_LOCKDEP) &&
> > + kref_read(>base.refcount) > 0)
> > + lockdep_assert_held(>mm.lock);
> > +}
> > +
> > static inline int __i915_gem_object_lock(struct
> > drm_i915_gem_object *obj,
> > struct i915_gem_ww_ctx
> > *ww,
> > bool intr)
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > index a24617af3c93..2d0065fa6e80 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > @@ -19,7 +19,7 @@ void __i915_gem_object_set_pages(struct
> > drm_i915_gem_object *obj,
> > bool shrinkable;
> > int i;
> >
> > - lockdep_assert_held(>mm.lock);
> > + assert_object_held_shared(obj);
> >
> > if (i915_gem_object_is_volatile(obj))
> > obj->mm.madv = I915_MADV_DONTNEED;
> > @@ -70,6 +70,7 @@ void __i915_gem_object_set_pages(struct
> > drm_i915_gem_object *obj,
> > struct list_head *list;
> > unsigned long flags;
> >
> > + lockdep_assert_held(>mm.lock);
> > spin_lock_irqsave(>mm.obj_lock, flags);
> >
> > i915->mm.shrink_count++;
> > @@ -91,6 +92,8 @@ int i915_gem_object_get_pages(struct
> > drm_i915_gem_object *obj)
> > struct drm_i915_private *i915 = to_i915(obj->base.dev);
> > int err;
> >
> > + assert_object_held_shared(obj);
> > +
> > if (unlikely(obj->mm.madv != I915_MADV_WILLNEED)) {
> > drm_dbg(>drm,
> > "Attempting to obtain a purgeable
> > object\n");
> > @@ -118,6 +121,8 @@ int __i915_gem_object_get_pages(struct
> > drm_i915_gem_object *obj)
> > if (err)
> > return err;
> >
> > + assert_object_held_shared(obj);
> > +
> > if (unlikely(!i915_gem_object_has_pages(obj))) {
> > GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
> >
> > @@ -145,7 +150,7 @@ void i915_gem_object_truncate(struct
> > drm_i915_gem_object *obj)
> > /* Try to discard unwanted pages */
> > void i915_gem_object_writeback(struct drm_i915_gem_object *obj)
> > {
> > - lockdep_assert_held(>mm.lock);
> > + assert_object_held_shared(obj);
> > GEM_BUG_ON(i915_gem_object_has_pages(obj));
> >
> > if (obj->ops->writeback)
> > @@ -176,6 +181,8 @@ __i915_gem_object_unset_pages(struct
> > drm_i915_gem_object *obj)
> > {
> > struct sg_table *pages;
> >
> > + assert_object_held_shared(obj);
> > +
> > pages = fetch_and_zero(>mm.pages);
> > if (IS_ERR_OR_NULL(pages))
> > return pages;
> > @@ -203,6 +210,9 @@ int __i915_gem_object_put_pages_locked(struct
> > drm_i915_gem_object *obj)
> > if (i915_gem_object_has_pinned_pages(obj))
> > return -EBUSY;
> >
> > + /* May be called by shrinker from within get_pages() (on
> > another bo) */
> > + assert_object_held_shared(obj);
> > +
> > i915_gem_object_release_mmap_offset(obj);
> >
> > /*
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> > index 7cdb32d881d9..b0597de206de 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> > +++
Re: [PATCH] drm/fourcc: add Vivante TS modifiers
Am Montag, dem 22.03.2021 um 10:20 +0100 schrieb Lucas Stach: > Hi Christian, > > Am Montag, dem 22.03.2021 um 09:54 +0100 schrieb Christian Gmeiner: > > Am Sa., 20. März 2021 um 20:11 Uhr schrieb Daniel Vetter : > > > > > > On Sat, Mar 20, 2021 at 10:28 AM Christian Gmeiner > > > wrote: > > > > > > > > Hi Lucas > > > > > > > > Am Fr., 19. März 2021 um 20:06 Uhr schrieb Lucas Stach > > > > : > > > > > > > > > > Vivante TS (tile-status) buffer modifiers. They can be combined with > > > > > all of > > > > > the Vivante color buffer tiling modifiers, so they are kind of a > > > > > modifier > > > > > modifier. If a TS modifier is present we have a additional plane for > > > > > the > > > > > TS buffer and the modifier defines the layout of this TS buffer. > > > > > > > > > > > > > I am unsure why you want to have the TS modifiers in drm_fourcc.h. Can > > > > you share some insight on this? > > > > > > It's the official registry for drm_fourcc codes and drm modifiers. > > > Whether the kernel ever uses it or not doesn't matter. > > > > Fair point.. but I do not see any usage of these TS modifiers in mesa > > - that's why I am asking. > > I have a Mesa series using those modifiers, which I'm currently > rebasing and will be posted shortly. However, the way things work is: > first get the modifier into drm_fourcc.h, then merge any code using the > new modifiers, so I figured it would be fair game to post this patch > before I fully finished reworking the Mesa series. Rebasing and re-testing did take a bit more time than I expected, but userspace bits are now available at: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9780 I also have patches for DCSS to enable compression support all the way to the display on i.MX8M, but those also need rebasing and re-testing. I'll send them out when ready. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 00/21] Host1x sync point UAPI should not be used for tracking DRM jobs
23.03.2021 22:57, Dmitry Osipenko пишет:
> 23.03.2021 21:21, Thierry Reding пишет:
>> On Sat, Feb 27, 2021 at 02:19:39PM +0300, Dmitry Osipenko wrote:
>>> 03.02.2021 14:18, Mikko Perttunen пишет:
>>> ...
> I'll need more time to think about it.
>
How about something like this:
Turn the syncpt_incr field back into an array of structs like
#define DRM_TEGRA_SUBMIT_SYNCPT_INCR_REPLACE_SYNCOBJ (1<<0)
#define DRM_TEGRA_SUBMIT_SYNCPT_INCR_PATCH_DYNAMIC_SYNCPT (1<<1)
struct drm_tegra_submit_syncpt_incr {
/* can be left as zero if using dynamic syncpt */
__u32 syncpt_id;
__u32 flags;
struct {
__u32 syncobj;
__u32 value;
} fence;
/* patch word as such:
* *word = *word | (syncpt_id << shift)
*/
struct {
__u32 gather_offset_words;
__u32 shift;
} patch;
};
So this will work similarly to the buffer reloc system; the kernel
driver will allocate a job syncpoint and patch in the syncpoint ID if
requested, and allows outputting syncobjs for each increment.
>>>
>>> I haven't got any great ideas so far, but it feels that will be easier
>>> and cleaner if we could have separate job paths (and job IOCTLS) based
>>> on hardware generation since the workloads a too different. The needs of
>>> a newer h/w are too obscure for me and absence of userspace code,
>>> firmware sources and full h/w documentation do not help.
>>>
>>> There still should be quite a lot to share, but things like
>>> mapping-to-channel and VM sync points are too far away from older h/w,
>>> IMO. This means that code path before drm-sched and path for job-timeout
>>> handling should be separate.
>>>
>>> Maybe later on it will become cleaner that we actually could unify it
>>> all nicely, but for now it doesn't look like a good idea to me.
>>
>> Sorry for jumping in rather randomly here and elsewhere, but it's been a
>> long time since the discussion and I just want to share my thoughts on a
>> couple of topics in order to hopefully help move this forward somehow.
>>
>> For UAPI, "unifying it later" doesn't really work.
>
> Of course I meant a "later version of this series" :) Sorry for not
> making it clear.
>
>> So I think the only
>> realistic option is to make a best attempt at getting the UABI right so
>> that it works for all existing use-cases and ideally perhaps even as of
>> yet unknown use-cases in the future. As with all APIs this means that
>> there's going to be a need to abstract away some of the hardware details
>> so that we don't have to deal with too many low-level details in
>> userspace, because otherwise the UAPI is just going to be a useless
>> mess.
>>
>> I think a proposal such as the above to allow both implicit and explicit
>> syncpoints makes sense. For what it's worth, it's fairly similar to what
>> we had come up with last time we tried destaging the ABI, although back
>> at the time I'm not sure we had even considered explicit syncpoint usage
>> yet. I think where reasonably possible this kind of optional behaviour
>> is acceptable, but I don't think having two completely separate paths is
>> going to help in any way. If anything it's just going to make it more
>> difficult to maintain the code and get it to a usable state in the first
>> place.
>>
>> Like I said elsewhere, the programming model for host1x hasn't changed
>> since Tegra20. It's rather evolved and gained a couple more features,
>> but that doesn't change anything about how userspace uses it.
>
> Not having a complete control over sync points state is a radical
> change, IMO. I prefer not to use this legacy and error-prone way of sync
> points handling at least for older h/w where it's possible to do. This
> is what downstream driver did 10 years ago and what it still continues
> to do. I was very happy to move away from this unnecessary complication
> in the experimental grate-kernel driver and I think this will be great
> to do in the mainline as well.
>
> The need to map buffers explicitly is also a big difference. The need to
> map BO for each channel is a quite big over-complication as we already
> found out in the current version of UAPI.
>
> Alright, perhaps the mapping could improved for older userspace if we
> will move away from a per-channel contexts to a single DRM context like
> I already was suggesting to Mikko before. I.e. instead of mapping BO "to
> a channel", we will need to map BO "to h/w clients" within the DRM
> context. This should allow older userspace to create a single mapping
> for all channels/clients using a single IOCTL and then to have a single
> "mapping handle" to care about. Objections?
>
I just recalled that Mikko didn't like *not* to have the per-channel
contexts, saying that it should be good to have for later SoCs.
We could have a DRM context and channel contexts within the
Re: [PATCH v5 00/21] Host1x sync point UAPI should not be used for tracking DRM jobs
23.03.2021 21:21, Thierry Reding пишет:
> On Sat, Feb 27, 2021 at 02:19:39PM +0300, Dmitry Osipenko wrote:
>> 03.02.2021 14:18, Mikko Perttunen пишет:
>> ...
I'll need more time to think about it.
>>>
>>> How about something like this:
>>>
>>> Turn the syncpt_incr field back into an array of structs like
>>>
>>> #define DRM_TEGRA_SUBMIT_SYNCPT_INCR_REPLACE_SYNCOBJ (1<<0)
>>> #define DRM_TEGRA_SUBMIT_SYNCPT_INCR_PATCH_DYNAMIC_SYNCPT (1<<1)
>>>
>>> struct drm_tegra_submit_syncpt_incr {
>>> /* can be left as zero if using dynamic syncpt */
>>> __u32 syncpt_id;
>>> __u32 flags;
>>>
>>> struct {
>>> __u32 syncobj;
>>> __u32 value;
>>> } fence;
>>>
>>> /* patch word as such:
>>> * *word = *word | (syncpt_id << shift)
>>> */
>>> struct {
>>> __u32 gather_offset_words;
>>> __u32 shift;
>>> } patch;
>>> };
>>>
>>> So this will work similarly to the buffer reloc system; the kernel
>>> driver will allocate a job syncpoint and patch in the syncpoint ID if
>>> requested, and allows outputting syncobjs for each increment.
>>
>> I haven't got any great ideas so far, but it feels that will be easier
>> and cleaner if we could have separate job paths (and job IOCTLS) based
>> on hardware generation since the workloads a too different. The needs of
>> a newer h/w are too obscure for me and absence of userspace code,
>> firmware sources and full h/w documentation do not help.
>>
>> There still should be quite a lot to share, but things like
>> mapping-to-channel and VM sync points are too far away from older h/w,
>> IMO. This means that code path before drm-sched and path for job-timeout
>> handling should be separate.
>>
>> Maybe later on it will become cleaner that we actually could unify it
>> all nicely, but for now it doesn't look like a good idea to me.
>
> Sorry for jumping in rather randomly here and elsewhere, but it's been a
> long time since the discussion and I just want to share my thoughts on a
> couple of topics in order to hopefully help move this forward somehow.
>
> For UAPI, "unifying it later" doesn't really work.
Of course I meant a "later version of this series" :) Sorry for not
making it clear.
> So I think the only
> realistic option is to make a best attempt at getting the UABI right so
> that it works for all existing use-cases and ideally perhaps even as of
> yet unknown use-cases in the future. As with all APIs this means that
> there's going to be a need to abstract away some of the hardware details
> so that we don't have to deal with too many low-level details in
> userspace, because otherwise the UAPI is just going to be a useless
> mess.
>
> I think a proposal such as the above to allow both implicit and explicit
> syncpoints makes sense. For what it's worth, it's fairly similar to what
> we had come up with last time we tried destaging the ABI, although back
> at the time I'm not sure we had even considered explicit syncpoint usage
> yet. I think where reasonably possible this kind of optional behaviour
> is acceptable, but I don't think having two completely separate paths is
> going to help in any way. If anything it's just going to make it more
> difficult to maintain the code and get it to a usable state in the first
> place.
>
> Like I said elsewhere, the programming model for host1x hasn't changed
> since Tegra20. It's rather evolved and gained a couple more features,
> but that doesn't change anything about how userspace uses it.
Not having a complete control over sync points state is a radical
change, IMO. I prefer not to use this legacy and error-prone way of sync
points handling at least for older h/w where it's possible to do. This
is what downstream driver did 10 years ago and what it still continues
to do. I was very happy to move away from this unnecessary complication
in the experimental grate-kernel driver and I think this will be great
to do in the mainline as well.
The need to map buffers explicitly is also a big difference. The need to
map BO for each channel is a quite big over-complication as we already
found out in the current version of UAPI.
Alright, perhaps the mapping could improved for older userspace if we
will move away from a per-channel contexts to a single DRM context like
I already was suggesting to Mikko before. I.e. instead of mapping BO "to
a channel", we will need to map BO "to h/w clients" within the DRM
context. This should allow older userspace to create a single mapping
for all channels/clients using a single IOCTL and then to have a single
"mapping handle" to care about. Objections?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] drm/bridge: ti-sn65dsi86: Read EDID blob over DDC
Hi Doug,
On Tue, Mar 23, 2021 at 12:07:27PM -0700, Doug Anderson wrote:
> On Mon, Mar 22, 2021 at 8:17 PM Stephen Boyd wrote:
> >
> > Quoting Laurent Pinchart (2021-03-17 17:20:43)
> > > Hi Stephen,
> > >
> > > Reviving a bit of an old thread, for a question.
> > >
> > > On Mon, Nov 02, 2020 at 10:11:43AM -0800, Stephen Boyd wrote:
> > > > @@ -265,6 +267,23 @@ connector_to_ti_sn_bridge(struct drm_connector
> > > > *connector)
> > > > static int ti_sn_bridge_connector_get_modes(struct drm_connector
> > > > *connector)
> > > > {
> > > > struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector);
> > > > + struct edid *edid = pdata->edid;
> > > > + int num, ret;
> > > > +
> > > > + if (!edid) {
> > > > + pm_runtime_get_sync(pdata->dev);
> > > > + edid = pdata->edid = drm_get_edid(connector,
> > > > >aux.ddc);
> > > > + pm_runtime_put(pdata->dev);
> > >
> > > Is there any specific reason to use the indirect access method, compared
> > > to the direct method that translates access to an I2C ancillary address
> > > to an I2C-over-AUX transaction (see page 20 of SLLSEH2B) ? The direct
> > > method seems it would be more efficient.
> >
> > No I don't think it matters. I was just using the existing support code
> > that Sean wrote instead of digging into the details. Maybe Sean ran into
> > something earlier and abandoned that approach?
>
> From reading the docs, it sounds as if there _could_ be a reason to
> use the indirect method. Specifically if the i2c host that the bridge
> is on doesn't support clock stretching then the direct method wouldn't
> work according to the docs. Is that something that we'd have to
> reasonably worry about?
I'm not sure. I'm going through BSP code that uses the direct method,
and I was wondering if it was just an implementation detail. Once I get
the display working on this board, I'll try to find time to compare the
two methods, to see if there's a significatant performance improvement
from the direct method. If there isn't, I won't bother.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages
On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellström (Intel) wrote:
> TTM sets up huge page-table-entries both to system- and device
> memory,
> and we don't want gup to assume there are always valid backing struct
> pages for these. For PTEs this is handled by setting the pte_special
> bit,
> but for the huge PUDs and PMDs, we have neither pmd_special nor
> pud_special. Normally, huge TTM entries are identified by looking at
> vma_is_special_huge(), but fast gup can't do that, so as an
> alternative
> define _devmap entries for which there are no backing dev_pagemap as
> special, update documentation and make huge TTM entries _devmap,
> after
> verifying that there is no backing dev_pagemap.
Please do not abuse p{m,u}d_devmap like this. I'm in the process of
removing get_devpagemap() from the gup-fast path [1]. Instead there
should be space for p{m,u}d_special in the page table entries (at least
for x86-64). So the fix is to remove that old assumption that huge
pages can never be special.
[1]:
http://lore.kernel.org/r/161604050866.1463742.7759521510383551055.st...@dwillia2-desk3.amr.corp.intel.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/18] vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV
On Tue, Mar 23, 2021 at 08:26:30PM +0100, Christoph Hellwig wrote: > On Tue, Mar 23, 2021 at 02:55:32PM -0300, Jason Gunthorpe wrote: > > Ideally all of this would be moved to kvmgt.c, but it is entangled with > > the rest of the "generic" code in an odd way. Thus put in a kconfig > > dependency so we don't get randconfig failures when the next patch creates > > a link time dependency related to the use of MDEV_TYPE. > > Ideally that weird struct intel_gvt_mpt would go away entirely. But > that is clearly out of scope for this patchset.. Yes.. Maybe someone from Intel will take that on, along with that other note you had. Compared to all the others this driver is quite twisty! Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] dma-buf: Add an API for exporting sync files (v8)
On Tue, Mar 23, 2021 at 2:06 PM Simon Ser wrote: > > From a user-space point-of-view, this looks super useful! The uAPI sounds > good to me. > > Acked-by: Simon Ser > > Would be nice to have some short docs as well. Here's an example of a > patch adding some docs for an ioctl [1], if you aren't familiar with > that. I think just some basic stuff (description, which parameters are > in/out, what the flags are) would be great. Good call. v9 will have docs. --Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used
HI,
On 3/23/21 8:13 PM, Hans de Goede wrote:
> Hi,
>
> On 3/23/21 6:51 PM, Ville Syrjälä wrote:
>> On Tue, Mar 23, 2021 at 06:29:53PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 3/22/21 10:47 PM, Ville Syrjälä wrote:
On Mon, Mar 22, 2021 at 10:28:06PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/22/21 9:59 PM, Ville Syrjälä wrote:
>> On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
>>> On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
Hi,
On 3/1/21 4:43 PM, Hans de Goede wrote:
> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> Predia Basic tablet would no longer properly light up after reboot.
>
> The backlight still turns back on after reboot, but the LCD shows an
> all black display. The display is also all black during the time that
> EFI / the GOP is managing it, so e.g. the grub menu also is not
> visible.
>
> In this scenario the panel is initialized so that it appears to be
> working
> and the fastboot code skips doing a modeset. Forcing a modeset by
> doing a
> chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
> /sys/class/graphics/fb0/blank causes the panel to work again.
>
> Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown()
> into
> a no-op when set; and set this on vlv/chv devices when a DSI panel is
> detected, to work around this.
>
> Admittedly this is a bit of a big hammer, but these platforms have
> been
> around for quite some time now and they have always worked fine
> without
> the new behavior to shutdown everything on shutdown/reboot. This
> approach
> simply disables the recently introduced new shutdown behavior in this
> specific case where it is known to cause problems. Which is a nice and
> simple way to deal with this.
>
> Signed-off-by: Hans de Goede
Ping? Since sending this patch I've been seeing the issue addressed by
this on variour other CHT based devices too.
So we have various devices suffering from a black screen after reboot
now. This is pretty serious usability regression.
As such it would be good to get this reviewed, or another fix proposed.
>>>
>>> For the quirks we try to limit them to very specific vendor and model
>>> ids,
>>> so I wonder if it would be possible to get this information in here
>>> instead
>>> to all the vlv with dsi...
>>>
>>> Or avoid the quirk "infra" and skip to all vlv with active dsi?!
>>>
>>> Jani?
>>> Ville?
>>
>> We need to figure out why the panel doesn't start up again.
>
> Note it is the GOP which fails to light it up again. I think we turn
> something
> off, which after a power-on-reset is on, so the GOP expects it to be on.
Hmm. Do any of the reboot=warm|cold|whatever knobs make a difference?
Are there any fast vs. slow boot settings in the BIOS setup?
>>>
>>> Ok, so I was running the tests which you requested and during this
>>> I managed to find the real problem.
>>>
>>> What happens on reboot is a really quick panel off/on cycle and that is
>>> causing the issue.
>>>
>>> I can reproduce this by doing:
>>>
>>> chvt 3; echo 1 > /sys/class/graphics/fb0/blank; echo 0 >
>>> /sys/class/graphics/fb0/blank
>>>
>>> The problem is that we're not honoring panel_pwr_cycle_delay because
>>> intel_dsi_msleep() is a no-op on devices with a MIPI-sequences version >= 3,
>>> because those sequences already contain the necessary delays, at least
>>> for most of the steps during the on/off sequences. It seems that the
>>> pwr-cycle delay is not handled by those v3+ sequences.
>>>
>>> So fixing this is as simple as switching to a regular msleep for the
>>> intel_dsi->panel_pwr_cycle_delay.
>>>
>>> Once we do that it would be good (for e.g. suspend/resume speed) to fix:
>>>
>>> /*
>>> * FIXME As we do with eDP, just make a note of the time here
>>> * and perform the wait before the next panel power on.
>>> */
>>>
>>> Which sits right above that msleep. Since I have a reproducer now which
>>> shows when the sleep is too short, it should now be easy ti fix the FIXME
>>> and test that the fix works. I'll do this in a separate patch and send
>>> a patch-set with both patches replacing this patch.
>>
>> Awesome. I'm really happy to avoid any quirks and whatnot since
>> they always come back to bite you later. Thanks for digging into it.
>>
>> Speaking of DSI, you wouldn't happen to have one these machines:
>> https://gitlab.freedesktop.org/drm/intel/-/issues/2698 ?
>
> Sorry I don't have any 10" Dell
Re: [PATCH] drm/amdgpu: Ensure that the modifier requested is supported by plane.
On Tue, Mar 23, 2021 at 11:02 AM Alex Deucher wrote:
>
> On Wed, Mar 10, 2021 at 11:15 AM Mark Yacoub wrote:
> >
> > From: Mark Yacoub
> >
> > On initializing the framebuffer, call drm_any_plane_has_format to do a
> > check if the modifier is supported. drm_any_plane_has_format calls
> > dm_plane_format_mod_supported which is extended to validate that the
> > modifier is on the list of the plane's supported modifiers.
> >
> > The bug was caught using igt-gpu-tools test:
> > kms_addfb_basic.addfb25-bad-modifier
> >
> > Tested on ChromeOS Zork by turning on the display, running an overlay
> > test, and running a YT video.
> >
> > Cc: Alex Deucher
> > Cc: Bas Nieuwenhuizen
> > Signed-off-by: default avatarMark Yacoub
>
> I'm not an expert with modifiers yet. Will this break chips which
> don't currently support modifiers?
No it shouldn't. When you don't support modifiers yet, your will
default to Linear Modifier (DRM_FORMAT_MOD_LINEAR),
which is later checked in amdgpu_dm.c::dm_plane_format_mod_supported()
/*
* We always have to allow this modifier, because core DRM still
* checks LINEAR support if userspace does not provide modifiers.
*/
if (modifier == DRM_FORMAT_MOD_LINEAR)
return true;
>
> Alex
>
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 13 +
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +
> > 2 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> > index afa5f8ad0f563..a947b5aa420d2 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> > @@ -908,6 +908,19 @@ int amdgpu_display_gem_fb_verify_and_init(
> > _fb_funcs);
> > if (ret)
> > goto err;
> > + /* Verify that the modifier is supported. */
> > + if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
> > + mode_cmd->modifier[0])) {
> > + struct drm_format_name_buf format_name;
> > + drm_dbg_kms(dev,
> > + "unsupported pixel format %s / modifier
> > 0x%llx\n",
> > + drm_get_format_name(mode_cmd->pixel_format,
> > + _name),
> > + mode_cmd->modifier[0]);
> > +
> > + ret = -EINVAL;
> > + goto err;
> > + }
> >
> > ret = amdgpu_display_framebuffer_init(dev, rfb, mode_cmd, obj);
> > if (ret)
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 961abf1cf040c..21314024a83ce 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -3939,6 +3939,7 @@ static bool dm_plane_format_mod_supported(struct
> > drm_plane *plane,
> > {
> > struct amdgpu_device *adev = drm_to_adev(plane->dev);
> > const struct drm_format_info *info = drm_format_info(format);
> > + int i;
> >
> > enum dm_micro_swizzle microtile =
> > modifier_gfx9_swizzle_mode(modifier) & 3;
> >
> > @@ -3952,6 +3953,14 @@ static bool dm_plane_format_mod_supported(struct
> > drm_plane *plane,
> > if (modifier == DRM_FORMAT_MOD_LINEAR)
> > return true;
> >
> > + /* Check that the modifier is on the list of the plane's supported
> > modifiers. */
> > + for (i = 0; i < plane->modifier_count; i++) {
> > + if (modifier == plane->modifiers[i])
> > + break;
> > + }
> > + if (i == plane->modifier_count)
> > + return false;
> > +
> > /*
> > * The arbitrary tiling support for multiplane formats has not been
> > hooked
> > * up.
> > --
> > 2.30.1.766.gb4fecdf3b7-goog
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used
Hi,
On 3/23/21 6:51 PM, Ville Syrjälä wrote:
> On Tue, Mar 23, 2021 at 06:29:53PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 3/22/21 10:47 PM, Ville Syrjälä wrote:
>>> On Mon, Mar 22, 2021 at 10:28:06PM +0100, Hans de Goede wrote:
Hi,
On 3/22/21 9:59 PM, Ville Syrjälä wrote:
> On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
>> On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 3/1/21 4:43 PM, Hans de Goede wrote:
After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
displays gracefully on reboot"), the DSI panel on a Cherry Trail based
Predia Basic tablet would no longer properly light up after reboot.
The backlight still turns back on after reboot, but the LCD shows an
all black display. The display is also all black during the time that
EFI / the GOP is managing it, so e.g. the grub menu also is not
visible.
In this scenario the panel is initialized so that it appears to be
working
and the fastboot code skips doing a modeset. Forcing a modeset by
doing a
chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
/sys/class/graphics/fb0/blank causes the panel to work again.
Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
a no-op when set; and set this on vlv/chv devices when a DSI panel is
detected, to work around this.
Admittedly this is a bit of a big hammer, but these platforms have been
around for quite some time now and they have always worked fine without
the new behavior to shutdown everything on shutdown/reboot. This
approach
simply disables the recently introduced new shutdown behavior in this
specific case where it is known to cause problems. Which is a nice and
simple way to deal with this.
Signed-off-by: Hans de Goede
>>>
>>> Ping? Since sending this patch I've been seeing the issue addressed by
>>> this on variour other CHT based devices too.
>>>
>>> So we have various devices suffering from a black screen after reboot
>>> now. This is pretty serious usability regression.
>>>
>>> As such it would be good to get this reviewed, or another fix proposed.
>>
>> For the quirks we try to limit them to very specific vendor and model
>> ids,
>> so I wonder if it would be possible to get this information in here
>> instead
>> to all the vlv with dsi...
>>
>> Or avoid the quirk "infra" and skip to all vlv with active dsi?!
>>
>> Jani?
>> Ville?
>
> We need to figure out why the panel doesn't start up again.
Note it is the GOP which fails to light it up again. I think we turn
something
off, which after a power-on-reset is on, so the GOP expects it to be on.
>>>
>>> Hmm. Do any of the reboot=warm|cold|whatever knobs make a difference?
>>> Are there any fast vs. slow boot settings in the BIOS setup?
>>
>> Ok, so I was running the tests which you requested and during this
>> I managed to find the real problem.
>>
>> What happens on reboot is a really quick panel off/on cycle and that is
>> causing the issue.
>>
>> I can reproduce this by doing:
>>
>> chvt 3; echo 1 > /sys/class/graphics/fb0/blank; echo 0 >
>> /sys/class/graphics/fb0/blank
>>
>> The problem is that we're not honoring panel_pwr_cycle_delay because
>> intel_dsi_msleep() is a no-op on devices with a MIPI-sequences version >= 3,
>> because those sequences already contain the necessary delays, at least
>> for most of the steps during the on/off sequences. It seems that the
>> pwr-cycle delay is not handled by those v3+ sequences.
>>
>> So fixing this is as simple as switching to a regular msleep for the
>> intel_dsi->panel_pwr_cycle_delay.
>>
>> Once we do that it would be good (for e.g. suspend/resume speed) to fix:
>>
>> /*
>> * FIXME As we do with eDP, just make a note of the time here
>> * and perform the wait before the next panel power on.
>> */
>>
>> Which sits right above that msleep. Since I have a reproducer now which
>> shows when the sleep is too short, it should now be easy ti fix the FIXME
>> and test that the fix works. I'll do this in a separate patch and send
>> a patch-set with both patches replacing this patch.
>
> Awesome. I'm really happy to avoid any quirks and whatnot since
> they always come back to bite you later. Thanks for digging into it.
>
> Speaking of DSI, you wouldn't happen to have one these machines:
> https://gitlab.freedesktop.org/drm/intel/-/issues/2698 ?
Sorry I don't have any 10" Dell models in my collection.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Re: [PATCH] drm/ttm: stop warning on TT shrinker failure
On Tue 23-03-21 14:56:54, Christian König wrote: > Am 23.03.21 um 14:41 schrieb Michal Hocko: [...] > > Anyway, I am wondering whether the overall approach is sound. Why don't > > you simply use shmem as your backing storage from the beginning and pin > > those pages if they are used by the device? > > Yeah, that is exactly what the Intel guys are doing for their integrated > GPUs :) > > Problem is for TTM I need to be able to handle dGPUs and those have all > kinds of funny allocation restrictions. In other words I need to guarantee > that the allocated memory is coherent accessible to the GPU without using > SWIOTLB. > > The simple case is that the device can only do DMA32, but you also got > device which can only do 40bits or 48bits. > > On top of that you also got AGP, CMA and stuff like CPU cache behavior > changes (write back vs. write through, vs. uncached). OK, so the underlying problem seems to be that gfp mask (thus mapping_gfp_mask) cannot really reflect your requirements, right? Would it help if shmem would allow to provide an allocation callback to override alloc_page_vma which is used currently? I am pretty sure there will be more to handle but going through shmem for the whole life time is just so much easier to reason about than some tricks to abuse shmem just for the swapout path. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] drm/bridge: ti-sn65dsi86: Read EDID blob over DDC
Hi,
On Mon, Mar 22, 2021 at 8:17 PM Stephen Boyd wrote:
>
> Quoting Laurent Pinchart (2021-03-17 17:20:43)
> > Hi Stephen,
> >
> > Reviving a bit of an old thread, for a question.
> >
> > On Mon, Nov 02, 2020 at 10:11:43AM -0800, Stephen Boyd wrote:
> > > @@ -265,6 +267,23 @@ connector_to_ti_sn_bridge(struct drm_connector
> > > *connector)
> > > static int ti_sn_bridge_connector_get_modes(struct drm_connector
> > > *connector)
> > > {
> > > struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector);
> > > + struct edid *edid = pdata->edid;
> > > + int num, ret;
> > > +
> > > + if (!edid) {
> > > + pm_runtime_get_sync(pdata->dev);
> > > + edid = pdata->edid = drm_get_edid(connector,
> > > >aux.ddc);
> > > + pm_runtime_put(pdata->dev);
> >
> > Is there any specific reason to use the indirect access method, compared
> > to the direct method that translates access to an I2C ancillary address
> > to an I2C-over-AUX transaction (see page 20 of SLLSEH2B) ? The direct
> > method seems it would be more efficient.
> >
>
> No I don't think it matters. I was just using the existing support code
> that Sean wrote instead of digging into the details. Maybe Sean ran into
> something earlier and abandoned that approach?
>From reading the docs, it sounds as if there _could_ be a reason to
use the indirect method. Specifically if the i2c host that the bridge
is on doesn't support clock stretching then the direct method wouldn't
work according to the docs. Is that something that we'd have to
reasonably worry about?
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] dma-buf: Add an API for exporting sync files (v8)
>From a user-space point-of-view, this looks super useful! The uAPI sounds good to me. Acked-by: Simon Ser Would be nice to have some short docs as well. Here's an example of a patch adding some docs for an ioctl [1], if you aren't familiar with that. I think just some basic stuff (description, which parameters are in/out, what the flags are) would be great. [1]: https://patchwork.freedesktop.org/patch/401951/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] drm/tegra: dc: Implement hardware cursor on Tegra186 and later
23.03.2021 21:24, Thierry Reding пишет:
> On Tue, Mar 23, 2021 at 08:57:42PM +0300, Dmitry Osipenko wrote:
>> 23.03.2021 18:54, Thierry Reding пишет:
>>> @@ -920,15 +934,42 @@ static void tegra_cursor_atomic_update(struct
>>> drm_plane *plane,
>>> value = tegra_dc_readl(dc, DC_DISP_BLEND_CURSOR_CONTROL);
>>> value &= ~CURSOR_DST_BLEND_MASK;
>>> value &= ~CURSOR_SRC_BLEND_MASK;
>>> - value |= CURSOR_MODE_NORMAL;
>>> +
>>> + if (dc->soc->has_nvdisplay)
>>> + value &= ~CURSOR_COMPOSITION_MODE_XOR;
>>> + else
>>> + value |= CURSOR_MODE_NORMAL;
>>> +
>>> value |= CURSOR_DST_BLEND_NEG_K1_TIMES_SRC;
>>> value |= CURSOR_SRC_BLEND_K1_TIMES_SRC;
>>> value |= CURSOR_ALPHA;
>>> tegra_dc_writel(dc, value, DC_DISP_BLEND_CURSOR_CONTROL);
>>>
>>> + /* nvdisplay relies on software for clipping */
>>> + if (dc->soc->has_nvdisplay) {
>>
>> But coordinates already should be clipped by
>> drm_atomic_helper_check_plane_state().
>
> Yes, and the driver goes on to use the clipped coordinates later on in
> this function.
I see now what it does, looks okay.
Minor nit: the i/j aren't very expressive names, something like sx/sy
sw/sh should be a bit more appropriate naming.
You could also make use of drm_rect_width/height helpers.
But this doesn't deserve a v2 if there is nothing more important to improve.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/doc: Add RFC section
On Tue, Mar 23, 2021 at 6:55 PM Jason Ekstrand wrote: > > On Tue, Mar 23, 2021 at 12:01 PM Simon Ser wrote: > > > > Side note: I feel like we could have better lines of communication > > between kernel devs and user-space devs. The new uAPI requirements seem > > to be a high barrier to entry for kernel devs. However sometimes > > user-space devs might be interested in helping out with the user-space > > part… > > > > Maybe it would be good to CC e.g. wayland-devel for new RFCs, so that > > user-space devs can jump in if they're interested. And also provide > > feedback, since new uAPI is hard to spot in the sea of messages in > > dri-devel. > > That's a good suggestion. CCing wayland-dev or mesa-dev, as > appropriate, with such docs patches sounds like a good idea. I'm not > sure where we would put that in here but it would be good to call out. I'll add a suggestion to that extend, it's a good one. -Daniel -- 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 4/9] drm/tegra: dc: Implement hardware cursor on Tegra186 and later
On Tue, Mar 23, 2021 at 08:57:42PM +0300, Dmitry Osipenko wrote:
> 23.03.2021 18:54, Thierry Reding пишет:
> > @@ -920,15 +934,42 @@ static void tegra_cursor_atomic_update(struct
> > drm_plane *plane,
> > value = tegra_dc_readl(dc, DC_DISP_BLEND_CURSOR_CONTROL);
> > value &= ~CURSOR_DST_BLEND_MASK;
> > value &= ~CURSOR_SRC_BLEND_MASK;
> > - value |= CURSOR_MODE_NORMAL;
> > +
> > + if (dc->soc->has_nvdisplay)
> > + value &= ~CURSOR_COMPOSITION_MODE_XOR;
> > + else
> > + value |= CURSOR_MODE_NORMAL;
> > +
> > value |= CURSOR_DST_BLEND_NEG_K1_TIMES_SRC;
> > value |= CURSOR_SRC_BLEND_K1_TIMES_SRC;
> > value |= CURSOR_ALPHA;
> > tegra_dc_writel(dc, value, DC_DISP_BLEND_CURSOR_CONTROL);
> >
> > + /* nvdisplay relies on software for clipping */
> > + if (dc->soc->has_nvdisplay) {
>
> But coordinates already should be clipped by
> drm_atomic_helper_check_plane_state().
Yes, and the driver goes on to use the clipped coordinates later on in
this function.
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 v5 00/21] Host1x sync point UAPI should not be used for tracking DRM jobs
On Sat, Feb 27, 2021 at 02:19:39PM +0300, Dmitry Osipenko wrote:
> 03.02.2021 14:18, Mikko Perttunen пишет:
> ...
> >> I'll need more time to think about it.
> >>
> >
> > How about something like this:
> >
> > Turn the syncpt_incr field back into an array of structs like
> >
> > #define DRM_TEGRA_SUBMIT_SYNCPT_INCR_REPLACE_SYNCOBJ (1<<0)
> > #define DRM_TEGRA_SUBMIT_SYNCPT_INCR_PATCH_DYNAMIC_SYNCPT (1<<1)
> >
> > struct drm_tegra_submit_syncpt_incr {
> > /* can be left as zero if using dynamic syncpt */
> > __u32 syncpt_id;
> > __u32 flags;
> >
> > struct {
> > __u32 syncobj;
> > __u32 value;
> > } fence;
> >
> > /* patch word as such:
> > * *word = *word | (syncpt_id << shift)
> > */
> > struct {
> > __u32 gather_offset_words;
> > __u32 shift;
> > } patch;
> > };
> >
> > So this will work similarly to the buffer reloc system; the kernel
> > driver will allocate a job syncpoint and patch in the syncpoint ID if
> > requested, and allows outputting syncobjs for each increment.
>
> I haven't got any great ideas so far, but it feels that will be easier
> and cleaner if we could have separate job paths (and job IOCTLS) based
> on hardware generation since the workloads a too different. The needs of
> a newer h/w are too obscure for me and absence of userspace code,
> firmware sources and full h/w documentation do not help.
>
> There still should be quite a lot to share, but things like
> mapping-to-channel and VM sync points are too far away from older h/w,
> IMO. This means that code path before drm-sched and path for job-timeout
> handling should be separate.
>
> Maybe later on it will become cleaner that we actually could unify it
> all nicely, but for now it doesn't look like a good idea to me.
Sorry for jumping in rather randomly here and elsewhere, but it's been a
long time since the discussion and I just want to share my thoughts on a
couple of topics in order to hopefully help move this forward somehow.
For UAPI, "unifying it later" doesn't really work. So I think the only
realistic option is to make a best attempt at getting the UABI right so
that it works for all existing use-cases and ideally perhaps even as of
yet unknown use-cases in the future. As with all APIs this means that
there's going to be a need to abstract away some of the hardware details
so that we don't have to deal with too many low-level details in
userspace, because otherwise the UAPI is just going to be a useless
mess.
I think a proposal such as the above to allow both implicit and explicit
syncpoints makes sense. For what it's worth, it's fairly similar to what
we had come up with last time we tried destaging the ABI, although back
at the time I'm not sure we had even considered explicit syncpoint usage
yet. I think where reasonably possible this kind of optional behaviour
is acceptable, but I don't think having two completely separate paths is
going to help in any way. If anything it's just going to make it more
difficult to maintain the code and get it to a usable state in the first
place.
Like I said elsewhere, the programming model for host1x hasn't changed
since Tegra20. It's rather evolved and gained a couple more features,
but that doesn't change anything about how userspace uses it.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 2/2] drm/bridge: Introduce LT8912B DSI to HDMI bridge
Lontium LT8912B is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
Reported-by: kernel test robot
Reviewed-by: Robert Foss
---
MAINTAINERS | 1 +
drivers/gpu/drm/bridge/Kconfig | 14 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/lontium-lt8912b.c | 765 +++
4 files changed, 781 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lontium-lt8912b.c
diff --git a/MAINTAINERS b/MAINTAINERS
index d9a125e5d295..6af083797947 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10530,6 +10530,7 @@ LONTIUM LT8912B MIPI TO HDMI BRIDGE
M: Adrien Grassein
S: Maintained
F: Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
+F: drivers/gpu/drm/bridge/lontium-lt8912b.c
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
M: Sathya Prakash
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e4110d6ca7b3..f2c5ec75d2f5 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,20 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_LONTIUM_LT8912B
+ tristate "Lontium LT8912B DSI/HDMI bridge"
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ Driver for Lontium LT8912B DSI to HDMI bridge
+ chip driver.
+ Please say Y if you have such hardware.
+
+ Say M here if you want to support this hardware as a module.
+ The module will be named "lontium-lt8912b".
+
config DRM_LONTIUM_LT9611
tristate "Lontium LT9611 DSI/HDMI bridge"
select SND_SOC_HDMI_CODEC if SND_SOC
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 86e7acc76f8d..756ce401aad3 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o
obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
b/drivers/gpu/drm/bridge/lontium-lt8912b.c
new file mode 100644
index ..fd0ec1c84368
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
@@ -0,0 +1,765 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define I2C_MAIN 0
+#define I2C_ADDR_MAIN 0x48
+
+#define I2C_CEC_DSI 1
+#define I2C_ADDR_CEC_DSI 0x49
+
+#define I2C_MAX_IDX 2
+
+struct lt8912 {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+
+ struct i2c_client *i2c_client[I2C_MAX_IDX];
+ struct regmap *regmap[I2C_MAX_IDX];
+
+ struct device_node *host_node;
+ struct drm_bridge *hdmi_port;
+
+ struct mipi_dsi_device *dsi;
+
+ struct gpio_desc *gp_reset;
+
+ struct videomode mode;
+
+ u8 data_lanes;
+ bool is_power_on;
+ bool is_attached;
+};
+
+static int lt8912_write_init_config(struct lt8912 *lt)
+{
+ const struct reg_sequence seq[] = {
+ /* Digital clock en*/
+ {0x08, 0xff},
+ {0x09, 0xff},
+ {0x0a, 0xff},
+ {0x0b, 0x7c},
+ {0x0c, 0xff},
+ {0x42, 0x04},
+
+ /*Tx Analog*/
+ {0x31, 0xb1},
+ {0x32, 0xb1},
+ {0x33, 0x0e},
+ {0x37, 0x00},
+ {0x38, 0x22},
+ {0x60, 0x82},
+
+ /*Cbus Analog*/
+ {0x39, 0x45},
+ {0x3a, 0x00},
+ {0x3b, 0x00},
+
+ /*HDMI Pll Analog*/
+ {0x44, 0x31},
+ {0x55, 0x44},
+ {0x57, 0x01},
+ {0x5a, 0x02},
+
+ /*MIPI Analog*/
+ {0x3e, 0xd6},
+ {0x3f, 0xd4},
+ {0x41, 0x3c},
+ {0xB2, 0x00},
+ };
+
+ return regmap_multi_reg_write(lt->regmap[I2C_MAIN], seq,
ARRAY_SIZE(seq));
+}
+
+static int lt8912_write_mipi_basic_config(struct lt8912 *lt)
+{
+ const struct reg_sequence seq[] = {
+ {0x12, 0x04},
+ {0x14, 0x00},
+ {0x15, 0x00},
+ {0x1a, 0x03},
+ {0x1b, 0x03},
+ };
+
+ return regmap_multi_reg_write(lt->regmap[I2C_CEC_DSI], seq,
ARRAY_SIZE(seq));
+};
+
+static int lt8912_write_dds_config(struct lt8912 *lt)
+{
+ const
[PATCH v8 1/2] dt-bindings: display: bridge: Add documentation for LT8912B
Lontium LT8912B is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
Reviewed-by: Rob Herring
---
.../display/bridge/lontium,lt8912b.yaml | 102 ++
MAINTAINERS | 5 +
2 files changed, 107 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
new file mode 100644
index ..735d0233a7d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lontium,lt8912b.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lontium LT8912B MIPI to HDMI Bridge
+
+maintainers:
+ - Adrien Grassein
+
+description: |
+ The LT8912B is a bridge device which convert DSI to HDMI
+
+properties:
+ compatible:
+enum:
+ - lontium,lt8912b
+
+ reg:
+maxItems: 1
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active high RESET pin.
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Primary MIPI port for MIPI input
+
+properties:
+ endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+unevaluatedProperties: false
+
+properties:
+ data-lanes: true
+
+required:
+ - data-lanes
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: |
+ HDMI port, should be connected to a node compatible with the
+ hdmi-connector binding.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi-bridge@48 {
+compatible = "lontium,lt8912b";
+reg = <0x48>;
+reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+
+hdmi_out_in: endpoint {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <_dsi_out>;
+};
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+};
+ };
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 8c44fd8fd85d..d9a125e5d295 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10526,6 +10526,11 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
F: drivers/hid/hid-lg-g15.c
+LONTIUM LT8912B MIPI TO HDMI BRIDGE
+M: Adrien Grassein
+S: Maintained
+F: Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
+
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
M: Sathya Prakash
M: Sreekanth Reddy
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 0/2] Add support of Lontium lt8912 MIPI to HDMI bridge
Hi, this patch set adds the support of the Lontium lt8912 MIPI to HDMI bridge in the kernel. It's only support the video part, not the audio part yet since I don't have the datasheet of this component. I get the current i2c configuration from Digi and Boundary drivers. Developed using the DB_DSIHD board from BoundaryDevices. Update in v2 - Use standard data-lanes instead of a custom prop; - Use hdmi-connector node. Update in v3 - Fix indentation; - Implement missing bridge functions; - Add some comments. Update in v4 - Fix bridge ops; - Fix i2c error detection. Update in v5 - Fix lt8912 name (lt8912b instead of lt8912); - Implement HPD via a workaround. In fact I don't have the datasheet of this component yet so I can't say if the configuration of the registers is correct or if I have an HW issue on my board. So, I choose to implement a fake version of HPD using a workqueue and polling the status regularly. Update in v6 - Fix a warning found by "kernel test robot" Update in v7 - Fix HPD logic (via an HW emulation); - HPD from chip is still not working. Update in v8 - Remove HPD logic (will be added later when HW bug qill be fixed). Thanks, Adrien Grassein (2): dt-bindings: display: bridge: Add documentation for LT8912B drm/bridge: Introduce LT8912B DSI to HDMI bridge .../display/bridge/lontium,lt8912b.yaml | 102 +++ MAINTAINERS | 6 + drivers/gpu/drm/bridge/Kconfig| 14 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/lontium-lt8912b.c | 765 ++ 5 files changed, 888 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml create mode 100644 drivers/gpu/drm/bridge/lontium-lt8912b.c -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/i915: add gem/gt TODO
On Tue, Mar 23, 2021 at 8:18 AM Daniel Vetter wrote: > > On Tue, Mar 23, 2021 at 08:34:55AM -0400, Rodrigo Vivi wrote: > > On Tue, Mar 23, 2021 at 12:57:39PM +0100, Daniel Vetter wrote: > > > On Tue, Mar 23, 2021 at 12:13:11PM +0200, Jani Nikula wrote: > > > > On Tue, 23 Mar 2021, Daniel Vetter wrote: > > > > > We've discussed a bit how to get the gem/gt team better integrated > > > > > and collaborate more with the wider community and agreed to the > > > > > following: > > > > > > > > > > - all gem/gt patches are reviewed on dri-devel for now. That's > > > > > overkill, but in the past there was definitely too little of that. > > > > > > > > > > - i915-gem folks are encouraged to cross review core patches from > > > > > other teams > > > > > > > > > > - big features (especially uapi changes) need to be discussed in an > > > > > rfc patch that documents the interface and big picture design, > > > > > before we get lost in the details of the code > > > > > > > > > > - Also a rough TODO (can be refined as we go ofc) to get gem/gt back > > > > > on track, like we've e.g. done with DAL/DC to get that in shape. > > > > > > > > I personally think there should be a lower bar for discussing and > > > > editing the TODO items than via patches on the mailing list. Granted, > > > > the TODO file enforces the discussion happens at a large enough > > > > audience, but for at least some of the items I'd suggest filing gitlab > > > > issues [1], with todo label, and tracking there. > > > > I also don't like the todo list in files and I agree that gitlab issues > > section should be better... > > > > > In general yes, and I'd go even further: it's up to each team/contributor > > > how they track review feedback and further work, whether that's gitlab or > > > some notes or just in their heads. > > > > > > This is a different situation here, and the "changes require big audience" > > > is a feature, not a bug. But it is a very exceptional situation, I think > > > this is only the 2nd time we're using a formal TODO for a gpu driver. If > > > we ignore gma500 in staging, which for me only showed that the separate > > > staging tree doesn't work so well for complex drivers like we have. > > > > ... but I understand the motivation, so > > > > Acked-by: Rodrigo Vivi > > > > However... what about: > > > > 1. moving the smaller items to gitlab at least? > > 2. having both, all the entries in the todo file have gitlab issue > > associated and the number-id is also here in the todo file? > > Yeah that sounds reasonable. tbh we haven't started any of the > intel-internal planning on most of these (ttm and scheduler are started), > so none of these tracking things exist yet at all ... I'm a fan of this. GitLab issues provide a good place to organize the chatter on any particular ToDo item. I'd also rather see people chattering about this stuff on public GitLab than JIRA, when possible. The last patch in the series closing out a ToDo can be a patch to this file to remove the bullet point. --Jason > -Daniel > > > > > > -Daniel > > > > > > > > > > > BR, > > > > Jani. > > > > > > > > > > > > [1] https://gitlab.freedesktop.org/drm/intel/-/issues > > > > > > > > > > > > > > > > > > > > > > Cc: Jani Nikula > > > > > Cc: Joonas Lahtinen > > > > > Cc: Rodrigo Vivi > > > > > Cc: Jason Ekstrand > > > > > Cc: Dave Airlie > > > > > Signed-off-by: Daniel Vetter > > > > > --- > > > > > drivers/gpu/drm/i915/TODO.txt | 36 > > > > > +++ > > > > > 1 file changed, 36 insertions(+) > > > > > create mode 100644 drivers/gpu/drm/i915/TODO.txt > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/TODO.txt > > > > > b/drivers/gpu/drm/i915/TODO.txt > > > > > new file mode 100644 > > > > > index ..d2e5bbb6339d > > > > > --- /dev/null > > > > > +++ b/drivers/gpu/drm/i915/TODO.txt > > > > > @@ -0,0 +1,36 @@ > > > > > +gem/gt TODO items > > > > > +- > > > > > + > > > > > +- For discrete memory manager, merge enough dg1 to be able to > > > > > refactor it to > > > > > + TTM. Then land pci ids (just in case that turns up an uapi > > > > > problem). TTM has > > > > > + improved a lot the past 2 years, there's no reason anymore not to > > > > > use it. > > > > > + > > > > > +- Come up with a plan what to do with drm/scheduler and how to get > > > > > there. > > > > > + > > > > > +- There's a lot of complexity added past few years to make > > > > > relocations faster. > > > > > + That doesn't make sense given hw and gpu apis moved away from this > > > > > model years > > > > > + ago: > > > > > + 1. Land a modern pre-bound uapi like VM_BIND > > > > > + 2. Any complexity added in this area past few years which can't be > > > > > justified > > > > > + with VM_BIND using userspace should be removed. Looking at amdgpu > > > > > dma_resv on > > > > > + the bo and vm, plus some lru locks is all that needed. No complex > > > > > rcu, > > > > > + refcounts, caching, ...
Re: [PATCH 4/9] drm/tegra: dc: Implement hardware cursor on Tegra186 and later
23.03.2021 18:54, Thierry Reding пишет:
> @@ -920,15 +934,42 @@ static void tegra_cursor_atomic_update(struct drm_plane
> *plane,
> value = tegra_dc_readl(dc, DC_DISP_BLEND_CURSOR_CONTROL);
> value &= ~CURSOR_DST_BLEND_MASK;
> value &= ~CURSOR_SRC_BLEND_MASK;
> - value |= CURSOR_MODE_NORMAL;
> +
> + if (dc->soc->has_nvdisplay)
> + value &= ~CURSOR_COMPOSITION_MODE_XOR;
> + else
> + value |= CURSOR_MODE_NORMAL;
> +
> value |= CURSOR_DST_BLEND_NEG_K1_TIMES_SRC;
> value |= CURSOR_SRC_BLEND_K1_TIMES_SRC;
> value |= CURSOR_ALPHA;
> tegra_dc_writel(dc, value, DC_DISP_BLEND_CURSOR_CONTROL);
>
> + /* nvdisplay relies on software for clipping */
> + if (dc->soc->has_nvdisplay) {
But coordinates already should be clipped by
drm_atomic_helper_check_plane_state().
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] dma-buf: Add an API for exporting sync files (v8)
Adding mesa-dev and wayland-devel for broader circulation.
On Wed, Mar 17, 2021 at 5:19 PM Jason Ekstrand wrote:
>
> Modern userspace APIs like Vulkan are built on an explicit
> synchronization model. This doesn't always play nicely with the
> implicit synchronization used in the kernel and assumed by X11 and
> Wayland. The client -> compositor half of the synchronization isn't too
> bad, at least on intel, because we can control whether or not i915
> synchronizes on the buffer and whether or not it's considered written.
>
> The harder part is the compositor -> client synchronization when we get
> the buffer back from the compositor. We're required to be able to
> provide the client with a VkSemaphore and VkFence representing the point
> in time where the window system (compositor and/or display) finished
> using the buffer. With current APIs, it's very hard to do this in such
> a way that we don't get confused by the Vulkan driver's access of the
> buffer. In particular, once we tell the kernel that we're rendering to
> the buffer again, any CPU waits on the buffer or GPU dependencies will
> wait on some of the client rendering and not just the compositor.
>
> This new IOCTL solves this problem by allowing us to get a snapshot of
> the implicit synchronization state of a given dma-buf in the form of a
> sync file. It's effectively the same as a poll() or I915_GEM_WAIT only,
> instead of CPU waiting directly, it encapsulates the wait operation, at
> the current moment in time, in a sync_file so we can check/wait on it
> later. As long as the Vulkan driver does the sync_file export from the
> dma-buf before we re-introduce it for rendering, it will only contain
> fences from the compositor or display. This allows to accurately turn
> it into a VkFence or VkSemaphore without any over- synchronization.
>
> v2 (Jason Ekstrand):
> - Use a wrapper dma_fence_array of all fences including the new one
>when importing an exclusive fence.
>
> v3 (Jason Ekstrand):
> - Lock around setting shared fences as well as exclusive
> - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
> - Initialize ret to 0 in dma_buf_wait_sync_file
>
> v4 (Jason Ekstrand):
> - Use the new dma_resv_get_singleton helper
>
> v5 (Jason Ekstrand):
> - Rename the IOCTLs to import/export rather than wait/signal
> - Drop the WRITE flag and always get/set the exclusive fence
>
> v6 (Jason Ekstrand):
> - Drop the sync_file import as it was all-around sketchy and not nearly
>as useful as import.
> - Re-introduce READ/WRITE flag support for export
> - Rework the commit message
>
> v7 (Jason Ekstrand):
> - Require at least one sync flag
> - Fix a refcounting bug: dma_resv_get_excl() doesn't take a reference
> - Use _rcu helpers since we're accessing the dma_resv read-only
>
> v8 (Jason Ekstrand):
> - Return -ENOMEM if the sync_file_create fails
> - Predicate support on IS_ENABLED(CONFIG_SYNC_FILE)
>
> Signed-off-by: Jason Ekstrand
> ---
> drivers/dma-buf/dma-buf.c| 62
> include/uapi/linux/dma-buf.h | 6
> 2 files changed, 68 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f264b70c383eb..a5e4b0b6a049c 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -362,6 +363,62 @@ static long dma_buf_set_name(struct dma_buf *dmabuf,
> const char __user *buf)
> return ret;
> }
>
> +#if IS_ENABLED(CONFIG_SYNC_FILE)
> +static long dma_buf_export_sync_file(struct dma_buf *dmabuf,
> +void __user *user_data)
> +{
> + struct dma_buf_sync_file arg;
> + struct dma_fence *fence = NULL;
> + struct sync_file *sync_file;
> + int fd, ret;
> +
> + if (copy_from_user(, user_data, sizeof(arg)))
> + return -EFAULT;
> +
> + if (arg.flags & ~DMA_BUF_SYNC_RW)
> + return -EINVAL;
> +
> + if ((arg.flags & DMA_BUF_SYNC_RW) == 0)
> + return -EINVAL;
> +
> + fd = get_unused_fd_flags(O_CLOEXEC);
> + if (fd < 0)
> + return fd;
> +
> + if (arg.flags & DMA_BUF_SYNC_WRITE) {
> + ret = dma_resv_get_singleton_rcu(dmabuf->resv, );
> + if (ret)
> + goto err_put_fd;
> + } else if (arg.flags & DMA_BUF_SYNC_READ) {
> + fence = dma_resv_get_excl_rcu(dmabuf->resv);
> + }
> +
> + if (!fence)
> + fence = dma_fence_get_stub();
> +
> + sync_file = sync_file_create(fence);
> +
> + dma_fence_put(fence);
> +
> + if (!sync_file) {
> + ret = -ENOMEM;
> + goto err_put_fd;
> + }
> +
> + fd_install(fd, sync_file->file);
> +
> + arg.fd = fd;
> + if (copy_to_user(user_data, , sizeof(arg)))
> + return -EFAULT;
> +
> +
Re: [PATCH v5 15/21] drm/tegra: Add new UAPI to header
On Tue, Mar 23, 2021 at 08:32:50PM +0300, Dmitry Osipenko wrote:
> 23.03.2021 19:44, Thierry Reding пишет:
> > On Tue, Mar 23, 2021 at 05:00:30PM +0300, Dmitry Osipenko wrote:
> >> 23.03.2021 15:30, Thierry Reding пишет:
> >>> On Thu, Jan 14, 2021 at 12:34:22PM +0200, Mikko Perttunen wrote:
> On 1/14/21 10:36 AM, Dmitry Osipenko wrote:
> > 13.01.2021 21:56, Mikko Perttunen пишет:
> >> On 1/13/21 8:14 PM, Dmitry Osipenko wrote:
> >>> 11.01.2021 16:00, Mikko Perttunen пишет:
> +struct drm_tegra_submit_buf {
> + /**
> + * @mapping_id: [in]
> + *
> + * Identifier of the mapping to use in the submission.
> + */
> + __u32 mapping_id;
> >>>
> >>> I'm now in process of trying out the UAPI using grate drivers and this
> >>> becomes the first obstacle.
> >>>
> >>> Looks like this is not going to work well for older Tegra SoCs, in
> >>> particular for T20, which has a small GART.
> >>>
> >>> Given that the usefulness of the partial mapping feature is very
> >>> questionable until it will be proven with a real userspace, we should
> >>> start with a dynamic mappings that are done at a time of job
> >>> submission.
> >>>
> >>> DRM already should have everything necessary for creating and managing
> >>> caches of mappings, grate kernel driver has been using drm_mm_scan
> >>> for a
> >>> long time now for that.
> >>>
> >>> It should be fine to support the static mapping feature, but it should
> >>> be done separately with the drm_mm integration, IMO.
> >>>
> >>> What do think?
> >>>
> >>
> >> Can you elaborate on the requirements to be able to use GART? Are there
> >> any other reasons this would not work on older chips?
> >
> > We have all DRM devices in a single address space on T30+, hence having
> > duplicated mappings for each device should be a bit wasteful.
>
> I guess this should be pretty easy to change to only keep one mapping per
> GEM object.
> >>>
> >>> The important point here is the semantics: this IOCTL establishes a
> >>> mapping for a given GEM object on a given channel. If the underlying
> >>> implementation is such that the mapping doesn't fit into the GART, then
> >>> that's an implementation detail that the driver needs to take care of.
> >>> Similarly, if multiple devices share a single address space, that's
> >>> something the driver already knows and can take advantage of by simply
> >>> reusing an existing mapping if one already exists. In both cases the
> >>> semantics would be correctly implemented and that's really all that
> >>> matters.
> >>>
> >>> Overall this interface seems sound from a high-level point of view and
> >>> allows these mappings to be properly created even for the cases we have
> >>> where each channel may have a separate address space. It may not be the
> >>> optimal interface for all use-cases or any one individual case, but the
> >>> very nature of these interfaces is to abstract away certain differences
> >>> in order to provide a unified interface to a common programming model.
> >>> So there will always be certain tradeoffs.
> >>
> >> For now this IOCTL isn't useful from a userspace perspective of older
> >> SoCs and I'll need to add a lot of code that won't do anything useful
> >> just to conform to the specific needs of the newer SoCs. Trying to unify
> >> everything into a single API doesn't sound like a good idea at this
> >> point and I already suggested to Mikko to try out variant with a
> >> separated per-SoC code paths in the next version, then the mappings
> >> could be handled separately by the T186+ paths.
> >
> > I'm not sure I understand what you're saying. Obviously the underlying
> > implementation of this might have to differ depending on SoC generation.
> > But it sounds like you're suggesting having different UAPIs depending on
> > SoC generation.
>
> I suggested that this IOCTL shouldn't be mandatory for older SoCs, which
> we should to have anyways for preserving the older UAPI. Yes, this makes
> UAPI different and I want to see how it will look like in the next
> version since the current variant was sub-optimal.
What exactly is sub-optimal about the current variant? And what would an
alternative look like? Like what we have in the old ABI where we pass in
GEM handles directly during submissions?
I can see how this new variant would be a bit more work than the
alternative, but even on older SoCs, wouldn't the explicit mapping be
much better for performance than having to constantly remap GEM objects
for every job?
In general I don't think it's useful to have separate UAPIs for what's
basically the same hardware. I mean from a high-level point of view what
we need to do for each job remains exactly the same whether the job is
executed on Tegra20 or Tegra194. We have to map a bunch of buffers so
that they can be
[PATCH 00/18] Make vfio_mdev type safe
Prologue This is series #2 in part of a larger work that arose from the minor remark that the mdev_parent_ops indirection shim is useless and complicates things. It follows the "Embed struct vfio_device in all sub-structures" already sent, and must be applied on top of it. A preview of the future series's is here: https://github.com/jgunthorpe/linux/pull/3/commits This series: vfio_mdev has a number of different objects: mdev_parent, mdev_type and mdev_device. Unfortunately the types of these have been erased in various places throughout the API, and this makes it very hard to understand this code or maintain it by the time it reaches all of the drivers. This series puts in all the types and aligns some of the design with the driver core standard for a driver core bus driver: - Replace 'struct device *' with 'struct mdev_device * - Replace 'struct device *' with 'struct mdev_type *' and mtype_get_parent_dev() - Replace 'struct kobject *' with 'struct mdev_type *' Now that types are clear it is easy to spot a few places that have duplicated information. More significantly we can now understand how to directly fix the obfuscated 'kobj->name' matching by realizing the the kobj is a mdev_type, which is linked to the supported_types_list provided by the driver, and thus the core code can directly return the array indexes all the drivers actually want. Jason Jason Gunthorpe (18): vfio/mdev: Fix missing static's on MDEV_TYPE_ATTR's vfio/mdev: Add missing typesafety around mdev_device vfio/mdev: Simplify driver registration vfio/mdev: Use struct mdev_type in struct mdev_device vfio/mdev: Do not allow a mdev_type to have a NULL parent pointer vfio/mdev: Expose mdev_get/put_parent to mdev_private.h vfio/mdev: Add missing reference counting to mdev_type vfio/mdev: Reorganize mdev_device_create() vfio/mdev: Add missing error handling to dev_set_name() vfio/mdev: Remove duplicate storage of parent in mdev_device vfio/mdev: Add mdev/mtype_get_type_group_id() vfio/mtty: Use mdev_get_type_group_id() vfio/mdpy: Use mdev_get_type_group_id() vfio/mbochs: Use mdev_get_type_group_id() vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV vfio/gvt: Use mdev_get_type_group_id() vfio/mdev: Remove kobj from mdev_parent_ops->create() vfio/mdev: Correct the function signatures for the mdev_type_attributes .../driver-api/vfio-mediated-device.rst | 9 +- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/gvt/gvt.c| 41 ++--- drivers/gpu/drm/i915/gvt/gvt.h| 4 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 7 +- drivers/s390/cio/vfio_ccw_ops.c | 17 +- drivers/s390/crypto/vfio_ap_ops.c | 14 +- drivers/vfio/mdev/mdev_core.c | 160 ++ drivers/vfio/mdev/mdev_driver.c | 19 +-- drivers/vfio/mdev/mdev_private.h | 40 ++--- drivers/vfio/mdev/mdev_sysfs.c| 59 --- drivers/vfio/mdev/vfio_mdev.c | 29 ++-- drivers/vfio/vfio_iommu_type1.c | 25 +-- include/linux/mdev.h | 80 ++--- samples/vfio-mdev/mbochs.c| 55 +++--- samples/vfio-mdev/mdpy.c | 56 +++--- samples/vfio-mdev/mtty.c | 66 ++-- 17 files changed, 306 insertions(+), 376 deletions(-) -- 2.31.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/doc: Add RFC section
On Tue, Mar 23, 2021 at 12:01 PM Simon Ser wrote: > > Side note: I feel like we could have better lines of communication > between kernel devs and user-space devs. The new uAPI requirements seem > to be a high barrier to entry for kernel devs. However sometimes > user-space devs might be interested in helping out with the user-space > part… > > Maybe it would be good to CC e.g. wayland-devel for new RFCs, so that > user-space devs can jump in if they're interested. And also provide > feedback, since new uAPI is hard to spot in the sea of messages in > dri-devel. That's a good suggestion. CCing wayland-dev or mesa-dev, as appropriate, with such docs patches sounds like a good idea. I'm not sure where we would put that in here but it would be good to call out. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 16/18] vfio/gvt: Use mdev_get_type_group_id()
intel_gvt_init_vgpu_type_groups() makes gvt->types 1:1 with the
supported_type_groups array, so the type_group_id is also the index into
gvt->types. Use it directly and remove the string matching.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.c | 24 +++-
drivers/gpu/drm/i915/gvt/gvt.h | 4 ++--
drivers/gpu/drm/i915/gvt/kvmgt.c | 5 ++---
3 files changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index d1d8ee4a5f16a3..4b47a18e9dfa0f 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -46,22 +46,12 @@ static const char * const supported_hypervisors[] = {
[INTEL_GVT_HYPERVISOR_KVM] = "KVM",
};
-static struct intel_vgpu_type *intel_gvt_find_vgpu_type(struct intel_gvt *gvt,
- const char *name)
+static struct intel_vgpu_type *
+intel_gvt_find_vgpu_type(struct intel_gvt *gvt, unsigned int type_group_id)
{
- const char *driver_name =
- dev_driver_string(>gt->i915->drm.pdev->dev);
- int i;
-
- name += strlen(driver_name) + 1;
- for (i = 0; i < gvt->num_types; i++) {
- struct intel_vgpu_type *t = >types[i];
-
- if (!strncmp(t->name, name, sizeof(t->name)))
- return t;
- }
-
- return NULL;
+ if (WARN_ON(type_group_id >= gvt->num_types))
+ return NULL;
+ return >types[type_group_id];
}
static ssize_t available_instances_show(struct kobject *kobj,
@@ -71,7 +61,7 @@ static ssize_t available_instances_show(struct kobject *kobj,
unsigned int num = 0;
void *gvt = kdev_to_i915(dev)->gvt;
- type = intel_gvt_find_vgpu_type(gvt, kobject_name(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
if (!type)
num = 0;
else
@@ -92,7 +82,7 @@ static ssize_t description_show(struct kobject *kobj, struct
device *dev,
struct intel_vgpu_type *type;
void *gvt = kdev_to_i915(dev)->gvt;
- type = intel_gvt_find_vgpu_type(gvt, kobject_name(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
if (!type)
return 0;
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 03c993d68f105a..0cf480f42850d2 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -569,8 +569,8 @@ struct intel_gvt_ops {
void (*vgpu_reset)(struct intel_vgpu *);
void (*vgpu_activate)(struct intel_vgpu *);
void (*vgpu_deactivate)(struct intel_vgpu *);
- struct intel_vgpu_type *(*gvt_find_vgpu_type)(struct intel_gvt *gvt,
- const char *name);
+ struct intel_vgpu_type *(*gvt_find_vgpu_type)(
+ struct intel_gvt *gvt, unsigned int type_group_id);
bool (*get_gvt_attrs)(struct attribute_group ***intel_vgpu_type_groups);
int (*vgpu_query_plane)(struct intel_vgpu *vgpu, void *);
int (*vgpu_get_dmabuf)(struct intel_vgpu *vgpu, unsigned int);
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index b4348256ae9591..16e1e4a38aa1f6 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -700,10 +700,9 @@ static int intel_vgpu_create(struct kobject *kobj, struct
mdev_device *mdev)
pdev = mdev_parent_dev(mdev);
gvt = kdev_to_i915(pdev)->gvt;
- type = intel_gvt_ops->gvt_find_vgpu_type(gvt, kobject_name(kobj));
+ type = intel_gvt_ops->gvt_find_vgpu_type(gvt,
+mdev_get_type_group_id(mdev));
if (!type) {
- gvt_vgpu_err("failed to find type %s to create\n",
- kobject_name(kobj));
ret = -EINVAL;
goto out;
}
--
2.31.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 18/18] vfio/mdev: Correct the function signatures for the mdev_type_attributes
The driver core standard is to pass in the properly typed object, the
properly typed attribute and the buffer data. It stems from the root
kobject method:
ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,..)
Each subclass of kobject should provide their own function with the same
signature but more specific types, eg struct device uses:
ssize_t (*show)(struct device *dev, struct device_attribute *attr,..)
In this case the existing signature is:
ssize_t (*show)(struct kobject *kobj, struct device *dev,..)
Where kobj is a 'struct mdev_type *' and dev is 'mdev_type->parent->dev'.
Change the mdev_type related sysfs attribute functions to:
ssize_t (*show)(struct mdev_type *mtype, struct mdev_type_attribute *attr,..)
In order to restore type safety and match the driver core standard
There are no current users of 'attr', but if it is ever needed it would be
hard to add in retroactively, so do it now.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.c| 21 +++--
drivers/s390/cio/vfio_ccw_ops.c | 15 +--
drivers/s390/crypto/vfio_ap_ops.c | 12 +++-
drivers/vfio/mdev/mdev_core.c | 14 --
drivers/vfio/mdev/mdev_sysfs.c| 11 ++-
include/linux/mdev.h | 11 +++
samples/vfio-mdev/mbochs.c| 26 +++---
samples/vfio-mdev/mdpy.c | 24 ++--
samples/vfio-mdev/mtty.c | 18 +-
9 files changed, 90 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 4b47a18e9dfa0f..3703814a669b46 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -54,14 +54,15 @@ intel_gvt_find_vgpu_type(struct intel_gvt *gvt, unsigned
int type_group_id)
return >types[type_group_id];
}
-static ssize_t available_instances_show(struct kobject *kobj,
- struct device *dev, char *buf)
+static ssize_t available_instances_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr,
+ char *buf)
{
struct intel_vgpu_type *type;
unsigned int num = 0;
- void *gvt = kdev_to_i915(dev)->gvt;
+ void *gvt = kdev_to_i915(mtype_get_parent_dev(mtype))->gvt;
- type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(mtype));
if (!type)
num = 0;
else
@@ -70,19 +71,19 @@ static ssize_t available_instances_show(struct kobject
*kobj,
return sprintf(buf, "%u\n", num);
}
-static ssize_t device_api_show(struct kobject *kobj, struct device *dev,
- char *buf)
+static ssize_t device_api_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr, char *buf)
{
return sprintf(buf, "%s\n", VFIO_DEVICE_API_PCI_STRING);
}
-static ssize_t description_show(struct kobject *kobj, struct device *dev,
- char *buf)
+static ssize_t description_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr, char *buf)
{
struct intel_vgpu_type *type;
- void *gvt = kdev_to_i915(dev)->gvt;
+ void *gvt = kdev_to_i915(mtype_get_parent_dev(mtype))->gvt;
- type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(mtype));
if (!type)
return 0;
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 06a82ec136080c..74fe21eceb66cc 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -71,23 +71,26 @@ static int vfio_ccw_mdev_notifier(struct notifier_block *nb,
return NOTIFY_DONE;
}
-static ssize_t name_show(struct kobject *kobj, struct device *dev, char *buf)
+static ssize_t name_show(struct mdev_type *mtype,
+struct mdev_type_attribute *attr, char *buf)
{
return sprintf(buf, "I/O subchannel (Non-QDIO)\n");
}
static MDEV_TYPE_ATTR_RO(name);
-static ssize_t device_api_show(struct kobject *kobj, struct device *dev,
- char *buf)
+static ssize_t device_api_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr, char *buf)
{
return sprintf(buf, "%s\n", VFIO_DEVICE_API_CCW_STRING);
}
static MDEV_TYPE_ATTR_RO(device_api);
-static ssize_t available_instances_show(struct kobject *kobj,
- struct device *dev, char *buf)
+static ssize_t available_instances_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr,
+ char *buf)
{
- struct vfio_ccw_private *private =
[PATCH 17/18] vfio/mdev: Remove kobj from mdev_parent_ops->create()
The kobj here is a type-erased version of mdev_type, which is already
stored in the struct mdev_device being passed in. It was only ever used to
compute the type_group_id, which is now extracted directly from the mdev.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
drivers/s390/cio/vfio_ccw_ops.c | 2 +-
drivers/s390/crypto/vfio_ap_ops.c | 2 +-
drivers/vfio/mdev/mdev_core.c | 2 +-
include/linux/mdev.h | 3 +--
samples/vfio-mdev/mbochs.c| 2 +-
samples/vfio-mdev/mdpy.c | 2 +-
samples/vfio-mdev/mtty.c | 2 +-
8 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 16e1e4a38aa1f6..6bf176e8426e63 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -689,7 +689,7 @@ static void kvmgt_put_vfio_device(void *vgpu)
vfio_device_put(vdev->vfio_device);
}
-static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
+static int intel_vgpu_create(struct mdev_device *mdev)
{
struct intel_vgpu *vgpu = NULL;
struct intel_vgpu_type *type;
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 68106be4ba7a19..06a82ec136080c 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -110,7 +110,7 @@ static struct attribute_group *mdev_type_groups[] = {
NULL,
};
-static int vfio_ccw_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
+static int vfio_ccw_mdev_create(struct mdev_device *mdev)
{
struct vfio_ccw_private *private =
dev_get_drvdata(mdev_parent_dev(mdev));
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 41fc2e4135fe18..6d75ed07bcd49d 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -322,7 +322,7 @@ static void vfio_ap_matrix_init(struct ap_config_info *info,
matrix->adm_max = info->apxa ? info->Nd : 15;
}
-static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
+static int vfio_ap_mdev_create(struct mdev_device *mdev)
{
struct ap_matrix_mdev *matrix_mdev;
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 3ba5e9464b4d20..71455812cb84cf 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -286,7 +286,7 @@ int mdev_device_create(struct mdev_type *type, const guid_t
*uuid)
goto mdev_fail;
}
- ret = parent->ops->create(>kobj, mdev);
+ ret = parent->ops->create(mdev);
if (ret)
goto ops_create_fail;
diff --git a/include/linux/mdev.h b/include/linux/mdev.h
index 41e91936522394..c3a800051d6146 100644
--- a/include/linux/mdev.h
+++ b/include/linux/mdev.h
@@ -61,7 +61,6 @@ unsigned int mtype_get_type_group_id(struct kobject
*mtype_kobj);
* @create:Called to allocate basic resources in parent device's
* driver for a particular mediated device. It is
* mandatory to provide create ops.
- * @kobj: kobject of type for which 'create' is called.
* @mdev: mdev_device structure on of mediated device
* that is being created
* Returns integer: success (0) or error (< 0)
@@ -107,7 +106,7 @@ struct mdev_parent_ops {
const struct attribute_group **mdev_attr_groups;
struct attribute_group **supported_type_groups;
- int (*create)(struct kobject *kobj, struct mdev_device *mdev);
+ int (*create)(struct mdev_device *mdev);
int (*remove)(struct mdev_device *mdev);
int (*open)(struct mdev_device *mdev);
void(*release)(struct mdev_device *mdev);
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index a1af30df10a2ee..ac4d0dc2490705 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -506,7 +506,7 @@ static int mbochs_reset(struct mdev_device *mdev)
return 0;
}
-static int mbochs_create(struct kobject *kobj, struct mdev_device *mdev)
+static int mbochs_create(struct mdev_device *mdev)
{
const struct mbochs_type *type =
_types[mdev_get_type_group_id(mdev)];
diff --git a/samples/vfio-mdev/mdpy.c b/samples/vfio-mdev/mdpy.c
index 08c15f9f06a880..da88fd7dd42329 100644
--- a/samples/vfio-mdev/mdpy.c
+++ b/samples/vfio-mdev/mdpy.c
@@ -216,7 +216,7 @@ static int mdpy_reset(struct mdev_device *mdev)
return 0;
}
-static int mdpy_create(struct kobject *kobj, struct mdev_device *mdev)
+static int mdpy_create(struct mdev_device *mdev)
{
const struct mdpy_type *type =
_types[mdev_get_type_group_id(mdev)];
diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
index 191a587a8d5ab1..f2e36c06ac6aa2 100644
--- a/samples/vfio-mdev/mtty.c
[PATCH 15/18] vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV
At some point there may have been some reason for this weird split in this driver, but today only the VFIO side is actually implemented. However, it got messed up at some point and mdev code was put in gvt.c and is pretending to be "generic" by masquerading as some generic attribute list: static MDEV_TYPE_ATTR_RO(description); But MDEV_TYPE attributes are only usable with mdev_device, nothing else. Ideally all of this would be moved to kvmgt.c, but it is entangled with the rest of the "generic" code in an odd way. Thus put in a kconfig dependency so we don't get randconfig failures when the next patch creates a link time dependency related to the use of MDEV_TYPE. Signed-off-by: Jason Gunthorpe --- drivers/gpu/drm/i915/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 1e1cb245fca778..483e9ff8ca1d23 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -101,6 +101,7 @@ config DRM_I915_GVT bool "Enable Intel GVT-g graphics virtualization host support" depends on DRM_I915 depends on 64BIT + depends on VFIO_MDEV default n help Choose this option if you want to enable Intel GVT-g graphics -- 2.31.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used
On Tue, Mar 23, 2021 at 06:29:53PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/22/21 10:47 PM, Ville Syrjälä wrote:
> > On Mon, Mar 22, 2021 at 10:28:06PM +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 3/22/21 9:59 PM, Ville Syrjälä wrote:
> >>> On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
> On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
> > Hi,
> >
> > On 3/1/21 4:43 PM, Hans de Goede wrote:
> >> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> >> displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> >> Predia Basic tablet would no longer properly light up after reboot.
> >>
> >> The backlight still turns back on after reboot, but the LCD shows an
> >> all black display. The display is also all black during the time that
> >> EFI / the GOP is managing it, so e.g. the grub menu also is not
> >> visible.
> >>
> >> In this scenario the panel is initialized so that it appears to be
> >> working
> >> and the fastboot code skips doing a modeset. Forcing a modeset by
> >> doing a
> >> chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
> >> /sys/class/graphics/fb0/blank causes the panel to work again.
> >>
> >> Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
> >> a no-op when set; and set this on vlv/chv devices when a DSI panel is
> >> detected, to work around this.
> >>
> >> Admittedly this is a bit of a big hammer, but these platforms have been
> >> around for quite some time now and they have always worked fine without
> >> the new behavior to shutdown everything on shutdown/reboot. This
> >> approach
> >> simply disables the recently introduced new shutdown behavior in this
> >> specific case where it is known to cause problems. Which is a nice and
> >> simple way to deal with this.
> >>
> >> Signed-off-by: Hans de Goede
> >
> > Ping? Since sending this patch I've been seeing the issue addressed by
> > this on variour other CHT based devices too.
> >
> > So we have various devices suffering from a black screen after reboot
> > now. This is pretty serious usability regression.
> >
> > As such it would be good to get this reviewed, or another fix proposed.
>
> For the quirks we try to limit them to very specific vendor and model
> ids,
> so I wonder if it would be possible to get this information in here
> instead
> to all the vlv with dsi...
>
> Or avoid the quirk "infra" and skip to all vlv with active dsi?!
>
> Jani?
> Ville?
> >>>
> >>> We need to figure out why the panel doesn't start up again.
> >>
> >> Note it is the GOP which fails to light it up again. I think we turn
> >> something
> >> off, which after a power-on-reset is on, so the GOP expects it to be on.
> >
> > Hmm. Do any of the reboot=warm|cold|whatever knobs make a difference?
> > Are there any fast vs. slow boot settings in the BIOS setup?
>
> Ok, so I was running the tests which you requested and during this
> I managed to find the real problem.
>
> What happens on reboot is a really quick panel off/on cycle and that is
> causing the issue.
>
> I can reproduce this by doing:
>
> chvt 3; echo 1 > /sys/class/graphics/fb0/blank; echo 0 >
> /sys/class/graphics/fb0/blank
>
> The problem is that we're not honoring panel_pwr_cycle_delay because
> intel_dsi_msleep() is a no-op on devices with a MIPI-sequences version >= 3,
> because those sequences already contain the necessary delays, at least
> for most of the steps during the on/off sequences. It seems that the
> pwr-cycle delay is not handled by those v3+ sequences.
>
> So fixing this is as simple as switching to a regular msleep for the
> intel_dsi->panel_pwr_cycle_delay.
>
> Once we do that it would be good (for e.g. suspend/resume speed) to fix:
>
> /*
> * FIXME As we do with eDP, just make a note of the time here
> * and perform the wait before the next panel power on.
> */
>
> Which sits right above that msleep. Since I have a reproducer now which
> shows when the sleep is too short, it should now be easy ti fix the FIXME
> and test that the fix works. I'll do this in a separate patch and send
> a patch-set with both patches replacing this patch.
Awesome. I'm really happy to avoid any quirks and whatnot since
they always come back to bite you later. Thanks for digging into it.
Speaking of DSI, you wouldn't happen to have one these machines:
https://gitlab.freedesktop.org/drm/intel/-/issues/2698 ? Haven't gotten
a response from the bug reporter so no idea if my quick patch helps or
not.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v2)
This API is entirely unnecessary and I'd love to get rid of it. If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed. The justification given at the time
was that it would help GL drivers which are inherently single-timeline.
However, neither of our GL drivers actually wanted the feature. i965
was already in maintenance mode at the time and iris uses syncobj for
everything.
Unfortunately, as much as I'd love to get rid of it, it is used by the
media driver so we can't do that. We can, however, do the next-best
thing which is to embed a syncobj in the context and do exactly what
we'd expect from userspace internally. This isn't an entirely identical
implementation because it's no longer atomic if userspace races with
itself by calling execbuffer2 twice simultaneously from different
threads. It won't crash in that case; it just doesn't guarantee any
ordering between those two submits.
Moving SINGLE_TIMELINE to a syncobj emulation has a couple of technical
advantages beyond mere annoyance. One is that intel_timeline is no
longer an api-visible object and can remain entirely an implementation
detail. This may be advantageous as we make scheduler changes going
forward. Second is that, together with deleting the CLONE_CONTEXT API,
we should now have a 1:1 mapping between intel_context and
intel_timeline which may help us reduce locking.
v2 (Jason Ekstrand):
- Update the comment on i915_gem_context::syncobj to mention that it's
an emulation and the possible race if userspace calls execbuffer2
twice on the same context concurrently.
- Wrap the checks for eb.gem_context->syncobj in unlikely()
- Drop the dma_fence reference
- Improved commit message
Signed-off-by: Jason Ekstrand
Cc: Maarten Lankhorst
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 47 ---
.../gpu/drm/i915/gem/i915_gem_context_types.h | 14 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 16 +++
3 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index f88bac19333ec..e094f4a1ca4cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -67,6 +67,8 @@
#include
#include
+#include
+
#include "gt/gen6_ppgtt.h"
#include "gt/intel_context.h"
#include "gt/intel_engine_heartbeat.h"
@@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context *ce,
ce->vm = vm;
}
- GEM_BUG_ON(ce->timeline);
- if (ctx->timeline)
- ce->timeline = intel_timeline_get(ctx->timeline);
-
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, >flags);
@@ -344,8 +342,8 @@ void i915_gem_context_release(struct kref *ref)
mutex_destroy(>engines_mutex);
mutex_destroy(>lut_mutex);
- if (ctx->timeline)
- intel_timeline_put(ctx->timeline);
+ if (ctx->syncobj)
+ drm_syncobj_put(ctx->syncobj);
put_pid(ctx->pid);
mutex_destroy(>mutex);
@@ -790,33 +788,11 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
i915_vm_close(vm);
}
-static void __set_timeline(struct intel_timeline **dst,
- struct intel_timeline *src)
-{
- struct intel_timeline *old = *dst;
-
- *dst = src ? intel_timeline_get(src) : NULL;
-
- if (old)
- intel_timeline_put(old);
-}
-
-static void __apply_timeline(struct intel_context *ce, void *timeline)
-{
- __set_timeline(>timeline, timeline);
-}
-
-static void __assign_timeline(struct i915_gem_context *ctx,
- struct intel_timeline *timeline)
-{
- __set_timeline(>timeline, timeline);
- context_apply_all(ctx, __apply_timeline, timeline);
-}
-
static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
{
struct i915_gem_context *ctx;
+ int ret;
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
!HAS_EXECLISTS(i915))
@@ -845,16 +821,13 @@ i915_gem_create_context(struct drm_i915_private *i915,
unsigned int flags)
}
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
- struct intel_timeline *timeline;
-
- timeline = intel_timeline_create(>gt);
- if (IS_ERR(timeline)) {
+ ret = drm_syncobj_create(>syncobj,
+DRM_SYNCOBJ_CREATE_SIGNALED,
+NULL);
+ if (ret) {
context_close(ctx);
- return ERR_CAST(timeline);
+ return ERR_PTR(ret);
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API
On Tue, Mar 23, 2021 at 11:23 AM Tvrtko Ursulin wrote: > > > On 23/03/2021 13:23, Daniel Vetter wrote: > > On Tue, Mar 23, 2021 at 09:14:36AM +, Tvrtko Ursulin wrote: > >> > >> On 22/03/2021 16:43, Daniel Vetter wrote: > >>> On Mon, Mar 22, 2021 at 4:31 PM Tvrtko Ursulin > >>> wrote: > > > On 22/03/2021 14:57, Daniel Vetter wrote: > > On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin > > wrote: > >> > >> > >> On 22/03/2021 14:09, Daniel Vetter wrote: > >>> On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote: > > On 19/03/2021 22:38, Jason Ekstrand wrote: > > This API allows one context to grab bits out of another context upon > > creation. It can be used as a short-cut for setparam(getparam()) > > for > > things like I915_CONTEXT_PARAM_VM. However, it's never been used > > by any > > real userspace. It's used by a few IGT tests and that's it. Since > > it > > doesn't add any real value (most of the stuff you can CLONE you can > > copy > > in other ways), drop it. > > No complaints to remove if it ended up unused outside IGT. Latter is > a _big_ > problem though, since it is much more that a few IGT tests. So I > really > think there really needs to be an evaluation and a plan for that (we > don't > want to lose 50% of the coverage over night). > > > There is one thing that this API allows you to clone which you > > cannot > > clone via getparam/setparam: timelines. However, timelines are an > > implementation detail of i915 and not really something that needs > > to be > > Not really true timelines are i915 implementation detail. They are > in fact a > dma-fence context:seqno concept, nothing more that than. I think you > are > probably confusing struct intel_timeline with the timeline wording > in the > uapi. Former is i915 implementation detail, but context:seqno are > truly > userspace timelines. > >>> > >>> I think you're both saying the same thing and talking a bit past each > >>> another. > >>> > >>> Yes the timeline is just a string of dma_fence, that's correct. Now > >>> usually if you submit batches with execbuf, we have 3 ways to > >>> synchronize > >>> concurrent submission: implicit sync, sync_file and drm_syncob. They > >>> all > >>> map to different needs in different protocols/render apis. > >>> > >>> Now in one additional case the kernel makes sure that batchbuffers are > >>> ordered, and that's when you submit them to the same hw ctx. Because > >>> there's only 1 hw context and you really can't have batchbuffers run > >>> on > >>> that single hw context out of order. That's what the timeline object > >>> we > >>> talk about here is. But that largely is an internal implementation > >>> detail, > >>> which happens to also use most/all the same infrastructure as the > >>> dma_fence uapi pieces above. > >>> > >>> Now the internal implementation detail leaking here is that we exposed > >>> this to userspace, without there being any need for this. What Jason > >>> implements with syncobj in the next patch is essentially what > >>> userspace > >>> should have been using for cross-engine sync. media userspace doesn't > >>> care > >>> about interop with winsys/client apis, so they equally could have used > >>> implicit sync or sync_file here (which I think is the solution now > >>> for the > >>> new uapi prepped internally), since they all are about equally > >>> powerful > >>> for stringing batchbuffers together. > >> > >> Are you saying we exposed a single timeline of execution per hw context > >> via the single timeline flag?! > > > > Nope. > > > >> Timelines of execution were always exposed. Any "engine" (ring > >> previously) in I915_EXEC_RING_MASK was a single timeline of execution. > >> It is completely the same with engine map engines, which are also > >> different indices into I915_EXEC_RING_MASK space. > >> > >> Userspace was aware of these timelines forever as well. Media was > >> creating multiple contexts to have multiple timelines (so parallelism). > >> Everyone knew that engine-hopping submissions needs to be either > >> implicitly or explicitly synchronised, etc. > > > > Yup, I think we're saying the same thing here. > > > >> So I really don't see that we have leaked timelines as a concept *now*. > >> What the patch has exposed to userspace is a new way to sync between > >> timelines and nothing more. > > > > We've leaked it as something you can now share across hw context. >
Re: [PATCH] drm/dp_mst: Enhance DP MST topology logging
Sorry for the wait! Review comments below
On Thu, 2021-03-18 at 11:55 -0400, Eryk Brol wrote:
> [why]
> MST topology print was missing fec logging and pdt printed
> as an int wasn't clear. vcpi and payload info were also logged as an
> arbitrary series of ints which require the user to know the ordering
> of the prints, making the logs difficult to use.
>
> [how]
> -add fec logging
> -add pdt parsing into strings
> -format vcpi and payload info into tables with headings
> -clean up topology prints
>
> Signed-off-by: Eryk Brol
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 67 ---
> 1 file changed, 51 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 932c4641ec3e..3afeaa59cbaa 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4720,6 +4720,24 @@ static void drm_dp_mst_kick_tx(struct
> drm_dp_mst_topology_mgr *mgr)
> queue_work(system_long_wq, >tx_work);
> }
>
> +static char *pdt_to_string(u8 pdt)
Let's make this static const char *
> +{
> + switch (pdt) {
> + case DP_PEER_DEVICE_NONE:
> + return "NONE";
> + case DP_PEER_DEVICE_SOURCE_OR_SST:
> + return "SOURCE OR SST";
> + case DP_PEER_DEVICE_MST_BRANCHING:
> + return "MST BRANCHING";
> + case DP_PEER_DEVICE_SST_SINK:
> + return "SST SINK";
> + case DP_PEER_DEVICE_DP_LEGACY_CONV:
> + return "DP LEGACY CONV";
> + default:
> + return "ERR";
> + }
> +}
> +
> static void drm_dp_mst_dump_mstb(struct seq_file *m,
> struct drm_dp_mst_branch *mstb)
> {
> @@ -4732,9 +4750,20 @@ static void drm_dp_mst_dump_mstb(struct seq_file *m,
> prefix[i] = '\t';
> prefix[i] = '\0';
>
> - seq_printf(m, "%smst: %p, %d\n", prefix, mstb, mstb->num_ports);
> + seq_printf(m, "%smstb - [%p]: num_ports: %d\n", prefix, mstb, mstb-
> >num_ports);
> list_for_each_entry(port, >ports, next) {
> - seq_printf(m, "%sport: %d: input: %d: pdt: %d, ddps: %d ldps:
> %d, sdp: %d/%d, %p, conn: %p\n", prefix, port->port_num, port->input,
> port->pdt,
> port->ddps, port->ldps, port->num_sdp_streams, port->num_sdp_stream_sinks,
> port,
> port->connector);
> + seq_printf(m, "%sport %d - [%p] (%s - %s): ddps: %d, ldps: %d,
> sdp: %d/%d, fec: %s, conn: %p\n",
> + prefix,
> + port->port_num,
> + port,
> + port->input ? "input" : "output",
> + pdt_to_string(port->pdt),
> + port->ddps,
> + port->ldps,
> + port->num_sdp_streams,
> + port->num_sdp_stream_sinks,
> + port->fec_capable ? "true" : "false",
> + port->connector);
The indenting here is wrong, "i," and all the lines up until the end of the
function call should be aligned to one col after the starting paranthesis
So like this:
seq_printf(m, "foo%d",
bar);
> if (port->mstb)
> drm_dp_mst_dump_mstb(m, port->mstb);
> }
> @@ -4787,33 +4816,39 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
> mutex_unlock(>lock);
>
> mutex_lock(>payload_lock);
> - seq_printf(m, "vcpi: %lx %lx %d\n", mgr->payload_mask, mgr->vcpi_mask,
> - mgr->max_payloads);
> + seq_printf(m, "\n *** VCPI Info ***\npayload_mask: %lx, vcpi_mask:
> %lx,
> max_payloads: %d\n",
There's an extra space between the \n and the ***
> + mgr->payload_mask,
> + mgr->vcpi_mask,
> + mgr->max_payloads);
IMHO I would do the seq_printf() here like this instead:
seq_printf("\n*** VCPI INFO***\n");
seq_printf("payload_mask: %lx, vcpi_mask: %lx, max_payloads: %d\n", ...);
Just to make things a bit easier to read
>
> + seq_printf(m, "\n| idx | port # | vcp_id | # slots | sink
> name |\n");
> for (i = 0; i < mgr->max_payloads; i++) {
> if (mgr->proposed_vcpis[i]) {
> char name[14];
>
> port = container_of(mgr->proposed_vcpis[i], struct
> drm_dp_mst_port, vcpi);
> fetch_monitor_name(mgr, port, name, sizeof(name));
> - seq_printf(m, "vcpi %d: %d %d %d sink name: %s\n", i,
> - port->port_num, port->vcpi.vcpi,
> - port->vcpi.num_slots,
> - (*name != 0) ? name : "Unknown");
> + seq_printf(m, "%10d%10d%10d%10d%20s\n",
> +
Re: [PATCH] drm/ttm: stop warning on TT shrinker failure
On Tue 23-03-21 14:15:05, Daniel Vetter wrote: > On Tue, Mar 23, 2021 at 01:04:03PM +0100, Michal Hocko wrote: > > On Tue 23-03-21 12:48:58, Christian König wrote: > > > Am 23.03.21 um 12:28 schrieb Daniel Vetter: > > > > On Tue, Mar 23, 2021 at 08:38:33AM +0100, Michal Hocko wrote: > > > > > I think this is where I don't get yet what Christian tries to do: We > > > > > really shouldn't do different tricks and calling contexts between > > > > > direct > > > > > reclaim and kswapd reclaim. Otherwise very hard to track down bugs are > > > > > pretty much guaranteed. So whether we use explicit gfp flags or the > > > > > context apis, result is exactly the same. > > > > > > Ok let us recap what TTMs TT shrinker does here: > > > > > > 1. We got memory which is not swapable because it might be accessed by the > > > GPU at any time. > > > 2. Make sure the memory is not accessed by the GPU and driver need to > > > grab a > > > lock before they can make it accessible again. > > > 3. Allocate a shmem file and copy over the not swapable pages. > > > > This is quite tricky because the shrinker operates in the PF_MEMALLOC > > context so such an allocation would be allowed to completely deplete > > memory unless you explicitly mark that context as __GFP_NOMEMALLOC. Also > > note that if the allocation cannot succeed it will not trigger reclaim > > again because you are already called from the reclaim context. > > [Limiting to that discussion] > > Yes it's not emulating real (direct) reclaim correctly, but ime the > biggest issue with direct reclaim is when you do mutex_lock instead of > mutex_trylock or in general block on stuff that you cant. And lockdep + > fs_reclaim annotations gets us that, so pretty good to make sure our > shrinker is correct. I have to confess that I manage to (happily) forget all the nasty details about fs_reclaim lockdep internals so I am not sure the use by the proposed patch is actually reasonable. Talk to lockdep guys about that and make sure to put a big fat comment explaining what is going on. In general allocating from the reclaim context is a bad idea and you should avoid that. As already said a simple allocation request from the reclaim context is not constrained and it will not recurse back into the reclaim. Calling into shmem from the shrinker context might be really tricky as well. I am not even sure this is possible for anything other than full (GFP_KERNEL) reclaim context. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Implement SINGLE_TIMELINE with a syncobj
On Tue, Mar 23, 2021 at 4:35 AM Tvrtko Ursulin
wrote:
>
>
> On 22/03/2021 16:10, Jason Ekstrand wrote:
> > On Mon, Mar 22, 2021 at 7:28 AM Tvrtko Ursulin
>
> [snip]
>
> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> index 96403130a373d..2c56796f6a71b 100644
> >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> >>> @@ -3295,6 +3295,15 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> >>>goto err_vma;
> >>>}
> >>>
> >>> + if (eb.gem_context->syncobj) {
> >>> + struct dma_fence *fence;
> >>> +
> >>> + fence = drm_syncobj_fence_get(eb.gem_context->syncobj);
> >>
> >> Who drops this reference?
> >
> > i915_request_await_dma_fence() below consumes a reference.
>
> Not sure, please check on difference wrt input fence handling.
Gah. You were right. It takes a reference if it needs one. I
thought I was being symmetric with the other syncobj usage but it was
well hidden inside our confusing tear-down paths.
> >>> + err = i915_request_await_dma_fence(eb.request, fence);
> >>> + if (err)
> >>> + goto err_ext;
> >>> + }
> >>> +
> >>>if (in_fence) {
> >>>if (args->flags & I915_EXEC_FENCE_SUBMIT)
> >>>err = i915_request_await_execution(eb.request,
> >>> @@ -3351,6 +3360,12 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> >>>fput(out_fence->file);
> >>>}
> >>>}
> >>> +
> >>> + if (eb.gem_context->syncobj) {
At Daniel's request, I've wrapped these in unlikely()
> >>> + drm_syncobj_replace_fence(eb.gem_context->syncobj,
> >>> + >fence);
> >>> + }
> >>> +
> >>>i915_request_put(eb.request);
> >>>
> >>>err_vma:
> >>>
> >>
> >> So essentially moving the synchronisation to top level which is extra
> >> work, but given limited and questionable usage of the uapi may be
> >> acceptable. Need full picture on motivation to understand.
> >
> > For one thing, the GuC scheduler doesn't natively have a concept of
> > "timelines" which can be shared like this. To work with the GuC
>
> Confused - neither does execlists. It is handled in common layer in
> i915. GuC scheduler has the same concept of one hw context is one
> timeline because that is the hw concept and not backend specific.
>
> > scheduler as currently proposed in DII, they've asked the media driver
> > to stop using this flag in favor of passing a sync file from batch to
> > batch. If we want to slide GuC scheduling in smoothly, we've got to
> > keep it working. This means either making timelines a concept there
> > or doing an emulation like this.
>
> Hm not aware and don't see that GuC backend can't or doesn't implement
> this. Perhaps this would be best discussed once GuC patches are posted.
>
> >> Semantics are also not 1:1 since dma fence context will be different.
> >
> > Could you elaborate?
>
> Exported dma fence context as an "timeline" id will be single with the
> current patch and multiple contexts with this implementation.
>
> Daniel also raised another difference caused by lack of serialisation
> due multiple tl->mutex here.
>
> I don't think this is important, it was never part of a contract what
> happens with racing execbufs, but it is definitely required covering
> both topics in the commit message.
I've updated the commit message as follows:
drm/i915: Implement SINGLE_TIMELINE with a syncobj (v2)
This API is entirely unnecessary and I'd love to get rid of it. If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed. The justification given at the time
was that it would help GL drivers which are inherently single-timeline.
However, neither of our GL drivers actually wanted the feature. i965
was already in maintenance mode at the time and iris uses syncobj for
everything.
Unfortunately, as much as I'd love to get rid of it, it is used by the
media driver so we can't do that. We can, however, do the next-best
thing which is to embed a syncobj in the context and do exactly what
we'd expect from userspace internally. This isn't an entirely identical
implementation because it's no longer atomic if userspace races with
itself by calling execbuffer2 twice simultaneously from different
threads. It won't crash in that case; it just doesn't guarantee any
ordering between those two submits.
Moving SINGLE_TIMELINE to a syncobj emulation has a couple of technical
advantages beyond mere annoyance. One is that intel_timeline is no
longer an api-visible object and can remain entirely an implementation
detail. This may be advantageous as we make
Re: [PATCH] drm/ttm: stop warning on TT shrinker failure
On Tue 23-03-21 14:06:25, Christian König wrote: > Am 23.03.21 um 13:37 schrieb Michal Hocko: > > On Tue 23-03-21 13:21:32, Christian König wrote: [...] > > > Ideally I would like to be able to trigger swapping out the shmem page I > > > allocated immediately after doing the copy. > > So let me try to rephrase to make sure I understand. You would like to > > swap out the existing content from the shrinker and you use shmem as a > > way to achieve that. The swapout should happen at the time of copying > > (shrinker context) or shortly afterwards? > > > > So effectively to call pageout() on the shmem page after the copy? > > Yes, exactly that. OK, good. I see what you are trying to achieve now. I do not think we would want to allow pageout from the shrinker's context but what you can do is to instantiate the shmem page into the tail of the inactive list so the next reclaim attempt will swap it out (assuming swap is available of course). This is not really something that our existing infrastructure gives you though, I am afraid. There is no way to tell a newly allocated shmem page should be in fact cold and the first one to swap out. But there are people more familiar with shmem and its pecularities so I might be wrong here. Anyway, I am wondering whether the overall approach is sound. Why don't you simply use shmem as your backing storage from the beginning and pin those pages if they are used by the device? -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 15/21] drm/tegra: Add new UAPI to header
23.03.2021 19:44, Thierry Reding пишет:
> On Tue, Mar 23, 2021 at 05:00:30PM +0300, Dmitry Osipenko wrote:
>> 23.03.2021 15:30, Thierry Reding пишет:
>>> On Thu, Jan 14, 2021 at 12:34:22PM +0200, Mikko Perttunen wrote:
On 1/14/21 10:36 AM, Dmitry Osipenko wrote:
> 13.01.2021 21:56, Mikko Perttunen пишет:
>> On 1/13/21 8:14 PM, Dmitry Osipenko wrote:
>>> 11.01.2021 16:00, Mikko Perttunen пишет:
+struct drm_tegra_submit_buf {
+ /**
+ * @mapping_id: [in]
+ *
+ * Identifier of the mapping to use in the submission.
+ */
+ __u32 mapping_id;
>>>
>>> I'm now in process of trying out the UAPI using grate drivers and this
>>> becomes the first obstacle.
>>>
>>> Looks like this is not going to work well for older Tegra SoCs, in
>>> particular for T20, which has a small GART.
>>>
>>> Given that the usefulness of the partial mapping feature is very
>>> questionable until it will be proven with a real userspace, we should
>>> start with a dynamic mappings that are done at a time of job submission.
>>>
>>> DRM already should have everything necessary for creating and managing
>>> caches of mappings, grate kernel driver has been using drm_mm_scan for a
>>> long time now for that.
>>>
>>> It should be fine to support the static mapping feature, but it should
>>> be done separately with the drm_mm integration, IMO.
>>>
>>> What do think?
>>>
>>
>> Can you elaborate on the requirements to be able to use GART? Are there
>> any other reasons this would not work on older chips?
>
> We have all DRM devices in a single address space on T30+, hence having
> duplicated mappings for each device should be a bit wasteful.
I guess this should be pretty easy to change to only keep one mapping per
GEM object.
>>>
>>> The important point here is the semantics: this IOCTL establishes a
>>> mapping for a given GEM object on a given channel. If the underlying
>>> implementation is such that the mapping doesn't fit into the GART, then
>>> that's an implementation detail that the driver needs to take care of.
>>> Similarly, if multiple devices share a single address space, that's
>>> something the driver already knows and can take advantage of by simply
>>> reusing an existing mapping if one already exists. In both cases the
>>> semantics would be correctly implemented and that's really all that
>>> matters.
>>>
>>> Overall this interface seems sound from a high-level point of view and
>>> allows these mappings to be properly created even for the cases we have
>>> where each channel may have a separate address space. It may not be the
>>> optimal interface for all use-cases or any one individual case, but the
>>> very nature of these interfaces is to abstract away certain differences
>>> in order to provide a unified interface to a common programming model.
>>> So there will always be certain tradeoffs.
>>
>> For now this IOCTL isn't useful from a userspace perspective of older
>> SoCs and I'll need to add a lot of code that won't do anything useful
>> just to conform to the specific needs of the newer SoCs. Trying to unify
>> everything into a single API doesn't sound like a good idea at this
>> point and I already suggested to Mikko to try out variant with a
>> separated per-SoC code paths in the next version, then the mappings
>> could be handled separately by the T186+ paths.
>
> I'm not sure I understand what you're saying. Obviously the underlying
> implementation of this might have to differ depending on SoC generation.
> But it sounds like you're suggesting having different UAPIs depending on
> SoC generation.
I suggested that this IOCTL shouldn't be mandatory for older SoCs, which
we should to have anyways for preserving the older UAPI. Yes, this makes
UAPI different and I want to see how it will look like in the next
version since the current variant was sub-optimal.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v9 68/70] drm/i915: Pass ww ctx to pin_map
On Tue, 23 Mar 2021 at 15:51, Maarten Lankhorst
wrote:
>
> This will allow us to explicitly pass the ww to pin_pages,
> when it starts taking it.
>
> This allows us to finally kill off the explicit passing of ww
> by retrieving it from the obj.
>
> Signed-off-by: Maarten Lankhorst
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 7 ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.h| 1 +
> .../gpu/drm/i915/gem/i915_gem_object_blt.c| 4 ++--
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 21 +++
> .../drm/i915/gem/selftests/i915_gem_context.c | 8 ---
> .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +-
> drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +-
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_lrc.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_ring.c | 2 +-
> .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_timeline.c | 7 ---
> drivers/gpu/drm/i915/gt/intel_timeline.h | 3 ++-
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> drivers/gpu/drm/i915/gt/mock_engine.c | 2 +-
> drivers/gpu/drm/i915/gt/selftest_lrc.c| 2 +-
> drivers/gpu/drm/i915/gt/selftest_rps.c| 10 -
> .../gpu/drm/i915/gt/selftest_workarounds.c| 6 +++---
> drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 ++--
> drivers/gpu/drm/i915/i915_perf.c | 4 ++--
> drivers/gpu/drm/i915/selftests/igt_spinner.c | 2 +-
> 24 files changed, 60 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index dcfcae9c841b..73dd2a7673f5 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1340,7 +1340,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
> if (err)
> goto err_pool;
>
> - cmd = i915_gem_object_pin_map(pool->obj, pool->type);
> + cmd = i915_gem_object_pin_map(pool->obj, >ww, pool->type);
> if (IS_ERR(cmd)) {
> err = PTR_ERR(cmd);
> goto err_pool;
> @@ -2489,7 +2489,8 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
> goto err_shadow;
> }
>
> - pw->shadow_map = i915_gem_object_pin_map(shadow->obj, I915_MAP_WB);
> + pw->shadow_map = i915_gem_object_pin_map(shadow->obj, >ww,
> +I915_MAP_WB);
> if (IS_ERR(pw->shadow_map)) {
> err = PTR_ERR(pw->shadow_map);
> goto err_trampoline;
> @@ -2500,7 +2501,7 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
>
> pw->batch_map = ERR_PTR(-ENODEV);
> if (needs_clflush && i915_has_memcpy_from_wc())
> - pw->batch_map = i915_gem_object_pin_map(batch, I915_MAP_WC);
> + pw->batch_map = i915_gem_object_pin_map(batch, >ww,
> I915_MAP_WC);
>
> if (IS_ERR(pw->batch_map)) {
> err = i915_gem_object_pin_pages(batch);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 2561a2f1e54f..edac8ee3be9a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -439,7 +439,7 @@ vm_access(struct vm_area_struct *area, unsigned long addr,
> goto out;
>
> /* As this is primarily for debugging, let's focus on simplicity */
> - vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
> + vaddr = i915_gem_object_pin_map(obj, , I915_MAP_FORCE_WC);
> if (IS_ERR(vaddr)) {
> err = PTR_ERR(vaddr);
> goto out;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 1a8ec4035112..9bd9b47dcc8d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -450,6 +450,7 @@ void i915_gem_object_writeback(struct drm_i915_gem_object
> *obj);
> * ERR_PTR() on error.
> */
> void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
> + struct i915_gem_ww_ctx *ww,
>enum i915_map_type type);
>
> void *__must_check i915_gem_object_pin_map_unlocked(struct
> drm_i915_gem_object *obj,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> index df8e8c18c6c9..fae18622d2da 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> @@ -58,7 +58,7 @@ struct i915_vma
Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used
Hi,
On 3/22/21 10:47 PM, Ville Syrjälä wrote:
> On Mon, Mar 22, 2021 at 10:28:06PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 3/22/21 9:59 PM, Ville Syrjälä wrote:
>>> On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/1/21 4:43 PM, Hans de Goede wrote:
>> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
>> displays gracefully on reboot"), the DSI panel on a Cherry Trail based
>> Predia Basic tablet would no longer properly light up after reboot.
>>
>> The backlight still turns back on after reboot, but the LCD shows an
>> all black display. The display is also all black during the time that
>> EFI / the GOP is managing it, so e.g. the grub menu also is not visible.
>>
>> In this scenario the panel is initialized so that it appears to be
>> working
>> and the fastboot code skips doing a modeset. Forcing a modeset by doing a
>> chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
>> /sys/class/graphics/fb0/blank causes the panel to work again.
>>
>> Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
>> a no-op when set; and set this on vlv/chv devices when a DSI panel is
>> detected, to work around this.
>>
>> Admittedly this is a bit of a big hammer, but these platforms have been
>> around for quite some time now and they have always worked fine without
>> the new behavior to shutdown everything on shutdown/reboot. This approach
>> simply disables the recently introduced new shutdown behavior in this
>> specific case where it is known to cause problems. Which is a nice and
>> simple way to deal with this.
>>
>> Signed-off-by: Hans de Goede
>
> Ping? Since sending this patch I've been seeing the issue addressed by
> this on variour other CHT based devices too.
>
> So we have various devices suffering from a black screen after reboot
> now. This is pretty serious usability regression.
>
> As such it would be good to get this reviewed, or another fix proposed.
For the quirks we try to limit them to very specific vendor and model ids,
so I wonder if it would be possible to get this information in here instead
to all the vlv with dsi...
Or avoid the quirk "infra" and skip to all vlv with active dsi?!
Jani?
Ville?
>>>
>>> We need to figure out why the panel doesn't start up again.
>>
>> Note it is the GOP which fails to light it up again. I think we turn
>> something
>> off, which after a power-on-reset is on, so the GOP expects it to be on.
>
> Hmm. Do any of the reboot=warm|cold|whatever knobs make a difference?
> Are there any fast vs. slow boot settings in the BIOS setup?
Ok, so I was running the tests which you requested and during this
I managed to find the real problem.
What happens on reboot is a really quick panel off/on cycle and that is
causing the issue.
I can reproduce this by doing:
chvt 3; echo 1 > /sys/class/graphics/fb0/blank; echo 0 >
/sys/class/graphics/fb0/blank
The problem is that we're not honoring panel_pwr_cycle_delay because
intel_dsi_msleep() is a no-op on devices with a MIPI-sequences version >= 3,
because those sequences already contain the necessary delays, at least
for most of the steps during the on/off sequences. It seems that the
pwr-cycle delay is not handled by those v3+ sequences.
So fixing this is as simple as switching to a regular msleep for the
intel_dsi->panel_pwr_cycle_delay.
Once we do that it would be good (for e.g. suspend/resume speed) to fix:
/*
* FIXME As we do with eDP, just make a note of the time here
* and perform the wait before the next panel power on.
*/
Which sits right above that msleep. Since I have a reproducer now which
shows when the sleep is too short, it should now be easy ti fix the FIXME
and test that the fix works. I'll do this in a separate patch and send
a patch-set with both patches replacing this patch.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drivers: gpu: priv.h is included twice
Reviewed-by: Lyude Paul On Mon, 2021-03-22 at 20:45 +0800, Wan Jiabing wrote: > priv.h has been included at line 22, so remove > the duplicate include at line 24. > > Signed-off-by: Wan Jiabing > --- > drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c > b/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c > index c39e797dc7c9..09524168431c 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c > @@ -20,8 +20,6 @@ > * OTHER DEALINGS IN THE SOFTWARE. > */ > #include "priv.h" > - > -#include "priv.h" > #include > > static void * -- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've asked me a question, are waiting for a review/merge on a patch, etc. and I haven't responded in a while, please feel free to send me another email to check on my status. I don't bite! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
On Tue, 2021-03-23 at 16:06 +0200, Jani Nikula wrote:
> On Thu, 18 Mar 2021, Lyude Paul wrote:
> > Actually-NAK this. I just realized I've been misreading the bug and that
> > this
> > doesn't actually seem to be fixed. Will resend once I figure out what's
> > going on
>
> Well, I think there are actually multiple issues on multiple
> machines. This fixes the issue on ThinkPad X1 Titanium Gen1 [1].
>
> I suspect reverting 98e497e203a5 ("drm/i915/dpcd_bl: uncheck PWM_PIN_CAP
> when detect eDP backlight capabilities") would too. But then that would
> break *other* machines that claim support for *both* eDP PWM pin and
> DPCD backlight control, I think.
>
> I think there are issues with how we try setup DPCD backlight if the GOP
> has set up PWM backlight. For example, we don't set the backlight
> control mode correctly until the next disable/enable sequence. However,
> I tried to fix this, and I think I was doing all the right things, and
> DPCD reads seemed to confirm this, yet I was not able to control
> brightness using DPCD. I don't know what gives, but I do know eDP PWM
> pin control works.
Should we go ahead and push the VESA fix for this then? If you're willing to
test future patches on that machine, we could give another shot at enabling this
in the future if we find reason to.
>
>
> BR,
> Jani.
>
>
> [1] https://gitlab.freedesktop.org/drm/intel/-/issues/3158
>
>
> >
> > On Thu, 2021-03-18 at 13:02 -0400, Lyude Paul wrote:
> > > Looks like that there actually are another subset of laptops on the market
> > > that don't support the Intel HDR backlight interface, but do advertise
> > > support for the VESA DPCD backlight interface despite the fact it doesn't
> > > seem to work.
> > >
> > > Note though I'm not entirely clear on this - on one of the machines where
> > > this issue was observed, I also noticed that we appeared to be rejecting
> > > the VBT defined backlight frequency in
> > > intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:
> > >
> > > /* Use highest possible value of Pn for more granularity of brightness
> > > * adjustment while satifying the conditions below.
> > > * ...
> > > * - FxP is within 25% of desired value.
> > > * Note: 25% is arbitrary value and may need some tweak.
> > > */
> > >
> > > So it's possible that this value might just need to be tweaked, but for
> > > now
> > > let's just disable the VESA backlight interface unless it's specified in
> > > the VBT just to be safe. We might be able to try enabling this again by
> > > default in the future.
> > >
> > > Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces
> > > through
> > > enable_dpcd_backlight")
> > > Cc: Jani Nikula
> > > Cc: Rodrigo Vivi
> > > Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
> > > Signed-off-by: Lyude Paul
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > index 651884390137..4f8337c7fd2e 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > @@ -646,7 +646,6 @@ int intel_dp_aux_init_backlight_funcs(struct
> > > intel_connector *connector)
> > > break;
> > > case INTEL_BACKLIGHT_DISPLAY_DDI:
> > > try_intel_interface = true;
> > > - try_vesa_interface = true;
> > > break;
> > > default:
> > > return -ENODEV;
>
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/amd/display/dc/calcs/dce_calcs: Fix allocation size for dceip and vbios
On Tue, 23 Mar 2021, Colin King wrote:
> From: Colin Ian King
>
> Currently the allocations for dceip and vbios are based on the size of
> the pointer rather than the size of the data structures, causing heap
> issues. Fix this by using the correct allocation sizes.
>
> Addresses-Coverity: ("Wrong size of argument")
> Fixes: a2a855772210 ("drm/amd/display/dc/calcs/dce_calcs: Remove some large
> variables from the stack")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Fixed already mate.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages
On 3/23/21 5:37 PM, Jason Gunthorpe wrote: On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas Hellström (Intel) wrote: @@ -210,6 +211,20 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault *vmf, if ((pfn & (fault_page_size - 1)) != 0) goto out_fallback; + /* +* Huge entries must be special, that is marking them as devmap +* with no backing device map range. If there is a backing +* range, Don't insert a huge entry. +* If this check turns out to be too much of a performance hit, +* we can instead have drivers indicate whether they may have +* backing device map ranges and if not, skip this lookup. +*/ I think we can do this statically: - if it's system memory we know there's no devmap for it, and we do the trick to block gup_fast Yes, that should work. - if it's iomem, we know gup_fast wont work anyway if don't set PFN_DEV, so might as well not do that I think gup_fast will unfortunately mistake a huge iomem page for an ordinary page and try to access a non-existant struct page for it, unless we do the devmap trick. And the lookup would then be for the rare case where a driver would have already registered a dev_pagemap for an iomem area which may also be mapped through TTM (like the patch from Felix a couple of weeks ago). If a driver can promise not to do that, then we can safely remove the lookup. Isn't the devmap PTE flag arch optional? Does this fall back to not using huge pages on arches that don't support it? Good point. No, currently it's only conditioned on transhuge page support. Need to condition it on also devmap support. Also, I feel like this code to install "pte_special" huge pages does not belong in the drm subsystem.. I could add helpers in huge_memory.c: vmf_insert_pfn_pmd_prot_special() and vmf_insert_pfn_pud_prot_special() /Thomas Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 20/21] drm/tegra: Implement job submission part of new UAPI
On Tue, Mar 23, 2021 at 04:16:00PM +0200, Mikko Perttunen wrote:
> On 3/23/21 3:38 PM, Thierry Reding wrote:
> > On Mon, Jan 11, 2021 at 03:00:18PM +0200, Mikko Perttunen wrote:
> > > Implement the job submission IOCTL with a minimum feature set.
> > >
> > > Signed-off-by: Mikko Perttunen
> > > ---
> > > v5:
> > > * Add 16K size limit to copies from userspace.
> > > * Guard RELOC_BLOCKLINEAR flag handling to only exist in ARM64
> > >to prevent oversized shift on 32-bit platforms.
> > > v4:
> > > * Remove all features that are not strictly necessary.
> > > * Split into two patches.
> > > v3:
> > > * Remove WRITE_RELOC. Relocations are now patched implicitly
> > >when patching is needed.
> > > * Directly call PM runtime APIs on devices instead of using
> > >power_on/power_off callbacks.
> > > * Remove incorrect mutex unlock in tegra_drm_ioctl_channel_open
> > > * Use XA_FLAGS_ALLOC1 instead of XA_FLAGS_ALLOC
> > > * Accommodate for removal of timeout field and inlining of
> > >syncpt_incrs array.
> > > * Copy entire user arrays at a time instead of going through
> > >elements one-by-one.
> > > * Implement waiting of DMA reservations.
> > > * Split out gather_bo implementation into a separate file.
> > > * Fix length parameter passed to sg_init_one in gather_bo
> > > * Cosmetic cleanup.
> > > ---
> > > drivers/gpu/drm/tegra/Makefile | 2 +
> > > drivers/gpu/drm/tegra/drm.c| 2 +
> > > drivers/gpu/drm/tegra/uapi/gather_bo.c | 86 +
> > > drivers/gpu/drm/tegra/uapi/gather_bo.h | 22 ++
> > > drivers/gpu/drm/tegra/uapi/submit.c| 428 +
> > > drivers/gpu/drm/tegra/uapi/submit.h| 17 +
> > > 6 files changed, 557 insertions(+)
> > > create mode 100644 drivers/gpu/drm/tegra/uapi/gather_bo.c
> > > create mode 100644 drivers/gpu/drm/tegra/uapi/gather_bo.h
> > > create mode 100644 drivers/gpu/drm/tegra/uapi/submit.c
> > > create mode 100644 drivers/gpu/drm/tegra/uapi/submit.h
> > >
> > > diff --git a/drivers/gpu/drm/tegra/Makefile
> > > b/drivers/gpu/drm/tegra/Makefile
> > > index 0abdb21b38b9..059322e88943 100644
> > > --- a/drivers/gpu/drm/tegra/Makefile
> > > +++ b/drivers/gpu/drm/tegra/Makefile
> > > @@ -4,6 +4,8 @@ ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG
> > > tegra-drm-y := \
> > > drm.o \
> > > uapi/uapi.o \
> > > + uapi/submit.o \
> > > + uapi/gather_bo.o \
> > > gem.o \
> > > fb.o \
> > > dp.o \
> > > diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> > > index 6a51035ce33f..60eab403ae9b 100644
> > > --- a/drivers/gpu/drm/tegra/drm.c
> > > +++ b/drivers/gpu/drm/tegra/drm.c
> > > @@ -737,6 +737,8 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[]
> > > = {
> > > DRM_RENDER_ALLOW),
> > > DRM_IOCTL_DEF_DRV(TEGRA_CHANNEL_UNMAP,
> > > tegra_drm_ioctl_channel_unmap,
> > > DRM_RENDER_ALLOW),
> > > + DRM_IOCTL_DEF_DRV(TEGRA_CHANNEL_SUBMIT, tegra_drm_ioctl_channel_submit,
> > > + DRM_RENDER_ALLOW),
> > > DRM_IOCTL_DEF_DRV(TEGRA_GEM_CREATE, tegra_drm_ioctl_gem_create,
> > > DRM_RENDER_ALLOW),
> > > DRM_IOCTL_DEF_DRV(TEGRA_GEM_MMAP, tegra_drm_ioctl_gem_mmap,
> > > diff --git a/drivers/gpu/drm/tegra/uapi/gather_bo.c
> > > b/drivers/gpu/drm/tegra/uapi/gather_bo.c
> > > new file mode 100644
> > > index ..b487a0d44648
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/tegra/uapi/gather_bo.c
> > > @@ -0,0 +1,86 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/* Copyright (c) 2020 NVIDIA Corporation */
> > > +
> > > +#include
> > > +#include
> > > +
> > > +#include "gather_bo.h"
> > > +
> > > +static struct host1x_bo *gather_bo_get(struct host1x_bo *host_bo)
> > > +{
> > > + struct gather_bo *bo = container_of(host_bo, struct gather_bo, base);
> > > +
> > > + kref_get(>ref);
> > > +
> > > + return host_bo;
> > > +}
> > > +
> > > +static void gather_bo_release(struct kref *ref)
> > > +{
> > > + struct gather_bo *bo = container_of(ref, struct gather_bo, ref);
> > > +
> > > + kfree(bo->gather_data);
> > > + kfree(bo);
> > > +}
> > > +
> > > +void gather_bo_put(struct host1x_bo *host_bo)
> > > +{
> > > + struct gather_bo *bo = container_of(host_bo, struct gather_bo, base);
> > > +
> > > + kref_put(>ref, gather_bo_release);
> > > +}
> > > +
> > > +static struct sg_table *
> > > +gather_bo_pin(struct device *dev, struct host1x_bo *host_bo, dma_addr_t
> > > *phys)
> > > +{
> > > + struct gather_bo *bo = container_of(host_bo, struct gather_bo, base);
> > > + struct sg_table *sgt;
> > > + int err;
> > > +
> > > + if (phys) {
> > > + *phys = virt_to_phys(bo->gather_data);
> > > + return NULL;
> > > + }
> > > +
> > > + sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
> > > + if (!sgt)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + err = sg_alloc_table(sgt, 1, GFP_KERNEL);
> > > +
Re: [PATCH 2/2] drm/doc: Add RFC section
Side note: I feel like we could have better lines of communication between kernel devs and user-space devs. The new uAPI requirements seem to be a high barrier to entry for kernel devs. However sometimes user-space devs might be interested in helping out with the user-space part… Maybe it would be good to CC e.g. wayland-devel for new RFCs, so that user-space devs can jump in if they're interested. And also provide feedback, since new uAPI is hard to spot in the sea of messages in dri-devel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 19/21] drm/tegra: Implement new UAPI
On Tue, Mar 23, 2021 at 06:00:34PM +0300, Dmitry Osipenko wrote: > 23.03.2021 17:43, Mikko Perttunen пишет: > >> > >> FWIW, I would've been fine with stashing all of this into drm.c as well > >> since the rest of the UAPI is in that already. The churn in this patch > >> is reasonably small, but it would've been even less if this was just all > >> in drm.c. > > > > I think we shouldn't have the uapi in drm.c -- it just makes the file a > > bit of a dumping ground. I think drm.c should have the code that relates > > to initialization and initial registration with DRM. > > +1 drm.c is already very unmanageable / difficult to follow, it > absolutely must be split up. I guess this comes down to personal preference. I don't find it difficult to navigate large files. On the contrary, I find it much more challenging to navigate a code base spread over lots and lots of files. I don't feel strongly about moving this code into a separate file, though, but let's maybe compromise and leave it at that. No need to split this out into 5 (or whatever it was) different tiny files that the end result of this series seems to yield. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212369] AMDGPU: GPU hangs with '*ERROR* Couldn't update BO_VA (-12)' on MIPS64
https://bugzilla.kernel.org/show_bug.cgi?id=212369 --- Comment #2 from Xi Ruoyao (xry...@mengyan1223.wang) --- With some workarounds, bisection gives: first bad commit: [5b8c596976d4338942dd889b66cd06dc766424e1] Merge tag 'amd-drm-next-5.11-2020-11-05' of git://people.freedesktop.org/~agd5f/linux into drm-next -- You may reply to this email to add a comment. 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 1/9] drm/fourcc: Add macro to check for the modifier vendor
On Tue, Mar 23, 2021 at 04:04:35PM +, Simon Ser wrote: > Can we instead have a macro/function to get the vendor? This would be > useful elsewhere as well, see drmGetFormatModifierVendor in a recent-ish > libdrm patch [1]. > > [1]: > https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/108/diffs#91ecb12b27c7154b26013bb95e17a5cc24ea443e_947_947 Either way would work. I chose this because it ends up being much shorter than extracting the vendor and comparing to the constant. Maybe we should just add both? 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 v5 15/21] drm/tegra: Add new UAPI to header
On Tue, Mar 23, 2021 at 05:00:30PM +0300, Dmitry Osipenko wrote:
> 23.03.2021 15:30, Thierry Reding пишет:
> > On Thu, Jan 14, 2021 at 12:34:22PM +0200, Mikko Perttunen wrote:
> >> On 1/14/21 10:36 AM, Dmitry Osipenko wrote:
> >>> 13.01.2021 21:56, Mikko Perttunen пишет:
> On 1/13/21 8:14 PM, Dmitry Osipenko wrote:
> > 11.01.2021 16:00, Mikko Perttunen пишет:
> >> +struct drm_tegra_submit_buf {
> >> + /**
> >> + * @mapping_id: [in]
> >> + *
> >> + * Identifier of the mapping to use in the submission.
> >> + */
> >> + __u32 mapping_id;
> >
> > I'm now in process of trying out the UAPI using grate drivers and this
> > becomes the first obstacle.
> >
> > Looks like this is not going to work well for older Tegra SoCs, in
> > particular for T20, which has a small GART.
> >
> > Given that the usefulness of the partial mapping feature is very
> > questionable until it will be proven with a real userspace, we should
> > start with a dynamic mappings that are done at a time of job submission.
> >
> > DRM already should have everything necessary for creating and managing
> > caches of mappings, grate kernel driver has been using drm_mm_scan for a
> > long time now for that.
> >
> > It should be fine to support the static mapping feature, but it should
> > be done separately with the drm_mm integration, IMO.
> >
> > What do think?
> >
>
> Can you elaborate on the requirements to be able to use GART? Are there
> any other reasons this would not work on older chips?
> >>>
> >>> We have all DRM devices in a single address space on T30+, hence having
> >>> duplicated mappings for each device should be a bit wasteful.
> >>
> >> I guess this should be pretty easy to change to only keep one mapping per
> >> GEM object.
> >
> > The important point here is the semantics: this IOCTL establishes a
> > mapping for a given GEM object on a given channel. If the underlying
> > implementation is such that the mapping doesn't fit into the GART, then
> > that's an implementation detail that the driver needs to take care of.
> > Similarly, if multiple devices share a single address space, that's
> > something the driver already knows and can take advantage of by simply
> > reusing an existing mapping if one already exists. In both cases the
> > semantics would be correctly implemented and that's really all that
> > matters.
> >
> > Overall this interface seems sound from a high-level point of view and
> > allows these mappings to be properly created even for the cases we have
> > where each channel may have a separate address space. It may not be the
> > optimal interface for all use-cases or any one individual case, but the
> > very nature of these interfaces is to abstract away certain differences
> > in order to provide a unified interface to a common programming model.
> > So there will always be certain tradeoffs.
>
> For now this IOCTL isn't useful from a userspace perspective of older
> SoCs and I'll need to add a lot of code that won't do anything useful
> just to conform to the specific needs of the newer SoCs. Trying to unify
> everything into a single API doesn't sound like a good idea at this
> point and I already suggested to Mikko to try out variant with a
> separated per-SoC code paths in the next version, then the mappings
> could be handled separately by the T186+ paths.
I'm not sure I understand what you're saying. Obviously the underlying
implementation of this might have to differ depending on SoC generation.
But it sounds like you're suggesting having different UAPIs depending on
SoC generation.
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] drm/ttm: stop warning on TT shrinker failure
On Tue 23-03-21 13:21:32, Christian König wrote: > Am 23.03.21 um 13:04 schrieb Michal Hocko: > > On Tue 23-03-21 12:48:58, Christian König wrote: > > > Am 23.03.21 um 12:28 schrieb Daniel Vetter: > > > > On Tue, Mar 23, 2021 at 08:38:33AM +0100, Michal Hocko wrote: > > > > > On Mon 22-03-21 20:34:25, Christian König wrote: > > [...] > > > > > > My only concern is that if I could rely on memalloc_no* being used > > > > > > we could > > > > > > optimize this quite a bit further. > > > > > Yes you can use the scope API and you will be guaranteed that _any_ > > > > > allocation from the enclosed context will inherit GFP_NO* semantic. > > > The question is if this is also guaranteed the other way around? > > > > > > In other words if somebody calls get_free_page(GFP_NOFS) are the context > > > flags set as well? > > gfp mask is always restricted in the page allocator. So say you have > > noio scope context and call get_free_page/kmalloc(GFP_NOFS) then the > > scope would restrict the allocation flags to GFP_NOIO (aka drop > > __GFP_IO). For further details, have a look at current_gfp_context > > and its callers. > > > > Does this answer your question? > > But what happens if you don't have noio scope and somebody calls > get_free_page(GFP_NOFS)? Then this will be a regular NOFS request. Let me repeat scope API will further restrict any requested allocation mode. > Is then the noio scope added automatically? And is it possible that the > shrinker gets called without noio scope even we would need it? Here you have lost me again. > > > > > I think this is where I don't get yet what Christian tries to do: We > > > > > really shouldn't do different tricks and calling contexts between > > > > > direct > > > > > reclaim and kswapd reclaim. Otherwise very hard to track down bugs are > > > > > pretty much guaranteed. So whether we use explicit gfp flags or the > > > > > context apis, result is exactly the same. > > > Ok let us recap what TTMs TT shrinker does here: > > > > > > 1. We got memory which is not swapable because it might be accessed by the > > > GPU at any time. > > > 2. Make sure the memory is not accessed by the GPU and driver need to > > > grab a > > > lock before they can make it accessible again. > > > 3. Allocate a shmem file and copy over the not swapable pages. > > This is quite tricky because the shrinker operates in the PF_MEMALLOC > > context so such an allocation would be allowed to completely deplete > > memory unless you explicitly mark that context as __GFP_NOMEMALLOC. > > Thanks, exactly that was one thing I was absolutely not sure about. And yes > I agree that this is really tricky. > > Ideally I would like to be able to trigger swapping out the shmem page I > allocated immediately after doing the copy. So let me try to rephrase to make sure I understand. You would like to swap out the existing content from the shrinker and you use shmem as a way to achieve that. The swapout should happen at the time of copying (shrinker context) or shortly afterwards? So effectively to call pageout() on the shmem page after the copy? > This way I would only need a single page for the whole shrink operation at > any given time. What do you mean by that? You want the share the same shmem page for other copy+swapout? -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages
On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas Hellström (Intel) wrote: > > > @@ -210,6 +211,20 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct > > > vm_fault *vmf, > > > if ((pfn & (fault_page_size - 1)) != 0) > > > goto out_fallback; > > > + /* > > > + * Huge entries must be special, that is marking them as devmap > > > + * with no backing device map range. If there is a backing > > > + * range, Don't insert a huge entry. > > > + * If this check turns out to be too much of a performance hit, > > > + * we can instead have drivers indicate whether they may have > > > + * backing device map ranges and if not, skip this lookup. > > > + */ > > I think we can do this statically: > > - if it's system memory we know there's no devmap for it, and we do the > >trick to block gup_fast > Yes, that should work. > > - if it's iomem, we know gup_fast wont work anyway if don't set PFN_DEV, > >so might as well not do that > > I think gup_fast will unfortunately mistake a huge iomem page for an > ordinary page and try to access a non-existant struct page for it, unless we > do the devmap trick. > > And the lookup would then be for the rare case where a driver would have > already registered a dev_pagemap for an iomem area which may also be mapped > through TTM (like the patch from Felix a couple of weeks ago). If a driver > can promise not to do that, then we can safely remove the lookup. Isn't the devmap PTE flag arch optional? Does this fall back to not using huge pages on arches that don't support it? Also, I feel like this code to install "pte_special" huge pages does not belong in the drm subsystem.. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages
Hi, On 3/23/21 12:34 PM, Daniel Vetter wrote: On Sun, Mar 21, 2021 at 07:45:28PM +0100, Thomas Hellström (Intel) wrote: TTM sets up huge page-table-entries both to system- and device memory, and we don't want gup to assume there are always valid backing struct pages for these. For PTEs this is handled by setting the pte_special bit, but for the huge PUDs and PMDs, we have neither pmd_special nor pud_special. Normally, huge TTM entries are identified by looking at vma_is_special_huge(), but fast gup can't do that, so as an alternative define _devmap entries for which there are no backing dev_pagemap as special, update documentation and make huge TTM entries _devmap, after verifying that there is no backing dev_pagemap. One other alternative would be to block TTM huge page-table-entries completely, and while currently only vmwgfx use them, they would be beneficial to other graphis drivers moving forward as well. Cc: Christian Koenig Cc: David Airlie Cc: Daniel Vetter Cc: Andrew Morton Cc: Jason Gunthorpe Cc: linux...@kvack.org Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Thomas Hellström (Intel) --- drivers/gpu/drm/ttm/ttm_bo_vm.c | 17 - mm/gup.c| 21 +++-- mm/memremap.c | 5 + 3 files changed, 32 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index 6dc96cf66744..1c34983480e5 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -195,6 +195,7 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault *vmf, pfn_t pfnt; struct ttm_tt *ttm = bo->ttm; bool write = vmf->flags & FAULT_FLAG_WRITE; + struct dev_pagemap *pagemap; /* Fault should not cross bo boundary. */ page_offset &= ~(fault_page_size - 1); @@ -210,6 +211,20 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault *vmf, if ((pfn & (fault_page_size - 1)) != 0) goto out_fallback; + /* +* Huge entries must be special, that is marking them as devmap +* with no backing device map range. If there is a backing +* range, Don't insert a huge entry. +* If this check turns out to be too much of a performance hit, +* we can instead have drivers indicate whether they may have +* backing device map ranges and if not, skip this lookup. +*/ I think we can do this statically: - if it's system memory we know there's no devmap for it, and we do the trick to block gup_fast Yes, that should work. - if it's iomem, we know gup_fast wont work anyway if don't set PFN_DEV, so might as well not do that I think gup_fast will unfortunately mistake a huge iomem page for an ordinary page and try to access a non-existant struct page for it, unless we do the devmap trick. And the lookup would then be for the rare case where a driver would have already registered a dev_pagemap for an iomem area which may also be mapped through TTM (like the patch from Felix a couple of weeks ago). If a driver can promise not to do that, then we can safely remove the lookup. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API
On 23/03/2021 13:23, Daniel Vetter wrote: On Tue, Mar 23, 2021 at 09:14:36AM +, Tvrtko Ursulin wrote: On 22/03/2021 16:43, Daniel Vetter wrote: On Mon, Mar 22, 2021 at 4:31 PM Tvrtko Ursulin wrote: On 22/03/2021 14:57, Daniel Vetter wrote: On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin wrote: On 22/03/2021 14:09, Daniel Vetter wrote: On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote: On 19/03/2021 22:38, Jason Ekstrand wrote: This API allows one context to grab bits out of another context upon creation. It can be used as a short-cut for setparam(getparam()) for things like I915_CONTEXT_PARAM_VM. However, it's never been used by any real userspace. It's used by a few IGT tests and that's it. Since it doesn't add any real value (most of the stuff you can CLONE you can copy in other ways), drop it. No complaints to remove if it ended up unused outside IGT. Latter is a _big_ problem though, since it is much more that a few IGT tests. So I really think there really needs to be an evaluation and a plan for that (we don't want to lose 50% of the coverage over night). There is one thing that this API allows you to clone which you cannot clone via getparam/setparam: timelines. However, timelines are an implementation detail of i915 and not really something that needs to be Not really true timelines are i915 implementation detail. They are in fact a dma-fence context:seqno concept, nothing more that than. I think you are probably confusing struct intel_timeline with the timeline wording in the uapi. Former is i915 implementation detail, but context:seqno are truly userspace timelines. I think you're both saying the same thing and talking a bit past each another. Yes the timeline is just a string of dma_fence, that's correct. Now usually if you submit batches with execbuf, we have 3 ways to synchronize concurrent submission: implicit sync, sync_file and drm_syncob. They all map to different needs in different protocols/render apis. Now in one additional case the kernel makes sure that batchbuffers are ordered, and that's when you submit them to the same hw ctx. Because there's only 1 hw context and you really can't have batchbuffers run on that single hw context out of order. That's what the timeline object we talk about here is. But that largely is an internal implementation detail, which happens to also use most/all the same infrastructure as the dma_fence uapi pieces above. Now the internal implementation detail leaking here is that we exposed this to userspace, without there being any need for this. What Jason implements with syncobj in the next patch is essentially what userspace should have been using for cross-engine sync. media userspace doesn't care about interop with winsys/client apis, so they equally could have used implicit sync or sync_file here (which I think is the solution now for the new uapi prepped internally), since they all are about equally powerful for stringing batchbuffers together. Are you saying we exposed a single timeline of execution per hw context via the single timeline flag?! Nope. Timelines of execution were always exposed. Any "engine" (ring previously) in I915_EXEC_RING_MASK was a single timeline of execution. It is completely the same with engine map engines, which are also different indices into I915_EXEC_RING_MASK space. Userspace was aware of these timelines forever as well. Media was creating multiple contexts to have multiple timelines (so parallelism). Everyone knew that engine-hopping submissions needs to be either implicitly or explicitly synchronised, etc. Yup, I think we're saying the same thing here. So I really don't see that we have leaked timelines as a concept *now*. What the patch has exposed to userspace is a new way to sync between timelines and nothing more. We've leaked it as something you can now share across hw context. Okay so we agree on most things but apparently have different definitions of what it means to leak internal implementation details. While at the same time proof that we haven't leaked the internal implementation details is that Jason was able to implement the single timeline flag with a drm syncobj at the execbuf top level. (Well mostly, ignoring the probably inconsequential difference of one vs multiple fence contexts.) It's not a matching implementation. It's only good enough for what media needs, and essentially what media should have done to begin with. There's substantially different behaviour between SINGLE_TIMELINE and what Jason has done here when you race concurrent execbuf calls: Former guarantees total ordering, the latter doesn't even try. They are not the same thing, but luckily userspace doesn't care about that difference. Sounds like a very important difference to stress in the commit message. Secondly, I am unclear whether we have agreement on whether the single timeline flag is leaking implementation details of the execlists scheduler to userspace or
Re: [Intel-gfx] [PATCH v9 32/70] drm/i915: Prepare for obj->mm.lock removal, v2.
On Tue, 23 Mar 2021 at 15:52, Maarten Lankhorst
wrote:
>
> From: Thomas Hellström
>
> Stolen objects need to lock, and we may call put_pages when
> refcount drops to 0, ensure all calls are handled correctly.
>
> Changes since v1:
> - Rebase on top of upstream changes.
>
> Idea-from: Thomas Hellström
> Signed-off-by: Maarten Lankhorst
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 14 ++
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 14 --
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 12 +++-
> 3 files changed, 33 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 983f2d4b2a85..74de195b57de 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -144,6 +144,20 @@ i915_gem_object_put(struct drm_i915_gem_object *obj)
>
> #define assert_object_held(obj) dma_resv_assert_held((obj)->base.resv)
>
> +/*
> + * If more than one potential simultaneous locker, assert held.
> + */
> +static inline void assert_object_held_shared(struct drm_i915_gem_object *obj)
> +{
> + /*
> +* Note mm list lookup is protected by
What is meant with mm list here? Maybe just a stale comment?
> +* kref_get_unless_zero().
> +*/
> + if (IS_ENABLED(CONFIG_LOCKDEP) &&
> + kref_read(>base.refcount) > 0)
> + lockdep_assert_held(>mm.lock);
> +}
> +
> static inline int __i915_gem_object_lock(struct drm_i915_gem_object *obj,
> struct i915_gem_ww_ctx *ww,
> bool intr)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index a24617af3c93..2d0065fa6e80 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -19,7 +19,7 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object
> *obj,
> bool shrinkable;
> int i;
>
> - lockdep_assert_held(>mm.lock);
> + assert_object_held_shared(obj);
>
> if (i915_gem_object_is_volatile(obj))
> obj->mm.madv = I915_MADV_DONTNEED;
> @@ -70,6 +70,7 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object
> *obj,
> struct list_head *list;
> unsigned long flags;
>
> + lockdep_assert_held(>mm.lock);
> spin_lock_irqsave(>mm.obj_lock, flags);
>
> i915->mm.shrink_count++;
> @@ -91,6 +92,8 @@ int i915_gem_object_get_pages(struct
> drm_i915_gem_object *obj)
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
> int err;
>
> + assert_object_held_shared(obj);
> +
> if (unlikely(obj->mm.madv != I915_MADV_WILLNEED)) {
> drm_dbg(>drm,
> "Attempting to obtain a purgeable object\n");
> @@ -118,6 +121,8 @@ int __i915_gem_object_get_pages(struct
> drm_i915_gem_object *obj)
> if (err)
> return err;
>
> + assert_object_held_shared(obj);
> +
> if (unlikely(!i915_gem_object_has_pages(obj))) {
> GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
>
> @@ -145,7 +150,7 @@ void i915_gem_object_truncate(struct drm_i915_gem_object
> *obj)
> /* Try to discard unwanted pages */
> void i915_gem_object_writeback(struct drm_i915_gem_object *obj)
> {
> - lockdep_assert_held(>mm.lock);
> + assert_object_held_shared(obj);
> GEM_BUG_ON(i915_gem_object_has_pages(obj));
>
> if (obj->ops->writeback)
> @@ -176,6 +181,8 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object
> *obj)
> {
> struct sg_table *pages;
>
> + assert_object_held_shared(obj);
> +
> pages = fetch_and_zero(>mm.pages);
> if (IS_ERR_OR_NULL(pages))
> return pages;
> @@ -203,6 +210,9 @@ int __i915_gem_object_put_pages_locked(struct
> drm_i915_gem_object *obj)
> if (i915_gem_object_has_pinned_pages(obj))
> return -EBUSY;
>
> + /* May be called by shrinker from within get_pages() (on another bo)
> */
> + assert_object_held_shared(obj);
> +
> i915_gem_object_release_mmap_offset(obj);
>
> /*
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index 7cdb32d881d9..b0597de206de 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -637,13 +637,15 @@ static int __i915_gem_object_create_stolen(struct
> intel_memory_region *mem,
> cache_level = HAS_LLC(mem->i915) ? I915_CACHE_LLC : I915_CACHE_NONE;
> i915_gem_object_set_cache_coherency(obj, cache_level);
>
> - err = i915_gem_object_pin_pages(obj);
> - if (err)
> - return err;
> + if
Re: [PATCH] drm/ttm: stop warning on TT shrinker failure
On Tue 23-03-21 12:51:13, Christian König wrote: > > > Am 23.03.21 um 12:46 schrieb Michal Hocko: > > On Tue 23-03-21 12:28:20, Daniel Vetter wrote: > > > On Tue, Mar 23, 2021 at 08:38:33AM +0100, Michal Hocko wrote: > > [...] > > > > > > fs_reclaim_acquire is there to make sure lockdep understands that > > > > > > this > > > > > > is a shrinker and that it checks all the dependencies for us like if > > > > > > we'd be in real reclaim. There is some drop caches interfaces in > > > > > > proc > > > > > > iirc, but those drop everything, and they don't have the fs_reclaim > > > > > > annotations to teach lockdep about what we're doing. > > > > ... I really do not follow this. You shouldn't really care whether this > > > > is a reclaim interface or not. Or maybe I just do not understand this... > > > We're heavily relying on lockdep and fs_reclaim to make sure we get it all > > > right. So any drop caches interface that isn't wrapped in fs_reclaim > > > context is kinda useless for testing. Plus ideally we want to only hit our > > > own paths, and not trash every other cache in the system. Speed matters in > > > CI. > > But what is special about this path to hack around and make it pretend > > it is part of the fs reclaim path? > > That's just to teach lockdep that there is a dependency. > > In other words we pretend in the debugfs file that it is part of the fs > reclaim path to check for the case when it really becomes part of the fs > reclaim path. OK, our emails crossed and I can see your response only after replying to your other email. OK, this makes more sense now. But as pointed in other email this will likely not do what you think. Let's continue discussing in the other subthread to reduce the further confusion. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 2/2] mm,drm/ttm: Use VM_PFNMAP for TTM vmas
On Tue, Mar 23, 2021 at 04:46:00PM +0100, Thomas Hellström (Intel) wrote:
> > > +static inline bool is_cow_mapping(vm_flags_t flags)
> > > +{
> > > + return (flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE;
> > > +}
> > Most driver places are just banning VM_SHARED.
> >
> > I see you copied this from remap_pfn_range(), but that logic is so
> > special I'm not sure..
>
> It's actually used all over the place. Both in drivers and also redefined
> with
> CONFIG_MEM_SOFT_DIRTY which makes me think Daniels idea of
> vma_is_cow_mapping() is better since it won't clash and cause compilation
> failures...
Well, lets update more mmap fops to use this new helper then?
Searching for VM_SHARED gives a good list, there are several in
drivers/infiniband
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm/fourcc: Add macro to check for the modifier vendor
Can we instead have a macro/function to get the vendor? This would be useful elsewhere as well, see drmGetFormatModifierVendor in a recent-ish libdrm patch [1]. [1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/108/diffs#91ecb12b27c7154b26013bb95e17a5cc24ea443e_947_947 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: stop warning on TT shrinker failure
On Tue 23-03-21 12:48:58, Christian König wrote: > Am 23.03.21 um 12:28 schrieb Daniel Vetter: > > On Tue, Mar 23, 2021 at 08:38:33AM +0100, Michal Hocko wrote: > > > On Mon 22-03-21 20:34:25, Christian König wrote: [...] > > > > My only concern is that if I could rely on memalloc_no* being used we > > > > could > > > > optimize this quite a bit further. > > > Yes you can use the scope API and you will be guaranteed that _any_ > > > allocation from the enclosed context will inherit GFP_NO* semantic. > > The question is if this is also guaranteed the other way around? > > In other words if somebody calls get_free_page(GFP_NOFS) are the context > flags set as well? gfp mask is always restricted in the page allocator. So say you have noio scope context and call get_free_page/kmalloc(GFP_NOFS) then the scope would restrict the allocation flags to GFP_NOIO (aka drop __GFP_IO). For further details, have a look at current_gfp_context and its callers. Does this answer your question? > > > I think this is where I don't get yet what Christian tries to do: We > > > really shouldn't do different tricks and calling contexts between direct > > > reclaim and kswapd reclaim. Otherwise very hard to track down bugs are > > > pretty much guaranteed. So whether we use explicit gfp flags or the > > > context apis, result is exactly the same. > > Ok let us recap what TTMs TT shrinker does here: > > 1. We got memory which is not swapable because it might be accessed by the > GPU at any time. > 2. Make sure the memory is not accessed by the GPU and driver need to grab a > lock before they can make it accessible again. > 3. Allocate a shmem file and copy over the not swapable pages. This is quite tricky because the shrinker operates in the PF_MEMALLOC context so such an allocation would be allowed to completely deplete memory unless you explicitly mark that context as __GFP_NOMEMALLOC. Also note that if the allocation cannot succeed it will not trigger reclaim again because you are already called from the reclaim context. > 4. Free the not swapable/reclaimable pages. > > The pages we got from the shmem file are easily swapable to disk after the > copy is completed. But only if IO is not already blocked because the > shrinker was called from an allocation restricted by GFP_NOFS or GFP_NOIO. Sorry for being dense here but I still do not follow the actual problem (well, except for the above mentioned one). Is the sole point of this to emulate a GFP_NO* allocation context and see how shrinker behaves? -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/4] Fixes to bridge/panel and ingenic-drm
Le mer. 24 févr. 2021 à 13:44, Paul Cercueil a écrit : Hi, Some feedback for patches 1-3? Laurent? 1-month anniversary ping :) Cheers, -Paul Cheers, -Paul Le dim. 24 janv. 2021 à 8:55, Paul Cercueil a écrit : Hi, Here are three independent fixes. The first one addresses a use-after-free in bridge/panel.c; the second one addresses a use-after-free in the ingenic-drm driver; finally, the third one makes the ingenic-drm driver work again on older Ingenic SoCs. Changes from v2: - patch [1/4] added a FIXME. - patch [2/4] is new. It introduces a drmm_plain_simple_encoder_alloc() macro that will be used in patch [3/4]. - patch [3/4] uses the macro introduced in patch [2/4]. - patch [4/4] is unmodified. Note to linux-stable guys: patch [v2 2/3] will only apply on the current drm-misc-next branch, to fix it for v5.11 and older kernels, use the V1 of that patch. Cheers, -Paul Paul Cercueil (4): drm: bridge/panel: Cleanup connector on bridge detach drm/simple_kms_helper: Add macro drmm_plain_simple_encoder_alloc() drm/ingenic: Register devm action to cleanup encoders drm/ingenic: Fix non-OSD mode drivers/gpu/drm/bridge/panel.c| 12 +++ drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 26 +++ include/drm/drm_simple_kms_helper.h | 17 +++ 3 files changed, 42 insertions(+), 13 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 15/70] drm/i915: Make compilation of userptr code depend on MMU_NOTIFIER.
Now that unsynchronized mappings are removed, the only time userptr
works is when the MMU notifier is enabled. Put all of the userptr
code behind a mmu notifier ifdef.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +
drivers/gpu/drm/i915/gem/i915_gem_object.h| 4 ++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 58 +++
drivers/gpu/drm/i915/i915_drv.h | 2 +
5 files changed, 31 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 3c37a85c0d9d..795c68fcc6ed 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1971,8 +1971,10 @@ static noinline int eb_relocate_parse_slow(struct
i915_execbuffer *eb,
err = 0;
}
+#ifdef CONFIG_MMU_NOTIFIER
if (!err)
flush_workqueue(eb->i915->mm.userptr_wq);
+#endif
err_relock:
i915_gem_ww_ctx_init(>ww, true);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 1008c6c47809..69509dbd01c7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -576,7 +576,11 @@ void __i915_gem_object_invalidate_frontbuffer(struct
drm_i915_gem_object *obj,
static inline bool
i915_gem_object_is_userptr(struct drm_i915_gem_object *obj)
{
+#ifdef CONFIG_MMU_NOTIFIER
return obj->userptr.mm;
+#else
+ return false;
+#endif
}
static inline void
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 0320508b66b3..414322619781 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -296,6 +296,7 @@ struct drm_i915_gem_object {
unsigned long *bit_17;
union {
+#ifdef CONFIG_MMU_NOTIFIER
struct i915_gem_userptr {
uintptr_t ptr;
@@ -303,6 +304,7 @@ struct drm_i915_gem_object {
struct i915_mmu_object *mmu_object;
struct work_struct *work;
} userptr;
+#endif
struct drm_mm_node *stolen;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 80bc10b4ac74..b466ab2def4d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -15,6 +15,8 @@
#include "i915_gem_object.h"
#include "i915_scatterlist.h"
+#if defined(CONFIG_MMU_NOTIFIER)
+
struct i915_mm_struct {
struct mm_struct *mm;
struct drm_i915_private *i915;
@@ -24,7 +26,6 @@ struct i915_mm_struct {
struct rcu_work work;
};
-#if defined(CONFIG_MMU_NOTIFIER)
#include
struct i915_mmu_notifier {
@@ -217,15 +218,11 @@ i915_mmu_notifier_find(struct i915_mm_struct *mm)
}
static int
-i915_gem_userptr_init__mmu_notifier(struct drm_i915_gem_object *obj,
- unsigned flags)
+i915_gem_userptr_init__mmu_notifier(struct drm_i915_gem_object *obj)
{
struct i915_mmu_notifier *mn;
struct i915_mmu_object *mo;
- if (flags & I915_USERPTR_UNSYNCHRONIZED)
- return -ENODEV;
-
if (GEM_WARN_ON(!obj->userptr.mm))
return -EINVAL;
@@ -258,32 +255,6 @@ i915_mmu_notifier_free(struct i915_mmu_notifier *mn,
kfree(mn);
}
-#else
-
-static void
-__i915_gem_userptr_set_active(struct drm_i915_gem_object *obj, bool value)
-{
-}
-
-static void
-i915_gem_userptr_release__mmu_notifier(struct drm_i915_gem_object *obj)
-{
-}
-
-static int
-i915_gem_userptr_init__mmu_notifier(struct drm_i915_gem_object *obj,
- unsigned flags)
-{
- return -ENODEV;
-}
-
-static void
-i915_mmu_notifier_free(struct i915_mmu_notifier *mn,
- struct mm_struct *mm)
-{
-}
-
-#endif
static struct i915_mm_struct *
__i915_mm_struct_find(struct drm_i915_private *i915, struct mm_struct *real)
@@ -725,6 +696,8 @@ static const struct drm_i915_gem_object_ops
i915_gem_userptr_ops = {
.release = i915_gem_userptr_release,
};
+#endif
+
/*
* Creates a new mm object that wraps some normal memory from the process
* context - user memory.
@@ -765,12 +738,12 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file)
{
- static struct lock_class_key lock_class;
+ static struct lock_class_key __maybe_unused lock_class;
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_gem_userptr *args = data;
- struct drm_i915_gem_object *obj;
- int ret;
- u32 handle;
+ struct drm_i915_gem_object __maybe_unused *obj;
+
[PATCH v9 24/70] drm/i915: Move pinning to inside engine_wa_list_verify()
This should be done as part of the ww loop, in order to remove a
i915_vma_pin that needs ww held.
Now only i915_ggtt_pin() callers remaining.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_gtt.c| 14 +-
drivers/gpu/drm/i915/gt/intel_gtt.h| 3 +++
drivers/gpu/drm/i915/gt/intel_workarounds.c| 10 --
drivers/gpu/drm/i915/gt/selftest_execlists.c | 5 +++--
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_mocs.c| 3 ++-
drivers/gpu/drm/i915/gt/selftest_workarounds.c | 6 +++---
7 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index d34770ae4c9a..1b532a2791ea 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -427,7 +427,6 @@ __vm_create_scratch_for_read(struct i915_address_space *vm,
unsigned long size)
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
- int err;
obj = i915_gem_object_create_internal(vm->i915, PAGE_ALIGN(size));
if (IS_ERR(obj))
@@ -441,6 +440,19 @@ __vm_create_scratch_for_read(struct i915_address_space
*vm, unsigned long size)
return vma;
}
+ return vma;
+}
+
+struct i915_vma *
+__vm_create_scratch_for_read_pinned(struct i915_address_space *vm, unsigned
long size)
+{
+ struct i915_vma *vma;
+ int err;
+
+ vma = __vm_create_scratch_for_read(vm, size);
+ if (IS_ERR(vma))
+ return vma;
+
err = i915_vma_pin(vma, 0, 0,
i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
if (err) {
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 24b5808df16d..784c4372b405 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -581,6 +581,9 @@ void i915_vm_free_pt_stash(struct i915_address_space *vm,
struct i915_vma *
__vm_create_scratch_for_read(struct i915_address_space *vm, unsigned long
size);
+struct i915_vma *
+__vm_create_scratch_for_read_pinned(struct i915_address_space *vm, unsigned
long size);
+
static inline struct sgt_dma {
struct scatterlist *sg;
dma_addr_t dma, max;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 3b4a7da60f0b..bb2357119792 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2211,10 +2211,15 @@ static int engine_wa_list_verify(struct intel_context
*ce,
if (err)
goto err_pm;
+ err = i915_vma_pin_ww(vma, , 0, 0,
+ i915_vma_is_ggtt(vma) ? PIN_GLOBAL : PIN_USER);
+ if (err)
+ goto err_unpin;
+
rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto err_unpin;
+ goto err_vma;
}
err = i915_request_await_object(rq, vma->obj, true);
@@ -2255,6 +2260,8 @@ static int engine_wa_list_verify(struct intel_context *ce,
err_rq:
i915_request_put(rq);
+err_vma:
+ i915_vma_unpin(vma);
err_unpin:
intel_context_unpin(ce);
err_pm:
@@ -2265,7 +2272,6 @@ static int engine_wa_list_verify(struct intel_context *ce,
}
i915_gem_ww_ctx_fini();
intel_engine_pm_put(ce->engine);
- i915_vma_unpin(vma);
i915_vma_put(vma);
return err;
}
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index f625c29023ea..a6e77a161b70 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -4165,8 +4165,9 @@ static int preserved_virtual_engine(struct intel_gt *gt,
int err = 0;
u32 *cs;
- scratch = __vm_create_scratch_for_read([0]->gt->ggtt->vm,
- PAGE_SIZE);
+ scratch =
+ __vm_create_scratch_for_read_pinned([0]->gt->ggtt->vm,
+ PAGE_SIZE);
if (IS_ERR(scratch))
return PTR_ERR(scratch);
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 279091e41b41..1f7a120606e6 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -27,7 +27,7 @@
static struct i915_vma *create_scratch(struct intel_gt *gt)
{
- return __vm_create_scratch_for_read(>ggtt->vm, PAGE_SIZE);
+ return __vm_create_scratch_for_read_pinned(>ggtt->vm, PAGE_SIZE);
}
static bool is_active(struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index 44609d1c7780..01dd050d4161 100644
--- a/drivers/gpu/drm/i915/gt/selftest_mocs.c
[PATCH v9 45/70] drm/i915/selftests: Prepare dma-buf tests for obj->mm.lock removal.
Use pin_pages_unlocked() where we don't have a lock.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 b6d43880b0c1..dd74bc09ec88 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -194,7 +194,7 @@ static int igt_dmabuf_import_ownership(void *arg)
dma_buf_put(dmabuf);
- err = i915_gem_object_pin_pages(obj);
+ err = i915_gem_object_pin_pages_unlocked(obj);
if (err) {
pr_err("i915_gem_object_pin_pages failed with err=%d\n", err);
goto out_obj;
--
2.31.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 02/70] drm/i915: Pin timeline map after first timeline pin, v4.
We're starting to require the reservation lock for pinning,
so wait until we have that.
Update the selftests to handle this correctly, and ensure pin is
called in live_hwsp_rollover_user() and mock_hwsp_freelist().
Changes since v1:
- Fix NULL + XX arithmatic, use casts. (kbuild)
Changes since v2:
- Clear entire cacheline when pinning.
Changes since v3:
- CACHELINE_BYTES -> TIMELINE_SEQNO_BYTES. (jekstrand)
Signed-off-by: Maarten Lankhorst
Reported-by: kernel test robot
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_timeline.c| 40 ++
drivers/gpu/drm/i915/gt/intel_timeline.h| 2 +
drivers/gpu/drm/i915/gt/mock_engine.c | 22 +++-
drivers/gpu/drm/i915/gt/selftest_timeline.c | 61 +++--
drivers/gpu/drm/i915/i915_selftest.h| 2 +
5 files changed, 83 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index efe2030cfe5e..f19cf6d2fa85 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -52,14 +52,29 @@ static int __timeline_active(struct i915_active *active)
return 0;
}
+I915_SELFTEST_EXPORT int
+intel_timeline_pin_map(struct intel_timeline *timeline)
+{
+ struct drm_i915_gem_object *obj = timeline->hwsp_ggtt->obj;
+ u32 ofs = offset_in_page(timeline->hwsp_offset);
+ void *vaddr;
+
+ vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ if (IS_ERR(vaddr))
+ return PTR_ERR(vaddr);
+
+ timeline->hwsp_map = vaddr;
+ timeline->hwsp_seqno = memset(vaddr + ofs, 0, TIMELINE_SEQNO_BYTES);
+ clflush(vaddr + ofs);
+
+ return 0;
+}
+
static int intel_timeline_init(struct intel_timeline *timeline,
struct intel_gt *gt,
struct i915_vma *hwsp,
unsigned int offset)
{
- void *vaddr;
- u32 *seqno;
-
kref_init(>kref);
atomic_set(>pin_count, 0);
@@ -76,14 +91,8 @@ static int intel_timeline_init(struct intel_timeline
*timeline,
timeline->hwsp_ggtt = hwsp;
}
- vaddr = i915_gem_object_pin_map(hwsp->obj, I915_MAP_WB);
- if (IS_ERR(vaddr))
- return PTR_ERR(vaddr);
-
- timeline->hwsp_map = vaddr;
- seqno = vaddr + timeline->hwsp_offset;
- WRITE_ONCE(*seqno, 0);
- timeline->hwsp_seqno = seqno;
+ timeline->hwsp_map = NULL;
+ timeline->hwsp_seqno = (void *)(long)timeline->hwsp_offset;
GEM_BUG_ON(timeline->hwsp_offset >= hwsp->size);
@@ -113,7 +122,8 @@ static void intel_timeline_fini(struct rcu_head *rcu)
struct intel_timeline *timeline =
container_of(rcu, struct intel_timeline, rcu);
- i915_gem_object_unpin_map(timeline->hwsp_ggtt->obj);
+ if (timeline->hwsp_map)
+ i915_gem_object_unpin_map(timeline->hwsp_ggtt->obj);
i915_vma_put(timeline->hwsp_ggtt);
i915_active_fini(>active);
@@ -173,6 +183,12 @@ int intel_timeline_pin(struct intel_timeline *tl, struct
i915_gem_ww_ctx *ww)
if (atomic_add_unless(>pin_count, 1, 0))
return 0;
+ if (!tl->hwsp_map) {
+ err = intel_timeline_pin_map(tl);
+ if (err)
+ return err;
+ }
+
err = i915_ggtt_pin(tl->hwsp_ggtt, ww, 0, PIN_HIGH);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.h
b/drivers/gpu/drm/i915/gt/intel_timeline.h
index b1f81d947f8d..57308c4d664a 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.h
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.h
@@ -98,4 +98,6 @@ intel_timeline_is_last(const struct intel_timeline *tl,
return list_is_last_rcu(>link, >requests);
}
+I915_SELFTEST_DECLARE(int intel_timeline_pin_map(struct intel_timeline *tl));
+
#endif
diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c
b/drivers/gpu/drm/i915/gt/mock_engine.c
index 5662f7c2f719..42fd86658ee7 100644
--- a/drivers/gpu/drm/i915/gt/mock_engine.c
+++ b/drivers/gpu/drm/i915/gt/mock_engine.c
@@ -13,9 +13,20 @@
#include "mock_engine.h"
#include "selftests/mock_request.h"
-static void mock_timeline_pin(struct intel_timeline *tl)
+static int mock_timeline_pin(struct intel_timeline *tl)
{
+ int err;
+
+ if (WARN_ON(!i915_gem_object_trylock(tl->hwsp_ggtt->obj)))
+ return -EBUSY;
+
+ err = intel_timeline_pin_map(tl);
+ i915_gem_object_unlock(tl->hwsp_ggtt->obj);
+ if (err)
+ return err;
+
atomic_inc(>pin_count);
+ return 0;
}
static void mock_timeline_unpin(struct intel_timeline *tl)
@@ -133,6 +144,8 @@ static void mock_context_destroy(struct kref *ref)
static int mock_context_alloc(struct intel_context *ce)
{
+ int err;
+
ce->ring = mock_ring(ce->engine);
if (!ce->ring)
return
[PATCH v9 44/70] drm/i915/selftests: Prepare context tests for obj->mm.lock removal.
Straightforward conversion, just convert a bunch of calls to
unlocked versions.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index df949320f2b5..82d5d37e9b66 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1092,7 +1092,7 @@ __read_slice_count(struct intel_context *ce,
if (ret < 0)
return ret;
- buf = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ buf = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
if (IS_ERR(buf)) {
ret = PTR_ERR(buf);
return ret;
@@ -1509,7 +1509,7 @@ static int write_to_scratch(struct i915_gem_context *ctx,
if (IS_ERR(obj))
return PTR_ERR(obj);
- cmd = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
goto out;
@@ -1620,7 +1620,7 @@ static int read_from_scratch(struct i915_gem_context *ctx,
if (err)
goto out_vm;
- cmd = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
goto out;
@@ -1656,7 +1656,7 @@ static int read_from_scratch(struct i915_gem_context *ctx,
if (err)
goto out_vm;
- cmd = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
goto out;
@@ -1715,7 +1715,7 @@ static int read_from_scratch(struct i915_gem_context *ctx,
}
i915_request_put(rq);
- cmd = i915_gem_object_pin_map(obj, I915_MAP_WC);
+ cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
goto out_vm;
--
2.31.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 21/70] drm/i915: Rework clflush to work correctly without obj->mm.lock.
Pin in the caller, not in the work itself. This should also
work better for dma-fence annotations.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
index a28f8c912a3e..e4c24558eaa8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
@@ -27,15 +27,8 @@ static void __do_clflush(struct drm_i915_gem_object *obj)
static int clflush_work(struct dma_fence_work *base)
{
struct clflush *clflush = container_of(base, typeof(*clflush), base);
- struct drm_i915_gem_object *obj = clflush->obj;
- int err;
- err = i915_gem_object_pin_pages(obj);
- if (err)
- return err;
-
- __do_clflush(obj);
- i915_gem_object_unpin_pages(obj);
+ __do_clflush(clflush->obj);
return 0;
}
@@ -44,6 +37,7 @@ static void clflush_release(struct dma_fence_work *base)
{
struct clflush *clflush = container_of(base, typeof(*clflush), base);
+ i915_gem_object_unpin_pages(clflush->obj);
i915_gem_object_put(clflush->obj);
}
@@ -61,6 +55,11 @@ static struct clflush *clflush_work_create(struct
drm_i915_gem_object *obj)
if (!clflush)
return NULL;
+ if (__i915_gem_object_get_pages(obj) < 0) {
+ kfree(clflush);
+ return NULL;
+ }
+
dma_fence_work_init(>base, _ops);
clflush->obj = i915_gem_object_get(obj); /* obj <-> clflush cycle */
--
2.31.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 16/70] drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v7.
Instead of doing what we do currently, which will never work with
PROVE_LOCKING, do the same as AMD does, and something similar to
relocation slowpath. When all locks are dropped, we acquire the
pages for pinning. When the locks are taken, we transfer those
pages in .get_pages() to the bo. As a final check before installing
the fences, we ensure that the mmu notifier was not called; if it is,
we return -EAGAIN to userspace to signal it has to start over.
Changes since v1:
- Unbinding is done in submit_init only. submit_begin() removed.
- MMU_NOTFIER -> MMU_NOTIFIER
Changes since v2:
- Make i915->mm.notifier a spinlock.
Changes since v3:
- Add WARN_ON if there are any page references left, should have been 0.
- Return 0 on success in submit_init(), bug from spinlock conversion.
- Release pvec outside of notifier_lock (Thomas).
Changes since v4:
- Mention why we're clearing eb->[i + 1].vma in the code. (Thomas)
- Actually check all invalidations in eb_move_to_gpu. (Thomas)
- Do not wait when process is exiting to fix gem_ctx_persistence.userptr.
Changes since v5:
- Clarify why check on PF_EXITING is (temporarily) required.
Changes since v6:
- Ensure userptr validity is checked in set_domain through a special path.
Signed-off-by: Maarten Lankhorst
Acked-by: Dave Airlie
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 18 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 101 ++-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 38 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 796 ++
drivers/gpu/drm/i915/i915_drv.h | 9 +-
drivers/gpu/drm/i915/i915_gem.c | 5 +-
8 files changed, 395 insertions(+), 584 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 2f4980bf742e..76cb9f5c66aa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -468,14 +468,28 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
if (!obj)
return -ENOENT;
+ if (i915_gem_object_is_userptr(obj)) {
+ /*
+* Try to grab userptr pages, iris uses set_domain to check
+* userptr validity
+*/
+ err = i915_gem_object_userptr_validate(obj);
+ if (!err)
+ err = i915_gem_object_wait(obj,
+ I915_WAIT_INTERRUPTIBLE |
+ I915_WAIT_PRIORITY |
+ (write_domain ?
I915_WAIT_ALL : 0),
+ MAX_SCHEDULE_TIMEOUT);
+ goto out;
+ }
+
/*
* Proxy objects do not control access to the backing storage, ergo
* they cannot be used as a means to manipulate the cache domain
* tracking for that backing storage. The proxy object is always
* considered to be outside of any cache domain.
*/
- if (i915_gem_object_is_proxy(obj) &&
- !i915_gem_object_is_userptr(obj)) {
+ if (i915_gem_object_is_proxy(obj)) {
err = -ENXIO;
goto out;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 795c68fcc6ed..b5ca9eb53565 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -53,14 +53,16 @@ enum {
/* __EXEC_OBJECT_NO_RESERVE is BIT(31), defined in i915_vma.h */
#define __EXEC_OBJECT_HAS_PIN BIT(30)
#define __EXEC_OBJECT_HAS_FENCEBIT(29)
-#define __EXEC_OBJECT_NEEDS_MAPBIT(28)
-#define __EXEC_OBJECT_NEEDS_BIAS BIT(27)
-#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 27) /* all of the above + */
+#define __EXEC_OBJECT_USERPTR_INIT BIT(28)
+#define __EXEC_OBJECT_NEEDS_MAPBIT(27)
+#define __EXEC_OBJECT_NEEDS_BIAS BIT(26)
+#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 26) /* all of the above + */
#define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN |
__EXEC_OBJECT_HAS_FENCE)
#define __EXEC_HAS_RELOC BIT(31)
#define __EXEC_ENGINE_PINNED BIT(30)
-#define __EXEC_INTERNAL_FLAGS (~0u << 30)
+#define __EXEC_USERPTR_USEDBIT(29)
+#define __EXEC_INTERNAL_FLAGS (~0u << 29)
#define UPDATE PIN_OFFSET_FIXED
#define BATCH_OFFSET_BIAS (256*1024)
@@ -871,6 +873,26 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
}
eb_add_vma(eb, i, batch, vma);
+
+ if (i915_gem_object_is_userptr(vma->obj)) {
+ err = i915_gem_object_userptr_submit_init(vma->obj);
+ if (err) {
+ if (i + 1 <
[PATCH v9 11/70] drm/i915: Disable userptr pread/pwrite support.
Userptr should not need the kernel for a userspace memcpy, userspace
needs to call memcpy directly.
Specifically, disable i915_gem_pwrite_ioctl() and i915_gem_pread_ioctl().
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
-- Still needs an ack from relevant userspace that it won't break, but should
be good.
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 20
drivers/gpu/drm/i915/i915_gem.c | 5 +
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 0f9024c62c06..5a19699c2d7e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -700,6 +700,24 @@ i915_gem_userptr_dmabuf_export(struct drm_i915_gem_object
*obj)
return i915_gem_userptr_init__mmu_notifier(obj, 0);
}
+static int
+i915_gem_userptr_pwrite(struct drm_i915_gem_object *obj,
+ const struct drm_i915_gem_pwrite *args)
+{
+ drm_dbg(obj->base.dev, "pwrite to userptr no longer allowed\n");
+
+ return -EINVAL;
+}
+
+static int
+i915_gem_userptr_pread(struct drm_i915_gem_object *obj,
+ const struct drm_i915_gem_pread *args)
+{
+ drm_dbg(obj->base.dev, "pread from userptr no longer allowed\n");
+
+ return -EINVAL;
+}
+
static const struct drm_i915_gem_object_ops i915_gem_userptr_ops = {
.name = "i915_gem_object_userptr",
.flags = I915_GEM_OBJECT_IS_SHRINKABLE |
@@ -708,6 +726,8 @@ static const struct drm_i915_gem_object_ops
i915_gem_userptr_ops = {
.get_pages = i915_gem_userptr_get_pages,
.put_pages = i915_gem_userptr_put_pages,
.dmabuf_export = i915_gem_userptr_dmabuf_export,
+ .pwrite = i915_gem_userptr_pwrite,
+ .pread = i915_gem_userptr_pread,
.release = i915_gem_userptr_release,
};
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 25444d360f7f..dde12ce4f90b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -403,6 +403,11 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
}
trace_i915_gem_object_pread(obj, args->offset, args->size);
+ ret = -ENODEV;
+ if (obj->ops->pread)
+ ret = obj->ops->pread(obj, args);
+ if (ret != -ENODEV)
+ goto out;
ret = -ENODEV;
if (obj->ops->pread)
--
2.31.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 56/70] drm/i915/selftests: Prepare timeline tests for obj->mm.lock removal
We can no longer call intel_timeline_pin with a null argument,
so add a ww loop that locks the backing object.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 30 +
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c
b/drivers/gpu/drm/i915/gt/selftest_timeline.c
index fa4b965ed5ee..9adbd9d147be 100644
--- a/drivers/gpu/drm/i915/gt/selftest_timeline.c
+++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c
@@ -37,6 +37,26 @@ static unsigned long hwsp_cacheline(struct intel_timeline
*tl)
return (address + offset_in_page(tl->hwsp_offset)) /
TIMELINE_SEQNO_BYTES;
}
+static int selftest_tl_pin(struct intel_timeline *tl)
+{
+ struct i915_gem_ww_ctx ww;
+ int err;
+
+ i915_gem_ww_ctx_init(, false);
+retry:
+ err = i915_gem_object_lock(tl->hwsp_ggtt->obj, );
+ if (!err)
+ err = intel_timeline_pin(tl, );
+
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
+ return err;
+}
+
/* Only half of seqno's are usable, see __intel_timeline_get_seqno() */
#define CACHELINES_PER_PAGE (PAGE_SIZE / TIMELINE_SEQNO_BYTES / 2)
@@ -79,7 +99,7 @@ static int __mock_hwsp_timeline(struct mock_hwsp_freelist
*state,
if (IS_ERR(tl))
return PTR_ERR(tl);
- err = intel_timeline_pin(tl, NULL);
+ err = selftest_tl_pin(tl);
if (err) {
intel_timeline_put(tl);
return err;
@@ -465,7 +485,7 @@ checked_tl_write(struct intel_timeline *tl, struct
intel_engine_cs *engine, u32
struct i915_request *rq;
int err;
- err = intel_timeline_pin(tl, NULL);
+ err = selftest_tl_pin(tl);
if (err) {
rq = ERR_PTR(err);
goto out;
@@ -665,7 +685,7 @@ static int live_hwsp_wrap(void *arg)
if (!tl->has_initial_breadcrumb)
goto out_free;
- err = intel_timeline_pin(tl, NULL);
+ err = selftest_tl_pin(tl);
if (err)
goto out_free;
@@ -812,13 +832,13 @@ static int setup_watcher(struct hwsp_watcher *w, struct
intel_gt *gt)
if (IS_ERR(obj))
return PTR_ERR(obj);
- w->map = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ w->map = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
if (IS_ERR(w->map)) {
i915_gem_object_put(obj);
return PTR_ERR(w->map);
}
- vma = i915_gem_object_ggtt_pin_ww(obj, NULL, NULL, 0, 0, 0);
+ vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
if (IS_ERR(vma)) {
i915_gem_object_put(obj);
return PTR_ERR(vma);
--
2.31.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
