Re: [PATCH] drm/msm/dp: remove limitation of link rate at 5.4G to support HBR3
On 10/11/2022 02:47, Kuogee Hsieh wrote: On 11/2/2022 11:04 AM, Dmitry Baryshkov wrote: On 02/11/2022 20:28, Doug Anderson wrote: Hi, On Wed, Nov 2, 2022 at 10:23 AM Dmitry Baryshkov wrote: 1. Someone figures out how to model this with the bridge chain and then we only allow HBR3 if we detect we've got a TCPC that supports it. This seems like the cleanest / best but feels like a long pole. Not only have we been trying to get the TCPC-modeled-as-a-bridge stuff landed for a long time but even when we do it we still don't have a solution for how to communicate the number of lanes and other stuff between the TCPC and the DP controller so we have to enrich the bridge interface. I think we'd need some OOB interface. For example for DSI interfaces we have mipi_dsi_device struct to communicate such OOB data. Also take a note regarding data-lanes from my previous email. Right, we can somehow communicate the max link rate through the bridge chain to the DP controller in an OOB manner that would work. I'd note that our dp_panel has some notion of such OOB data. So do AUX drivers including the panel-edp. My suggestion would be to consider both of them while modelling the OOB data. 2. We add in a DT property to the display controller node that says the max link rate for use on this board. This feels like a hack, but maybe it's not too bad. Certainly it would be incredibly simple to implement. Actually... ...one could argue that even if we later model the TCPC as a bridge that this property would still be valid / useful! You could certainly imagine that the SoC supports HBR3 and the TCPC supports HBR3 but that the board routing between the SoC and the TCPC is bad and only supports HBR2. In this case the only way out is essentially a "board constraint" AKA a DT property in the DP controller. We have been discussing similar topics with Abhinav. Krzysztof suggested using link-frequencies property to provide max and min values. questions, 1)is Krzysztof suggested had been implemented? I can not parse this question, please excuse me. Yes, Krzysztof suggested this being implemented as a link property, see media/video-interfaces.txt. Moreover your implementation goes against both the existing definition (array with the list of frequencies) and Krzysztof's suggested extension (min and max). Listing just a single frequency goes against both these suggestions. In case of DP we have a fixed set of frequencies. Thus I'd suggest listing all supported frequencies instead. 2) where is link property i can add link-frequencies? link node. Create outbound graph node, add link-frequencies there. Also as you are touching this part, please move the data-lanes property too. This sounds good to me and seems worth doing even if we eventually do #1. And the bonus point is that it can be done easily. -- With best wishes Dmitry
Re: [PATCH v3 08/10] phy: cadence: Add driver for HDP-TX DisplyPort PHY
On 08-11-22, 21:00, Sandor Yu wrote: > Add Cadence HDP-TX DisplayPort PHY driver. > > Cadence HDP-TX PHY could be put in either DP mode or > HDMI mode base on the configuration chosen. > DisplayPort PHY mode is configurated in the driver. > > Signed-off-by: Sandor Yu > --- > drivers/phy/cadence/Kconfig| 8 + > drivers/phy/cadence/Makefile | 1 + > drivers/phy/cadence/phy-cadence-hdptx-dp.c | 774 + > 3 files changed, 783 insertions(+) > create mode 100644 drivers/phy/cadence/phy-cadence-hdptx-dp.c > > diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig > index 1adde2d99ae7..1e1914d3afdc 100644 > --- a/drivers/phy/cadence/Kconfig > +++ b/drivers/phy/cadence/Kconfig > @@ -46,3 +46,11 @@ config PHY_CADENCE_SALVO > Enable this to support the Cadence SALVO PHY driver, > this PHY is a legacy PHY, and only are used for USB3 > and USB2. > + > +config PHY_CADENCE_HDPTX_DP alphabetically sorted please > + tristate "Cadence HDPTX DP PHY Driver" > + depends on OF && HAS_IOMEM > + depends on COMMON_CLK > + select GENERIC_PHY > + help > + Enable this to support the Cadence HDPTX DP PHY driver > diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile > index e17f035ddece..fbdb0bc5ff11 100644 > --- a/drivers/phy/cadence/Makefile > +++ b/drivers/phy/cadence/Makefile > @@ -4,3 +4,4 @@ obj-$(CONFIG_PHY_CADENCE_DPHY)+= cdns-dphy.o > obj-$(CONFIG_PHY_CADENCE_DPHY_RX)+= cdns-dphy-rx.o > obj-$(CONFIG_PHY_CADENCE_SIERRA) += phy-cadence-sierra.o > obj-$(CONFIG_PHY_CADENCE_SALVO) += phy-cadence-salvo.o > +obj-$(CONFIG_PHY_CADENCE_HDPTX_DP) += phy-cadence-hdptx-dp.o here too > diff --git a/drivers/phy/cadence/phy-cadence-hdptx-dp.c > b/drivers/phy/cadence/phy-cadence-hdptx-dp.c > new file mode 100644 > index ..079d43772d1d > --- /dev/null > +++ b/drivers/phy/cadence/phy-cadence-hdptx-dp.c > @@ -0,0 +1,774 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Cadence HDP-TX Display Port Interface (DP) PHY driver > + * > + * Copyright (C) 2022 NXP Semiconductor, Inc. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define ADDR_PHY_AFE 0x8 > + > +/* PHY registers */ > +#define CMN_SSM_BIAS_TMR0x0022 > +#define CMN_PLLSM0_PLLEN_TMR0x0029 > +#define CMN_PLLSM0_PLLPRE_TMR 0x002A > +#define CMN_PLLSM0_PLLVREF_TMR 0x002B > +#define CMN_PLLSM0_PLLLOCK_TMR 0x002C > +#define CMN_PLLSM0_USER_DEF_CTRL0x002F > +#define CMN_PSM_CLK_CTRL0x0061 > +#define CMN_CDIAG_REFCLK_CTRL 0x0062 > +#define CMN_PLL0_VCOCAL_START 0x0081 > +#define CMN_PLL0_VCOCAL_INIT_TMR0x0084 > +#define CMN_PLL0_VCOCAL_ITER_TMR0x0085 > +#define CMN_PLL0_INTDIV 0x0094 > +#define CMN_PLL0_FRACDIV0x0095 > +#define CMN_PLL0_HIGH_THR 0x0096 > +#define CMN_PLL0_DSM_DIAG 0x0097 > +#define CMN_PLL0_SS_CTRL1 0x0098 > +#define CMN_PLL0_SS_CTRL2 0x0099 > +#define CMN_ICAL_INIT_TMR 0x00C4 > +#define CMN_ICAL_ITER_TMR 0x00C5 > +#define CMN_RXCAL_INIT_TMR 0x00D4 > +#define CMN_RXCAL_ITER_TMR 0x00D5 > +#define CMN_TXPUCAL_CTRL0x00E0 > +#define CMN_TXPUCAL_INIT_TMR0x00E4 > +#define CMN_TXPUCAL_ITER_TMR0x00E5 > +#define CMN_TXPDCAL_CTRL0x00F0 > +#define CMN_TXPDCAL_INIT_TMR0x00F4 > +#define CMN_TXPDCAL_ITER_TMR0x00F5 > +#define CMN_ICAL_ADJ_INIT_TMR 0x0102 > +#define CMN_ICAL_ADJ_ITER_TMR 0x0103 > +#define CMN_RX_ADJ_INIT_TMR 0x0106 > +#define CMN_RX_ADJ_ITER_TMR 0x0107 > +#define CMN_TXPU_ADJ_CTRL 0x0108 > +#define CMN_TXPU_ADJ_INIT_TMR 0x010A > +#define CMN_TXPU_ADJ_ITER_TMR 0x010B > +#define CMN_TXPD_ADJ_CTRL 0x010c > +#define CMN_TXPD_ADJ_INIT_TMR 0x010E > +#define CMN_TXPD_ADJ_ITER_TMR 0x010F > +#define CMN_DIAG_PLL0_FBH_OVRD 0x01C0 > +#define CMN_DIAG_PLL0_FBL_OVRD 0x01C1 > +#define CMN_DIAG_PLL0_OVRD 0x01C2 > +#define CMN_DIAG_PLL0_TEST_MODE 0x01C4 > +#define CMN_DIAG_PLL0_V2I_TUNE 0x01C5 > +#define CMN_DIAG_PLL0_CP_TUNE 0x01C6 > +#define CMN_DIAG_PLL0_LF_PROG 0x01C7 > +#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01C8 > +#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01C9 > +#define CMN_DIAG_PLL0_INCLK_CTRL0x01CA > +#define CMN_DIAG_PLL0_PXL_DIVH 0x01CB > +#define CMN_DIAG_PLL0_PXL_DIVL 0x01CC > +#define CMN_DIAG_HSCLK_SEL 0x01E0 > +#define CMN_DIAG_PER_CAL_ADJ0x01EC > +#define CMN_DIAG_CAL_CTRL 0x01ED > +#define CMN_DIAG_ACYA 0x01FF >
Re: [PATCH v3 04/10] phy: Add HDMI configuration options
On 08-11-22, 21:00, Sandor Yu wrote:
> Allow HDMI PHYs to be configured through the generic
> functions through a custom structure added to the generic union.
>
> The parameters added here are based on HDMI PHY
> implementation practices. The current set of parameters
> should cover the potential users.
Is there any dpendency b/w phy and hdmi, I dont see anything in cover..
Pls consider splitting the phy series ..
>
> Signed-off-by: Sandor Yu
> ---
> include/linux/phy/phy-hdmi.h | 33 +
> include/linux/phy/phy.h | 7 ++-
> 2 files changed, 39 insertions(+), 1 deletion(-)
> create mode 100644 include/linux/phy/phy-hdmi.h
>
> diff --git a/include/linux/phy/phy-hdmi.h b/include/linux/phy/phy-hdmi.h
> new file mode 100644
> index ..73a32eb535b0
> --- /dev/null
> +++ b/include/linux/phy/phy-hdmi.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright 2022 NXP
> + */
> +
> +#ifndef __PHY_HDMI_H_
> +#define __PHY_HDMI_H_
> +
> +enum hdmi_phy_colorspace {
> + HDMI_PHY_COLORSPACE_RGB,
> + HDMI_PHY_COLORSPACE_YUV422,
> + HDMI_PHY_COLORSPACE_YUV444,
> + HDMI_PHY_COLORSPACE_YUV420,
> + HDMI_PHY_COLORSPACE_RESERVED4,
> + HDMI_PHY_COLORSPACE_RESERVED5,
> + HDMI_PHY_COLORSPACE_RESERVED6,
> +};
kernel-doc style comments here too please
> +
> +/**
> + * struct phy_configure_opts_hdmi - HDMI configuration set
> + * @pixel_clk_rate: Pixel clock of video modes in KHz.
> + * @bpc: Maximum bits per color channel.
> + * @color_space: Colorspace in enum hdmi_phy_colorspace.
> + *
> + * This structure is used to represent the configuration state of a HDMI phy.
> + */
> +struct phy_configure_opts_hdmi {
> + unsigned int pixel_clk_rate;
> + unsigned int bpc;
> + enum hdmi_phy_colorspace color_space;
> +};
> +
> +#endif /* __PHY_HDMI_H_ */
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index b1413757fcc3..6f6873ea7270 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -17,6 +17,7 @@
> #include
>
> #include
> +#include
> #include
> #include
>
> @@ -42,7 +43,8 @@ enum phy_mode {
> PHY_MODE_MIPI_DPHY,
> PHY_MODE_SATA,
> PHY_MODE_LVDS,
> - PHY_MODE_DP
> + PHY_MODE_DP,
> + PHY_MODE_HDMI,
> };
>
> enum phy_media {
> @@ -60,11 +62,14 @@ enum phy_media {
> * the DisplayPort protocol.
> * @lvds:Configuration set applicable for phys supporting
> * the LVDS phy mode.
> + * @hdmi:Configuration set applicable for phys supporting
> + * the HDMI phy mode.
> */
> union phy_configure_opts {
> struct phy_configure_opts_mipi_dphy mipi_dphy;
> struct phy_configure_opts_dpdp;
> struct phy_configure_opts_lvds lvds;
> + struct phy_configure_opts_hdmi hdmi;
> };
>
> /**
> --
> 2.34.1
--
~Vinod
Re: [PATCH v3 10/12] phy: mediatek: add support for phy-mtk-hdmi-mt8195
On 04-11-22, 15:09, Guillaume Ranquet wrote:
> Add basic support for the mediatek hdmi phy on MT8195 SoC
Are phy patches in this series dependent upon changes in drm/, if not
consider splitting them up!
>
> Signed-off-by: Guillaume Ranquet
> ---
> drivers/phy/mediatek/Makefile | 1 +
> drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 543
> +
> drivers/phy/mediatek/phy-mtk-hdmi-mt8195.h | 109 ++
> drivers/phy/mediatek/phy-mtk-hdmi.c| 3 +
> drivers/phy/mediatek/phy-mtk-hdmi.h| 1 +
> 5 files changed, 657 insertions(+)
>
> diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> index fb1f8edaffa7..c9a50395533e 100644
> --- a/drivers/phy/mediatek/Makefile
> +++ b/drivers/phy/mediatek/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_PHY_MTK_XSPHY) += phy-mtk-xsphy.o
> phy-mtk-hdmi-drv-y := phy-mtk-hdmi.o
> phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt2701.o
> phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt8173.o
> +phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt8195.o
> obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
>
> phy-mtk-mipi-dsi-drv-y := phy-mtk-mipi-dsi.o
> diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> new file mode 100644
> index ..48efd3936f29
> --- /dev/null
> +++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> @@ -0,0 +1,543 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 MediaTek Inc.
> + * Copyright (c) 2022 BayLibre, SAS
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "phy-mtk-io.h"
> +#include "phy-mtk-hdmi.h"
> +#include "phy-mtk-hdmi-mt8195.h"
> +
> +static void mtk_hdmi_ana_fifo_en(struct mtk_hdmi_phy *hdmi_phy)
> +{
> + /* make data fifo writable for hdmi2.0 */
> + mtk_phy_set_bits(hdmi_phy->regs + HDMI_ANA_CTL, REG_ANA_HDMI20_FIFO_EN);
> +}
> +
> +static void
> +mtk_mt8195_phy_tmds_high_bit_clk_ratio(struct mtk_hdmi_phy *hdmi_phy,
> +bool enable)
> +{
> + void __iomem *regs = hdmi_phy->regs;
> +
> + mtk_hdmi_ana_fifo_en(hdmi_phy);
> +
> + /* HDMI 2.0 specification, 3.4Gbps <= TMDS Bit Rate <= 6G,
> + * clock bit ratio 1:40, under 3.4Gbps, clock bit ratio 1:10
> + */
> + if (enable)
> + mtk_phy_update_field(regs + HDMI20_CLK_CFG, REG_TXC_DIV,
> REG_TXC_DIV);
> + else
> + mtk_phy_clear_bits(regs + HDMI20_CLK_CFG, REG_TXC_DIV);
> +}
> +
> +static void mtk_hdmi_pll_select_source(struct clk_hw *hw)
> +{
> + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> + void __iomem *regs = hdmi_phy->regs;
> +
> + mtk_phy_clear_bits(regs + HDMI_CTL_3, REG_HDMITX_REF_XTAL_SEL);
> + mtk_phy_clear_bits(regs + HDMI_CTL_3, REG_HDMITX_REF_RESPLL_SEL);
> +
> + /* DA_HDMITX21_REF_CK for TXPLL input source */
> + mtk_phy_clear_bits(regs + HDMI_1_CFG_10, RG_HDMITXPLL_REF_CK_SEL);
> +}
> +
> +static int mtk_hdmi_pll_performance_setting(struct clk_hw *hw)
> +{
> + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> + void __iomem *regs = hdmi_phy->regs;
> +
> + /* BP2 */
> + mtk_phy_set_bits(regs + HDMI_1_PLL_CFG_0, RG_HDMITXPLL_BP2);
> +
> + /* BC */
> + mtk_phy_set_bits(regs + HDMI_1_PLL_CFG_2, RG_HDMITXPLL_BC);
> +
> + /* IC */
> + mtk_phy_update_field(regs + HDMI_1_PLL_CFG_2, RG_HDMITXPLL_IC, 0x1);
> +
> + /* BR */
> + mtk_phy_update_field(regs + HDMI_1_PLL_CFG_2, RG_HDMITXPLL_BR, 0x2);
> +
> + /* IR */
> + mtk_phy_update_field(regs + HDMI_1_PLL_CFG_2, RG_HDMITXPLL_IR, 0x2);
> +
> + /* BP */
> + mtk_phy_set_bits(regs + HDMI_1_PLL_CFG_2, RG_HDMITXPLL_BP);
> +
> + /* IBAND_FIX_EN, RESERVE[14] */
> + mtk_phy_clear_bits(regs + HDMI_1_PLL_CFG_0, RG_HDMITXPLL_IBAND_FIX_EN);
> + mtk_phy_clear_bits(regs + HDMI_1_PLL_CFG_1, RG_HDMITXPLL_RESERVE_BIT14);
> +
> + /* HIKVCO */
> + mtk_phy_clear_bits(regs + HDMI_1_PLL_CFG_2, RG_HDMITXPLL_HIKVCO);
> +
> + /* HREN */
> + mtk_phy_update_field(regs + HDMI_1_PLL_CFG_0, RG_HDMITXPLL_HREN, 0x1);
> +
> + /* LVR_SEL */
> + mtk_phy_update_field(regs + HDMI_1_PLL_CFG_0, RG_HDMITXPLL_LVR_SEL,
> 0x1);
> +
> + /* RG_HDMITXPLL_RESERVE[12:11] */
> + mtk_phy_set_bits(regs + HDMI_1_PLL_CFG_1,
> RG_HDMITXPLL_RESERVE_BIT12_11);
> +
> + /* TCL_EN */
> + mtk_phy_set_bits(regs + HDMI_1_PLL_CFG_0, RG_HDMITXPLL_TCL_EN);
> +
> + return 0;
> +}
> +
> +static int mtk_hdmi_pll_set_hw(struct clk_hw *hw, unsigned char prediv,
> +unsigned char fbkdiv_high,
> +unsigned long fbkdiv_low,
> +unsigned char fbkdiv_hs3, unsigned char posdiv1,
> +unsigned char posdiv2, unsigned char txprediv,
> +
RE: [PATCH v2 11/11] iommufd: Allow iommufd to supply /dev/vfio/vfio
> From: Jason Gunthorpe > Sent: Tuesday, November 8, 2022 8:53 AM > > If the VFIO container is compiled out, give a kconfig option for iommufd > to provide the miscdev node with the same name and permissions as vfio > uses. > > The compatibility node supports the same ioctls as VFIO and automatically > enables the VFIO compatible pinned page accounting mode. > > Tested-by: Nicolin Chen > Signed-off-by: Jason Gunthorpe Reviewed-by: Kevin Tian
RE: [PATCH v2 10/11] vfio: Make vfio_container optionally compiled
> From: Jason Gunthorpe
> Sent: Thursday, November 10, 2022 3:53 AM
>
> On Wed, Nov 09, 2022 at 10:18:09AM -0700, Alex Williamson wrote:
>
> > DPDK supports no-iommu mode.
>
> Er? Huh? How? I thought no-iommu was for applications that didn't do
> DMA? How is DPDK getting packets in/out without DMA? I guess it snoops
> in /proc/ or something to learn PFNs of mlock'd memory?
iirc dpdk started with UIO plus various tricks (root privilege, hugepage, etc.)
to lock and learn PFN's from pagemap. Then when migrating it to vfio the
no-iommu option was introduced to provide UIO compatibility.
>
> > I agree that it's very useful for testing, I'm certainly not suggesting
> > to give up, but I'm not sure where no-iommu lives when iommufd owns
> > /dev/vfio/vfio. Given the unsafe interrupts discussion, it doesn't
> > seem like the type of thing that would be a priority for iommufd.
>
> Ah, I think the bit below will do the job, I'm not sure without doing
> some testing (and I don't think I have the necessary Intel NIC for
> DPDK). The basic point is no-iommu literally means 'do not use iommufd
> at all, do not create an iommufd_device or an iommufd_access'. VFIO
> can easially do that on its own.
>
> The only slightly messy bit is that uAPI requires the SET_CONTAINER
> which we can just NOP in vfio_compat. With more checks it could have
> higher fidelity of error cases, but not sure it is worth it.
>
> When we talk about the device cdev flow then I suggest that no-iommu
> simply requires -1 for the iommufd during bind - ie no iommufd is
> used or accepted and that is how the userspace knows/confirms it is in
> no-iommu mode.
>
> > We're on a path where vfio accepts an iommufd as a container, and
> > ultimately iommufd becomes the container provider, supplanting the
> > IOMMU driver registration aspect of vfio. I absolutely want type1 and
> > spapr backends to get replaced by iommufd, but reluctance to support
> > aspects of vfio "legacy" behavior doesn't give me warm fuzzies about a
> > wholesale hand-off of the container to a different subsystem, for
> > example vs an iommufd shim spoofing type1 support.
>
> Well, I will agree to do everything required, just let's go through the
> process to understand the security situation and ensure we are still
> doing things the right way.
>
> > Unfortunately we no longer have a CONFIG_EXPERIMENTAL option to hide
> > behind for disabling VFIO_CONTAINER, so regardless of our intentions
> > that a transition is some time off, it may become an issue sooner than
> > we expect.
>
> We can add kconfig text discouraging that?
>
> diff --git a/drivers/iommu/iommufd/vfio_compat.c
> b/drivers/iommu/iommufd/vfio_compat.c
> index dbef3274803336..81f7594cfff8e0 100644
> --- a/drivers/iommu/iommufd/vfio_compat.c
> +++ b/drivers/iommu/iommufd/vfio_compat.c
> @@ -259,6 +259,14 @@ static int iommufd_vfio_set_iommu(struct
> iommufd_ctx *ictx, unsigned long type)
> struct iommufd_ioas *ioas = NULL;
> int rc = 0;
>
> + /*
> + * Emulation for NOIMMU is imperfect in that VFIO blocks almost all
> + * other ioctls. We let them keep working but they mostly fail since no
> + * IOAS should exist.
> + */
> + if (IS_ENABLED(CONFIG_VFIO_NOIOMMU) && type ==
> VFIO_NOIOMMU_IOMMU)
> + return 0;
> +
> if (type != VFIO_TYPE1_IOMMU && type != VFIO_TYPE1v2_IOMMU)
> return -EINVAL;
>
also need a check in iommufd_vfio_check_extension() so only
VFIO_NOIOMMU_IOMMU is supported in no-iommu mode.
> diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
> index 595c7b2146f88c..64a336ebc99b9f 100644
> --- a/drivers/vfio/iommufd.c
> +++ b/drivers/vfio/iommufd.c
> @@ -18,6 +18,10 @@ int vfio_iommufd_bind(struct vfio_device *vdev,
> struct iommufd_ctx *ictx)
>
> lockdep_assert_held(>dev_set->lock);
>
> + if (IS_ENABLED(CONFIG_VFIO_NO_IOMMU) &&
> + vdev->group->type == VFIO_NO_IOMMU)
> + return 0;
> +
> /*
>* If the driver doesn't provide this op then it means the device does
>* not do DMA at all. So nothing to do.
> @@ -53,6 +57,10 @@ void vfio_iommufd_unbind(struct vfio_device *vdev)
> {
> lockdep_assert_held(>dev_set->lock);
>
> + if (IS_ENABLED(CONFIG_VFIO_NO_IOMMU) &&
> + vdev->group->type == VFIO_NO_IOMMU)
> + return;
> +
> if (vdev->ops->unbind_iommufd)
> vdev->ops->unbind_iommufd(vdev);
> }
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index f3c48b8c45627d..08c5b05a129c2c 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -749,10 +749,13 @@ static int vfio_group_ioctl_set_container(struct
> vfio_group *group,
> if (!IS_ERR(iommufd)) {
> u32 ioas_id;
>
> - ret = iommufd_vfio_compat_ioas_id(iommufd, _id);
> - if (ret) {
> - iommufd_ctx_put(group->iommufd);
> - goto out_unlock;
> +
Re: [Intel-gfx] [PATCH] drm/i915: Don't wait forever in drop_caches
On 11/9/2022 03:35, Tvrtko Ursulin wrote: On 08/11/2022 19:37, John Harrison wrote: On 11/8/2022 01:08, Tvrtko Ursulin wrote: On 07/11/2022 19:45, John Harrison wrote: On 11/7/2022 06:09, Tvrtko Ursulin wrote: On 04/11/2022 17:45, John Harrison wrote: On 11/4/2022 03:01, Tvrtko Ursulin wrote: On 03/11/2022 19:16, John Harrison wrote: On 11/3/2022 02:38, Tvrtko Ursulin wrote: On 03/11/2022 09:18, Tvrtko Ursulin wrote: On 03/11/2022 01:33, John Harrison wrote: On 11/2/2022 07:20, Tvrtko Ursulin wrote: On 02/11/2022 12:12, Jani Nikula wrote: On Tue, 01 Nov 2022, john.c.harri...@intel.com wrote: From: John Harrison At the end of each test, IGT does a drop caches call via sysfs with sysfs? Sorry, that was meant to say debugfs. I've also been working on some sysfs IGT issues and evidently got my wires crossed! special flags set. One of the possible paths waits for idle with an infinite timeout. That causes problems for debugging issues when CI catches a "can't go idle" test failure. Best case, the CI system times out (after 90s), attempts a bunch of state dump actions and then reboots the system to recover it. Worst case, the CI system can't do anything at all and then times out (after 1000s) and simply reboots. Sometimes a serial port log of dmesg might be available, sometimes not. So rather than making life hard for ourselves, change the timeout to be 10s rather than infinite. Also, trigger the standard wedge/reset/recover sequence so that testing can continue with a working system (if possible). Signed-off-by: John Harrison --- drivers/gpu/drm/i915/i915_debugfs.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index ae987e92251dd..9d916fbbfc27c 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -641,6 +641,9 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_perf_noa_delay_fops, DROP_RESET_ACTIVE | \ DROP_RESET_SEQNO | \ DROP_RCU) + +#define DROP_IDLE_TIMEOUT (HZ * 10) I915_IDLE_ENGINES_TIMEOUT is defined in i915_drv.h. It's also only used here. So move here, dropping i915 prefix, next to the newly proposed one? Sure, can do that. I915_GEM_IDLE_TIMEOUT is defined in i915_gem.h. It's only used in gt/intel_gt.c. Move there and rename to GT_IDLE_TIMEOUT? I915_GT_SUSPEND_IDLE_TIMEOUT is defined and used only in intel_gt_pm.c. No action needed, maybe drop i915 prefix if wanted. These two are totally unrelated and in code not being touched by this change. I would rather not conflate changing random other things with fixing this specific issue. I915_IDLE_ENGINES_TIMEOUT is in ms, the rest are in jiffies. Add _MS suffix if wanted. My head spins. I follow and raise that the newly proposed DROP_IDLE_TIMEOUT applies to DROP_ACTIVE and not only DROP_IDLE. My original intention for the name was that is the 'drop caches timeout for intel_gt_wait_for_idle'. Which is quite the mouthful and hence abbreviated to DROP_IDLE_TIMEOUT. But yes, I realised later that name can be conflated with the DROP_IDLE flag. Will rename. Things get refactored, code moves around, bits get left behind, who knows. No reason to get too worked up. :) As long as people are taking a wider view when touching the code base, and are not afraid to send cleanups, things should be good. On the other hand, if every patch gets blocked in code review because someone points out some completely unrelated piece of code could be a bit better then nothing ever gets fixed. If you spot something that you think should be improved, isn't the general idea that you should post a patch yourself to improve it? There's two maintainers per branch and an order of magnitude or two more developers so it'd be nice if cleanups would just be incoming on self-initiative basis. ;) For the actual functional change at hand - it would be nice if code paths in question could handle SIGINT and then we could punt the decision on how long someone wants to wait purely to userspace. But it's probably hard and it's only debugfs so whatever. The code paths in question will already abort on a signal won't they? Both intel_gt_wait_for_idle() and intel_guc_wait_for_pending_msg(), which is where the uc_wait_for_idle eventually ends up, have an 'if(signal_pending) return -EINTR;' check. Beyond that, it sounds like what you are asking for is a change in the IGT libraries and/or CI framework to start sending signals after some specific timeout. That seems like a significantly more complex change (in terms of the number of entities affected and number of groups involved) and unnecessary. If you say so, I haven't looked at them all. But if the code path in question already aborts on signals then I am not sure what is the patch fixing? I assumed you are trying to avoid the write stuck in D forever, which then prevents
Re: [PATCH v6 00/20] drm/i915/vm_bind: Add VM_BIND functionality
On Wed, Nov 09, 2022 at 04:16:25PM -0800, Zanoni, Paulo R wrote: On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote: DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer objects (BOs) or sections of a BOs at specified GPU virtual addresses on a specified address space (VM). Multiple mappings can map to the same physical pages of an object (aliasing). These mappings (also referred to as persistent mappings) will be persistent across multiple GPU submissions (execbuf calls) issued by the UMD, without user having to provide a list of all required mappings during each submission (as required by older execbuf mode). This patch series support VM_BIND version 1, as described by the param I915_PARAM_VM_BIND_VERSION. Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. The new execbuf3 ioctl will not have any execlist support and all the legacy support like relocations etc., are removed. NOTEs: * It is based on below VM_BIND design+uapi rfc. Documentation/gpu/rfc/i915_vm_bind.rst Hi One difference for execbuf3 that I noticed that is not mentioned in the RFC document is that we now don't have a way to signal EXEC_OBJECT_WRITE. When looking at the Kernel code, some there are some pieces that check for this flag: - there's code that deals with frontbuffer rendering - there's code that deals with fences - there's code that prevents self-modifying batches - another that seems related to waiting for objects Are there any new rules regarding frontbuffer rendering when we use execbuf3? Any other behavior changes related to the other places that we should expect when using execbuf3? Paulo, Most of the EXEC_OBJECT_WRITE check in execbuf path is related to implicit dependency tracker which execbuf3 does not support. The frontbuffer related updated is the only exception and I don't remember the rationale to not require this on execbuf3. Matt, Tvrtko, Daniel, can you please comment here? Thanks, Niranjana Thanks, Paulo * The IGT RFC series is posted as, [PATCH i-g-t v5 0/12] vm_bind: Add VM_BIND validation support v2: Address various review comments v3: Address review comments and other fixes v4: Remove vm_unbind out fence uapi which is not supported yet, replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode() v5: Render kernel-doc, use PIN_NOEVICT, limit vm_bind support to non-recoverable faults v6: Rebased, minor fixes, add reserved fields to drm_i915_gem_vm_bind, add new patch for async vm_unbind support Signed-off-by: Niranjana Vishwanathapura Niranjana Vishwanathapura (20): drm/i915/vm_bind: Expose vm lookup function drm/i915/vm_bind: Add __i915_sw_fence_await_reservation() drm/i915/vm_bind: Expose i915_gem_object_max_page_size() drm/i915/vm_bind: Add support to create persistent vma drm/i915/vm_bind: Implement bind and unbind of object drm/i915/vm_bind: Support for VM private BOs drm/i915/vm_bind: Add support to handle object evictions drm/i915/vm_bind: Support persistent vma activeness tracking drm/i915/vm_bind: Add out fence support drm/i915/vm_bind: Abstract out common execbuf functions drm/i915/vm_bind: Use common execbuf functions in execbuf path drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl drm/i915/vm_bind: Update i915_vma_verify_bind_complete() drm/i915/vm_bind: Expose i915_request_await_bind() drm/i915/vm_bind: Handle persistent vmas in execbuf3 drm/i915/vm_bind: userptr dma-resv changes drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode drm/i915/vm_bind: Render VM_BIND documentation drm/i915/vm_bind: Async vm_unbind support Documentation/gpu/i915.rst| 78 +- drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +- drivers/gpu/drm/i915/gem/i915_gem_context.h | 17 + drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 6 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 516 +-- .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 871 ++ .../drm/i915/gem/i915_gem_execbuffer_common.c | 666 + .../drm/i915/gem/i915_gem_execbuffer_common.h | 74 ++ drivers/gpu/drm/i915/gem/i915_gem_ioctls.h| 2 + drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 + drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 6 + drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 19 + drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 30 + .../drm/i915/gem/i915_gem_vm_bind_object.c| 449 + drivers/gpu/drm/i915/gt/intel_gtt.c | 17 + drivers/gpu/drm/i915/gt/intel_gtt.h | 21 + drivers/gpu/drm/i915/i915_driver.c| 4 + drivers/gpu/drm/i915/i915_drv.h | 2 +
RE: [PATCH v2 09/11] vfio: Move container related MODULE_ALIAS statements into container.c
> From: Jason Gunthorpe
> Sent: Tuesday, November 8, 2022 8:53 AM
>
> The miscdev is in container.c, so should these related MODULE_ALIAS
> statements. This is necessary for the next patch to be able to fully
> disable /dev/vfio/vfio.
>
> Fixes: cdc71fe4ecbf ("vfio: Move container code into
> drivers/vfio/container.c")
> Reported-by: "Liu, Yi L"
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
RE: [PATCH v2 08/11] vfio-iommufd: Support iommufd for emulated VFIO devices
> From: Jason Gunthorpe > Sent: Tuesday, November 8, 2022 8:53 AM > > Emulated VFIO devices are calling vfio_register_emulated_iommu_dev() and > consist of all the mdev drivers. > > Like the physical drivers, support for iommufd is provided by the driver > supplying the correct standard ops. Provide ops from the core that > duplicate what vfio_register_emulated_iommu_dev() does. > > Emulated drivers are where it is more likely to see variation in the > iommfd support ops. For instance IDXD will probably need to setup both a > iommfd_device context linked to a PASID and an iommufd_access context to > support all their mdev operations. > > Tested-by: Nicolin Chen > Signed-off-by: Jason Gunthorpe this looks good to me overall. but I'll wait for next version to ack after the change for s390 is settled down and incorporated.
[Bug 204181] NULL pointer dereference regression in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204181 buro (francesco.bure...@proton.me) changed: What|Removed |Added CC||francesco.bure...@proton.me --- Comment #68 from buro (francesco.bure...@proton.me) --- Hello, I get similar system freeze and I know exactly how to reproduce it (on my machine): just visit https://www.unrealengine.com/ with Firefox 106.0.3 and you get the freeze. It happens also in others websites but more randomly. If you need more info I can give you, many thanks. Info about my graphic card: 07:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Device 3001 uname -a Linux arch-tower 6.0.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 29 Oct 2022 14:08:39 + x86_64 GNU/Linux The log from journalctl: Nov 09 19:30:29 arch-tower kernel: BUG: kernel NULL pointer dereference, address: 0020 Nov 09 19:30:29 arch-tower kernel: #PF: supervisor read access in kernel mode Nov 09 19:30:29 arch-tower kernel: #PF: error_code(0x) - not-present page Nov 09 19:30:29 arch-tower kernel: PGD 0 P4D 0 Nov 09 19:30:29 arch-tower kernel: Oops: [#1] PREEMPT SMP NOPTI Nov 09 19:30:29 arch-tower kernel: CPU: 7 PID: 220976 Comm: firefox:cs0 Not tainted 6.0.6-arch1-1 #1 a46cc4b882cfc11c3bbb09d6a0fab3dcad53b5c2 Nov 09 19:30:29 arch-tower kernel: Hardware name: System manufacturer System Product Name/PRIME A320M-K, BIOS 5207 08/30/2019 Nov 09 19:30:29 arch-tower kernel: RIP: 0010:amdgpu_sa_bo_free+0x57/0x150 [amdgpu] Nov 09 19:30:29 arch-tower kernel: Code: 00 00 4c 8b 60 20 48 89 d5 4c 89 e7 e8 22 fd 4b c3 48 85 ed 0f 84 a4 00 00 00 48 8b 45 30 a8 01 0f 85 98 00 00 00 48 8b 45 08 <48> 8b 40 20 48 85 c0 74 0c 48 89 ef e8 48 1e 6c c3 84 c0 75 77 4c Nov 09 19:30:29 arch-tower kernel: RSP: 0018:b2c98cedfa70 EFLAGS: 00010246 Nov 09 19:30:29 arch-tower kernel: RAX: RBX: 948784158e30 RCX: 80800078 Nov 09 19:30:29 arch-tower kernel: RDX: 0001 RSI: 948784158e30 RDI: 94878b1e62f0 Nov 09 19:30:29 arch-tower kernel: RBP: 948784158d98 R08: R09: 80800078 Nov 09 19:30:29 arch-tower kernel: R10: 0008 R11: 1000 R12: 94878b1e62f0 Nov 09 19:30:29 arch-tower kernel: R13: 94878b1e9628 R14: fff4 R15: 0001 Nov 09 19:30:29 arch-tower kernel: FS: 7f494b1ff6c0() GS:9488969c() knlGS: Nov 09 19:30:29 arch-tower kernel: CS: 0010 DS: ES: CR0: 80050033 Nov 09 19:30:29 arch-tower kernel: CR2: 0020 CR3: 000154e5 CR4: 003506e0 Nov 09 19:30:29 arch-tower kernel: Call Trace: Nov 09 19:30:29 arch-tower kernel: Nov 09 19:30:29 arch-tower kernel: amdgpu_job_free+0x55/0xe0 [amdgpu 3b0071ba2e7e576c543138f03ed9b8249042cca2] Nov 09 19:30:29 arch-tower kernel: amdgpu_cs_ioctl+0x506/0x1f30 [amdgpu 3b0071ba2e7e576c543138f03ed9b8249042cca2] Nov 09 19:30:29 arch-tower kernel: ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu 3b0071ba2e7e576c543138f03ed9b8249042cca2] Nov 09 19:30:29 arch-tower kernel: drm_ioctl_kernel+0xcd/0x170 Nov 09 19:30:29 arch-tower kernel: drm_ioctl+0x231/0x410 Nov 09 19:30:29 arch-tower kernel: ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu 3b0071ba2e7e576c543138f03ed9b8249042cca2] Nov 09 19:30:29 arch-tower kernel: amdgpu_drm_ioctl+0x4e/0x90 [amdgpu 3b0071ba2e7e576c543138f03ed9b8249042cca2] Nov 09 19:30:29 arch-tower kernel: __x64_sys_ioctl+0x94/0xd0 Nov 09 19:30:29 arch-tower kernel: do_syscall_64+0x5f/0x90 Nov 09 19:30:29 arch-tower kernel: ? do_futex+0xde/0x1b0 Nov 09 19:30:29 arch-tower kernel: ? __x64_sys_futex+0x92/0x1d0 Nov 09 19:30:29 arch-tower kernel: ? syscall_exit_to_user_mode+0x1b/0x40 Nov 09 19:30:29 arch-tower kernel: ? do_syscall_64+0x6b/0x90 Nov 09 19:30:29 arch-tower kernel: ? do_syscall_64+0x6b/0x90 Nov 09 19:30:29 arch-tower kernel: ? syscall_exit_to_user_mode+0x1b/0x40 Nov 09 19:30:29 arch-tower kernel: ? do_syscall_64+0x6b/0x90 Nov 09 19:30:29 arch-tower kernel: ? do_syscall_64+0x6b/0x90 Nov 09 19:30:29 arch-tower kernel: ? syscall_exit_to_user_mode+0x1b/0x40 Nov 09 19:30:29 arch-tower kernel: ? do_syscall_64+0x6b/0x90 Nov 09 19:30:29 arch-tower kernel: entry_SYSCALL_64_after_hwframe+0x63/0xcd Nov 09 19:30:29 arch-tower kernel: RIP: 0033:0x7f494b515c0f Nov 09 19:30:29 arch-tower kernel: Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00 Nov 09 19:30:29 arch-tower kernel: RSP: 002b:7f494b1fe9c0 EFLAGS: 0246 ORIG_RAX: 0010 Nov 09 19:30:29 arch-tower kernel: RAX: ffda RBX:
Re: [RFC] Approaches to deal with a struct with multiple fake flexible arrays members
On Wed, Nov 9, 2022 at 8:31 PM Paulo Miguel Almeida
wrote:
>
> On Wed, Nov 09, 2022 at 06:45:57PM -0600, Gustavo A. R. Silva wrote:
> > On Wed, Nov 09, 2022 at 04:45:42PM +1300, Paulo Miguel Almeida wrote:
> >
> > Adding Alex, Christian and DRM lists to the thread.
>
> Thanks so much for your reply Gustavo
> Yep, that's a good idea.
>
> >
> > > struct _ATOM_INIT_REG_BLOCK {
> > > USHORT usRegIndexTblSize;/* 0 2 */
> > > USHORT usRegDataBlkSize; /* 2 2 */
> > > ATOM_INIT_REG_INDEX_FORMAT asRegIndexBuf[1]; /* 4 3 */
> > > ATOM_MEMORY_SETTING_DATA_BLOCK asRegDataBuf[1]; /* 7 8 */
> >
> > I didn't find evidence that asRegDataBuf is used anywhere in the
> > codebase[1].
> > ...
> >
> > ...
> > As I pointed out above, I don't see asRegDataBuf[] being used in the
> > codebase (of course it may describe firmware memory layout). Instead,
> > there is this jump to a block of data past asRegIndexBuf[]:
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1444:
> > 1444: ATOM_MEMORY_SETTING_DATA_BLOCK *reg_data =
> > 1445: (ATOM_MEMORY_SETTING_DATA_BLOCK *)
> > 1446: ((u8 *)reg_block + (2 * sizeof(u16)) +
> > 1447: le16_to_cpu(reg_block->usRegIndexTblSize));
> >
> > So, it seems the one relevant array, from the kernel side, is
> > asRegIndexBuf[]. I wonder if we really need asRegDataBuf[] in that
> > structure... or if we could try modifying that struct and only have
> > asRegIndexBuf[] as last member? and then we can transform it into a
> > flex-array member.
>
> I saw that one too. That would be the way it's currently accessing
> asRegDataBuf member as the existing struct would make asRegDataBuf[0] point
> to some index within the asRegIndexBuf member (as you probably got it too)
>
> you are right... asRegDataBuff isn't used from a static analysis
> point of view but removing it make the code a bit cryptic, right?
>
> That's pickle, ay? :-)
>
> >
> > If for any strong reasong we cannot remove asRegDataBuf[] then I think we
> > could give it a try and use DECLARE_FLEX_ARRAY() to declare both arrays
> > in the structure.
> >
>
> Out of curiosity, why both rather than just asRegIndexBuf?
>
> > But first, of course, Alex, Christian, it'd be really great if we can
> > have your input and feedback. :)
This header describes the layout of memory stored in the ROM on the
GPU. It's shared between vbios and driver so some parts aren't
necessarily directly used by the driver. As for what to do about it,
I'm not sure. This structure stores a set of register offsets
(asRegIndexBuf) and data values (asRegDataBuf) for specific operations
(e.g., walk this structure and program register X with value Y. For a
little background on atombios, it's a set of data and command tables
stored in the vbios ROM image. The driver has an interpreter for the
command tables (see atom.c) so it can parse the command tables to
initialize the asic to a usable state. The various programming
sequences vary depending on the components the AIB/OEM uses for the
board (different vram vendors, different clock/voltage settings,
etc.). The legacy VGA/VBE and the GOP driver and the OS driver can
use these tables, so this allows us to initialize any GPU in a generic
way on any architecture even if the platform firmware doesn't post the
card. For the most part the driver doesn't have to deal with these
particular tables directly, other than for some very specific cases
where the driver needs to grab some elements from the tables to
populate the power management controller for GPU memory reclocking
parameters. However, the command tables as interpreted by the parser
very often will directly parse these tables. So you might have a
command table that the driver executes to initialize some part of the
GPU which ultimately fetches the table from the ROM image and walks it
programming registers based on the offset and values in that table.
So if you were debugging something that involves the atombios parser
and walking through one of the command tables, you may be confused if
the data tables don't match what header says. So ideally, we'd keep
both arrays.
Alex
> >
> > Thanks!
> > --
> > Gustavo
> >
>
> - Paulo A.
RE: [PATCH v2 07/11] vfio-iommufd: Support iommufd for physical VFIO devices
> From: Jason Gunthorpe
> Sent: Wednesday, November 9, 2022 1:52 AM
>
> On Tue, Nov 08, 2022 at 03:41:25PM +0800, Yi Liu wrote:
> > On 2022/11/8 14:10, Nicolin Chen wrote:
> > > On Mon, Nov 07, 2022 at 08:52:51PM -0400, Jason Gunthorpe wrote:
> > >
> > > > @@ -795,6 +800,10 @@ static int vfio_device_first_open(struct
> vfio_device *device)
> > > > ret = vfio_group_use_container(device->group);
> > > > if (ret)
> > > > goto err_module_put;
> > > > + } else if (device->group->iommufd) {
> > > > + ret = vfio_iommufd_bind(device, device->group->iommufd);
> > >
> > > Here we check device->group->iommufd...
> > >
> > > > + if (ret)
> > > > + goto err_module_put;
> > > > }
> > > > device->kvm = device->group->kvm;
> > > > @@ -812,6 +821,7 @@ static int vfio_device_first_open(struct
> vfio_device *device)
> > > > device->kvm = NULL;
> > > > if (device->group->container)
> > > > vfio_group_unuse_container(device->group);
> > > > + vfio_iommufd_unbind(device);
> > >
> > > ...yet, missing here, which could result in kernel oops.
> > >
> > > Should probably add something similar:
> > > + if (device->group->iommufd)
> > > + vfio_iommufd_unbind(device);
> > >
> > > Or should check !vdev->iommufd_device inside the ->unbind.
> >
> > this check was in prior version, but removed in this version. any
> > special reason? Jason?
>
> Oooh, this makes more sense - Kevin pointed out the check was wrong:
>
> > > +void vfio_iommufd_unbind(struct vfio_device *vdev)
> > > +{
> > > + lockdep_assert_held(>dev_set->lock);
> > > +
> > > + if (!vdev->iommufd_device)
> > > + return;
>
> > there is no iommufd_device in the emulated path...
>
> And he is right, so I dropped it. But really the check was just
> misspelled, it was supposed to be "device->group->iommufd" because the
> caller assumed it.
>
> Still, I think the right way to fix it is to lift the check as we
> don't touch group->iommufd in iommufd.c
>
yes this is the right fix.
RE: [PATCH v2 07/11] vfio-iommufd: Support iommufd for physical VFIO devices
> From: Jason Gunthorpe
> Sent: Tuesday, November 8, 2022 8:53 AM
>
> +
> +int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
> +{
> + u32 ioas_id;
> + u32 device_id;
> + int ret;
> +
> + lockdep_assert_held(>dev_set->lock);
> +
> + /*
> + * If the driver doesn't provide this op then it means the device does
> + * not do DMA at all. So nothing to do.
> + */
> + if (!vdev->ops->bind_iommufd)
> + return 0;
> +
> + ret = vdev->ops->bind_iommufd(vdev, ictx, _id);
> + if (ret)
> + return ret;
> +
> + ret = iommufd_vfio_compat_ioas_id(ictx, _id);
> + if (ret)
> + goto err_unbind;
> + ret = vdev->ops->attach_ioas(vdev, _id);
> + if (ret)
> + goto err_unbind;
with our discussion in v1:
https://lore.kernel.org/all/y2mgjqz8fvm54...@nvidia.com/
I got the rationale on iommufd part which doesn't have the concept
of container hence not necessarily to impose restriction on when
an user can change a compat ioas.
But from vfio side I wonder whether we should cache the compat
ioas id when it's attached by the first device and then use it all the
way for other device attachments coming after. implying IOAS_SET
only affects containers which haven't been attached.
In concept a container should be only aliased to one compat ioas
in its lifetime.
RE: [PATCH v2 06/11] vfio-iommufd: Allow iommufd to be used in place of a container fd
> From: Jason Gunthorpe > Sent: Tuesday, November 8, 2022 8:53 AM > > This makes VFIO_GROUP_SET_CONTAINER accept both a vfio container FD > and an > iommufd. > > In iommufd mode an IOAS will exist after the SET_CONTAINER, but it will > not be attached to any groups. > > For VFIO this means that the VFIO_GROUP_GET_STATUS and > VFIO_GROUP_FLAGS_VIABLE works subtly differently. With the container FD > the iommu_group_claim_dma_owner() is done during SET_CONTAINER but > for > IOMMUFD this is done during VFIO_GROUP_GET_DEVICE_FD. Meaning that > VFIO_GROUP_FLAGS_VIABLE could be set but GET_DEVICE_FD will fail due to > viability. > > As GET_DEVICE_FD can fail for many reasons already this is not expected to > be a meaningful difference. > > Reorganize the tests for if the group has an assigned container or iommu > into a vfio_group_has_iommu() function and consolidate all the duplicated > WARN_ON's etc related to this. > > Call container functions only if a container is actually present on the > group. > > Tested-by: Nicolin Chen > Signed-off-by: Jason Gunthorpe Reviewed-by: Kevin Tian
RE: [PATCH v2 05/11] vfio: Use IOMMU_CAP_ENFORCE_CACHE_COHERENCY for vfio_file_enforced_coherent()
> From: Jason Gunthorpe
> Sent: Tuesday, November 8, 2022 8:53 AM
>
> iommufd doesn't establish the iommu_domains until after the device FD is
> opened, even if the container has been set. This design is part of moving
> away from the group centric iommu APIs.
>
> This is fine, except that the normal sequence of establishing the kvm
> wbinvd won't work:
>
>group = open("/dev/vfio/XX")
>ioctl(group, VFIO_GROUP_SET_CONTAINER)
>ioctl(kvm, KVM_DEV_VFIO_GROUP_ADD)
>ioctl(group, VFIO_GROUP_GET_DEVICE_FD)
>
> As the domains don't start existing until GET_DEVICE_FD. Further,
> GET_DEVICE_FD requires that KVM_DEV_VFIO_GROUP_ADD already be
> done as that
> is what sets the group->kvm and thus device->kvm for the driver to use
> during open.
>
> Now that we have device centric cap ops and the new
> IOMMU_CAP_ENFORCE_CACHE_COHERENCY we know what the
> iommu_domain will be
> capable of without having to create it. Use this to compute
> vfio_file_enforced_coherent() and resolve the ordering problems.
>
> VFIO always tries to upgrade domains to enforce cache coherency, it never
> attaches a device that supports enforce cache coherency to a less capable
> domain, so the cap test is a sufficient proxy for the ultimate
> outcome. iommufd also ensures that devices that set the cap will be
> connected to enforcing domains.
>
> Tested-by: Nicolin Chen
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
RE: [PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c
> From: Jason Gunthorpe > Sent: Wednesday, November 9, 2022 9:11 PM > > > If all agree that VFIO_CONTAINER=n is a process to evolve, does it make > > more sense to remove this patch from this series i.e. let it buried in > > VFIO_CONTAINER=y for now? Then resolve it in a follow up patch if > > no consensus can be made quickly at this point. > > This is worse, it would make iommufd completely unusable in situations > where we need allow_unsafe_interrupts. If we belive that is important > we should keep this patch so existing systems on kernels with > VFIO_CONTAINER=y continue to work after libvirt/qemu are upgraded to > iommufd. > You are right. I kept a wrong thought that v2 has moved the option into vfio_main which is what I commented to hold before consensus was made. btw is it a good tradeoff by making vfio-compat as a module to carry this option? anyway it's not necessarily to be in iommufd core when VFIO=n.
RE: [PATCH v2 00/11] Connect VFIO to IOMMUFD
> From: Jason Gunthorpe > Sent: Wednesday, November 9, 2022 8:48 PM > > On Wed, Nov 09, 2022 at 09:03:52AM +, Tian, Kevin wrote: > > every mail in this series is shown thrice in lore: > > > > https://lore.kernel.org/all/0-v2-65016290f146+33e- > vfio_iommufd_...@nvidia.com/ > > > > not sure what caused it but it's annoying to check the conversation there. > > It is sort of a lore issue, it only combines messages that are exactly > the same together. Several of the mailing lists on CC here mangle the > message in various ways, eg adding trailer or whatever. This causes > repeated messages in lore. > > The trick in lore is to replace "/all/" with a good list, like /kvm/ > or /linux-iommu/ that shows the original non-mangled version, and only > once. > this trick works. Thanks!
Re: [RFC PATCH 1/3] drm: Introduce color fill properties for drm plane
On 11/9/2022 5:59 AM, Daniel Vetter wrote: On Wed, Nov 09, 2022 at 04:53:45PM +0300, Dmitry Baryshkov wrote: On 09/11/2022 16:52, Daniel Vetter wrote: On Tue, Nov 08, 2022 at 06:25:29PM +, Simon Ser wrote: On Saturday, October 29th, 2022 at 13:23, Dmitry Baryshkov wrote: On 29/10/2022 01:59, Jessica Zhang wrote: Add support for COLOR_FILL and COLOR_FILL_FORMAT properties for drm_plane. In addition, add support for setting and getting the values of these properties. COLOR_FILL represents the color fill of a plane while COLOR_FILL_FORMAT represents the format of the color fill. Userspace can set enable solid fill on a plane by assigning COLOR_FILL to a uint64_t value, assigning the COLOR_FILL_FORMAT property to a uint32_t value, and setting the framebuffer to NULL. I suppose that COLOR_FILL should override framebuffer rather than requiring that FB is set to NULL. In other words, if color_filL_format is non-zero, it would make sense to ignore the FB. Then one can use the color_fill_format property to quickly switch between filled plane and FB-backed one. That would be inconsistent with the rest of the KMS uAPI. For instance, the kernel will error out if CRTC has active=0 but a connector is still linked to the CRTC. IOW, the current uAPI errors out if the KMS state is inconsistent. So if the use-case here really is to solid-fill a plane (and not just provide a background color for the crtc overall), then I guess we could also extend addfb to make that happen. We've talked in the past about propertery-fying framebuffer objects, and that would sort out this uapi wart. And I agree the color fill vs PLANE_ID issue is a bit ugly at least. But if the use-cases are all background color then just doing the crtc background color would be tons simpler (and likely also easier to support for more hardware). No. The hardware supports multiple color-filled planes, which do not have to cover the whole CRTC. The use case here means the userspace use-case. What the hw can do on any given chip kinda doesnt matter, which is why I'm asking. KMD uapi is not meant to reflect 100% exactly what a specific chip can do, but instead: - provide features userspace actually needs. If you want per-plane fill, you need userspace that makes use of per-plane fill, and if all you have is crtc background, then that's it. Hey Daniel, The userspace use case we're trying to support is the Android HWC SOLID_FILL hint here [1], which is specifying per-plane fill. Thanks, Jessica Zhang [1] https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/master/graphics/composer/aidl/android/hardware/graphics/composer3/Composition.aidl#52 - we should create uapi with an eye towards what's actually possible on a reasonable set of drivers and hw. Sometimes that means a slightly more restricted set so that it's possible to implement in more places, especially if that restricted feature set still gets the job done for userspace. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [RFC] Approaches to deal with a struct with multiple fake flexible arrays members
On Wed, Nov 09, 2022 at 06:45:57PM -0600, Gustavo A. R. Silva wrote:
> On Wed, Nov 09, 2022 at 04:45:42PM +1300, Paulo Miguel Almeida wrote:
>
> Adding Alex, Christian and DRM lists to the thread.
Thanks so much for your reply Gustavo
Yep, that's a good idea.
>
> > struct _ATOM_INIT_REG_BLOCK {
> > USHORT usRegIndexTblSize;/* 0 2 */
> > USHORT usRegDataBlkSize; /* 2 2 */
> > ATOM_INIT_REG_INDEX_FORMAT asRegIndexBuf[1]; /* 4 3 */
> > ATOM_MEMORY_SETTING_DATA_BLOCK asRegDataBuf[1]; /* 7 8 */
>
> I didn't find evidence that asRegDataBuf is used anywhere in the
> codebase[1].
> ...
>
> ...
> As I pointed out above, I don't see asRegDataBuf[] being used in the
> codebase (of course it may describe firmware memory layout). Instead,
> there is this jump to a block of data past asRegIndexBuf[]:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1444:
> 1444: ATOM_MEMORY_SETTING_DATA_BLOCK *reg_data =
> 1445: (ATOM_MEMORY_SETTING_DATA_BLOCK *)
> 1446: ((u8 *)reg_block + (2 * sizeof(u16)) +
> 1447: le16_to_cpu(reg_block->usRegIndexTblSize));
>
> So, it seems the one relevant array, from the kernel side, is
> asRegIndexBuf[]. I wonder if we really need asRegDataBuf[] in that
> structure... or if we could try modifying that struct and only have
> asRegIndexBuf[] as last member? and then we can transform it into a
> flex-array member.
I saw that one too. That would be the way it's currently accessing
asRegDataBuf member as the existing struct would make asRegDataBuf[0] point
to some index within the asRegIndexBuf member (as you probably got it too)
you are right... asRegDataBuff isn't used from a static analysis
point of view but removing it make the code a bit cryptic, right?
That's pickle, ay? :-)
>
> If for any strong reasong we cannot remove asRegDataBuf[] then I think we
> could give it a try and use DECLARE_FLEX_ARRAY() to declare both arrays
> in the structure.
>
Out of curiosity, why both rather than just asRegIndexBuf?
> But first, of course, Alex, Christian, it'd be really great if we can
> have your input and feedback. :)
>
> Thanks!
> --
> Gustavo
>
- Paulo A.
Re: [PATCH v6 05/20] drm/i915/vm_bind: Implement bind and unbind of object
On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote:
> Add uapi and implement support for bind and unbind of an
> object at the specified GPU virtual addresses.
>
> The vm_bind mode is not supported in legacy execbuf2 ioctl.
> It will be supported only in the newer execbuf3 ioctl.
>
> v2: On older platforms ctx->vm is not set, check for it.
> In vm_bind call, add vma to vm_bind_list.
> Add more input validity checks.
> Update some documentation.
> v3: In vm_bind call, add vma to vm_bound_list as user can
> request a fence and pass to execbuf3 as input fence.
> Remove short term pinning with PIN_VALIDATE flag.
> v4: Replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode().
> v5: Ensure all reserved fields are 0, use PIN_NOEVICT.
> v6: Add reserved fields to drm_i915_gem_vm_bind.
>
> Reviewed-by: Matthew Auld
> Signed-off-by: Niranjana Vishwanathapura
> Signed-off-by: Prathap Kumar Valsan
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/gem/i915_gem_context.h | 15 +
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 5 +
> drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 26 ++
> .../drm/i915/gem/i915_gem_vm_bind_object.c| 324 ++
> drivers/gpu/drm/i915/gt/intel_gtt.c | 10 +
> drivers/gpu/drm/i915/gt/intel_gtt.h | 9 +
> drivers/gpu/drm/i915/i915_driver.c| 3 +
> drivers/gpu/drm/i915/i915_vma.c | 1 +
> drivers/gpu/drm/i915/i915_vma_types.h | 14 +
> include/uapi/drm/i915_drm.h | 99 ++
> 11 files changed, 507 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 51704b54317c..b731f3ac80da 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -166,6 +166,7 @@ gem-y += \
> gem/i915_gem_ttm_move.o \
> gem/i915_gem_ttm_pm.o \
> gem/i915_gem_userptr.o \
> + gem/i915_gem_vm_bind_object.o \
> gem/i915_gem_wait.o \
> gem/i915_gemfs.o
> i915-y += \
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> index 899fa8f1e0fe..e8b41aa8f8c4 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
> @@ -139,6 +139,21 @@ int i915_gem_context_setparam_ioctl(struct drm_device
> *dev, void *data,
> int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file);
>
>
>
>
> +/**
> + * i915_gem_vm_is_vm_bind_mode() - Check if address space is in vm_bind mode
> + * @vm: the address space
> + *
> + * Returns:
> + * true: @vm is in vm_bind mode; allows only vm_bind method of binding.
> + * false: @vm is not in vm_bind mode; allows only legacy execbuff method
> + *of binding.
> + */
> +static inline bool i915_gem_vm_is_vm_bind_mode(struct i915_address_space *vm)
> +{
> + /* No support to enable vm_bind mode yet */
> + return false;
> +}
> +
> struct i915_address_space *
> i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id);
>
>
>
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 1160723c9d2d..c5bc9f6e887f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -781,6 +781,11 @@ static int eb_select_context(struct i915_execbuffer *eb)
> if (unlikely(IS_ERR(ctx)))
> return PTR_ERR(ctx);
>
>
>
>
> + if (ctx->vm && i915_gem_vm_is_vm_bind_mode(ctx->vm)) {
> + i915_gem_context_put(ctx);
> + return -EOPNOTSUPP;
> + }
> +
> eb->gem_context = ctx;
> if (i915_gem_context_has_full_ppgtt(ctx))
> eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> new file mode 100644
> index ..36262a6357b5
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +#ifndef __I915_GEM_VM_BIND_H
> +#define __I915_GEM_VM_BIND_H
> +
> +#include
> +
> +struct drm_device;
> +struct drm_file;
> +struct i915_address_space;
> +struct i915_vma;
> +
> +struct i915_vma *
> +i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
> +
> +int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
> +struct drm_file *file);
> +int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file);
> +
> +void i915_gem_vm_unbind_all(struct
Re: Nested AVIC design (was:Re: [RFC PATCH v3 04/19] KVM: x86: mmu: allow to enable write tracking externally)
Sorry for the super slow reply, I don't have a good excuse other than I needed to take break from AVIC code... On Mon, Oct 03, 2022, Maxim Levitsky wrote: > On Thu, 2022-09-29 at 22:38 +, Sean Christopherson wrote: > > On Mon, Aug 08, 2022, Maxim Levitsky wrote: > > > Hi Sean, Paolo, and everyone else who wants to review my nested AVIC work. > > > > Before we dive deep into design details, I think we should first decide > > whether > > or not nested AVIC is worth pursing/supporting. > > > > - Rome has a ucode/silicon bug with no known workaround and no > > anticipated fix[*]; > > AMD's recommended "workaround" is to disable AVIC. > > - AVIC is not available in Milan, which may or may not be related to the > > aforementioned bug. > > - AVIC is making a comeback on Zen4, but Zen4 comes with x2AVIC. > > - x2APIC is likely going to become ubiquitous, e.g. Intel is effectively > > requiring x2APIC to fudge around xAPIC bugs. > > - It's actually quite realistic to effectively force the guest to use > > x2APIC, > > at least if it's a Linux guest. E.g. turn x2APIC on in BIOS, which is > > often > > (always?) controlled by the host, and Linux will use x2APIC. > > > > In other words, given that AVIC is well on its way to becoming a "legacy" > > feature, > > IMO there needs to be a fairly strong use case to justify taking on this > > much code > > and complexity. ~1500 lines of code to support a feature that has > > historically > > been buggy _without_ nested support is going to require a non-trivial > > amount of > > effort to review, stabilize, and maintain. > > > > [*] 1235 "Guest With AVIC (Advanced Virtual Interrupt Controller) Enabled > > May Fail > > to Process IPI (Inter-Processor Interrupt) Until Guest Is Re-Scheduled" > > in > > https://www.amd.com/system/files/TechDocs/56323-PUB_1.00.pdf > > > > I am afraid that you mixed things up: > > You mistake is that x2avic is just a minor addition to AVIC. It is still for > all practical purposes the same feature. ... > Physid tables, apic backing pages, doorbell emulation, > everything is pretty much unchanged. Ya, it finally clicked for me that KVM would needs to shadow the physical ID tables irrespective of x2APIC. I'm still very hesitant to support full virtualization of nested (x2)AVIC. The complexity and amount of code is daunting, and nSVM has lower hanging fruit that we should pick before going after full nested (x2)AVIC, e.g. SVM's TLB flushing needs a serious overhaul. And if we go through the pain for SVM, I think we'd probably want to come up with a solution that can be at least shared shared with VMX's IPI virtualization. As an intermediate step, can we expose (x2)AVIC to L2 without any shadowing? E.g. run all L2s with a single dummy physical ID table and emulate IPIs in KVM? If that works, that seems like a logical first step even if we want to eventually support nested IPI virtualization.
Re: [RFC] Approaches to deal with a struct with multiple fake flexible arrays members
On Wed, Nov 09, 2022 at 04:45:42PM +1300, Paulo Miguel Almeida wrote:
Adding Alex, Christian and DRM lists to the thread.
> Hi KSPP community,
>
> I've been working on replacing 1-element arrays with flex array members
> on the drm/amdgpu files. I came across one insteresting case which I
> may need to pick your brains to find a solution for it.
>
> The structure below has two fake flexible arrays but I would get an
> error if I try make them both FAM. How should/could I deal with the
> asRegIndexBuf in this case? In theory, DECLARE_FLEX_ARRAY would "work"
> but that doesn't seem to be its intended usage as far I've searched.
> (unless I got it wrong, if that's the case, feel free to set me straight)
>
> Any ideas?
>
> struct _ATOM_INIT_REG_BLOCK {
> USHORT usRegIndexTblSize;/* 0 2 */
> USHORT usRegDataBlkSize; /* 2 2 */
> ATOM_INIT_REG_INDEX_FORMAT asRegIndexBuf[1]; /* 4 3 */
> ATOM_MEMORY_SETTING_DATA_BLOCK asRegDataBuf[1]; /* 7 8 */
I didn't find evidence that asRegDataBuf is used anywhere in the
codebase[1].
>
> /* size: 15, cachelines: 1, members: 4 */
> /* last cacheline: 15 bytes */
> } __attribute__((__packed__));
Alex, Christian,
It looks like this structure is only being used as a template to populate
instances of struct atom_mc_reg_table[2] and that these[3] are the only
places where asRegIndexBuf[] is being used. Apparently, this array is only
being used to retrieve it's address so that a pointer can jump[4] in chucks
of size sizeof(ATOM_INIT_REG_INDEX_FORMAT):
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1461:
1461: format = (ATOM_INIT_REG_INDEX_FORMAT *)
1462: ((u8 *)format + sizeof(ATOM_INIT_REG_INDEX_FORMAT));
up to (VBIOS_MC_REGISTER_ARRAY_SIZE * sizeof(ATOM_INIT_REG_INDEX_FORMAT))[5],
As I pointed out above, I don't see asRegDataBuf[] being used in the
codebase (of course it may describe firmware memory layout). Instead,
there is this jump to a block of data past asRegIndexBuf[]:
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1444:
1444: ATOM_MEMORY_SETTING_DATA_BLOCK *reg_data =
1445: (ATOM_MEMORY_SETTING_DATA_BLOCK *)
1446: ((u8 *)reg_block + (2 * sizeof(u16)) +
1447:le16_to_cpu(reg_block->usRegIndexTblSize));
So, it seems the one relevant array, from the kernel side, is
asRegIndexBuf[]. I wonder if we really need asRegDataBuf[] in that
structure... or if we could try modifying that struct and only have
asRegIndexBuf[] as last member? and then we can transform it into a
flex-array member.
If for any strong reasong we cannot remove asRegDataBuf[] then I think we
could give it a try and use DECLARE_FLEX_ARRAY() to declare both arrays
in the structure.
But first, of course, Alex, Christian, it'd be really great if we can
have your input and feedback. :)
Thanks!
--
Gustavo
[1] https://elixir.bootlin.com/linux/latest/C/ident/asRegDataBuf
[2]
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c#L1441
[3] https://elixir.bootlin.com/linux/latest/C/ident/asRegIndexBuf
Re: [PATCH v6 20/20] drm/i915/vm_bind: Async vm_unbind support
On Wed, Nov 09, 2022 at 10:13:36PM +0100, Andi Shyti wrote:
Hi Niranjana,
...
-static void force_unbind(struct i915_vma *vma)
+static void force_unbind(struct i915_vma *vma, bool async)
{
if (!drm_mm_node_allocated(>node))
return;
@@ -1725,7 +1727,21 @@ static void force_unbind(struct i915_vma *vma)
i915_vma_set_purged(vma);
atomic_and(~I915_VMA_PIN_MASK, >flags);
- WARN_ON(__i915_vma_unbind(vma));
+ if (async) {
+ struct dma_fence *fence;
+
+ fence = __i915_vma_unbind_async(vma);
+ if (IS_ERR_OR_NULL(fence)) {
+ async = false;
+ } else {
+ dma_resv_add_fence(vma->obj->base.resv, fence,
+ DMA_RESV_USAGE_READ);
+ dma_fence_put(fence);
+ }
+ }
+
+ if (!async)
+ WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(>node));
}
@@ -1785,7 +1801,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
{
lockdep_assert_held(>vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
How about:
#define force_unbind(v) __force_unbind(v, false)
#define force_unbind_async(v) __force_unbind(v, true)
The true/false parameters in a function is not immediately
understandable.
or
#define force_unbind_sync(v)force_unbind(v, false)
#define force_unbind_async(v) force_unbind(v, true)
but I prefer the first version.
Andi, I get the point. But currently, force_unbind() is staic
function with only couple of invocations. These defines seems
an overkill (would be good to define these in header files
if the function is not static). Hope we can keep it as is for now.
Niranjana
Andi
Re: [PATCH v6 00/20] drm/i915/vm_bind: Add VM_BIND functionality
On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote: > DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM > buffer objects (BOs) or sections of a BOs at specified GPU virtual > addresses on a specified address space (VM). Multiple mappings can map > to the same physical pages of an object (aliasing). These mappings (also > referred to as persistent mappings) will be persistent across multiple > GPU submissions (execbuf calls) issued by the UMD, without user having > to provide a list of all required mappings during each submission (as > required by older execbuf mode). > > This patch series support VM_BIND version 1, as described by the param > I915_PARAM_VM_BIND_VERSION. > > Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in > vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. > The new execbuf3 ioctl will not have any execlist support and all the > legacy support like relocations etc., are removed. > > NOTEs: > * It is based on below VM_BIND design+uapi rfc. > Documentation/gpu/rfc/i915_vm_bind.rst Hi One difference for execbuf3 that I noticed that is not mentioned in the RFC document is that we now don't have a way to signal EXEC_OBJECT_WRITE. When looking at the Kernel code, some there are some pieces that check for this flag: - there's code that deals with frontbuffer rendering - there's code that deals with fences - there's code that prevents self-modifying batches - another that seems related to waiting for objects Are there any new rules regarding frontbuffer rendering when we use execbuf3? Any other behavior changes related to the other places that we should expect when using execbuf3? Thanks, Paulo > > * The IGT RFC series is posted as, > [PATCH i-g-t v5 0/12] vm_bind: Add VM_BIND validation support > > v2: Address various review comments > v3: Address review comments and other fixes > v4: Remove vm_unbind out fence uapi which is not supported yet, > replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode() > v5: Render kernel-doc, use PIN_NOEVICT, limit vm_bind support to > non-recoverable faults > v6: Rebased, minor fixes, add reserved fields to drm_i915_gem_vm_bind, > add new patch for async vm_unbind support > > Signed-off-by: Niranjana Vishwanathapura > > Niranjana Vishwanathapura (20): > drm/i915/vm_bind: Expose vm lookup function > drm/i915/vm_bind: Add __i915_sw_fence_await_reservation() > drm/i915/vm_bind: Expose i915_gem_object_max_page_size() > drm/i915/vm_bind: Add support to create persistent vma > drm/i915/vm_bind: Implement bind and unbind of object > drm/i915/vm_bind: Support for VM private BOs > drm/i915/vm_bind: Add support to handle object evictions > drm/i915/vm_bind: Support persistent vma activeness tracking > drm/i915/vm_bind: Add out fence support > drm/i915/vm_bind: Abstract out common execbuf functions > drm/i915/vm_bind: Use common execbuf functions in execbuf path > drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl > drm/i915/vm_bind: Update i915_vma_verify_bind_complete() > drm/i915/vm_bind: Expose i915_request_await_bind() > drm/i915/vm_bind: Handle persistent vmas in execbuf3 > drm/i915/vm_bind: userptr dma-resv changes > drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts > drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode > drm/i915/vm_bind: Render VM_BIND documentation > drm/i915/vm_bind: Async vm_unbind support > > Documentation/gpu/i915.rst| 78 +- > drivers/gpu/drm/i915/Makefile | 3 + > drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +- > drivers/gpu/drm/i915/gem/i915_gem_context.h | 17 + > drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 +- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 6 + > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 516 +-- > .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 871 ++ > .../drm/i915/gem/i915_gem_execbuffer_common.c | 666 + > .../drm/i915/gem/i915_gem_execbuffer_common.h | 74 ++ > drivers/gpu/drm/i915/gem/i915_gem_ioctls.h| 2 + > drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 + > drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 + > .../gpu/drm/i915/gem/i915_gem_object_types.h | 6 + > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 19 + > drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 30 + > .../drm/i915/gem/i915_gem_vm_bind_object.c| 449 + > drivers/gpu/drm/i915/gt/intel_gtt.c | 17 + > drivers/gpu/drm/i915/gt/intel_gtt.h | 21 + > drivers/gpu/drm/i915/i915_driver.c| 4 + > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/i915_gem_gtt.c | 39 + > drivers/gpu/drm/i915/i915_gem_gtt.h | 3 + > drivers/gpu/drm/i915/i915_getparam.c | 3 + > drivers/gpu/drm/i915/i915_sw_fence.c | 28 +- >
linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/nouveau/nouveau_drm.c: In function 'nouveau_drm_probe':
drivers/gpu/drm/nouveau/nouveau_drm.c:797:17: error: implicit declaration of
function 'drm_fbdev_generic_setup' [-Werror=implicit-function-declaration]
797 | drm_fbdev_generic_setup(drm_dev, 8);
| ^~~
Caused by commit
8ab59da26bc0 ("drm/fb-helper: Move generic fbdev emulation into separate
source file")
interacting with commit
4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
from the drm tree.
I have applied the following merge fix patch for today.
From: Stephen Rothwell
Date: Thu, 10 Nov 2022 11:05:52 +1100
Subject: [PATCH] drm-misc: fix up for "drm/fb-helper: Move generic fbdev
emulation into separate source file"
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index a19f18b251f3..80f154b6adab 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#include
--
2.35.1
--
Cheers,
Stephen Rothwell
pgpSU8th31Bg5.pgp
Description: OpenPGP digital signature
Re: [PATCH 5/6] drm/i915: Extract VESA DSC bpp alignment to separate function
On Thu, Nov 03, 2022 at 03:21:46PM +0200, Stanislav Lisovskiy wrote:
> We might to use that function separately from intel_dp_dsc_compute_config
> for DP DSC over MST case, because allocating bandwidth in that
> case can be a bit more tricky. So in order to avoid code copy-pasta
> lets extract this to separate function and reuse it for both SST
> and MST cases.
>
> v2: Removed multiple blank lines
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 50 +
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 -
> 3 files changed, 32 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 70f4d6422795..8288a30dbd51 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -671,6 +671,36 @@ small_joiner_ram_size_bits(struct drm_i915_private *i915)
> return 6144 * 8;
> }
>
> +u32 intel_dp_dsc_nearest_vesa_bpp(struct drm_i915_private *i915, u32 bpp,
> u32 pipe_bpp)
It makes sense to pull this out into a separate function.
For the function name, we have never had vesa in any of the function
names even though most of these come from vesa spec. So I think we
should remove vesa IMO, just name it as intel_dp_dsc_nearest_valid_bpp
or something?
Manasi
> +{
> + u32 bits_per_pixel = bpp;
> + int i;
> +
> + /* Error out if the max bpp is less than smallest allowed valid bpp */
> + if (bits_per_pixel < valid_dsc_bpp[0]) {
> + drm_dbg_kms(>drm, "Unsupported BPP %u, min %u\n",
> + bits_per_pixel, valid_dsc_bpp[0]);
> + return 0;
> + }
> +
> + /* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs
> */
> + if (DISPLAY_VER(i915) >= 13) {
> + bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
> + } else {
> + /* Find the nearest match in the array of known BPPs from VESA
> */
> + for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
> + if (bits_per_pixel < valid_dsc_bpp[i + 1])
> + break;
> + }
> + drm_dbg_kms(>drm, "Set dsc bpp from %d to VESA %d\n",
> + bits_per_pixel, valid_dsc_bpp[i]);
> +
> + bits_per_pixel = valid_dsc_bpp[i];
> + }
> +
> + return bits_per_pixel;
> +}
> +
> u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> u32 link_clock, u32 lane_count,
> u32 mode_clock, u32 mode_hdisplay,
> @@ -679,7 +709,6 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
> *i915,
> u32 timeslots)
> {
> u32 bits_per_pixel, max_bpp_small_joiner_ram;
> - int i;
>
> /*
>* Available Link Bandwidth(Kbits/sec) = (NumberOfLanes)*
> @@ -712,24 +741,7 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
> *i915,
> bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
> }
>
> - /* Error out if the max bpp is less than smallest allowed valid bpp */
> - if (bits_per_pixel < valid_dsc_bpp[0]) {
> - drm_dbg_kms(>drm, "Unsupported BPP %u, min %u\n",
> - bits_per_pixel, valid_dsc_bpp[0]);
> - return 0;
> - }
> -
> - /* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs
> */
> - if (DISPLAY_VER(i915) >= 13) {
> - bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
> - } else {
> - /* Find the nearest match in the array of known BPPs from VESA
> */
> - for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
> - if (bits_per_pixel < valid_dsc_bpp[i + 1])
> - break;
> - }
> - bits_per_pixel = valid_dsc_bpp[i];
> - }
> + bits_per_pixel = intel_dp_dsc_nearest_vesa_bpp(i915, bits_per_pixel,
> pipe_bpp);
>
> /*
>* Compressed BPP in U6.4 format so multiply by 16, for Gen 11,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index c6539a6915e9..0fe10d93b75c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -120,6 +120,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int
> lane_count)
> }
>
> u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
> +u32 intel_dp_dsc_nearest_vesa_bpp(struct drm_i915_private *i915, u32 bpp,
> u32 pipe_bpp);
>
> void intel_ddi_update_pipe(struct intel_atomic_state *state,
> struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 61b2bd504e80..8442eea27a57 100644
> ---
linux-next: manual merge of the drm-misc tree with the drm tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/nouveau/nouveau_fbcon.c
between commit:
4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
from the drm tree and commits:
9877d8f6bc37 ("drm/fb_helper: Rename field fbdev to info in struct
drm_fb_helper")
7fd50bc39d12 ("drm/fb-helper: Rename drm_fb_helper_alloc_fbi() to use _info
postfix")
afb0ff78c13c ("drm/fb-helper: Rename drm_fb_helper_unregister_fbi() to use
_info postfix")
from the drm-misc tree.
I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgp0e2ElSpTGk.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 2/2] drm/msm: Hangcheck progress detection
On Fri, Nov 4, 2022 at 8:08 AM Rob Clark wrote:
>
> From: Rob Clark
>
> If the hangcheck timer expires, check if the fw's position in the
> cmdstream has advanced (changed) since last timer expiration, and
> allow it up to three additional "extensions" to it's alotted time.
> The intention is to continue to catch "shader stuck in a loop" type
> hangs quickly, but allow more time for things that are actually
> making forward progress.
>
> Because we need to sample the CP state twice to detect if there has
> not been progress, this also cuts the the timer's duration in half.
>
> v2: Fix typo (REG_A6XX_CP_CSQ_IB2_STAT), add comment
> v3: Only halve hangcheck timer duration for generations which
> support progress detection (hdanton); removed unused a5xx
> progress (without knowing how to adjust for data buffered
> in ROQ it is too likely to report a false negative)
>
> Signed-off-by: Rob Clark
> Reviewed-by: Akhil P Oommen
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 34 +++
> drivers/gpu/drm/msm/msm_drv.c | 1 -
> drivers/gpu/drm/msm/msm_drv.h | 8 ++-
> drivers/gpu/drm/msm/msm_gpu.c | 31 +++-
> drivers/gpu/drm/msm/msm_gpu.h | 3 +++
> drivers/gpu/drm/msm/msm_ringbuffer.h | 24 +++
> 6 files changed, 98 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 1ff605c18ee6..7fe60c65a1eb 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -1843,6 +1843,39 @@ static uint32_t a6xx_get_rptr(struct msm_gpu *gpu,
> struct msm_ringbuffer *ring)
> return ring->memptrs->rptr = gpu_read(gpu, REG_A6XX_CP_RB_RPTR);
> }
>
> +static bool a6xx_progress(struct msm_gpu *gpu, struct msm_ringbuffer *ring)
> +{
> + struct msm_cp_state cp_state = {
> + .ib1_base = gpu_read64(gpu, REG_A6XX_CP_IB1_BASE),
> + .ib2_base = gpu_read64(gpu, REG_A6XX_CP_IB2_BASE),
> + .ib1_rem = gpu_read(gpu, REG_A6XX_CP_IB1_REM_SIZE),
> + .ib2_rem = gpu_read(gpu, REG_A6XX_CP_IB2_REM_SIZE),
> + };
> + bool progress;
> +
> + /*
> +* Adjust the remaining data to account for what has already been
> +* fetched from memory, but not yet consumed by the SQE.
> +*
> +* This is not *technically* correct, the amount buffered could
> +* exceed the IB size due to hw prefetching ahead, but:
> +*
> +* (1) We aren't trying to find the exact position, just whether
> +* progress has been made
> +* (2) The CP_REG_TO_MEM at the end of a submit should be enough
> +* to prevent prefetching into an unrelated submit. (And
> +* either way, at some point the ROQ will be full.)
> +*/
> + cp_state.ib1_rem += gpu_read(gpu, REG_A6XX_CP_CSQ_IB1_STAT) >> 16;
> + cp_state.ib2_rem += gpu_read(gpu, REG_A6XX_CP_CSQ_IB2_STAT) >> 16;
> +
> + progress = !!memcmp(_state, >last_cp_state,
> sizeof(cp_state));
> +
> + ring->last_cp_state = cp_state;
> +
> + return progress;
> +}
> +
> static u32 a618_get_speed_bin(u32 fuse)
> {
> if (fuse == 0)
> @@ -1961,6 +1994,7 @@ static const struct adreno_gpu_funcs funcs = {
> .create_address_space = a6xx_create_address_space,
> .create_private_address_space =
> a6xx_create_private_address_space,
> .get_rptr = a6xx_get_rptr,
> + .progress = a6xx_progress,
> },
> .get_timestamp = a6xx_get_timestamp,
> };
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 670651cdfa79..c3b77b44b2aa 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -419,7 +419,6 @@ static int msm_drm_init(struct device *dev, const struct
> drm_driver *drv)
> priv->dev = ddev;
>
> priv->wq = alloc_ordered_workqueue("msm", 0);
> - priv->hangcheck_period = DRM_MSM_HANGCHECK_DEFAULT_PERIOD;
>
> INIT_LIST_HEAD(>objects);
> mutex_init(>obj_lock);
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 0609daf4fa4c..876d8d5eec2f 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -225,7 +225,13 @@ struct msm_drm_private {
>
> struct drm_atomic_state *pm_state;
>
> - /* For hang detection, in ms */
> + /**
> +* hangcheck_period: For hang detection, in ms
> +*
> +* Note that in practice, a submit/job will get at least two hangcheck
> +* periods, due to checking for progress being implemented as simply
> +* "have the CP position registers changed since last time?"
> +*/
> unsigned int hangcheck_period;
>
> /**
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c
Re: [PATCH] drm/msm/dp: remove limitation of link rate at 5.4G to support HBR3
On 11/2/2022 11:04 AM, Dmitry Baryshkov wrote: On 02/11/2022 20:28, Doug Anderson wrote: Hi, On Wed, Nov 2, 2022 at 10:23 AM Dmitry Baryshkov wrote: 1. Someone figures out how to model this with the bridge chain and then we only allow HBR3 if we detect we've got a TCPC that supports it. This seems like the cleanest / best but feels like a long pole. Not only have we been trying to get the TCPC-modeled-as-a-bridge stuff landed for a long time but even when we do it we still don't have a solution for how to communicate the number of lanes and other stuff between the TCPC and the DP controller so we have to enrich the bridge interface. I think we'd need some OOB interface. For example for DSI interfaces we have mipi_dsi_device struct to communicate such OOB data. Also take a note regarding data-lanes from my previous email. Right, we can somehow communicate the max link rate through the bridge chain to the DP controller in an OOB manner that would work. I'd note that our dp_panel has some notion of such OOB data. So do AUX drivers including the panel-edp. My suggestion would be to consider both of them while modelling the OOB data. 2. We add in a DT property to the display controller node that says the max link rate for use on this board. This feels like a hack, but maybe it's not too bad. Certainly it would be incredibly simple to implement. Actually... ...one could argue that even if we later model the TCPC as a bridge that this property would still be valid / useful! You could certainly imagine that the SoC supports HBR3 and the TCPC supports HBR3 but that the board routing between the SoC and the TCPC is bad and only supports HBR2. In this case the only way out is essentially a "board constraint" AKA a DT property in the DP controller. We have been discussing similar topics with Abhinav. Krzysztof suggested using link-frequencies property to provide max and min values. questions, 1)is Krzysztof suggested had been implemented? 2) where is link property i can add link-frequencies? This sounds good to me and seems worth doing even if we eventually do #1. And the bonus point is that it can be done easily.
[pull] amdgpu, amdkfd drm-fixes-6.1
Hi Dave, Daniel, Fixes for 6.1. The following changes since commit 6295f1d8b4503ad8a18519b781dd2d1fe5e88c52: Merge tag 'drm-intel-fixes-2022-11-03' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2022-11-04 09:30:18 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.1-2022-11-09 for you to fetch changes up to 675d84621a24490e1de3d59a4992a17fa9ff92b5: drm/amd/display: only fill dirty rectangles when PSR is enabled (2022-11-09 18:07:59 -0500) amd-drm-fixes-6.1-2022-11-09: amdgpu: - SMU 13.0.4 update - GPUVM TLB race fix - DCN 3.1.4 fixes - DCN 3.2.x fixes - Vega10 fan fix - BACO fix for Beige Goby board - PSR fix - GPU VM PT locking fixes amdkfd: - CRIU fixes Asher Song (1): Revert "drm/amdgpu: Revert "drm/amdgpu: getting fan speed pwm for vega10 properly"" Aurabindo Pillai (1): drm/amd/display: Zeromem mypipe heap struct before using it Chaitanya Dhere (1): drm/amd/display: Fix FCLK deviation and tool compile issues Christian König (1): drm/amdgpu: workaround for TLB seq race Dillon Varone (1): drm/amd/display: Enforce minimum prefetch time for low memclk on DCN32 Felix Kuehling (2): drm/amdkfd: Fix error handling in kfd_criu_restore_events drm/amdkfd: Fix error handling in criu_checkpoint Guchun Chen (1): drm/amdgpu: disable BACO on special BEIGE_GOBY card Hamza Mahfooz (1): drm/amd/display: only fill dirty rectangles when PSR is enabled Nicholas Kazlauskas (2): drm/amd/display: Update SR watermarks for DCN314 drm/amd/display: Fix reg timeout in enc314_enable_fifo Philip Yang (2): drm/amdgpu: Unlock bo_list_mutex after error handling drm/amdgpu: Drop eviction lock when allocating PT BO Steve Su (1): drm/amd/display: Fix gpio port mapping issue Tim Huang (1): drm/amd/pm: update SMU IP v13.0.4 msg interface header drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 26 -- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 41 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 2 ++ drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 34 -- drivers/gpu/drm/amd/amdkfd/kfd_events.c| 3 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++-- .../amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.c | 32 - drivers/gpu/drm/amd/display/dc/dc.h| 1 + .../display/dc/dcn314/dcn314_dio_stream_encoder.c | 24 + .../gpu/drm/amd/display/dc/dcn32/dcn32_resource.c | 1 + .../drm/amd/display/dc/dcn321/dcn321_resource.c| 1 + .../gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c | 4 +-- .../gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c | 2 ++ .../amd/display/dc/dml/dcn32/display_mode_vba_32.c | 5 +++ .../amd/display/dc/dml/dcn32/display_mode_vba_32.h | 3 ++ .../dc/dml/dcn32/display_mode_vba_util_32.c| 14 ++-- .../dc/dml/dcn32/display_mode_vba_util_32.h| 3 +- .../gpu/drm/amd/display/dc/dml/dcn321/dcn321_fpu.c | 2 ++ .../drm/amd/display/dc/dml/display_mode_structs.h | 1 + .../amd/display/dc/gpio/dcn32/hw_factory_dcn32.c | 14 drivers/gpu/drm/amd/display/dc/gpio/hw_ddc.c | 9 +++-- .../drm/amd/pm/powerplay/hwmgr/vega10_thermal.c| 25 +++-- .../amd/pm/swsmu/inc/pmfw_if/smu_v13_0_4_ppsmc.h | 15 .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c| 4 ++- 25 files changed, 171 insertions(+), 103 deletions(-)
Re: [PATCH v6 20/20] drm/i915/vm_bind: Async vm_unbind support
Hi Niranjana,
...
> -static void force_unbind(struct i915_vma *vma)
> +static void force_unbind(struct i915_vma *vma, bool async)
> {
> if (!drm_mm_node_allocated(>node))
> return;
> @@ -1725,7 +1727,21 @@ static void force_unbind(struct i915_vma *vma)
> i915_vma_set_purged(vma);
>
> atomic_and(~I915_VMA_PIN_MASK, >flags);
> - WARN_ON(__i915_vma_unbind(vma));
> + if (async) {
> + struct dma_fence *fence;
> +
> + fence = __i915_vma_unbind_async(vma);
> + if (IS_ERR_OR_NULL(fence)) {
> + async = false;
> + } else {
> + dma_resv_add_fence(vma->obj->base.resv, fence,
> +DMA_RESV_USAGE_READ);
> + dma_fence_put(fence);
> + }
> + }
> +
> + if (!async)
> + WARN_ON(__i915_vma_unbind(vma));
> GEM_BUG_ON(drm_mm_node_allocated(>node));
> }
>
> @@ -1785,7 +1801,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
> {
> lockdep_assert_held(>vm->mutex);
>
> - force_unbind(vma);
> + force_unbind(vma, false);
How about:
#define force_unbind(v) __force_unbind(v, false)
#define force_unbind_async(v) __force_unbind(v, true)
The true/false parameters in a function is not immediately
understandable.
or
#define force_unbind_sync(v)force_unbind(v, false)
#define force_unbind_async(v) force_unbind(v, true)
but I prefer the first version.
Andi
Re: [PATCH] docs/sphinx: More depth in the rtd sidebar toc
Daniel Vetter writes:
> We love to nest our documenation for good structure, but that means
> the table of contents needs to keep up or you can't navigate them.
>
> Realized this trying to find the drm property documentation, which
> with some shuffling around disappeared. Why I didn't realize we can do
> this earlier, no idea.
>
> Since the relevant parts of the toc are only loaded if you're in the
> right .html file there's no harm in going all the way to unlimited.
>
> Note that this has no impact on the alabaster theme (which has a much
> simpler sidebar toc which doesn't show the entire hierarchy, only
> what's in the local rendered file) nor on the various :toctree:
> rendered inline in the output.
>
> Signed-off-by: Daniel Vetter
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> ---
> v2: Rebase onto linux-next, reword commit message to take into account
> that alabaster is the default now.
> ---
> Documentation/conf.py | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index c715610d6297..a5c45df0bd83 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -296,6 +296,10 @@ if html_theme == 'sphinx_rtd_theme' or html_theme ==
> 'sphinx_rtd_dark_mode':
> # Add color-specific RTD normal mode
> html_css_files.append('theme_rtd_colors.css')
>
> +html_theme_options = {
> +'navigation_depth': -1,
> +}
> +
> except ImportError:
> html_theme = 'alabaster'
Applied, thanks.
jon
Re: [PATCH v6 20/20] drm/i915/vm_bind: Async vm_unbind support
On Wed, Nov 09, 2022 at 05:52:54PM +, Matthew Auld wrote:
On Mon, 7 Nov 2022 at 08:53, Niranjana Vishwanathapura
wrote:
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.
No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_vma.c | 51 ++---
drivers/gpu/drm/i915/i915_vma.h | 1 +
2 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 08218e3a2f12..03c966fad87b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
#include "i915_vma.h"
#include "i915_vma_resource.h"
+static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
+
static inline void assert_vma_held_evict(const struct i915_vma *vma)
{
/*
@@ -1711,7 +1713,7 @@ void i915_vma_reopen(struct i915_vma *vma)
spin_unlock_irq(>closed_lock);
}
-static void force_unbind(struct i915_vma *vma)
+static void force_unbind(struct i915_vma *vma, bool async)
{
if (!drm_mm_node_allocated(>node))
return;
@@ -1725,7 +1727,21 @@ static void force_unbind(struct i915_vma *vma)
i915_vma_set_purged(vma);
atomic_and(~I915_VMA_PIN_MASK, >flags);
- WARN_ON(__i915_vma_unbind(vma));
+ if (async) {
+ struct dma_fence *fence;
+
+ fence = __i915_vma_unbind_async(vma);
+ if (IS_ERR_OR_NULL(fence)) {
+ async = false;
+ } else {
+ dma_resv_add_fence(vma->obj->base.resv, fence,
+ DMA_RESV_USAGE_READ);
+ dma_fence_put(fence);
+ }
+ }
+
+ if (!async)
+ WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(>node));
}
@@ -1785,7 +1801,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
{
lockdep_assert_held(>vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
list_del_init(>vm_link);
release_references(vma, vma->vm->gt, false);
}
@@ -1796,7 +1812,34 @@ void i915_vma_destroy(struct i915_vma *vma)
bool vm_ddestroy;
mutex_lock(>vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
+ list_del_init(>vm_link);
+ vm_ddestroy = vma->vm_ddestroy;
+ vma->vm_ddestroy = false;
+
+ /* vma->vm may be freed when releasing vma->vm->mutex. */
+ gt = vma->vm->gt;
+ mutex_unlock(>vm->mutex);
+ release_references(vma, gt, vm_ddestroy);
+}
+
+void i915_vma_destroy_async(struct i915_vma *vma)
Where are we calling this? I can't find it.
Ah, got missed out in this patch. It should be called from vm_unbind
path. Will fix it.
Thanks,
Niranjana
+{
+ bool vm_ddestroy, async = vma->obj->mm.rsgt;
+ struct intel_gt *gt;
+
+ if (dma_resv_reserve_fences(vma->obj->base.resv, 1))
+ async = false;
+
+ mutex_lock(>vm->mutex);
+ /*
+* Ensure any asynchronous binding is complete while using
+* async unbind as we will be releasing the vma here.
+*/
+ if (async && i915_active_wait(>active))
+ async = false;
+
+ force_unbind(vma, async);
list_del_init(>vm_link);
vm_ddestroy = vma->vm_ddestroy;
vma->vm_ddestroy = false;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 737ef310d046..25f15965dab8 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -272,6 +272,7 @@ void i915_vma_reopen(struct i915_vma *vma);
void i915_vma_destroy_locked(struct i915_vma *vma);
void i915_vma_destroy(struct i915_vma *vma);
+void i915_vma_destroy_async(struct i915_vma *vma);
#define assert_vma_held(vma) dma_resv_assert_held((vma)->obj->base.resv)
--
2.21.0.rc0.32.g243a4c7e27
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Add GT oriented dmesg output
On 09.11.2022 18:46, John Harrison wrote:
> On 11/9/2022 03:05, Tvrtko Ursulin wrote:
>> On 08/11/2022 20:15, John Harrison wrote:
>>> On 11/8/2022 01:01, Tvrtko Ursulin wrote:
On 07/11/2022 19:14, John Harrison wrote:
> On 11/7/2022 08:17, Tvrtko Ursulin wrote:
>> On 07/11/2022 09:33, Tvrtko Ursulin wrote:
>>> On 05/11/2022 01:03, Ceraolo Spurio, Daniele wrote:
On 11/4/2022 10:25 AM, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> When trying to analyse bug reports from CI, customers, etc. it
> can be
> difficult to work out exactly what is happening on which GT in a
> multi-GT system. So add GT oriented debug/error message
> wrappers. If
> used instead of the drm_ equivalents, you get the same output
> but with
> a GT# prefix on it.
>
> Signed-off-by: John Harrison
The only downside to this is that we'll print "GT0: " even on
single-GT devices. We could introduce a gt->info.name and print
that, so we could have it different per-platform, but IMO it's
not worth the effort.
Reviewed-by: Daniele Ceraolo Spurio
I think it might be worth getting an ack from one of the
maintainers to make sure we're all aligned on transitioning to
these new logging macro for gt code.
>>>
>>> Idea is I think a very good one. First I would suggest
>>> standardising to lowercase GT in logs because:
>>>
>>> $ grep "GT%" i915/ -r
>>> $ grep "gt%" i915/ -r
>>> i915/gt/intel_gt_sysfs.c: gt->i915->sysfs_gt, "gt%d", gt->info.id))
>>> i915/gt/intel_gt_sysfs.c: "failed to initialize
>>> gt%d sysfs root\n", gt->info.id);
>>> i915/gt/intel_gt_sysfs_pm.c: "failed to
>>> create gt%u RC6 sysfs files (%pe)\n",
>>> i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u RC6p sysfs
>>> files (%pe)\n",
>>> i915/gt/intel_gt_sysfs_pm.c: "failed to
>>> create gt%u RPS sysfs files (%pe)",
>>> i915/gt/intel_gt_sysfs_pm.c: "failed to
>>> create gt%u punit_req_freq_mhz sysfs (%pe)",
>>> i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u throttle
>>> sysfs files (%pe)",
>>> i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u
>>> media_perf_power_attrs sysfs (%pe)\n",
>>> i915/gt/intel_gt_sysfs_pm.c: "failed to add
>>> gt%u rps defaults (%pe)\n",
>>> i915/i915_driver.c: drm_err(>i915->drm, "gt%d:
>>> intel_pcode_init failed %d\n", id, ret);
>>> i915/i915_hwmon.c: snprintf(ddat_gt->name, sizeof(ddat_gt->name),
>>> "i915_gt%u", i);
>>>
>
> Just because there are 11 existing instances of one form doesn't
> mean that the 275 instances that are waiting to be converted should
> be done incorrectly. GT is an acronym and should be capitalised.
Okay just make it consistent then.
> Besides:
> grep -r "GT " i915 | grep '"'
> i915/vlv_suspend.c: drm_err(>drm, "timeout
> disabling GT waking\n");
> i915/vlv_suspend.c: "timeout waiting for GT
> wells to go %s\n",
> i915/vlv_suspend.c: drm_dbg(>drm, "GT register access
> while GT waking disabled\n");
> i915/i915_gpu_error.c: err_printf(m, "GT awake: %s\n",
> str_yes_no(gt->awake));
> i915/i915_debugfs.c: seq_printf(m, "GT awake? %s [%d], %llums\n",
> i915/selftests/i915_gem_evict.c: pr_err("Failed to idle GT (on
> %s)", engine->name);
> i915/intel_uncore.c: "GT thread status wait timed
> out\n");
> i915/gt/uc/selftest_guc_multi_lrc.c: drm_err(>i915->drm, "GT
> failed to idle: %d\n", ret);
> i915/gt/uc/selftest_guc.c: drm_err(>i915->drm, "GT failed to
> idle: %d\n", ret);
> i915/gt/uc/selftest_guc.c: drm_err(>i915->drm, "GT failed to
> idle: %d\n", ret);
> i915/gt/intel_gt_mcr.c: * Some GT registers are designed as
> "multicast" or "replicated" registers:
> i915/gt/selftest_rps.c: pr_info("%s: rps counted %d
> C0 cycles [%lldns] in %lldns [%d cycles], using GT clock frequency
> of %uKHz\n",
> i915/gt/selftest_hangcheck.c: pr_err("[%s] GT is
> wedged!\n", engine->name);
> i915/gt/selftest_hangcheck.c: pr_err("GT is wedged!\n");
> i915/gt/intel_gt_clock_utils.c: "GT clock frequency
> changed, was %uHz, now %uHz!\n",
> i915/gt/selftest_engine_pm.c: pr_err("Unable to flush GT
> pm before test\n");
> i915/gt/selftest_engine_pm.c: pr_err("GT failed to idle\n");
> i915/i915_sysfs.c: "failed to register GT
> sysfs directory\n");
> i915/intel_uncore.h: * of the basic non-engine GT registers
> (referred to as "GSI" on
> i915/intel_uncore.h: * newer
Re: [PATCH v2 10/11] vfio: Make vfio_container optionally compiled
On Wed, Nov 09, 2022 at 10:18:09AM -0700, Alex Williamson wrote:
> DPDK supports no-iommu mode.
Er? Huh? How? I thought no-iommu was for applications that didn't do
DMA? How is DPDK getting packets in/out without DMA? I guess it snoops
in /proc/ or something to learn PFNs of mlock'd memory?
> I agree that it's very useful for testing, I'm certainly not suggesting
> to give up, but I'm not sure where no-iommu lives when iommufd owns
> /dev/vfio/vfio. Given the unsafe interrupts discussion, it doesn't
> seem like the type of thing that would be a priority for iommufd.
Ah, I think the bit below will do the job, I'm not sure without doing
some testing (and I don't think I have the necessary Intel NIC for
DPDK). The basic point is no-iommu literally means 'do not use iommufd
at all, do not create an iommufd_device or an iommufd_access'. VFIO
can easially do that on its own.
The only slightly messy bit is that uAPI requires the SET_CONTAINER
which we can just NOP in vfio_compat. With more checks it could have
higher fidelity of error cases, but not sure it is worth it.
When we talk about the device cdev flow then I suggest that no-iommu
simply requires -1 for the iommufd during bind - ie no iommufd is
used or accepted and that is how the userspace knows/confirms it is in
no-iommu mode.
> We're on a path where vfio accepts an iommufd as a container, and
> ultimately iommufd becomes the container provider, supplanting the
> IOMMU driver registration aspect of vfio. I absolutely want type1 and
> spapr backends to get replaced by iommufd, but reluctance to support
> aspects of vfio "legacy" behavior doesn't give me warm fuzzies about a
> wholesale hand-off of the container to a different subsystem, for
> example vs an iommufd shim spoofing type1 support.
Well, I will agree to do everything required, just let's go through the
process to understand the security situation and ensure we are still
doing things the right way.
> Unfortunately we no longer have a CONFIG_EXPERIMENTAL option to hide
> behind for disabling VFIO_CONTAINER, so regardless of our intentions
> that a transition is some time off, it may become an issue sooner than
> we expect.
We can add kconfig text discouraging that?
diff --git a/drivers/iommu/iommufd/vfio_compat.c
b/drivers/iommu/iommufd/vfio_compat.c
index dbef3274803336..81f7594cfff8e0 100644
--- a/drivers/iommu/iommufd/vfio_compat.c
+++ b/drivers/iommu/iommufd/vfio_compat.c
@@ -259,6 +259,14 @@ static int iommufd_vfio_set_iommu(struct iommufd_ctx
*ictx, unsigned long type)
struct iommufd_ioas *ioas = NULL;
int rc = 0;
+ /*
+* Emulation for NOIMMU is imperfect in that VFIO blocks almost all
+* other ioctls. We let them keep working but they mostly fail since no
+* IOAS should exist.
+*/
+ if (IS_ENABLED(CONFIG_VFIO_NOIOMMU) && type == VFIO_NOIOMMU_IOMMU)
+ return 0;
+
if (type != VFIO_TYPE1_IOMMU && type != VFIO_TYPE1v2_IOMMU)
return -EINVAL;
diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index 595c7b2146f88c..64a336ebc99b9f 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -18,6 +18,10 @@ int vfio_iommufd_bind(struct vfio_device *vdev, struct
iommufd_ctx *ictx)
lockdep_assert_held(>dev_set->lock);
+ if (IS_ENABLED(CONFIG_VFIO_NO_IOMMU) &&
+ vdev->group->type == VFIO_NO_IOMMU)
+ return 0;
+
/*
* If the driver doesn't provide this op then it means the device does
* not do DMA at all. So nothing to do.
@@ -53,6 +57,10 @@ void vfio_iommufd_unbind(struct vfio_device *vdev)
{
lockdep_assert_held(>dev_set->lock);
+ if (IS_ENABLED(CONFIG_VFIO_NO_IOMMU) &&
+ vdev->group->type == VFIO_NO_IOMMU)
+ return;
+
if (vdev->ops->unbind_iommufd)
vdev->ops->unbind_iommufd(vdev);
}
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index f3c48b8c45627d..08c5b05a129c2c 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -749,10 +749,13 @@ static int vfio_group_ioctl_set_container(struct
vfio_group *group,
if (!IS_ERR(iommufd)) {
u32 ioas_id;
- ret = iommufd_vfio_compat_ioas_id(iommufd, _id);
- if (ret) {
- iommufd_ctx_put(group->iommufd);
- goto out_unlock;
+ if (!IS_ENABLED(CONFIG_VFIO_NO_IOMMU) ||
+ group->type != VFIO_NO_IOMMU) {
+ ret = iommufd_vfio_compat_ioas_id(iommufd, _id);
+ if (ret) {
+ iommufd_ctx_put(group->iommufd);
+ goto out_unlock;
+ }
}
group->iommufd = iommufd;
Re: [PATCH v2 1/2] arm64: dts: qcom: Add link-frequencies property to specify the max link rate allowed
On 09/11/2022 21:34, Kuogee Hsieh wrote:
This patch add link-frequencies property to allow each platform to specify its
DP max link rate.
Signed-off-by: Kuogee Hsieh
---
arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index 93e39fc..7e5d755 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -441,6 +441,7 @@ ap_i2c_tpm: {
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
data-lanes = <0 1>;
+link-frequencies = <81>;
The link frequency is a property of the link - in other words a graph
connection. Please don't put random propreties into DT nodes where they
are not to be used.
};
_mdp {
--
With best wishes
Dmitry
Re: [PATCH v2] drm/amd/display: only fill dirty rectangles when PSR is enabled
On 11/9/22 13:20, Hamza Mahfooz wrote: Currently, we are calling fill_dc_dirty_rects() even if PSR isn't supported by the relevant link in amdgpu_dm_commit_planes(), this is undesirable especially because when drm.debug is enabled we are printing messages in fill_dc_dirty_rects() that are only useful for debugging PSR (and confusing otherwise). So, we can instead limit the filling of dirty rectangles to only when PSR is enabled. Signed-off-by: Hamza Mahfooz Reviewed-by: Leo Li Thanks --- v2: give a more concrete reason. --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) 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 66eb16fbe09f..956a6e494709 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -7697,9 +7697,10 @@ static void amdgpu_dm_commit_planes(struct drm_atomic_state *state, bundle->surface_updates[planes_count].plane_info = >plane_infos[planes_count]; - fill_dc_dirty_rects(plane, old_plane_state, new_plane_state, - new_crtc_state, - >flip_addrs[planes_count]); + if (acrtc_state->stream->link->psr_settings.psr_feature_enabled) + fill_dc_dirty_rects(plane, old_plane_state, + new_plane_state, new_crtc_state, + >flip_addrs[planes_count]); /* * Only allow immediate flips for fast updates that don't
Re: [PATCH v2] drm: xlnx: Fix return type of zynqmp_dp_bridge_mode_valid
On Tue, Nov 08, 2022 at 05:14:25PM -0700, Nathan Chancellor wrote: > From: Nathan Huckleberry > > The mode_valid field in drm_bridge_helper_funcs is expected to be of > type > enum drm_mode_status (* mode_valid) (struct drm_bridge *bridge, > struct drm_display_mode *mode); > > The mismatched return type breaks forward edge kCFI since the underlying > function definition does not match the function hook definition. A new > warning in clang will catch this at compile time: > > drivers/gpu/drm/xlnx/zynqmp_dp.c:1573:16: error: incompatible function > pointer types initializing 'enum drm_mode_status (*)(struct drm_bridge *, > const struct drm_display_info *, const struct drm_display_mode *)' with an > expression of type 'int (struct drm_bridge *, const struct drm_display_info > *, const struct drm_display_mode *)' > [-Werror,-Wincompatible-function-pointer-types-strict] > .mode_valid = zynqmp_dp_bridge_mode_valid, > ^~~ > 1 error generated. > > The return type of zynqmp_dp_bridge_mode_valid should be changed from > int to enum drm_mode_status. > > Reported-by: Dan Carpenter > Link: https://github.com/ClangBuiltLinux/linux/issues/1703 > Link: https://github.com/ClangBuiltLinux/linux/issues/1750 > Signed-off-by: Nathan Huckleberry Reviewed-by: Kees Cook -- Kees Cook
Re: [PATCH v8 4/7] drm/shmem-helper: Add memory shrinker
Hello Thomas,
On 11/9/22 13:28, Thomas Zimmermann wrote:
>> +int drm_gem_shmem_set_evictable(struct drm_gem_shmem_object *shmem)
>> +{
>> + dma_resv_lock(shmem->base.resv, NULL);
>> +
>> + if (shmem->madv < 0) {
>> + dma_resv_unlock(shmem->base.resv);
>> + return -ENOMEM;
>
> ENOMEM is not right here. It's for failed memory allocation. ENODEV
> seems more appropriate.
Had the same thought about ENOMEM and at one point was considering
ENOENT, but in the end decided it's not much better than ENOMEM.
> But why do we need an error here anyway? Why not just fail transparently?
I added the error handling everywhere for consistency. Perhaps indeed
will be better to fail transparently for now since nobody cares about
such errors and likely won't in the future.
The rest of the comments are also good to me, will start preparing the
v9. Thank you for the review!
--
Best regards,
Dmitry
[PATCH v2 1/2] arm64: dts: qcom: Add link-frequencies property to specify the max link rate allowed
This patch add link-frequencies property to allow each platform to specify its
DP max link rate.
Signed-off-by: Kuogee Hsieh
---
arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index 93e39fc..7e5d755 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -441,6 +441,7 @@ ap_i2c_tpm: {
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
data-lanes = <0 1>;
+link-frequencies = <81>;
};
_mdp {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v2 2/2] drm/msm/dp: add support of max dp link rate
Since it is not every platform supports HBR3 link rate, this patch
limit the DP link rate at max link rate if it is specified at DTS file.
Otherwise, the max dp link rate will be limited at HBR2 as before.
Changes in v2:
-- add max link rate from dtsi
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 1 +
drivers/gpu/drm/msm/dp/dp_panel.c | 5 ++---
drivers/gpu/drm/msm/dp/dp_panel.h | 1 +
drivers/gpu/drm/msm/dp/dp_parser.c | 8
drivers/gpu/drm/msm/dp/dp_parser.h | 1 +
5 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 29c9845..0e1a9b3 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -390,6 +390,7 @@ static int dp_display_process_hpd_high(struct
dp_display_private *dp)
struct edid *edid;
dp->panel->max_dp_lanes = dp->parser->max_dp_lanes;
+ dp->panel->max_dp_link_rate = dp->parser->max_dp_link_rate;
rc = dp_panel_read_sink_caps(dp->panel, dp->dp_display.connector);
if (rc)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 5149ceb..87c27ca 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -78,9 +78,8 @@ static int dp_panel_read_dpcd(struct dp_panel *dp_panel)
if (link_info->num_lanes > dp_panel->max_dp_lanes)
link_info->num_lanes = dp_panel->max_dp_lanes;
- /* Limit support upto HBR2 until HBR3 support is added */
- if (link_info->rate >= (drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4)))
- link_info->rate = drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4);
+ if (link_info->rate > dp_panel->max_dp_link_rate)
+ link_info->rate = dp_panel->max_dp_link_rate;
drm_dbg_dp(panel->drm_dev, "version: %d.%d\n", major, minor);
drm_dbg_dp(panel->drm_dev, "link_rate=%d\n", link_info->rate);
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h
b/drivers/gpu/drm/msm/dp/dp_panel.h
index d861197a..f04d021 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.h
+++ b/drivers/gpu/drm/msm/dp/dp_panel.h
@@ -50,6 +50,7 @@ struct dp_panel {
u32 vic;
u32 max_dp_lanes;
+ u32 max_dp_link_rate;
u32 max_bw_code;
};
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c
b/drivers/gpu/drm/msm/dp/dp_parser.c
index dd73221..d2e31c2 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -95,6 +95,7 @@ static int dp_parser_misc(struct dp_parser *parser)
{
struct device_node *of_node = parser->pdev->dev.of_node;
int len;
+ u32 rate;
len = drm_of_get_data_lanes_count(of_node, 1, DP_MAX_NUM_DP_LANES);
if (len < 0) {
@@ -104,6 +105,13 @@ static int dp_parser_misc(struct dp_parser *parser)
}
parser->max_dp_lanes = len;
+
+ len = of_property_read_s32(of_node, "link-frequencies", );
+ if (len >= 0)
+ parser->max_dp_link_rate = rate;
+ else
+ parser->max_dp_link_rate = 54; /* default HBR2 */
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h
b/drivers/gpu/drm/msm/dp/dp_parser.h
index 866c1a8..ba63375 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -119,6 +119,7 @@ struct dp_parser {
struct dp_io io;
struct dp_display_data disp_data;
u32 max_dp_lanes;
+ u32 max_dp_link_rate;
struct drm_bridge *next_bridge;
int (*parse)(struct dp_parser *parser);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v2 0/2] Add DP max link rate support
dd DP link-frequencies property to DTS file and support function to DP driver. Kuogee Hsieh (2): arm64: dts: qcom: Add link-frequencies property to specify the max link rate allowed drm/msm/dp: add support of max dp link rate arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 1 + drivers/gpu/drm/msm/dp/dp_display.c| 1 + drivers/gpu/drm/msm/dp/dp_panel.c | 5 ++--- drivers/gpu/drm/msm/dp/dp_panel.h | 1 + drivers/gpu/drm/msm/dp/dp_parser.c | 8 drivers/gpu/drm/msm/dp/dp_parser.h | 1 + 6 files changed, 14 insertions(+), 3 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c
On Tue, 8 Nov 2022 21:05:21 -0400 Jason Gunthorpe wrote: > On Tue, Nov 08, 2022 at 03:55:20PM -0700, Alex Williamson wrote: > > > > > So why exactly isn't this an issue for VDPA? Are we just burying our > > > > head in the sand that such platforms exists and can still be useful > > > > given the appropriate risk vs reward trade-off? > > > > > > Simply that nobody has asked for it, and might never ask for it. This > > > is all support for old platforms, and there just doesn't seem to be a > > > "real" use case for very new (and actually rare) NIC hardware stuck > > > into ancient platforms with this security problem. > > > > vIOMMU support for interrupt remapping is relatively new, the nesting > > case is important as well. > > This is where we got hit. In the end we fixed the qemu.. > > > > I'd be much more comfortable with this as a system wide iommufd flag > > > if we also tied it to do some demonstration of privilege - eg a > > > requirement to open iommufd with CAP_SYS_RAWIO for instance. > > > > Which is not compatible to existing use cases, which is also why we > > can't invent some way to allow some applications to run without CPU > > mitigations, while requiring it for others as a baseline. > > Isn't it? Didn't we learn that libvirt runs as root and will open and > pass the iommufd as root? We're jumping ahead to native iommufd support here, what happens when VFIO_CONTAINER=n and it's QEMU opening the fds, with only file access privileges? > > > That is the usual protocol for these kinds of insecurities.. > > > > Hmm, is it? > > I think so. At least you should have something to shut down an > insecure feature in kernel lockdown modes. CAP_SYS_RAWIO is a simple > way to do it. How are CPU vulnerabilities handled in lockdown mode, do apps require certain capabilities to run fast vs safe, or do we simply disallow unsafe globally in lockdown? I think we have a lot more leniency to ignore/disallow flags that enable global insecurities when any sort of lockdown is imposed. > > > I think right now we can leave this as-is and we can wait for some > > > more information to decide how best to proceed. > > > > It's certainly not acceptable in the latest proposal, iommufd consumes > > an option set by another module and when that module goes away, so does > > any claim of compatibility. The code becomes dead and the feature not > > present. The option doesn't belong on the vfio module. Do we need a > > vfio-iommufd module to host it? Thanks, > > I don't know, as I said in the other email, these little things need > work and discussion to resolve. We need to recheck the security stuff > against the 2022 kernel where things have changed. We don't need to do > it all right now. > > People who want allow_unsafe_interrupts to work will simply not set > VFIO_CONTAINER=n at this time. Same with P2P, vfio-no-iommu and any > other gaps we haven't discovered. > > vfio-iommufd seems like overkill, I think your first suggestion to put > in vfio.ko was more practical. Convenient perhaps, but architecturally the wrong place for it. > My only doubt is if we should make it system wide for everything - and > I'm just a bit uncomfortable with that from a security POV. But maybe > I don't quite know exactly what the risks are. There's a paper about these sorts of attacks here[1]. As I noted earlier, a non-malicious DMA targeting an address that would trigger an interrupt is extremely unlikely, and the resulting vulnerability is largely more of a denial of service, IIRC. It would certainly be strongly dis-recommended in any scenario where the userspace drivers are untrusted, such as a cloud hosting provider, but there are certainly other scenarios where either the guest or userspace drivers are also under the control of the hosting provider and this is not such a concern. Thanks, Alex [1]https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf
Re: [syzbot] memory leak in drm_vma_node_allow
syzbot has found a reproducer for the following issue on: HEAD commit:f141df371335 Merge tag 'audit-pr-20221107' of git://git.ke.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=123bdcd188 kernel config: https://syzkaller.appspot.com/x/.config?x=f7ebe38e4b66a7b dashboard link: https://syzkaller.appspot.com/bug?extid=04639d98c75c52e41b8a compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=158ec0c188 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=120cc3e188 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/d056ae4a8f32/disk-f141df37.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/02fdf71b87b4/vmlinux-f141df37.xz kernel image: https://storage.googleapis.com/syzbot-assets/14078d70a64d/bzImage-f141df37.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+04639d98c75c52e41...@syzkaller.appspotmail.com executing program executing program executing program executing program BUG: memory leak unreferenced object 0x88810f65f0c0 (size 64): comm "syz-executor402", pid 3630, jiffies 4294948375 (age 13.410s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 94 b3 05 81 88 ff ff backtrace: [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [] kmalloc include/linux/slab.h:576 [inline] [] drm_vma_node_allow+0x32/0x120 drivers/gpu/drm/drm_vma_manager.c:274 [] drm_gem_handle_create_tail+0x10a/0x250 drivers/gpu/drm/drm_gem.c:377 [] drm_gem_shmem_create_with_handle drivers/gpu/drm/drm_gem_shmem_helper.c:432 [inline] [] drm_gem_shmem_dumb_create+0xb9/0x200 drivers/gpu/drm/drm_gem_shmem_helper.c:534 [] drm_mode_create_dumb+0x117/0x150 drivers/gpu/drm/drm_dumb_buffers.c:96 [] drm_ioctl_kernel+0x144/0x260 drivers/gpu/drm/drm_ioctl.c:788 [] drm_ioctl+0x2ec/0x4f0 drivers/gpu/drm/drm_ioctl.c:891 [] vfs_ioctl fs/ioctl.c:51 [inline] [] __do_sys_ioctl fs/ioctl.c:870 [inline] [] __se_sys_ioctl fs/ioctl.c:856 [inline] [] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[PATCH v2] drm/amd/display: only fill dirty rectangles when PSR is enabled
Currently, we are calling fill_dc_dirty_rects() even if PSR isn't supported by the relevant link in amdgpu_dm_commit_planes(), this is undesirable especially because when drm.debug is enabled we are printing messages in fill_dc_dirty_rects() that are only useful for debugging PSR (and confusing otherwise). So, we can instead limit the filling of dirty rectangles to only when PSR is enabled. Signed-off-by: Hamza Mahfooz --- v2: give a more concrete reason. --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) 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 66eb16fbe09f..956a6e494709 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -7697,9 +7697,10 @@ static void amdgpu_dm_commit_planes(struct drm_atomic_state *state, bundle->surface_updates[planes_count].plane_info = >plane_infos[planes_count]; - fill_dc_dirty_rects(plane, old_plane_state, new_plane_state, - new_crtc_state, - >flip_addrs[planes_count]); + if (acrtc_state->stream->link->psr_settings.psr_feature_enabled) + fill_dc_dirty_rects(plane, old_plane_state, + new_plane_state, new_crtc_state, + >flip_addrs[planes_count]); /* * Only allow immediate flips for fast updates that don't -- 2.38.1
Re: [PATCH 0/3] add guard padding around i915_vma
Hi Thomas, On Wed, Nov 09, 2022 at 07:03:03PM +0100, Thomas Hellström wrote: > Hi, Andi, > > This has been on the list before (three times I think) and at that > point it (the guard pages) was NAK'd by Daniel as yet another > complication, and a VT-d > scanout workaround was implemented and pushed using a different > approach, initially outlined by Daniel. > > Patch is 2ef6efa79fecd. Those suspend/resumes should now be fast. > > I then also discussed patch 1 separately with Dave Airlie and Daniel > and since both me and Dave liked it, Daniel OK'd it, but it never made > it upstream. > > Just a short heads up on the history. Thanks for letting me know, I missed this part of the history. Will check what happened in the previous mails and your improvement on the vt-d suspend/resume. Thanks, Andi
Re: [PATCH 0/3] add guard padding around i915_vma
Hi, Andi, This has been on the list before (three times I think) and at that point it (the guard pages) was NAK'd by Daniel as yet another complication, and a VT-d scanout workaround was implemented and pushed using a different approach, initially outlined by Daniel. Patch is 2ef6efa79fecd. Those suspend/resumes should now be fast. I then also discussed patch 1 separately with Dave Airlie and Daniel and since both me and Dave liked it, Daniel OK'd it, but it never made it upstream. Just a short heads up on the history. /Thomas On Wed, 2022-11-09 at 18:40 +0100, Andi Shyti wrote: > Hi, > > This series adds guards around vma's but setting a pages at the > beginning and at the end that work as padding. > > The first user of the vma guard are scanout objects which don't > need anymore to add scratch to all the unused ggtt's and speeding > up up considerably the boot and resume by several hundreds of > milliseconds up to over a full second in slower machines. > > Andi > > Chris Wilson (3): > drm/i915: Wrap all access to i915_vma.node.start|size > drm/i915: Introduce guard pages to i915_vma > drm/i915: Refine VT-d scanout workaround > > drivers/gpu/drm/i915/display/intel_fbdev.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_domain.c | 13 > .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 33 ++- > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 4 +- > .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- > .../i915/gem/selftests/i915_gem_client_blt.c | 23 > .../drm/i915/gem/selftests/i915_gem_context.c | 15 +++-- > .../drm/i915/gem/selftests/i915_gem_mman.c | 2 +- > .../drm/i915/gem/selftests/igt_gem_utils.c | 7 ++- > drivers/gpu/drm/i915/gt/gen7_renderclear.c | 2 +- > drivers/gpu/drm/i915/gt/intel_ggtt.c | 39 > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- > drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- > .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- > drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 8 +-- > drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++--- > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 ++--- > drivers/gpu/drm/i915/gt/selftest_lrc.c | 16 ++--- > .../drm/i915/gt/selftest_ring_submission.c | 2 +- > drivers/gpu/drm/i915/gt/selftest_rps.c | 12 ++-- > .../gpu/drm/i915/gt/selftest_workarounds.c | 8 +-- > drivers/gpu/drm/i915/i915_cmd_parser.c | 4 +- > drivers/gpu/drm/i915/i915_debugfs.c | 2 +- > drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +- > drivers/gpu/drm/i915/i915_perf.c | 2 +- > drivers/gpu/drm/i915/i915_vma.c | 59 + > -- > drivers/gpu/drm/i915/i915_vma.h | 52 +++- > drivers/gpu/drm/i915/i915_vma_resource.c | 4 +- > drivers/gpu/drm/i915/i915_vma_resource.h | 17 -- > drivers/gpu/drm/i915/i915_vma_types.h | 3 +- > drivers/gpu/drm/i915/selftests/i915_request.c | 20 +++ > drivers/gpu/drm/i915/selftests/igt_spinner.c | 8 +-- > 34 files changed, 246 insertions(+), 160 deletions(-) >
Re: [PATCH v6 20/20] drm/i915/vm_bind: Async vm_unbind support
On Mon, 7 Nov 2022 at 08:53, Niranjana Vishwanathapura
wrote:
>
> Asynchronously unbind the vma upon vm_unbind call.
> Fall back to synchronous unbind if backend doesn't support
> async unbind or if async unbind fails.
>
> No need for vm_unbind out fence support as i915 will internally
> handle all sequencing and user need not try to sequence any
> operation with the unbind completion.
>
> Signed-off-by: Niranjana Vishwanathapura
> ---
> drivers/gpu/drm/i915/i915_vma.c | 51 ++---
> drivers/gpu/drm/i915/i915_vma.h | 1 +
> 2 files changed, 48 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 08218e3a2f12..03c966fad87b 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -42,6 +42,8 @@
> #include "i915_vma.h"
> #include "i915_vma_resource.h"
>
> +static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
> +
> static inline void assert_vma_held_evict(const struct i915_vma *vma)
> {
> /*
> @@ -1711,7 +1713,7 @@ void i915_vma_reopen(struct i915_vma *vma)
> spin_unlock_irq(>closed_lock);
> }
>
> -static void force_unbind(struct i915_vma *vma)
> +static void force_unbind(struct i915_vma *vma, bool async)
> {
> if (!drm_mm_node_allocated(>node))
> return;
> @@ -1725,7 +1727,21 @@ static void force_unbind(struct i915_vma *vma)
> i915_vma_set_purged(vma);
>
> atomic_and(~I915_VMA_PIN_MASK, >flags);
> - WARN_ON(__i915_vma_unbind(vma));
> + if (async) {
> + struct dma_fence *fence;
> +
> + fence = __i915_vma_unbind_async(vma);
> + if (IS_ERR_OR_NULL(fence)) {
> + async = false;
> + } else {
> + dma_resv_add_fence(vma->obj->base.resv, fence,
> + DMA_RESV_USAGE_READ);
> + dma_fence_put(fence);
> + }
> + }
> +
> + if (!async)
> + WARN_ON(__i915_vma_unbind(vma));
> GEM_BUG_ON(drm_mm_node_allocated(>node));
> }
>
> @@ -1785,7 +1801,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
> {
> lockdep_assert_held(>vm->mutex);
>
> - force_unbind(vma);
> + force_unbind(vma, false);
> list_del_init(>vm_link);
> release_references(vma, vma->vm->gt, false);
> }
> @@ -1796,7 +1812,34 @@ void i915_vma_destroy(struct i915_vma *vma)
> bool vm_ddestroy;
>
> mutex_lock(>vm->mutex);
> - force_unbind(vma);
> + force_unbind(vma, false);
> + list_del_init(>vm_link);
> + vm_ddestroy = vma->vm_ddestroy;
> + vma->vm_ddestroy = false;
> +
> + /* vma->vm may be freed when releasing vma->vm->mutex. */
> + gt = vma->vm->gt;
> + mutex_unlock(>vm->mutex);
> + release_references(vma, gt, vm_ddestroy);
> +}
> +
> +void i915_vma_destroy_async(struct i915_vma *vma)
Where are we calling this? I can't find it.
> +{
> + bool vm_ddestroy, async = vma->obj->mm.rsgt;
> + struct intel_gt *gt;
> +
> + if (dma_resv_reserve_fences(vma->obj->base.resv, 1))
> + async = false;
> +
> + mutex_lock(>vm->mutex);
> + /*
> +* Ensure any asynchronous binding is complete while using
> +* async unbind as we will be releasing the vma here.
> +*/
> + if (async && i915_active_wait(>active))
> + async = false;
> +
> + force_unbind(vma, async);
> list_del_init(>vm_link);
> vm_ddestroy = vma->vm_ddestroy;
> vma->vm_ddestroy = false;
> diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
> index 737ef310d046..25f15965dab8 100644
> --- a/drivers/gpu/drm/i915/i915_vma.h
> +++ b/drivers/gpu/drm/i915/i915_vma.h
> @@ -272,6 +272,7 @@ void i915_vma_reopen(struct i915_vma *vma);
>
> void i915_vma_destroy_locked(struct i915_vma *vma);
> void i915_vma_destroy(struct i915_vma *vma);
> +void i915_vma_destroy_async(struct i915_vma *vma);
>
> #define assert_vma_held(vma) dma_resv_assert_held((vma)->obj->base.resv)
>
> --
> 2.21.0.rc0.32.g243a4c7e27
>
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Add GT oriented dmesg output
On 11/9/2022 03:05, Tvrtko Ursulin wrote:
On 08/11/2022 20:15, John Harrison wrote:
On 11/8/2022 01:01, Tvrtko Ursulin wrote:
On 07/11/2022 19:14, John Harrison wrote:
On 11/7/2022 08:17, Tvrtko Ursulin wrote:
On 07/11/2022 09:33, Tvrtko Ursulin wrote:
On 05/11/2022 01:03, Ceraolo Spurio, Daniele wrote:
On 11/4/2022 10:25 AM, john.c.harri...@intel.com wrote:
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it
can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message
wrappers. If
used instead of the drm_ equivalents, you get the same output
but with
a GT# prefix on it.
Signed-off-by: John Harrison
The only downside to this is that we'll print "GT0: " even on
single-GT devices. We could introduce a gt->info.name and print
that, so we could have it different per-platform, but IMO it's
not worth the effort.
Reviewed-by: Daniele Ceraolo Spurio
I think it might be worth getting an ack from one of the
maintainers to make sure we're all aligned on transitioning to
these new logging macro for gt code.
Idea is I think a very good one. First I would suggest
standardising to lowercase GT in logs because:
$ grep "GT%" i915/ -r
$ grep "gt%" i915/ -r
i915/gt/intel_gt_sysfs.c: gt->i915->sysfs_gt, "gt%d", gt->info.id))
i915/gt/intel_gt_sysfs.c: "failed to initialize
gt%d sysfs root\n", gt->info.id);
i915/gt/intel_gt_sysfs_pm.c: "failed to
create gt%u RC6 sysfs files (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u RC6p sysfs
files (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to
create gt%u RPS sysfs files (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to
create gt%u punit_req_freq_mhz sysfs (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u throttle
sysfs files (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u
media_perf_power_attrs sysfs (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to add
gt%u rps defaults (%pe)\n",
i915/i915_driver.c: drm_err(>i915->drm, "gt%d:
intel_pcode_init failed %d\n", id, ret);
i915/i915_hwmon.c: snprintf(ddat_gt->name, sizeof(ddat_gt->name),
"i915_gt%u", i);
Just because there are 11 existing instances of one form doesn't
mean that the 275 instances that are waiting to be converted should
be done incorrectly. GT is an acronym and should be capitalised.
Okay just make it consistent then.
Besides:
grep -r "GT " i915 | grep '"'
i915/vlv_suspend.c: drm_err(>drm, "timeout
disabling GT waking\n");
i915/vlv_suspend.c: "timeout waiting for GT
wells to go %s\n",
i915/vlv_suspend.c: drm_dbg(>drm, "GT register access
while GT waking disabled\n");
i915/i915_gpu_error.c: err_printf(m, "GT awake: %s\n",
str_yes_no(gt->awake));
i915/i915_debugfs.c: seq_printf(m, "GT awake? %s [%d], %llums\n",
i915/selftests/i915_gem_evict.c: pr_err("Failed to idle GT (on
%s)", engine->name);
i915/intel_uncore.c: "GT thread status wait timed
out\n");
i915/gt/uc/selftest_guc_multi_lrc.c: drm_err(>i915->drm, "GT
failed to idle: %d\n", ret);
i915/gt/uc/selftest_guc.c: drm_err(>i915->drm, "GT failed to
idle: %d\n", ret);
i915/gt/uc/selftest_guc.c: drm_err(>i915->drm, "GT failed to
idle: %d\n", ret);
i915/gt/intel_gt_mcr.c: * Some GT registers are designed as
"multicast" or "replicated" registers:
i915/gt/selftest_rps.c: pr_info("%s: rps counted %d
C0 cycles [%lldns] in %lldns [%d cycles], using GT clock frequency
of %uKHz\n",
i915/gt/selftest_hangcheck.c: pr_err("[%s] GT is
wedged!\n", engine->name);
i915/gt/selftest_hangcheck.c: pr_err("GT is wedged!\n");
i915/gt/intel_gt_clock_utils.c: "GT clock frequency
changed, was %uHz, now %uHz!\n",
i915/gt/selftest_engine_pm.c: pr_err("Unable to flush GT
pm before test\n");
i915/gt/selftest_engine_pm.c: pr_err("GT failed to idle\n");
i915/i915_sysfs.c: "failed to register GT
sysfs directory\n");
i915/intel_uncore.h: * of the basic non-engine GT registers
(referred to as "GSI" on
i915/intel_uncore.h: * newer platforms, or "GT block" on older
platforms)? If so, we'll
Then there is a question of naming. Are we okay with GT_XXX or,
do we want intel_gt_, or something completely different. I don't
have a strong opinion at the moment so I'll add some more folks
to Cc.
You mean GT_ERR("msg") vs intel_gt_err("msg")? Personally, I would
prefer just gt_err("msg") to keep it as close to the official drm_*
versions as possible. Print lines tend to be excessively long
already. Taking a 'gt' parameter instead of a '>i915->drm'
parameter does help with that but it seems like calling the wrapper
intel_gt_* is shooting ourselves in the foot on that one. And
GT_ERR vs gt_err just comes down to the fact that it is a macro
wrapper and
[PATCH] drm/amd/display: only fill dirty rectangles when PSR is enabled
Currently, we are calling fill_dc_dirty_rects() even if PSR isn't supported by the relevant link in amdgpu_dm_commit_planes(). So, we can instead limit the filling of dirty rectangles to only when PSR is enabled. Signed-off-by: Hamza Mahfooz --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) 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 66eb16fbe09f..956a6e494709 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -7697,9 +7697,10 @@ static void amdgpu_dm_commit_planes(struct drm_atomic_state *state, bundle->surface_updates[planes_count].plane_info = >plane_infos[planes_count]; - fill_dc_dirty_rects(plane, old_plane_state, new_plane_state, - new_crtc_state, - >flip_addrs[planes_count]); + if (acrtc_state->stream->link->psr_settings.psr_feature_enabled) + fill_dc_dirty_rects(plane, old_plane_state, + new_plane_state, new_crtc_state, + >flip_addrs[planes_count]); /* * Only allow immediate flips for fast updates that don't -- 2.38.1
[PATCH 0/3] add guard padding around i915_vma
Hi, This series adds guards around vma's but setting a pages at the beginning and at the end that work as padding. The first user of the vma guard are scanout objects which don't need anymore to add scratch to all the unused ggtt's and speeding up up considerably the boot and resume by several hundreds of milliseconds up to over a full second in slower machines. Andi Chris Wilson (3): drm/i915: Wrap all access to i915_vma.node.start|size drm/i915: Introduce guard pages to i915_vma drm/i915: Refine VT-d scanout workaround drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c| 13 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 33 ++- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- .../i915/gem/selftests/i915_gem_client_blt.c | 23 .../drm/i915/gem/selftests/i915_gem_context.c | 15 +++-- .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +- .../drm/i915/gem/selftests/igt_gem_utils.c| 7 ++- drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 39 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 8 +-- drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++--- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 ++--- drivers/gpu/drm/i915/gt/selftest_lrc.c| 16 ++--- .../drm/i915/gt/selftest_ring_submission.c| 2 +- drivers/gpu/drm/i915/gt/selftest_rps.c| 12 ++-- .../gpu/drm/i915/gt/selftest_workarounds.c| 8 +-- drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +- drivers/gpu/drm/i915/i915_perf.c | 2 +- drivers/gpu/drm/i915/i915_vma.c | 59 +-- drivers/gpu/drm/i915/i915_vma.h | 52 +++- drivers/gpu/drm/i915/i915_vma_resource.c | 4 +- drivers/gpu/drm/i915/i915_vma_resource.h | 17 -- drivers/gpu/drm/i915/i915_vma_types.h | 3 +- drivers/gpu/drm/i915/selftests/i915_request.c | 20 +++ drivers/gpu/drm/i915/selftests/igt_spinner.c | 8 +-- 34 files changed, 246 insertions(+), 160 deletions(-) -- 2.37.2
[PATCH 1/3] drm/i915: Wrap all access to i915_vma.node.start|size
From: Chris Wilson
We already wrap i915_vma.node.start for use with the GGTT, as there we
can perform additional sanity checks that the node belongs to the GGTT
and fits within the 32b registers. In the next couple of patches, we
will introduce guard pages around the objects _inside_ the drm_mm_node
allocation. That is we will offset the vma->pages so that the first page
is at drm_mm_node.start + vma->guard (not 0 as is currently the case).
All users must then not use i915_vma.node.start directly, but compute
the guard offset, thus all users are converted to use a
i915_vma_offset() wrapper.
The notable exceptions are the selftests that are testing exact
behaviour of i915_vma_pin/i915_vma_insert.
Signed-off-by: Chris Wilson
Signed-off-by: Tejas Upadhyay
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 33 ++--
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../i915/gem/selftests/i915_gem_client_blt.c | 23 +
.../drm/i915/gem/selftests/i915_gem_context.c | 15 +++---
.../drm/i915/gem/selftests/i915_gem_mman.c| 2 +-
.../drm/i915/gem/selftests/igt_gem_utils.c| 7 +--
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +-
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 8 +--
drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 +++---
drivers/gpu/drm/i915/gt/selftest_lrc.c| 16 +++---
.../drm/i915/gt/selftest_ring_submission.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_rps.c| 12 ++---
.../gpu/drm/i915/gt/selftest_workarounds.c| 8 +--
drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 25 -
drivers/gpu/drm/i915/i915_vma.h | 51 +--
drivers/gpu/drm/i915/i915_vma_resource.h | 10 ++--
drivers/gpu/drm/i915/selftests/i915_request.c | 20
drivers/gpu/drm/i915/selftests/igt_spinner.c | 8 +--
29 files changed, 180 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 5575d7abdc092..03ed4607a46d2 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -286,7 +286,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
/* Our framebuffer is the entirety of fbdev's system memory */
info->fix.smem_start =
- (unsigned long)(ggtt->gmadr.start + vma->node.start);
+ (unsigned long)(ggtt->gmadr.start +
i915_ggtt_offset(vma));
info->fix.smem_len = vma->size;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 1160723c9d2d9..5f09d33f1c836 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -378,22 +378,25 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2
*entry,
const struct i915_vma *vma,
unsigned int flags)
{
- if (vma->node.size < entry->pad_to_size)
+ const u64 start = i915_vma_offset(vma);
+ const u64 size = i915_vma_size(vma);
+
+ if (size < entry->pad_to_size)
return true;
- if (entry->alignment && !IS_ALIGNED(vma->node.start, entry->alignment))
+ if (entry->alignment && !IS_ALIGNED(start, entry->alignment))
return true;
if (flags & EXEC_OBJECT_PINNED &&
- vma->node.start != entry->offset)
+ start != entry->offset)
return true;
if (flags & __EXEC_OBJECT_NEEDS_BIAS &&
- vma->node.start < BATCH_OFFSET_BIAS)
+ start < BATCH_OFFSET_BIAS)
return true;
if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
- (vma->node.start + vma->node.size + 4095) >> 32)
+ (start + size + 4095) >> 32)
return true;
if (flags & __EXEC_OBJECT_NEEDS_MAP &&
@@ -439,7 +442,7 @@ eb_pin_vma(struct i915_execbuffer *eb,
int err;
if (vma->node.size)
- pin_flags = vma->node.start;
+ pin_flags = __i915_vma_offset(vma);
else
pin_flags = entry->offset & PIN_OFFSET_MASK;
@@ -662,8 +665,8 @@ static int
[PATCH 2/3] drm/i915: Introduce guard pages to i915_vma
From: Chris Wilson Introduce the concept of padding the i915_vma with guard pages before and after. The major consequence is that all ordinary uses of i915_vma must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size directly, as the drm_mm_node will include the guard pages that surround our object. The biggest connundrum is how exactly to mix requesting a fixed address with guard pages, particularly through the existing uABI. The user does not know about guard pages, so such must be transparent to the user, and so the execobj.offset must be that of the object itself excluding the guard. So a PIN_OFFSET_FIXED must then be exclusive of the guard pages. The caveat is that some placements will be impossible with guard pages, as wrap arounds need to be avoided, and the vma itself will require a larger node. We must not report EINVAL but ENOSPC as these are unavailable locations within the GTT rather than conflicting user requirements. In the next patch, we start using guard pages for scanout objects. While these are limited to GGTT vma, on a few platforms these vma (or at least an alias of the vma) is shared with userspace, so we may leak the existence of such guards if we are not careful to ensure that the execobj.offset is transparent and excludes the guards. (On such platforms like ivb, without full-ppgtt, userspace has to use relocations so the presence of more untouchable regions within its GTT such be of no further issue.) Signed-off-by: Chris Wilson Signed-off-by: Tejas Upadhyay Signed-off-by: Tvrtko Ursulin Signed-off-by: Andi Shyti --- drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 drivers/gpu/drm/i915/i915_gem_gtt.h | 3 ++- drivers/gpu/drm/i915/i915_vma.c | 27 ++-- drivers/gpu/drm/i915/i915_vma.h | 5 +++-- drivers/gpu/drm/i915/i915_vma_resource.c | 4 ++-- drivers/gpu/drm/i915/i915_vma_resource.h | 7 +- drivers/gpu/drm/i915/i915_vma_types.h| 3 ++- 7 files changed, 46 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c index 2518cebbf931c..0dd81b18716c3 100644 --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c @@ -287,8 +287,11 @@ static void gen8_ggtt_insert_entries(struct i915_address_space *vm, */ gte = (gen8_pte_t __iomem *)ggtt->gsm; - gte += vma_res->start / I915_GTT_PAGE_SIZE; - end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE; + gte += (vma_res->start - vma_res->guard) / I915_GTT_PAGE_SIZE; + end = gte + vma_res->guard / I915_GTT_PAGE_SIZE; + while (gte < end) + gen8_set_pte(gte++, vm->scratch[0]->encode); + end += (vma_res->node_size + vma_res->guard) / I915_GTT_PAGE_SIZE; for_each_sgt_daddr(addr, iter, vma_res->bi.pages) gen8_set_pte(gte++, pte_encode | addr); @@ -338,9 +341,12 @@ static void gen6_ggtt_insert_entries(struct i915_address_space *vm, dma_addr_t addr; gte = (gen6_pte_t __iomem *)ggtt->gsm; - gte += vma_res->start / I915_GTT_PAGE_SIZE; - end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE; + gte += (vma_res->start - vma_res->guard) / I915_GTT_PAGE_SIZE; + end = gte + vma_res->guard / I915_GTT_PAGE_SIZE; + while (gte < end) + iowrite32(vm->scratch[0]->encode, gte++); + end += (vma_res->node_size + vma_res->guard) / I915_GTT_PAGE_SIZE; for_each_sgt_daddr(addr, iter, vma_res->bi.pages) iowrite32(vm->pte_encode(addr, level, flags), gte++); GEM_BUG_ON(gte > end); diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h index 8c2f57eb5ddaa..2434197830523 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.h +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h @@ -44,7 +44,8 @@ int i915_gem_gtt_insert(struct i915_address_space *vm, #define PIN_HIGH BIT_ULL(5) #define PIN_OFFSET_BIASBIT_ULL(6) #define PIN_OFFSET_FIXED BIT_ULL(7) -#define PIN_VALIDATE BIT_ULL(8) /* validate placement only, no need to call unpin() */ +#define PIN_OFFSET_GUARD BIT_ULL(8) +#define PIN_VALIDATE BIT_ULL(9) /* validate placement only, no need to call unpin() */ #define PIN_GLOBAL BIT_ULL(10) /* I915_VMA_GLOBAL_BIND */ #define PIN_USER BIT_ULL(11) /* I915_VMA_LOCAL_BIND */ diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index 2be43885a2b5d..ff24a654565f6 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -417,7 +417,7 @@ i915_vma_resource_init_from_vma(struct i915_vma_resource *vma_res, obj->mm.rsgt, i915_gem_object_is_readonly(obj), i915_gem_object_is_lmem(obj), obj->mm.region, vma->ops, vma->private, __i915_vma_offset(vma), -
[PATCH 3/3] drm/i915: Refine VT-d scanout workaround
From: Chris Wilson
VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 168 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Currently, we fill the entire GGTT with scratch pages when using VT-d to
always ensure there are valid entries around every vma, including
scanout. However, writing every PTE is slow as on recent devices we
perform 8MiB of uncached writes, incurring an extra 100ms during resume.
If instead we focus on only putting guard pages around scanout, we can
avoid touching the whole GGTT. To avoid having to introduce extra nodes
around each scanout vma, we adjust the scanout drm_mm_node to be smaller
than the allocated space, and fixup the extra PTE during dma binding.
Signed-off-by: Chris Wilson
Signed-off-by: Tejas Upadhyay
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 13 +++
drivers/gpu/drm/i915/gt/intel_ggtt.c | 25 +-
drivers/gpu/drm/i915/i915_vma.c| 9
3 files changed, 23 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index d44a152ce6800..882b91519f92b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -17,6 +17,8 @@
#include "i915_gem_object.h"
#include "i915_vma.h"
+#define VTD_GUARD (168u * I915_GTT_PAGE_SIZE) /* 168 or tile-row PTE padding */
+
static bool gpu_write_needs_clflush(struct drm_i915_gem_object *obj)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
@@ -424,6 +426,17 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
if (ret)
return ERR_PTR(ret);
+ /* VT-d may overfetch before/after the vma, so pad with scratch */
+ if (intel_scanout_needs_vtd_wa(i915)) {
+ unsigned int guard = VTD_GUARD;
+
+ if (i915_gem_object_is_tiled(obj))
+ guard = max(guard,
+ i915_gem_object_get_tile_row_size(obj));
+
+ flags |= PIN_OFFSET_GUARD | guard;
+ }
+
/*
* As the user may map the buffer once pinned in the display plane
* (e.g. libkms for the bootup splash), we have to ensure that we
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 0dd81b18716c3..b0acb645a6de6 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -367,27 +367,6 @@ static void nop_clear_range(struct i915_address_space *vm,
{
}
-static void gen8_ggtt_clear_range(struct i915_address_space *vm,
- u64 start, u64 length)
-{
- struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
- unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
- unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
- const gen8_pte_t scratch_pte = vm->scratch[0]->encode;
- gen8_pte_t __iomem *gtt_base =
- (gen8_pte_t __iomem *)ggtt->gsm + first_entry;
- const int max_entries = ggtt_total_entries(ggtt) - first_entry;
- int i;
-
- if (WARN(num_entries > max_entries,
-"First entry = %d; Num entries = %d (max=%d)\n",
-first_entry, num_entries, max_entries))
- num_entries = max_entries;
-
- for (i = 0; i < num_entries; i++)
- gen8_set_pte(_base[i], scratch_pte);
-}
-
static void bxt_vtd_ggtt_wa(struct i915_address_space *vm)
{
/*
@@ -959,8 +938,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.cleanup = gen6_gmch_remove;
ggtt->vm.insert_page = gen8_ggtt_insert_page;
ggtt->vm.clear_range = nop_clear_range;
- if (intel_scanout_needs_vtd_wa(i915))
- ggtt->vm.clear_range = gen8_ggtt_clear_range;
ggtt->vm.insert_entries = gen8_ggtt_insert_entries;
@@ -1121,7 +1098,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.alloc_scratch_dma = alloc_pt_dma;
ggtt->vm.clear_range = nop_clear_range;
- if (!HAS_FULL_PPGTT(i915) || intel_scanout_needs_vtd_wa(i915))
+ if (!HAS_FULL_PPGTT(i915))
ggtt->vm.clear_range = gen6_ggtt_clear_range;
ggtt->vm.insert_page = gen6_ggtt_insert_page;
ggtt->vm.insert_entries = gen6_ggtt_insert_entries;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index ff24a654565f6..973abe56cbaa0 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -675,6 +675,10 @@ bool i915_vma_misplaced(const struct i915_vma *vma,
i915_vma_offset(vma) != (flags & PIN_OFFSET_MASK))
return true;
+ if (flags & PIN_OFFSET_GUARD &&
+
Re: [PATCH] drm/tidss: Set max DMA segment size
On 8/22/22 7:16 PM, Andrew Davis wrote: We have no segment size limitations. Set to unlimited. Signed-off-by: Andrew Davis --- Ping, still valid. Andrew drivers/gpu/drm/tidss/tidss_dispc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c b/drivers/gpu/drm/tidss/tidss_dispc.c index dd3c6a606ae2..624545e4636c 100644 --- a/drivers/gpu/drm/tidss/tidss_dispc.c +++ b/drivers/gpu/drm/tidss/tidss_dispc.c @@ -2685,6 +2685,7 @@ int dispc_init(struct tidss_device *tidss) if (r) dev_warn(dev, "cannot set DMA masks to 48-bit\n"); } + dma_set_max_seg_size(dev, UINT_MAX); dispc = devm_kzalloc(dev, sizeof(*dispc), GFP_KERNEL); if (!dispc)
Re: [PATCH v2 10/11] vfio: Make vfio_container optionally compiled
On Tue, 8 Nov 2022 20:54:58 -0400 Jason Gunthorpe wrote: > On Tue, Nov 08, 2022 at 03:28:31PM -0700, Alex Williamson wrote: > > > Perhaps this should have been obvious, but I'm realizing that > > vfio-noiommu mode is completely missing without VFIO_CONTAINER, which > > seems a barrier to deprecating VFIO_CONTAINER and perhaps makes it a > > Yes, it is the same as the allow_unsafe_interrupts - it is something > that currently goes missing if you turn off VFIO_CONTAINER. > > This seems straightforward enough to resolve in a followup, we mostly > just need someone with an existing no-iommu application to test > compatability against. Keeping it working with the device cdev will > also be a bit interesting. If you have or know about some application > I can try to make a patch. DPDK supports no-iommu mode. > > question whether IOMMUFD should really be taking over /dev/vfio/vfio. > > No-iommu mode has users. > > I view VFIO_CONTAINER=n as a process. An aspiration we can work > toward. > > At this point there are few places that might want to use it. Android > perhaps, for example. It is also useful for testing. One of the main > values is you can switch the options and feed the kernel into an > existing test environment and see what happens. This is how we are > able to quickly get s390 mdev testing, for instance. > > We are not going to get to a widely useful VFIO_CONTAINER=n if we > don't have a target that people can test against and evaluate what > compatability gaps may exist. > > So, everytime we find something like this - let's think about how can > we make iommufd compatibility handle it and not jump straight to > giving up :) > > I'm kind of thinking v6.4 might be a reasonable kernel target when we > might have closed off enough things. I agree that it's very useful for testing, I'm certainly not suggesting to give up, but I'm not sure where no-iommu lives when iommufd owns /dev/vfio/vfio. Given the unsafe interrupts discussion, it doesn't seem like the type of thing that would be a priority for iommufd. We're on a path where vfio accepts an iommufd as a container, and ultimately iommufd becomes the container provider, supplanting the IOMMU driver registration aspect of vfio. I absolutely want type1 and spapr backends to get replaced by iommufd, but reluctance to support aspects of vfio "legacy" behavior doesn't give me warm fuzzies about a wholesale hand-off of the container to a different subsystem, for example vs an iommufd shim spoofing type1 support. Unfortunately we no longer have a CONFIG_EXPERIMENTAL option to hide behind for disabling VFIO_CONTAINER, so regardless of our intentions that a transition is some time off, it may become an issue sooner than we expect. Thanks, Alex
Re: [PATCH 0/3] add guard patting around i915_vma
Please ignore, this series is rebased on the wrong branch. Andi On Wed, Nov 09, 2022 at 05:49:10PM +0100, Andi Shyti wrote: > Hi, > > This patch series adds a padding around i915_vma's reducing > consequently the need to add scratch to the unused GGTT. > > This speeds up considerably the boot and resume by several > hundreds of milliseconds up to over a full second in slower > machines. > > Andi > > Chris Wilson (3): > drm/i915: Wrap all access to i915_vma.node.start|size > drm/i915: Introduce guard pages to i915_vma > drm/i915: Refine VT-d scanout workaround > > drivers/gpu/drm/i915/display/intel_dpt.c | 4 +- > drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +- > drivers/gpu/drm/i915/gem/i915_gem_domain.c| 13 + > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 37 ++-- > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +- > .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- > .../i915/gem/selftests/i915_gem_client_blt.c | 15 ++--- > .../drm/i915/gem/selftests/i915_gem_context.c | 19 -- > .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +- > .../drm/i915/gem/selftests/igt_gem_utils.c| 7 ++- > drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +- > drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +- > drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 8 +-- > drivers/gpu/drm/i915/gt/intel_ggtt.c | 39 - > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- > drivers/gpu/drm/i915/gt/intel_ppgtt.c | 7 ++- > drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- > .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- > drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 12 ++-- > drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++--- > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 17 +++--- > drivers/gpu/drm/i915/gt/selftest_lrc.c| 16 ++--- > .../drm/i915/gt/selftest_ring_submission.c| 2 +- > drivers/gpu/drm/i915/gt/selftest_rps.c| 12 ++-- > .../gpu/drm/i915/gt/selftest_workarounds.c| 8 +-- > drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +- > drivers/gpu/drm/i915/i915_debugfs.c | 3 +- > drivers/gpu/drm/i915/i915_gem_gtt.h | 1 + > drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- > drivers/gpu/drm/i915/i915_perf.c | 2 +- > drivers/gpu/drm/i915/i915_vma.c | 58 ++- > drivers/gpu/drm/i915/i915_vma.h | 24 +++- > drivers/gpu/drm/i915/i915_vma_types.h | 3 +- > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 12 +++- > drivers/gpu/drm/i915/selftests/i915_request.c | 20 +++ > drivers/gpu/drm/i915/selftests/igt_spinner.c | 11 ++-- > 38 files changed, 238 insertions(+), 163 deletions(-) > > -- > 2.37.2
Re: [PATCH v3] drm/nouveau: Add support to control backlight using bl_power for nva3.
On Fri, Nov 4, 2022 at 11:04 PM Antonio Gomes wrote:
>
> From: antoniospg
>
> Summary:
>
> * Add support to turn on/off backlight when changing values in bl_power
> file. This is achieved by using function backlight_get_brightness()
> in nva3_set_intensity to get current brightness.
>
> Test plan:
>
> * Turn off:
> echo 1 > /sys/class/backlight/nv_backlight/bl_power
>
> * Turn on:
> echo 0 > /sys/class/backlight/nv_backlight/bl_power
>
> Signed-off-by: antoniospg
> ---
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index a2141d3d9b1d..5c82f5189b79 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -263,7 +263,11 @@ nva3_set_intensity(struct backlight_device *bd)
> u32 div, val;
>
> div = nvif_rd32(device, NV50_PDISP_SOR_PWM_DIV(or));
> - val = (bd->props.brightness * div) / 100;
> +
> + val = backlight_get_brightness(bd);
> + if (val)
> + val = (val * div) / 100;
> +
> if (div) {
> nvif_wr32(device, NV50_PDISP_SOR_PWM_CTL(or),
> val |
> --
> 2.25.1
>
Reviewed-by: Karol Herbst
btw, i'll fix up the name with the one from the Email From field, so
you won't have to send it out again.
Re: [PATCH v2 00/11] Connect VFIO to IOMMUFD
On Tue, Nov 08, 2022 at 11:18:03PM +0800, Yi Liu wrote: > On 2022/11/8 17:19, Nicolin Chen wrote: > > On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe wrote: > > > > > This is on github: > > > https://github.com/jgunthorpe/linux/commits/vfio_iommufd > > [...] > > > v2: > > > - Rebase to v6.1-rc3, v4 iommufd series > > > - Fixup comments and commit messages from list remarks > > > - Fix leaking of the iommufd for mdevs > > > - New patch to fix vfio modaliases when vfio container is disabled > > > - Add a dmesg once when the iommufd provided /dev/vfio/vfio is opened > > > to signal that iommufd is providing this > > > > I've redone my previous sanity tests. Except those reported bugs, > > things look fine. Once we fix those issues, GVT and other modules > > can run some more stressful tests, I think. > > our side is also starting test (gvt, nic passthrough) this version. need to > wait a while for the result. I've updated the branches with the two functional fixes discussed on the list plus all the doc updates. Thanks, Jason
[PATCH 3/3] drm/i915: Refine VT-d scanout workaround
From: Chris Wilson
VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 168 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Currently, we fill the entire GGTT with scratch pages when using VT-d to
always ensure there are valid entries around every vma, including
scanout. However, writing every PTE is slow as on recent devices we
perform 8MiB of uncached writes, incurring an extra 100ms during resume.
If instead we focus on only putting guard pages around scanout, we can
avoid touching the whole GGTT. To avoid having to introduce extra nodes
around each scanout vma, we adjust the scanout drm_mm_node to be smaller
than the allocated space, and fixup the extra PTE during dma binding.
Signed-off-by: Chris Wilson
Signed-off-by: Tejas Upadhyay
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 13 +++
drivers/gpu/drm/i915/gt/intel_ggtt.c | 25 +-
drivers/gpu/drm/i915/i915_vma.c| 9
3 files changed, 23 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index b684a62bf3b07..fcc77f120675f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -16,6 +16,8 @@
#include "i915_gem_lmem.h"
#include "i915_gem_mman.h"
+#define VTD_GUARD (168u * I915_GTT_PAGE_SIZE) /* 168 or tile-row PTE padding */
+
static bool gpu_write_needs_clflush(struct drm_i915_gem_object *obj)
{
return !(obj->cache_level == I915_CACHE_NONE ||
@@ -401,6 +403,17 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
if (ret)
return ERR_PTR(ret);
+ /* VT-d may overfetch before/after the vma, so pad with scratch */
+ if (intel_scanout_needs_vtd_wa(i915)) {
+ unsigned int guard = VTD_GUARD;
+
+ if (i915_gem_object_is_tiled(obj))
+ guard = max(guard,
+ i915_gem_object_get_tile_row_size(obj));
+
+ flags |= PIN_OFFSET_GUARD | guard;
+ }
+
/*
* As the user may map the buffer once pinned in the display plane
* (e.g. libkms for the bootup splash), we have to ensure that we
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 717135f5bf5a6..531aca161295c 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -347,27 +347,6 @@ static void nop_clear_range(struct i915_address_space *vm,
{
}
-static void gen8_ggtt_clear_range(struct i915_address_space *vm,
- u64 start, u64 length)
-{
- struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
- unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
- unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
- const gen8_pte_t scratch_pte = vm->scratch[0]->encode;
- gen8_pte_t __iomem *gtt_base =
- (gen8_pte_t __iomem *)ggtt->gsm + first_entry;
- const int max_entries = ggtt_total_entries(ggtt) - first_entry;
- int i;
-
- if (WARN(num_entries > max_entries,
-"First entry = %d; Num entries = %d (max=%d)\n",
-first_entry, num_entries, max_entries))
- num_entries = max_entries;
-
- for (i = 0; i < num_entries; i++)
- gen8_set_pte(_base[i], scratch_pte);
-}
-
static void bxt_vtd_ggtt_wa(struct i915_address_space *vm)
{
/*
@@ -953,8 +932,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.cleanup = gen6_gmch_remove;
ggtt->vm.insert_page = gen8_ggtt_insert_page;
ggtt->vm.clear_range = nop_clear_range;
- if (intel_scanout_needs_vtd_wa(i915))
- ggtt->vm.clear_range = gen8_ggtt_clear_range;
ggtt->vm.insert_entries = gen8_ggtt_insert_entries;
@@ -1102,7 +1079,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.alloc_pt_dma = alloc_pt_dma;
ggtt->vm.clear_range = nop_clear_range;
- if (!HAS_FULL_PPGTT(i915) || intel_scanout_needs_vtd_wa(i915))
+ if (!HAS_FULL_PPGTT(i915))
ggtt->vm.clear_range = gen6_ggtt_clear_range;
ggtt->vm.insert_page = gen6_ggtt_insert_page;
ggtt->vm.insert_entries = gen6_ggtt_insert_entries;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index bf0f8d7e13405..f76c2d2fd3e75 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -562,6 +562,10 @@ bool i915_vma_misplaced(const struct i915_vma *vma,
i915_vma_offset(vma) != (flags & PIN_OFFSET_MASK))
return true;
+ if (flags & PIN_OFFSET_GUARD &&
+ vma->guard <
[PATCH 2/3] drm/i915: Introduce guard pages to i915_vma
From: Chris Wilson
Introduce the concept of padding the i915_vma with guard pages before
and after. The major consequence is that all ordinary uses of i915_vma
must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size
directly, as the drm_mm_node will include the guard pages that surround
our object.
The biggest connundrum is how exactly to mix requesting a fixed address
with guard pages, particularly through the existing uABI. The user does
not know about guard pages, so such must be transparent to the user, and
so the execobj.offset must be that of the object itself excluding the
guard. So a PIN_OFFSET_FIXED must then be exclusive of the guard pages.
The caveat is that some placements will be impossible with guard pages,
as wrap arounds need to be avoided, and the vma itself will require a
larger node. We must not report EINVAL but ENOSPC as these are unavailable
locations within the GTT rather than conflicting user requirements.
In the next patch, we start using guard pages for scanout objects. While
these are limited to GGTT vma, on a few platforms these vma (or at least
an alias of the vma) is shared with userspace, so we may leak the
existence of such guards if we are not careful to ensure that the
execobj.offset is transparent and excludes the guards. (On such platforms
like ivb, without full-ppgtt, userspace has to use relocations so the
presence of more untouchable regions within its GTT such be of no further
issue.)
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 12 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
drivers/gpu/drm/i915/i915_vma.c | 28 ++-
drivers/gpu/drm/i915/i915_vma.h | 5 +++--
drivers/gpu/drm/i915/i915_vma_types.h | 3 ++-
5 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 6549b8e3adbfc..717135f5bf5a6 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -266,8 +266,12 @@ static void gen8_ggtt_insert_entries(struct
i915_address_space *vm,
gte = (gen8_pte_t __iomem *)ggtt->gsm;
gte += vma->node.start / I915_GTT_PAGE_SIZE;
- end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
+ end = gte + vma->guard / I915_GTT_PAGE_SIZE;
+ while (gte < end)
+ gen8_set_pte(gte++, vm->scratch[0]->encode);
+
+ end += (vma->node.size - vma->guard) / I915_GTT_PAGE_SIZE;
for_each_sgt_daddr(addr, iter, vma->pages)
gen8_set_pte(gte++, pte_encode | addr);
GEM_BUG_ON(gte > end);
@@ -317,8 +321,12 @@ static void gen6_ggtt_insert_entries(struct
i915_address_space *vm,
gte = (gen6_pte_t __iomem *)ggtt->gsm;
gte += vma->node.start / I915_GTT_PAGE_SIZE;
- end = gte + vma->node.size / I915_GTT_PAGE_SIZE;
+ end = gte + vma->guard / I915_GTT_PAGE_SIZE;
+ while (gte < end)
+ gen8_set_pte(gte++, vm->scratch[0]->encode);
+
+ end += (vma->node.size - vma->guard) / I915_GTT_PAGE_SIZE;
for_each_sgt_daddr(addr, iter, vma->pages)
iowrite32(vm->pte_encode(addr, level, flags), gte++);
GEM_BUG_ON(gte > end);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index c9b0ee5e1d237..f3ae9afdee158 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -41,6 +41,7 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
#define PIN_HIGH BIT_ULL(5)
#define PIN_OFFSET_BIASBIT_ULL(6)
#define PIN_OFFSET_FIXED BIT_ULL(7)
+#define PIN_OFFSET_GUARD BIT_ULL(8)
#define PIN_GLOBAL BIT_ULL(10) /* I915_VMA_GLOBAL_BIND */
#define PIN_USER BIT_ULL(11) /* I915_VMA_LOCAL_BIND */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 4b4a6dcdc676b..bf0f8d7e13405 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -633,7 +633,7 @@ bool i915_gem_valid_gtt_space(struct i915_vma *vma,
unsigned long color)
static int
i915_vma_insert(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
{
- unsigned long color;
+ unsigned long color, guard;
u64 start, end;
int ret;
@@ -641,7 +641,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
GEM_BUG_ON(drm_mm_node_allocated(>node));
size = max(size, vma->size);
- alignment = max(alignment, vma->display_alignment);
+ alignment = max_t(typeof(alignment), alignment, vma->display_alignment);
if (flags & PIN_MAPPABLE) {
size = max_t(typeof(size), size, vma->fence_size);
alignment = max_t(typeof(alignment),
@@ -652,6 +652,9 @@ i915_vma_insert(struct i915_vma *vma,
[PATCH 1/3] drm/i915: Wrap all access to i915_vma.node.start|size
From: Chris Wilson
We already wrap i915_vma.node.start for use with the GGTT, as there we
can perform additional sanity checks that the node belongs to the GGTT
and fits within the 32b registers. In the next couple of patches, we
will introduce guard pages around the objects _inside_ the drm_mm_node
allocation. That is we will offset the vma->pages so that the first page
is at drm_mm_node.start + vma->guard (not 0 as is currently the case).
All users must then not use i915_vma.node.start directly, but compute
the guard offset, thus all users are converted to use a
i915_vma_offset() wrapper.
The notable exceptions are the selftests that are testing exact
behaviour of i915_vma_pin/i915_vma_insert.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_dpt.c | 4 +-
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 37 ++-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../i915/gem/selftests/i915_gem_client_blt.c | 15
.../drm/i915/gem/selftests/i915_gem_context.c | 19 +++---
.../drm/i915/gem/selftests/i915_gem_mman.c| 2 +-
.../drm/i915/gem/selftests/igt_gem_utils.c| 7 ++--
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 8 ++--
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +-
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 7 +++-
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 12 +++---
drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 -
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 17 +
drivers/gpu/drm/i915/gt/selftest_lrc.c| 16
.../drm/i915/gt/selftest_ring_submission.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_rps.c| 12 +++---
.../gpu/drm/i915/gt/selftest_workarounds.c| 8 ++--
drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +-
drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 21 ++-
drivers/gpu/drm/i915/i915_vma.h | 23 ++--
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 12 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 20 +-
drivers/gpu/drm/i915/selftests/igt_spinner.c | 11 --
35 files changed, 178 insertions(+), 131 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index de62bd77b15e6..eb32d7b0d25e9 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -64,7 +64,7 @@ static void dpt_insert_entries(struct i915_address_space *vm,
* not to allow the user to override access to a read only page.
*/
- i = vma->node.start / I915_GTT_PAGE_SIZE;
+ i = i915_vma_offset(vma) / I915_GTT_PAGE_SIZE;
for_each_sgt_daddr(addr, sgt_iter, vma->pages)
gen8_set_pte([i++], pte_encode | addr);
}
@@ -104,7 +104,7 @@ static void dpt_bind_vma(struct i915_address_space *vm,
static void dpt_unbind_vma(struct i915_address_space *vm, struct i915_vma *vma)
{
- vm->clear_range(vm, vma->node.start, vma->size);
+ vm->clear_range(vm, i915_vma_offset(vma), vma->size);
}
static void dpt_cleanup(struct i915_address_space *vm)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index adc3a81be9f72..dcd57421749ea 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -261,7 +261,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
/* Our framebuffer is the entirety of fbdev's system memory */
info->fix.smem_start =
- (unsigned long)(ggtt->gmadr.start + vma->node.start);
+ (unsigned long)(ggtt->gmadr.start +
i915_ggtt_offset(vma));
info->fix.smem_len = vma->node.size;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 78ac4ec9f285c..075d4afdd8a85 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -363,22 +363,23 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2
*entry,
const struct i915_vma *vma,
unsigned int flags)
{
- if (vma->node.size <
[PATCH 0/3] add guard patting around i915_vma
Hi, This patch series adds a padding around i915_vma's reducing consequently the need to add scratch to the unused GGTT. This speeds up considerably the boot and resume by several hundreds of milliseconds up to over a full second in slower machines. Andi Chris Wilson (3): drm/i915: Wrap all access to i915_vma.node.start|size drm/i915: Introduce guard pages to i915_vma drm/i915: Refine VT-d scanout workaround drivers/gpu/drm/i915/display/intel_dpt.c | 4 +- drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c| 13 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 37 ++-- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- .../i915/gem/selftests/i915_gem_client_blt.c | 15 ++--- .../drm/i915/gem/selftests/i915_gem_context.c | 19 -- .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +- .../drm/i915/gem/selftests/igt_gem_utils.c| 7 ++- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 8 +-- drivers/gpu/drm/i915/gt/intel_ggtt.c | 39 - drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 7 ++- drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 12 ++-- drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++--- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 17 +++--- drivers/gpu/drm/i915/gt/selftest_lrc.c| 16 ++--- .../drm/i915/gt/selftest_ring_submission.c| 2 +- drivers/gpu/drm/i915/gt/selftest_rps.c| 12 ++-- .../gpu/drm/i915/gt/selftest_workarounds.c| 8 +-- drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +- drivers/gpu/drm/i915/i915_debugfs.c | 3 +- drivers/gpu/drm/i915/i915_gem_gtt.h | 1 + drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- drivers/gpu/drm/i915/i915_perf.c | 2 +- drivers/gpu/drm/i915/i915_vma.c | 58 ++- drivers/gpu/drm/i915/i915_vma.h | 24 +++- drivers/gpu/drm/i915/i915_vma_types.h | 3 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 12 +++- drivers/gpu/drm/i915/selftests/i915_request.c | 20 +++ drivers/gpu/drm/i915/selftests/igt_spinner.c | 11 ++-- 38 files changed, 238 insertions(+), 163 deletions(-) -- 2.37.2
[PULL] drm-misc-fixes
Hey Daniel & Dave, Another small pull request. Various small assorted fixes. drm-misc-fixes-2022-11-09: drm-misc-fixes for v6.1-rc5: - HDMI fixes to vc4. - Make panfrost's uapi header compile with C++. - Add rotation quirks for 2 panels. - Fix s/r in amdgpu_vram_mgr_new - Handle 1 gb boundary correctly in panfrost mmu code. The following changes since commit fc007fb815ab5395c3962c09b79a1630b0fbed9c: drm/imx: imx-tve: Fix return type of imx_tve_connector_mode_valid (2022-11-01 14:36:55 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-11-09 for you to fetch changes up to f352262f727215553879705bacbcb208979f3eff: drm/panfrost: Split io-pgtable requests properly (2022-11-09 14:17:39 +) drm-misc-fixes for v6.1-rc5: - HDMI fixes to vc4. - Make panfrost's uapi header compile with C++. - Add rotation quirks for 2 panels. - Fix s/r in amdgpu_vram_mgr_new - Handle 1 gb boundary correctly in panfrost mmu code. Hans de Goede (2): drm: panel-orientation-quirks: Add quirk for Nanote UMPC-01 drm: panel-orientation-quirks: Add quirk for Acer Switch V 10 (SW5-017) Ma Jun (1): drm/amdgpu: Fix the lpfn checking condition in drm buddy Robin Murphy (1): drm/panfrost: Split io-pgtable requests properly Steven Price (1): drm/panfrost: Remove type name from internal struct again Yuan Can (1): drm/vc4: Fix missing platform_unregister_drivers() call in vc4_drm_register() max...@cerno.tech (3): drm/vc4: hdmi: Take our lock to reset the link drm/vc4: hdmi: Fix outdated function name in comment drm/vc4: hdmi: Fix HSM clock too low on Pi4 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +- drivers/gpu/drm/drm_panel_orientation_quirks.c | 12 +++ drivers/gpu/drm/panfrost/panfrost_mmu.c | 11 +- drivers/gpu/drm/vc4/vc4_drv.c | 7 +++- drivers/gpu/drm/vc4/vc4_hdmi.c | 47 -- drivers/gpu/drm/vc4/vc4_hdmi.h | 1 + include/uapi/drm/panfrost_drm.h | 2 +- 7 files changed, 67 insertions(+), 15 deletions(-)
Re: [PATCH] staging: fbtft: Use ARRAY_SIZE() to get argument count
On Wed, Nov 09, 2022 at 08:30:52PM +0530, Deepak R Varma wrote:
> On Fri, Nov 04, 2022 at 08:12:11PM +0530, Deepak R Varma wrote:
> > On Fri, Nov 04, 2022 at 05:31:24PM +0530, Deepak R Varma wrote:
> > > On Mon, Oct 31, 2022 at 01:05:32PM +0100, Julia Lawall wrote:
> > > >
> > > >
> > > > I took a look, but it's pretty complex. You could take the code and
> > > > reorganize it so that it is more readable, and then take the definition
> > > > of
> > > > the ARRAY_SIZE macro, to better see what is going on.
> > > >
> > > > julia
> > > >
> > >
> > > Hello Greg, Julia,
> > > I was able to successfully build the fbtft object file for arm
> > > architecture as
> > > well. I used gcc 6.5.0 and 9.5.0 tool chains. It was successful using
> > > both. I
> > > have attached the build log from my machine for your reference.
> > >
> > > I am also looking at the .i file and rearrange the expanded macro to
> > > understand
> > > it. However, since it is built successfully, I am not sure if that is
> > > truly the
> > > problem area.
> > >
> > > Should I resend the patch and check if it still errors the kernel build
> > > bot?
> > > Anything else I can try?
> >
> > Looks like the change I proposed is causing nesting inside the write_reg
> > function due to additional set of { & } brackets for the __VA_ARGS__ symbol.
> >
> > Am I understanding it right?
>
> Hello Julia, Greg,
> I am unable to reproduce this build failure on my local machine. I tried the
> X86
> and arm based build. I am unable to troubleshoot this further. Do you have any
> other suggestions? If not, I will drop this patch from my watch list.
Please just drop it, it is not a correct change to make.
thanks,
greg k-h
Re: [PATCH v3] drm/vmwgfx: Fix race issue calling pin_user_pages
From: Martin Krastev
Looks great!
Reviewed-by: Martin Krastev
Regards,
Martin
On 9.11.22 г. 17:37 ч., Dawei Li wrote:
pin_user_pages() is unsafe without protection of mmap_lock,
fix it by calling pin_user_pages_fast().
Fixes: 7a7a933edd6c ("drm/vmwgfx: Introduce VMware mks-guest-stats")
Signed-off-by: Dawei Li
---
v1:
https://lore.kernel.org/all/tycp286mb23235c9a9fcf85c045f95ea7ca...@tycp286mb2323.jpnp286.prod.outlook.com/
v1->v2:
Rebased to latest vmwgfx/drm-misc-fixes.
v2->v3
Replace pin_user_pages() with pin_user_pages_fast().
---
drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index 089046fa21be..50fa3df0bc0c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -1085,21 +1085,21 @@ int vmw_mksstat_add_ioctl(struct drm_device *dev, void
*data,
reset_ppn_array(pdesc->strsPPNs, ARRAY_SIZE(pdesc->strsPPNs));
/* Pin mksGuestStat user pages and store those in the instance descriptor */
- nr_pinned_stat = pin_user_pages(arg->stat, num_pages_stat,
FOLL_LONGTERM, pages_stat, NULL);
+ nr_pinned_stat = pin_user_pages_fast(arg->stat, num_pages_stat,
FOLL_LONGTERM, pages_stat);
if (num_pages_stat != nr_pinned_stat)
goto err_pin_stat;
for (i = 0; i < num_pages_stat; ++i)
pdesc->statPPNs[i] = page_to_pfn(pages_stat[i]);
- nr_pinned_info = pin_user_pages(arg->info, num_pages_info, FOLL_LONGTERM, pages_info, NULL);
+ nr_pinned_info = pin_user_pages_fast(arg->info, num_pages_info,
FOLL_LONGTERM, pages_info);
if (num_pages_info != nr_pinned_info)
goto err_pin_info;
for (i = 0; i < num_pages_info; ++i)
pdesc->infoPPNs[i] = page_to_pfn(pages_info[i]);
- nr_pinned_strs = pin_user_pages(arg->strs, num_pages_strs, FOLL_LONGTERM, pages_strs, NULL);
+ nr_pinned_strs = pin_user_pages_fast(arg->strs, num_pages_strs,
FOLL_LONGTERM, pages_strs);
if (num_pages_strs != nr_pinned_strs)
goto err_pin_strs;
Re: [PATCH v7 16/23] drm/probe-helper: Provide a TV get_modes helper
Hi Noralf,
On Mon, Nov 07, 2022 at 07:11:27PM +0100, Noralf Trønnes wrote:
>
>
> Den 07.11.2022 15.16, skrev Maxime Ripard:
> > From: Noralf Trønnes
> >
> > Most of the TV connectors will need a similar get_modes implementation
> > that will, depending on the drivers' capabilities, register the 480i and
> > 576i modes.
> >
> > That implementation will also need to set the preferred flag and order
> > the modes based on the driver and users preferrence.
> >
> > This is especially important to guarantee that a userspace stack such as
> > Xorg can start and pick up the preferred mode while maintaining a
> > working output.
> >
> > Signed-off-by: Noralf Trønnes
> > Signed-off-by: Maxime Ripard
> >
> > ---
> > Changes in v7:
> > - Used Noralf's implementation
> >
> > Changes in v6:
> > - New patch
> > ---
> > drivers/gpu/drm/drm_probe_helper.c | 97
> > ++
> > include/drm/drm_probe_helper.h | 1 +
> > 2 files changed, 98 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 2fc21df709bc..edb2e4c4530a 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -1147,3 +1147,100 @@ int drm_connector_helper_get_modes(struct
> > drm_connector *connector)
> > return count;
> > }
> > EXPORT_SYMBOL(drm_connector_helper_get_modes);
> > +
> > +static bool tv_mode_supported(struct drm_connector *connector,
> > + enum drm_connector_tv_mode mode)
> > +{
> > + struct drm_device *dev = connector->dev;
> > + struct drm_property *property = dev->mode_config.tv_mode_property;
> > +
> > + unsigned int i;
> > +
> > + for (i = 0; i < property->num_values; i++)
> > + if (property->values[i] == mode)
> > + return true;
> > +
> > + return false;
> > +}
>
> This function is not used in the new implementation.
>
> I hope you have tested this patch since I didn't even compile test my
> implementation (probably should have said so...)
You nailed it ;)
I had tested it (but missed the warning), and added unit tests to make
sure it was behaving properly, and it did. I'll send the unit tests in
my next version.
Thanks
Maxime
RE: [PATCH 4/4] drm/msm/disp/dpu1: add color management support for the crtc
>-Original Message-
>From: Kalyan Thota
>Sent: Wednesday, November 9, 2022 6:53 PM
>To: dmitry.barysh...@linaro.org; Kalyan Thota (QUIC)
>; dri-devel@lists.freedesktop.org; linux-arm-
>m...@vger.kernel.org; freedr...@lists.freedesktop.org;
>devicet...@vger.kernel.org
>Cc: linux-ker...@vger.kernel.org; robdcl...@chromium.org;
>diand...@chromium.org; swb...@chromium.org; Vinod Polimera (QUIC)
>; Abhinav Kumar (QUIC)
>
>Subject: RE: [PATCH 4/4] drm/msm/disp/dpu1: add color management support
>for the crtc
>
>
>
>>-Original Message-
>>From: Dmitry Baryshkov
>>Sent: Wednesday, November 9, 2022 6:02 PM
>>To: Kalyan Thota (QUIC) ; dri-
>>de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
>>freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
>>Cc: linux-ker...@vger.kernel.org; robdcl...@chromium.org;
>>diand...@chromium.org; swb...@chromium.org; Vinod Polimera (QUIC)
>>; Abhinav Kumar (QUIC)
>>
>>Subject: Re: [PATCH 4/4] drm/msm/disp/dpu1: add color management
>>support for the crtc
>>
>>WARNING: This email originated from outside of Qualcomm. Please be wary
>>of any links or attachments, and do not enable macros.
>>
>>On 09/11/2022 15:16, Kalyan Thota wrote:
>>> Add color management support for the crtc provided there are enough
>>> dspps that can be allocated from the catalogue
>>>
>>> Signed-off-by: Kalyan Thota
>>> ---
>>> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 15 ++--
>>> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 6
>>> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 11 +++---
>>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 53
>>+
>>> 4 files changed, 77 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>>> index 4170fbe..6bd3a64 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>>> @@ -18,9 +18,11 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> +#include "../../../drm_crtc_internal.h"
>>
>>If it's internal, it is not supposed to be used by other parties,
>>including the msm drm. At least a comment why you are including this file
>>would
>be helpful.
>>
>>>
>>> #include "dpu_kms.h"
>>> #include "dpu_hw_lm.h"
>>> @@ -553,6 +555,17 @@ static void _dpu_crtc_complete_flip(struct
>>> drm_crtc
>>*crtc)
>>> spin_unlock_irqrestore(>event_lock, flags);
>>> }
>>>
>>> +bool dpu_crtc_has_color_enabled(struct drm_crtc *crtc) {
>>> + u32 ctm_id = crtc->dev->mode_config.ctm_property->base.id;
>>> + u32 gamma_id = crtc->dev->mode_config.gamma_lut_property->base.id;
>>> + u32 degamma_id =
>>> +crtc->dev->mode_config.degamma_lut_property->base.id;
>>> +
>>> + return !!(drm_mode_obj_find_prop_id(>base, ctm_id) ||
>>> +drm_mode_obj_find_prop_id(>base, gamma_id) ||
>>> +drm_mode_obj_find_prop_id(>base, degamma_id));
>>> +}
>>> +
>>> enum dpu_intf_mode dpu_crtc_get_intf_mode(struct drm_crtc *crtc)
>>> {
>>> struct drm_encoder *encoder;
>>> @@ -1604,8 +1617,6 @@ struct drm_crtc *dpu_crtc_init(struct
>>> drm_device *dev, struct drm_plane *plane,
>>>
>>> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
>>>
>>> - drm_crtc_enable_color_mgmt(crtc, 0, true, 0);
>>> -
>>> /* save user friendly CRTC name for later */
>>> snprintf(dpu_crtc->name, DPU_CRTC_NAME_SIZE, "crtc%u",
>>> crtc->base.id);
>>>
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>>> index 539b68b..8bac395 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>>> @@ -300,4 +300,10 @@ static inline enum dpu_crtc_client_type
>>dpu_crtc_get_client_type(
>>> return crtc && crtc->state ? RT_CLIENT : NRT_CLIENT;
>>> }
>>>
>>> +/**
>>> + * dpu_crtc_has_color_enabled - check if the crtc has color
>>> +management enabled
>>> + * @crtc: Pointer to drm crtc object */ bool
>>> +dpu_crtc_has_color_enabled(struct drm_crtc *crtc);
>>> +
>>> #endif /* _DPU_CRTC_H_ */
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>>> index 4c56a16..ebc3f25 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>>> @@ -545,7 +545,8 @@ bool dpu_encoder_use_dsc_merge(struct
>drm_encoder
>>*drm_enc)
>>> static struct msm_display_topology dpu_encoder_get_topology(
>>> struct dpu_encoder_virt *dpu_enc,
>>> struct dpu_kms *dpu_kms,
>>> - struct drm_display_mode *mode)
>>> + struct drm_display_mode *mode,
>>> + struct drm_crtc *crtc)
>>> {
>>> struct msm_display_topology topology = {0};
>>> int i, intf_count = 0;
>>> @@ -573,11 +574,9 @@ static struct
[PATCH v3] drm/vmwgfx: Fix race issue calling pin_user_pages
pin_user_pages() is unsafe without protection of mmap_lock,
fix it by calling pin_user_pages_fast().
Fixes: 7a7a933edd6c ("drm/vmwgfx: Introduce VMware mks-guest-stats")
Signed-off-by: Dawei Li
---
v1:
https://lore.kernel.org/all/tycp286mb23235c9a9fcf85c045f95ea7ca...@tycp286mb2323.jpnp286.prod.outlook.com/
v1->v2:
Rebased to latest vmwgfx/drm-misc-fixes.
v2->v3
Replace pin_user_pages() with pin_user_pages_fast().
---
drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index 089046fa21be..50fa3df0bc0c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -1085,21 +1085,21 @@ int vmw_mksstat_add_ioctl(struct drm_device *dev, void
*data,
reset_ppn_array(pdesc->strsPPNs, ARRAY_SIZE(pdesc->strsPPNs));
/* Pin mksGuestStat user pages and store those in the instance
descriptor */
- nr_pinned_stat = pin_user_pages(arg->stat, num_pages_stat,
FOLL_LONGTERM, pages_stat, NULL);
+ nr_pinned_stat = pin_user_pages_fast(arg->stat, num_pages_stat,
FOLL_LONGTERM, pages_stat);
if (num_pages_stat != nr_pinned_stat)
goto err_pin_stat;
for (i = 0; i < num_pages_stat; ++i)
pdesc->statPPNs[i] = page_to_pfn(pages_stat[i]);
- nr_pinned_info = pin_user_pages(arg->info, num_pages_info,
FOLL_LONGTERM, pages_info, NULL);
+ nr_pinned_info = pin_user_pages_fast(arg->info, num_pages_info,
FOLL_LONGTERM, pages_info);
if (num_pages_info != nr_pinned_info)
goto err_pin_info;
for (i = 0; i < num_pages_info; ++i)
pdesc->infoPPNs[i] = page_to_pfn(pages_info[i]);
- nr_pinned_strs = pin_user_pages(arg->strs, num_pages_strs,
FOLL_LONGTERM, pages_strs, NULL);
+ nr_pinned_strs = pin_user_pages_fast(arg->strs, num_pages_strs,
FOLL_LONGTERM, pages_strs);
if (num_pages_strs != nr_pinned_strs)
goto err_pin_strs;
--
2.25.1
Re: [PATCH 16/26] drm: panfrost: Remove #ifdef guards for PM related functions
On 07/11/2022 17:52, Paul Cercueil wrote:
> Use the EXPORT_GPL_RUNTIME_DEV_PM_OPS() and pm_ptr() macros to handle
> the PM callbacks.
>
> These macros allow the PM functions to be automatically dropped by the
> compiler when CONFIG_PM is disabled, without having to use #ifdef
> guards.
>
> This has the advantage of always compiling these functions in,
> independently of any Kconfig option. Thanks to that, bugs and other
> regressions are subsequently easier to catch.
>
> Signed-off-by: Paul Cercueil
Reviewed-by: Steven Price
> ---
> Cc: Rob Herring
> Cc: Tomeu Vizoso
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> ---
> drivers/gpu/drm/panfrost/panfrost_device.c | 10 ++
> drivers/gpu/drm/panfrost/panfrost_device.h | 4 ++--
> drivers/gpu/drm/panfrost/panfrost_drv.c| 7 +--
> 3 files changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
> b/drivers/gpu/drm/panfrost/panfrost_device.c
> index ee612303f076..fa1a086a862b 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "panfrost_device.h"
> @@ -400,8 +401,7 @@ void panfrost_device_reset(struct panfrost_device *pfdev)
> panfrost_job_enable_interrupts(pfdev);
> }
>
> -#ifdef CONFIG_PM
> -int panfrost_device_resume(struct device *dev)
> +static int panfrost_device_resume(struct device *dev)
> {
> struct panfrost_device *pfdev = dev_get_drvdata(dev);
>
> @@ -411,7 +411,7 @@ int panfrost_device_resume(struct device *dev)
> return 0;
> }
>
> -int panfrost_device_suspend(struct device *dev)
> +static int panfrost_device_suspend(struct device *dev)
> {
> struct panfrost_device *pfdev = dev_get_drvdata(dev);
>
> @@ -423,4 +423,6 @@ int panfrost_device_suspend(struct device *dev)
>
> return 0;
> }
> -#endif
> +
> +EXPORT_GPL_RUNTIME_DEV_PM_OPS(panfrost_pm_ops, panfrost_device_suspend,
> + panfrost_device_resume, NULL);
> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
> b/drivers/gpu/drm/panfrost/panfrost_device.h
> index 8b25278f34c8..d9ba68cffb77 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.h
> @@ -7,6 +7,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -172,8 +173,7 @@ int panfrost_device_init(struct panfrost_device *pfdev);
> void panfrost_device_fini(struct panfrost_device *pfdev);
> void panfrost_device_reset(struct panfrost_device *pfdev);
>
> -int panfrost_device_resume(struct device *dev);
> -int panfrost_device_suspend(struct device *dev);
> +extern const struct dev_pm_ops panfrost_pm_ops;
>
> enum drm_panfrost_exception_type {
> DRM_PANFROST_EXCEPTION_OK = 0x00,
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 2fa5afe21288..fa619fe72086 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -676,17 +676,12 @@ static const struct of_device_id dt_match[] = {
> };
> MODULE_DEVICE_TABLE(of, dt_match);
>
> -static const struct dev_pm_ops panfrost_pm_ops = {
> - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> pm_runtime_force_resume)
> - SET_RUNTIME_PM_OPS(panfrost_device_suspend, panfrost_device_resume,
> NULL)
> -};
> -
> static struct platform_driver panfrost_driver = {
> .probe = panfrost_probe,
> .remove = panfrost_remove,
> .driver = {
> .name = "panfrost",
> - .pm = _pm_ops,
> + .pm = pm_ptr(_pm_ops),
> .of_match_table = dt_match,
> },
> };
Re: [PATCH] staging: fbtft: Use ARRAY_SIZE() to get argument count
On Fri, Nov 04, 2022 at 08:12:11PM +0530, Deepak R Varma wrote:
> On Fri, Nov 04, 2022 at 05:31:24PM +0530, Deepak R Varma wrote:
> > On Mon, Oct 31, 2022 at 01:05:32PM +0100, Julia Lawall wrote:
> > >
> > >
> > > I took a look, but it's pretty complex. You could take the code and
> > > reorganize it so that it is more readable, and then take the definition of
> > > the ARRAY_SIZE macro, to better see what is going on.
> > >
> > > julia
> > >
> >
> > Hello Greg, Julia,
> > I was able to successfully build the fbtft object file for arm architecture
> > as
> > well. I used gcc 6.5.0 and 9.5.0 tool chains. It was successful using both.
> > I
> > have attached the build log from my machine for your reference.
> >
> > I am also looking at the .i file and rearrange the expanded macro to
> > understand
> > it. However, since it is built successfully, I am not sure if that is truly
> > the
> > problem area.
> >
> > Should I resend the patch and check if it still errors the kernel build bot?
> > Anything else I can try?
>
> Looks like the change I proposed is causing nesting inside the write_reg
> function due to additional set of { & } brackets for the __VA_ARGS__ symbol.
>
> Am I understanding it right?
Hello Julia, Greg,
I am unable to reproduce this build failure on my local machine. I tried the X86
and arm based build. I am unable to troubleshoot this further. Do you have any
other suggestions? If not, I will drop this patch from my watch list.
Thank you,
./drv
>
> >
> > Thank you,
> > ./drv
>
>
>
>
[GIT PULL FOR v6.2] Renesas and Xilinx changes
Hi Daniel, Dave, The following changes since commit a143bc517bf31c4575191efbaac216a11ec016e0: Merge branch '00.06-gr-ampere' of https://gitlab.freedesktop.org/skeggsb/nouveau into drm-next (2022-11-09 11:18:56 +1000) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/drm-next-20221109 for you to fetch changes up to cec9e59cae6071e58140baf54e47c00aaa39851b: drm: xlnx: Fix return type of zynqmp_dp_bridge_mode_valid (2022-11-09 16:50:21 +0200) - Renesas RZ/G2L DSI support - Renesas DU Kconfig cleanup - Xilinx DPSUB fix Biju Das (3): dt-bindings: display: bridge: Document RZ/G2L MIPI DSI TX bindings drm: rcar-du: Add RZ/G2L DSI driver drm: rcar-du: rzg2l_mipi_dsi: Enhance device lanes check Laurent Pinchart (1): drm: rcar-du: Drop leftovers dependencies from Kconfig Nathan Huckleberry (1): drm: xlnx: Fix return type of zynqmp_dp_bridge_mode_valid .../bindings/display/bridge/renesas,dsi.yaml | 182 + drivers/gpu/drm/rcar-du/Kconfig| 10 +- drivers/gpu/drm/rcar-du/Makefile | 2 + drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 816 + drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi_regs.h | 151 drivers/gpu/drm/xlnx/zynqmp_dp.c | 7 +- 6 files changed, 1163 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml create mode 100644 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c -- Regards, Laurent Pinchart
[GIT PULL FOR v6.1] R-Car DU fixes
Hi Daniel, Dave, The following changes since commit 6295f1d8b4503ad8a18519b781dd2d1fe5e88c52: Merge tag 'drm-intel-fixes-2022-11-03' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2022-11-04 09:30:18 +1000) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/drm-fixes-20221109 for you to fetch changes up to a830a15678593948f3271a5a398c9b67d8beedb9: drm: rcar-du: Fix Kconfig dependency between RCAR_DU and RCAR_MIPI_DSI (2022-11-09 16:32:46 +0200) R-Car DSI Kconfig dependency fix Laurent Pinchart (1): drm: rcar-du: Fix Kconfig dependency between RCAR_DU and RCAR_MIPI_DSI drivers/gpu/drm/rcar-du/Kconfig | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) -- Regards, Laurent Pinchart
[Bug 216673] Recurring amdgpu freeze on kernel 6.0.6 only
https://bugzilla.kernel.org/show_bug.cgi?id=216673 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Stanislav Modrak from comment #3) > (In reply to Artem S. Tashkinov from comment #2) > > https://gitlab.freedesktop.org is where it should be anyways. > > Can you please explain why it belongs there and not here? Thx! That is where most GPU developers are and it also allows us to move bugs to other components when necessary. E.g., a mesa or xorg bug is misfiled as kernel. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v2] drm: xlnx: Fix return type of zynqmp_dp_bridge_mode_valid
Hi Nathan,
Thank you for the patch.
On Tue, Nov 08, 2022 at 05:14:25PM -0700, Nathan Chancellor wrote:
> From: Nathan Huckleberry
>
> The mode_valid field in drm_bridge_helper_funcs is expected to be of
> type
> enum drm_mode_status (* mode_valid) (struct drm_bridge *bridge,
> struct drm_display_mode *mode);
>
> The mismatched return type breaks forward edge kCFI since the underlying
> function definition does not match the function hook definition. A new
> warning in clang will catch this at compile time:
>
> drivers/gpu/drm/xlnx/zynqmp_dp.c:1573:16: error: incompatible function
> pointer types initializing 'enum drm_mode_status (*)(struct drm_bridge *,
> const struct drm_display_info *, const struct drm_display_mode *)' with an
> expression of type 'int (struct drm_bridge *, const struct drm_display_info
> *, const struct drm_display_mode *)'
> [-Werror,-Wincompatible-function-pointer-types-strict]
> .mode_valid = zynqmp_dp_bridge_mode_valid,
> ^~~
> 1 error generated.
>
> The return type of zynqmp_dp_bridge_mode_valid should be changed from
> int to enum drm_mode_status.
>
> Reported-by: Dan Carpenter
> Link: https://github.com/ClangBuiltLinux/linux/issues/1703
> Link: https://github.com/ClangBuiltLinux/linux/issues/1750
> Signed-off-by: Nathan Huckleberry
> Reviewed-by: Laurent Pinchart
> [nathan: Rebase on drm-misc-next and fix conflicts
> Add note about new clang warning]
> Signed-off-by: Nathan Chancellor
> ---
>
> Please consider picking this up so that it makes 6.2.
I'll send a pull request shortly.
> v2:
> - Take over for Nathan, as he is busy with other matters.
> - Rebase on drm-misc-next and resolve conflicts.
> - Add a note about new clang warning that will catch this issue at
> compile time.
>
> v1: https://lore.kernel.org/20220913205600.155172-1-nh...@google.com/
>
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 7c9ae167eac7..0a7b466446fb 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -1362,9 +1362,10 @@ static void zynqmp_dp_bridge_detach(struct drm_bridge
> *bridge)
> zynqmp_dp_aux_cleanup(dp);
> }
>
> -static int zynqmp_dp_bridge_mode_valid(struct drm_bridge *bridge,
> -const struct drm_display_info *info,
> -const struct drm_display_mode *mode)
> +static enum drm_mode_status
> +zynqmp_dp_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> + const struct drm_display_mode *mode)
> {
> struct zynqmp_dp *dp = bridge_to_dp(bridge);
> int rate;
>
> base-commit: 1a0257c352638916fdaffaac2ddedb8e049312f3
--
Regards,
Laurent Pinchart
Re: [PATCH] drm/panfrost: Split io-pgtable requests properly
On 08/11/2022 17:06, Robin Murphy wrote:
> Although we don't use 1GB block mappings, we still need to split
> map/unmap requests at 1GB boundaries to match what io-pgtable expects.
> Fix that, and add some explanation to make sense of it all.
>
> Fixes: 3740b081795a ("drm/panfrost: Update io-pgtable API")
> Reported-by: Dmitry Osipenko
> Signed-off-by: Robin Murphy
Reviewed-by: Steven Price
I'll push to drm-misc-fixes.
Thanks,
Steve
> ---
> The previous diff turned out to be not quite right, so I've not
> included Dmitry's Tested-by given for that.
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> index e246d914e7f6..4e83a1891f3e 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> @@ -250,13 +250,22 @@ void panfrost_mmu_reset(struct panfrost_device *pfdev)
>
> static size_t get_pgsize(u64 addr, size_t size, size_t *count)
> {
> + /*
> + * io-pgtable only operates on multiple pages within a single table
> + * entry, so we need to split at boundaries of the table size, i.e.
> + * the next block size up. The distance from address A to the next
> + * boundary of block size B is logically B - A % B, but in unsigned
> + * two's complement where B is a power of two we get the equivalence
> + * B - A % B == (B - A) % B == (n * B - A) % B, and choose n = 0 :)
> + */
> size_t blk_offset = -addr % SZ_2M;
>
> if (blk_offset || size < SZ_2M) {
> *count = min_not_zero(blk_offset, size) / SZ_4K;
> return SZ_4K;
> }
> - *count = size / SZ_2M;
> + blk_offset = -addr % SZ_1G ?: SZ_1G;
> + *count = min(blk_offset, size) / SZ_2M;
> return SZ_2M;
> }
>
Re: [PATCH v7 15/23] drm/modes: Introduce more named modes
Den 07.11.2022 15.16, skrev Maxime Ripard:
> Now that we can easily extend the named modes list, let's add a few more
> analog TV modes that were used in the wild, and some unit tests to make
> sure it works as intended.
>
> Signed-off-by: Maxime Ripard
>
> ---
> Changes in v6:
> - Renamed the tests to follow DRM test naming convention
>
> Changes in v5:
> - Switched to KUNIT_ASSERT_NOT_NULL
> ---
> drivers/gpu/drm/drm_modes.c | 2 +
> drivers/gpu/drm/tests/drm_client_modeset_test.c | 54
> +
> 2 files changed, 56 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 49441cabdd9d..17c5b6108103 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -2272,7 +2272,9 @@ struct drm_named_mode {
>
> static const struct drm_named_mode drm_named_modes[] = {
> NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE,
> DRM_MODE_TV_MODE_NTSC),
> + NAMED_MODE("NTSC-J", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE,
> DRM_MODE_TV_MODE_NTSC_J),
> NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE,
> DRM_MODE_TV_MODE_PAL),
> + NAMED_MODE("PAL-M", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE,
> DRM_MODE_TV_MODE_PAL_M),
> };
>
> static int drm_mode_parse_cmdline_named_mode(const char *name,
> diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
> b/drivers/gpu/drm/tests/drm_client_modeset_test.c
> index fdfe9e20702e..b3820d25beca 100644
> --- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
> +++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
> @@ -133,6 +133,32 @@ static void drm_test_pick_cmdline_named_ntsc(struct
> kunit *test)
> KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm),
> mode));
> }
>
> +static void drm_test_pick_cmdline_named_ntsc_j(struct kunit *test)
> +{
> + struct drm_client_modeset_test_priv *priv = test->priv;
> + struct drm_device *drm = priv->drm;
> + struct drm_connector *connector = >connector;
> + struct drm_cmdline_mode *cmdline_mode = >cmdline_mode;
> + struct drm_display_mode *mode;
> + const char *cmdline = "NTSC-J";
> + int ret;
> +
> + KUNIT_ASSERT_TRUE(test,
> + drm_mode_parse_command_line_for_connector(cmdline,
> + connector,
> +
> cmdline_mode));
> +
> + mutex_lock(>mode_config.mutex);
> + ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
> + mutex_unlock(>mode_config.mutex);
> + KUNIT_ASSERT_GT(test, ret, 0);
> +
> + mode = drm_connector_pick_cmdline_mode(connector);
> + KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> + KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm),
> mode));
> +}
> +
> static void drm_test_pick_cmdline_named_pal(struct kunit *test)
> {
> struct drm_client_modeset_test_priv *priv = test->priv;
> @@ -159,10 +185,38 @@ static void drm_test_pick_cmdline_named_pal(struct
> kunit *test)
> KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_pal_576i(drm),
> mode));
> }
>
> +static void drm_test_pick_cmdline_named_pal_m(struct kunit *test)
> +{
> + struct drm_client_modeset_test_priv *priv = test->priv;
> + struct drm_device *drm = priv->drm;
> + struct drm_connector *connector = >connector;
> + struct drm_cmdline_mode *cmdline_mode = >cmdline_mode;
> + struct drm_display_mode *mode;
> + const char *cmdline = "PAL-M";
> + int ret;
> +
> + KUNIT_ASSERT_TRUE(test,
> + drm_mode_parse_command_line_for_connector(cmdline,
> + connector,
> +
> cmdline_mode));
> +
> + mutex_lock(>mode_config.mutex);
> + ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
> + mutex_unlock(>mode_config.mutex);
> + KUNIT_ASSERT_GT(test, ret, 0);
> +
> + mode = drm_connector_pick_cmdline_mode(connector);
> + KUNIT_ASSERT_NOT_NULL(test, mode);
> +
> + KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm),
> mode));
> +}
> +
There are 4 named mode tests that are almost identical, should probably
use KUNIT_ARRAY_PARAM like in the parser tests.
This patchset has been going on for a long time now so it can be fixed
later if you don't want to do it now:
Reviewed-by: Noralf Trønnes
> static struct kunit_case drm_test_pick_cmdline_tests[] = {
> KUNIT_CASE(drm_test_pick_cmdline_res_1920_1080_60),
> KUNIT_CASE(drm_test_pick_cmdline_named_ntsc),
> + KUNIT_CASE(drm_test_pick_cmdline_named_ntsc_j),
> KUNIT_CASE(drm_test_pick_cmdline_named_pal),
> + KUNIT_CASE(drm_test_pick_cmdline_named_pal_m),
> {}
> };
>
>
Re: [PATCH] drm: rcar_du: DRM_RCAR_DU optionally depends on RCAR_MIPI_DSI
Hi Randy,
Thank you for the patch.
On Tue, Oct 18, 2022 at 11:18:28AM -0700, Randy Dunlap wrote:
> When CONFIG_DRM_RCAR_DU=y and CONFIG_DRM_RCAR_MIPI_DSI=m, calls
> from the builtin driver to the mipi driver fail due to linker
> errors.
> Since the RCAR_MIPI_DSI driver is not always required, fix the
> build error by making DRM_RCAR_DU optionally depend on the
> RCAR_MIPI_DSI Kconfig symbol. This prevents the problematic
> kconfig combination without requiring that RCAR_MIPI_DSI always
> be enabled.
>
> aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function
> `rcar_du_crtc_atomic_enable':
> rcar_du_crtc.c:(.text+0x3a18): undefined reference to
> `rcar_mipi_dsi_pclk_enable'
> aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function
> `rcar_du_crtc_atomic_disable':
> rcar_du_crtc.c:(.text+0x47cc): undefined reference to
> `rcar_mipi_dsi_pclk_disable'
I've already posted a fix, see
https://lore.kernel.org/dri-devel/20221001220342.5828-1-laurent.pinchart+rene...@ideasonboard.com/
It aligns with how the LVDS encoder driver is handled, so I would prefer
that. I will send a pull request shortly, as a v6.1 fix.
> Fixes: 957fe62d7d15 ("drm: rcar-du: Fix DSI enable & disable sequence")
> Signed-off-by: Randy Dunlap
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: LUU HOAI
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: David Airlie
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/rcar-du/Kconfig |1 +
> 1 file changed, 1 insertion(+)
>
> diff -- a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -4,6 +4,7 @@ config DRM_RCAR_DU
> depends on DRM && OF
> depends on ARM || ARM64
> depends on ARCH_RENESAS || COMPILE_TEST
> + depends on DRM_RCAR_MIPI_DSI || DRM_RCAR_MIPI_DSI=n
> select DRM_KMS_HELPER
> select DRM_GEM_DMA_HELPER
> select VIDEOMODE_HELPERS
--
Regards,
Laurent Pinchart
Re: [PATCH v2] drm: fix crash in drm_minor_alloc_release
On Tue, Nov 08, 2022 at 07:38:23PM +0100, Stanislaw Gruszka wrote:
> If drm_sysfs_minor_alloc() fail in drm_minor_alloc() we can end up
> freeing invalid minor->kdev pointer and drm_minor_alloc_release()
> will crash like below:
>
> RIP: 0010:kobject_put+0x19/0x1c0
> RSP: 0018:bc7001637c38 EFLAGS: 00010282
> RAX: a8d6deb0 RBX: RCX: 9cb5912d4540
> RDX: a9c45ec5 RSI: 9cb5902f2b68 RDI: fff4
> RBP: fff4 R08: a9c40dec R09: 0008
> R10: aa81f7d2 R11: aa81f7ca R12: 9cb5912d4540
> R13: 9cb5912d4540 R14: dead0122 R15: dead0100
> FS: 7f56b06e6740() GS:9cb728b4() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 0030 CR3: 00011285b004 CR4: 00170ee0
> DR0: DR1: DR2:
> DR3: DR6: 07f0 DR7: 0400
> Call Trace:
>
> drm_minor_alloc_release+0x19/0x50
> drm_managed_release+0xab/0x150
> drm_dev_init+0x21f/0x2f0
> __devm_drm_dev_alloc+0x3c/0xa0
> ivpu_probe+0x59/0x797 [intel_vpu 127058409b05eb2f99dcdecd3330bee28d6b3e76]
> pci_device_probe+0xa4/0x160
> really_probe+0x164/0x340
> __driver_probe_device+0x10d/0x190
> device_driver_attach+0x26/0x50
> bind_store+0x9f/0x120
> kernfs_fop_write_iter+0x12d/0x1c0
> new_sync_write+0x106/0x180
> vfs_write+0x216/0x2a0
> ksys_write+0x65/0xe0
> do_syscall_64+0x35/0x80
> entry_SYSCALL_64_after_hwframe+0x44/0xae
>
> Fix this crash by returning NULL minor->kdev on error.
>
> Fixes: f96306f9892b ("drm: manage drm_minor cleanup with drmm_")
> Signed-off-by: Stanislaw Gruszka
Reviewed-by: Daniel Vetter
On the entire drmm thing, you can avoid these if you do a drmm for every
little thing, that way you never get stuff that might or might not be set
up in the cleanup handler. But for one-off internal things that's a bit
overkill, and C utterly sucks at taking care of the boilerplate.
-Daniel
> ---
> v2: return minor->kdev NULL pointer instead of checking for IS_ERR in
> drm_minor_alloc_release()
>
> drivers/gpu/drm/drm_drv.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 8214a0b1ab7f..8d70b634d008 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -142,8 +142,11 @@ static int drm_minor_alloc(struct drm_device *dev,
> unsigned int type)
> return r;
>
> minor->kdev = drm_sysfs_minor_alloc(minor);
> - if (IS_ERR(minor->kdev))
> - return PTR_ERR(minor->kdev);
> + if (IS_ERR(minor->kdev)) {
> + r = PTR_ERR(minor->kdev);
> + minor->kdev = NULL;
> + return r;
> + }
>
> *drm_minor_get_slot(dev, type) = minor;
> return 0;
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RFC PATCH 1/3] drm: Introduce color fill properties for drm plane
On Wed, Nov 09, 2022 at 04:53:45PM +0300, Dmitry Baryshkov wrote: > On 09/11/2022 16:52, Daniel Vetter wrote: > > On Tue, Nov 08, 2022 at 06:25:29PM +, Simon Ser wrote: > > > On Saturday, October 29th, 2022 at 13:23, Dmitry Baryshkov > > > wrote: > > > > > > > On 29/10/2022 01:59, Jessica Zhang wrote: > > > > > > > > > Add support for COLOR_FILL and COLOR_FILL_FORMAT properties for > > > > > drm_plane. In addition, add support for setting and getting the values > > > > > of these properties. > > > > > > > > > > COLOR_FILL represents the color fill of a plane while > > > > > COLOR_FILL_FORMAT > > > > > represents the format of the color fill. Userspace can set enable > > > > > solid > > > > > fill on a plane by assigning COLOR_FILL to a uint64_t value, assigning > > > > > the COLOR_FILL_FORMAT property to a uint32_t value, and setting the > > > > > framebuffer to NULL. > > > > > > > > I suppose that COLOR_FILL should override framebuffer rather than > > > > requiring that FB is set to NULL. In other words, if color_filL_format > > > > is non-zero, it would make sense to ignore the FB. Then one can use the > > > > color_fill_format property to quickly switch between filled plane and > > > > FB-backed one. > > > > > > That would be inconsistent with the rest of the KMS uAPI. For instance, > > > the kernel will error out if CRTC has active=0 but a connector is still > > > linked to the CRTC. IOW, the current uAPI errors out if the KMS state > > > is inconsistent. > > > > So if the use-case here really is to solid-fill a plane (and not just > > provide a background color for the crtc overall), then I guess we could > > also extend addfb to make that happen. We've talked in the past about > > propertery-fying framebuffer objects, and that would sort out this uapi > > wart. And I agree the color fill vs PLANE_ID issue is a bit ugly at least. > > > > But if the use-cases are all background color then just doing the crtc > > background color would be tons simpler (and likely also easier to support > > for more hardware). > > No. The hardware supports multiple color-filled planes, which do not have to > cover the whole CRTC. The use case here means the userspace use-case. What the hw can do on any given chip kinda doesnt matter, which is why I'm asking. KMD uapi is not meant to reflect 100% exactly what a specific chip can do, but instead: - provide features userspace actually needs. If you want per-plane fill, you need userspace that makes use of per-plane fill, and if all you have is crtc background, then that's it. - we should create uapi with an eye towards what's actually possible on a reasonable set of drivers and hw. Sometimes that means a slightly more restricted set so that it's possible to implement in more places, especially if that restricted feature set still gets the job done for userspace. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [RFC PATCH 1/3] drm: Introduce color fill properties for drm plane
On 09/11/2022 16:52, Daniel Vetter wrote: On Tue, Nov 08, 2022 at 06:25:29PM +, Simon Ser wrote: On Saturday, October 29th, 2022 at 13:23, Dmitry Baryshkov wrote: On 29/10/2022 01:59, Jessica Zhang wrote: Add support for COLOR_FILL and COLOR_FILL_FORMAT properties for drm_plane. In addition, add support for setting and getting the values of these properties. COLOR_FILL represents the color fill of a plane while COLOR_FILL_FORMAT represents the format of the color fill. Userspace can set enable solid fill on a plane by assigning COLOR_FILL to a uint64_t value, assigning the COLOR_FILL_FORMAT property to a uint32_t value, and setting the framebuffer to NULL. I suppose that COLOR_FILL should override framebuffer rather than requiring that FB is set to NULL. In other words, if color_filL_format is non-zero, it would make sense to ignore the FB. Then one can use the color_fill_format property to quickly switch between filled plane and FB-backed one. That would be inconsistent with the rest of the KMS uAPI. For instance, the kernel will error out if CRTC has active=0 but a connector is still linked to the CRTC. IOW, the current uAPI errors out if the KMS state is inconsistent. So if the use-case here really is to solid-fill a plane (and not just provide a background color for the crtc overall), then I guess we could also extend addfb to make that happen. We've talked in the past about propertery-fying framebuffer objects, and that would sort out this uapi wart. And I agree the color fill vs PLANE_ID issue is a bit ugly at least. But if the use-cases are all background color then just doing the crtc background color would be tons simpler (and likely also easier to support for more hardware). No. The hardware supports multiple color-filled planes, which do not have to cover the whole CRTC. -- With best wishes Dmitry
Re: [RFC PATCH 1/3] drm: Introduce color fill properties for drm plane
On Tue, Nov 08, 2022 at 06:25:29PM +, Simon Ser wrote: > On Saturday, October 29th, 2022 at 13:23, Dmitry Baryshkov > wrote: > > > On 29/10/2022 01:59, Jessica Zhang wrote: > > > > > Add support for COLOR_FILL and COLOR_FILL_FORMAT properties for > > > drm_plane. In addition, add support for setting and getting the values > > > of these properties. > > > > > > COLOR_FILL represents the color fill of a plane while COLOR_FILL_FORMAT > > > represents the format of the color fill. Userspace can set enable solid > > > fill on a plane by assigning COLOR_FILL to a uint64_t value, assigning > > > the COLOR_FILL_FORMAT property to a uint32_t value, and setting the > > > framebuffer to NULL. > > > > I suppose that COLOR_FILL should override framebuffer rather than > > requiring that FB is set to NULL. In other words, if color_filL_format > > is non-zero, it would make sense to ignore the FB. Then one can use the > > color_fill_format property to quickly switch between filled plane and > > FB-backed one. > > That would be inconsistent with the rest of the KMS uAPI. For instance, > the kernel will error out if CRTC has active=0 but a connector is still > linked to the CRTC. IOW, the current uAPI errors out if the KMS state > is inconsistent. So if the use-case here really is to solid-fill a plane (and not just provide a background color for the crtc overall), then I guess we could also extend addfb to make that happen. We've talked in the past about propertery-fying framebuffer objects, and that would sort out this uapi wart. And I agree the color fill vs PLANE_ID issue is a bit ugly at least. But if the use-cases are all background color then just doing the crtc background color would be tons simpler (and likely also easier to support for more hardware). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/amd/display: delete the duplicate .set_odm_bypass initialization in dcn314_tg_funcs
Fix below sparse warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_optc.c:244:18: warning:
Initializer entry defined twice
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_optc.c:257:18: also
defined here
Fixes: 5ade1b951dec ("drm/amd/display: Add OTG/ODM functions")
Signed-off-by: Liu Jian
---
drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
index 47eb162f1a75..58d38de6a0f8 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
@@ -241,7 +241,6 @@ static struct timing_generator_funcs dcn314_tg_funcs = {
.set_dsc_config = optc3_set_dsc_config,
.get_dsc_status = optc2_get_dsc_status,
.set_dwb_source = NULL,
- .set_odm_bypass = optc3_set_odm_bypass,
.set_odm_combine = optc314_set_odm_combine,
.get_optc_source = optc2_get_optc_source,
.set_out_mux = optc3_set_out_mux,
--
2.17.1
[PATCH] drm/vkms: change min cursor size to accept smaller values
change min cursor size of vkms driver from 20 to 10, to increase the IGT test coverage of vkms by enabling 32x10 cursor size subtests in kms_cursor_crc Signed-off-by: Alaa Mohamed --- drivers/gpu/drm/vkms/vkms_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h index 0a67b8073f7e..4a248567efb2 100644 --- a/drivers/gpu/drm/vkms/vkms_drv.h +++ b/drivers/gpu/drm/vkms/vkms_drv.h @@ -12,8 +12,8 @@ #include #include -#define XRES_MIN20 -#define YRES_MIN20 +#define XRES_MIN10 +#define YRES_MIN10 #define XRES_DEF 1024 #define YRES_DEF 768 -- 2.34.1
Re: [Nouveau] [PATCH v7 06/23] drm/modes: Add a function to generate analog display modes
Hi, your statement:
"However, analog display usually have fairly loose timings requirements,
the only discrete parameters being the total number of lines and pixel
clock frequency."
Please do not make it as a rule. You said yourself: "usually". Arcade CRT
have more loose timings, but professional broadcast TV's such as Sony PVM,
Sony BVM, JVC. These cost tens of thousand dollars back in the day. Now
they are affordable for gamers. I just solved issue in Retroarch, CRT
Switchres library here: https://github.com/antonioginer/switchres/issues/96
This model is quite common among retrogamers and on Reddit.
Some developers do not test it properly.
This model requires exact number of lines.
For Switchres we came up with these ranges:
crt_range0 15625-15750, 49.50-65.00, 2.000, 4.700, 8.000,
0.064, 0.192, 1.024, 1, 1, 192, 288, 0, 0
crt_range1 15625.00-15625.00, 50.00-50.00, 1.500, 4.700,
5.800, 0.064, 0.160, 1.056, 1, 1, 0, 0, 448, 576
crt_range2 15734.26-15734.26, 59.94-59.94, 1.500, 4.700,
4.700, 0.191, 0.191, 0.953, 1, 1, 0, 0, 448, 480
crt_range0 is default, more loose definition for MAME emulators. crt_range1
is PAL and crt_range2 is NTSC.
Yes, this model does support both NTSC and PAL.
Does your driver or library support that?
For example old driver in Windows 7 with NVIDIA 2007 driver on Geforce 7600
can support both NTSC and PAL and these are being switched automatically by
the resolution you choose. So in desktop properties, you change to 640x480
and it will switch TV chipset to NTSC 480i. Then you change to 720x576 and
it will switch TV chipset to PAL 576i.
It would be preferred if advanced users could set up these numbers from a
commandline during a runtime, so it would depend on the app being used.
Lukas
On Mon, Nov 7, 2022 at 3:17 PM Maxime Ripard wrote:
> Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
> 625-lines modes in their drivers.
>
> Since those modes are fairly standard, and that we'll need to use them
> in more places in the future, it makes sense to move their definition
> into the core framework.
>
> However, analog display usually have fairly loose timings requirements,
> the only discrete parameters being the total number of lines and pixel
> clock frequency. Thus, we created a function that will create a display
> mode from the standard, the pixel frequency and the active area.
>
> Signed-off-by: Maxime Ripard
>
> ---
> Changes in v6:
> - Fix typo
>
> Changes in v4:
> - Reworded the line length check comment
> - Switch to HZ_PER_KHZ in tests
> - Use previous timing to fill our mode
> - Move the number of lines check earlier
> ---
> drivers/gpu/drm/drm_modes.c| 474
> +
> drivers/gpu/drm/tests/Makefile | 1 +
> drivers/gpu/drm/tests/drm_modes_test.c | 144 ++
> include/drm/drm_modes.h| 17 ++
> 4 files changed, 636 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 5d4ac79381c4..71c050c3ee6b 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -116,6 +116,480 @@ void drm_mode_probed_add(struct drm_connector
> *connector,
> }
> EXPORT_SYMBOL(drm_mode_probed_add);
>
> +enum drm_mode_analog {
> + DRM_MODE_ANALOG_NTSC, /* 525 lines, 60Hz */
> + DRM_MODE_ANALOG_PAL, /* 625 lines, 50Hz */
> +};
> +
> +/*
> + * The timings come from:
> + * -
> https://web.archive.org/web/20220406232708/http://www.kolumbus.fi/pami1/video/pal_ntsc.html
> + * -
> https://web.archive.org/web/20220406124914/http://martin.hinner.info/vga/pal.html
> + * -
> https://web.archive.org/web/20220609202433/http://www.batsocks.co.uk/readme/video_timing.htm
> + */
> +#define NTSC_LINE_DURATION_NS 63556U
> +#define NTSC_LINES_NUMBER 525
> +
> +#define NTSC_HBLK_DURATION_TYP_NS 10900U
> +#define NTSC_HBLK_DURATION_MIN_NS (NTSC_HBLK_DURATION_TYP_NS - 200)
> +#define NTSC_HBLK_DURATION_MAX_NS (NTSC_HBLK_DURATION_TYP_NS + 200)
> +
> +#define NTSC_HACT_DURATION_TYP_NS (NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_TYP_NS)
> +#define NTSC_HACT_DURATION_MIN_NS (NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_MAX_NS)
> +#define NTSC_HACT_DURATION_MAX_NS (NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_MIN_NS)
> +
> +#define NTSC_HFP_DURATION_TYP_NS 1500
> +#define NTSC_HFP_DURATION_MIN_NS 1270
> +#define NTSC_HFP_DURATION_MAX_NS 2220
> +
> +#define NTSC_HSLEN_DURATION_TYP_NS 4700
> +#define NTSC_HSLEN_DURATION_MIN_NS (NTSC_HSLEN_DURATION_TYP_NS - 100)
> +#define NTSC_HSLEN_DURATION_MAX_NS (NTSC_HSLEN_DURATION_TYP_NS + 100)
> +
> +#define NTSC_HBP_DURATION_TYP_NS 4700
> +
> +/*
> + * I couldn't find the actual tolerance for the back porch, so let's
> + * just reuse the sync length ones.
> + */
> +#define NTSC_HBP_DURATION_MIN_NS (NTSC_HBP_DURATION_TYP_NS - 100)
> +#define NTSC_HBP_DURATION_MAX_NS
Re: [Nouveau] [PATCH v7 22/23] drm/vc4: vec: Add support for more analog TV standards
They are important for retrogaming and connecting TV out to CRT TV or using
emulator.
I have PS1 that is using PAL-60 for example.
Can you add 240p and 288p non-interlaced modes for NTSC and PAL, please?
Lukas
On Mon, Nov 7, 2022 at 3:19 PM Maxime Ripard wrote:
> From: Mateusz Kwiatkowski
>
> Add support for the following composite output modes (all of them are
> somewhat more obscure than the previously defined ones):
>
> - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
> 4.43361875 MHz (the PAL subcarrier frequency). Never used for
> broadcasting, but sometimes used as a hack to play NTSC content in PAL
> regions (e.g. on VCRs).
> - PAL_N - PAL with alternative chroma subcarrier frequency,
> 3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay
> and Uruguay to fit 576i50 with colour in 6 MHz channel raster.
> - PAL60 - 480i60 signal with PAL-style color at normal European PAL
> frequency. Another non-standard, non-broadcast mode, used in similar
> contexts as NTSC_443. Some displays support one but not the other.
> - SECAM - French frequency-modulated analog color standard; also have
> been broadcast in Eastern Europe and various parts of Africa and Asia.
> Uses the same 576i50 timings as PAL.
>
> Also added some comments explaining color subcarrier frequency
> registers.
>
> Acked-by: Noralf Trønnes
> Signed-off-by: Mateusz Kwiatkowski
> Signed-off-by: Maxime Ripard
>
> ---
> Changes in v6:
> - Support PAL60 again
> ---
> drivers/gpu/drm/vc4/vc4_vec.c | 111
> --
> 1 file changed, 107 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> index a828fc6fb776..d23dbad3cbf6 100644
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> @@ -46,6 +46,7 @@
> #define VEC_CONFIG0_YDEL(x)((x) << 26)
> #define VEC_CONFIG0_CDEL_MASK GENMASK(25, 24)
> #define VEC_CONFIG0_CDEL(x)((x) << 24)
> +#define VEC_CONFIG0_SECAM_STD BIT(21)
> #define VEC_CONFIG0_PBPR_FIL BIT(18)
> #define VEC_CONFIG0_CHROMA_GAIN_MASK GENMASK(17, 16)
> #define VEC_CONFIG0_CHROMA_GAIN_UNITY (0 << 16)
> @@ -76,6 +77,27 @@
> #define VEC_SOFT_RESET 0x10c
> #define VEC_CLMP0_START0x144
> #define VEC_CLMP0_END 0x148
> +
> +/*
> + * These set the color subcarrier frequency
> + * if VEC_CONFIG1_CUSTOM_FREQ is enabled.
> + *
> + * VEC_FREQ1_0 contains the most significant 16-bit half-word,
> + * VEC_FREQ3_2 contains the least significant 16-bit half-word.
> + * 0x8000 seems to be equivalent to the pixel clock
> + * (which itself is the VEC clock divided by 8).
> + *
> + * Reference values (with the default pixel clock of 13.5 MHz):
> + *
> + * NTSC (3579545.[45] Hz) - 0x21F07C1F
> + * PAL (4433618.75 Hz) - 0x2A098ACB
> + * PAL-M (3575611.[888111] Hz) - 0x21E6EFE3
> + * PAL-N (3582056.25 Hz) - 0x21F69446
> + *
> + * NOTE: For SECAM, it is used as the Dr center frequency,
> + * regardless of whether VEC_CONFIG1_CUSTOM_FREQ is enabled or not;
> + * that is specified as 4406250 Hz, which corresponds to 0x29C71C72.
> + */
> #define VEC_FREQ3_20x180
> #define VEC_FREQ1_00x184
>
> @@ -118,6 +140,14 @@
>
> #define VEC_INTERRUPT_CONTROL 0x190
> #define VEC_INTERRUPT_STATUS 0x194
> +
> +/*
> + * Db center frequency for SECAM; the clock for this is the same as for
> + * VEC_FREQ3_2/VEC_FREQ1_0, which is used for Dr center frequency.
> + *
> + * This is specified as 425 Hz, which corresponds to 0x284BDA13.
> + * That is also the default value, so no need to set it explicitly.
> + */
> #define VEC_FCW_SECAM_B0x198
> #define VEC_SECAM_GAIN_VAL 0x19c
>
> @@ -197,10 +227,15 @@ enum vc4_vec_tv_mode_id {
> VC4_VEC_TV_MODE_NTSC_J,
> VC4_VEC_TV_MODE_PAL,
> VC4_VEC_TV_MODE_PAL_M,
> + VC4_VEC_TV_MODE_NTSC_443,
> + VC4_VEC_TV_MODE_PAL_60,
> + VC4_VEC_TV_MODE_PAL_N,
> + VC4_VEC_TV_MODE_SECAM,
> };
>
> struct vc4_vec_tv_mode {
> unsigned int mode;
> + u16 expected_htotal;
> u32 config0;
> u32 config1;
> u32 custom_freq;
> @@ -236,35 +271,68 @@ static const struct debugfs_reg32 vec_regs[] = {
> static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
> {
> .mode = DRM_MODE_TV_MODE_NTSC,
> + .expected_htotal = 858,
> .config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
> .config1 = VEC_CONFIG1_C_CVBS_CVBS,
> },
> + {
> + .mode = DRM_MODE_TV_MODE_NTSC_443,
> + .expected_htotal = 858,
> + .config0 = VEC_CONFIG0_NTSC_STD,
> + .config1 = VEC_CONFIG1_C_CVBS_CVBS |
> VEC_CONFIG1_CUSTOM_FREQ,
> + .custom_freq = 0x2a098acb,
Re: [Nouveau] [PATCH v7 00/23] drm: Analog TV Improvements
One can switch from NTSC to PAL now using (on vc4) modetest -M vc4 -s 53:720x480i -w 53:'TV mode':1 # NTSC modetest -M vc4 -s 53:720x576i -w 53:'TV mode':4 # PAL NTSC should be 640x480i, not 720. It will probably work on most TV's, but NTSC by the spec is 640x480i. On Mon, Nov 7, 2022 at 3:16 PM Maxime Ripard wrote: > Hi, > > Here's a series aiming at improving the command line named modes support, > and more importantly how we deal with all the analog TV variants. > > The named modes support were initially introduced to allow to specify the > analog TV mode to be used. > > However, this was causing multiple issues: > > * The mode name parsed on the command line was passed directly to the > driver, which had to figure out which mode it was suppose to match; > > * Figuring that out wasn't really easy, since the video= argument or what > the userspace might not even have a name in the first place, but > instead could have passed a mode with the same timings; > > * The fallback to matching on the timings was mostly working as long as > we were supporting one 525 lines (most likely NSTC) and one 625 lines > (PAL), but couldn't differentiate between two modes with the same > timings (NTSC vs PAL-M vs NSTC-J for example); > > * There was also some overlap with the tv mode property registered by > drm_mode_create_tv_properties(), but named modes weren't interacting > with that property at all. > > * Even though that property was generic, its possible values were > specific to each drivers, which made some generic support difficult. > > Thus, I chose to tackle in multiple steps: > > * A new TV mode property was introduced, with generic values, each driver > reporting through a bitmask what standard it supports to the userspace; > > * This option was added to the command line parsing code to be able to > specify it on the kernel command line, and new atomic_check and reset > helpers were created to integrate properly into atomic KMS; > > * The named mode parsing code is now creating a proper display mode for > the given named mode, and the TV standard will thus be part of the > connector state; > > * Two drivers were converted and tested for now (vc4 and sun4i), with > some backward compatibility code to translate the old TV mode to the > new TV mode; > > Unit tests were created along the way. > > One can switch from NTSC to PAL now using (on vc4) > > modetest -M vc4 -s 53:720x480i -w 53:'TV mode':1 # NTSC > modetest -M vc4 -s 53:720x576i -w 53:'TV mode':4 # PAL > > Let me know what you think, > Maxime > > To: David Airlie > To: Daniel Vetter > To: Maarten Lankhorst > To: Maxime Ripard > To: Thomas Zimmermann > To: Emma Anholt > To: Jani Nikula > To: Joonas Lahtinen > To: Rodrigo Vivi > To: Tvrtko Ursulin > To: Ben Skeggs > To: Karol Herbst > To: Lyude Paul > To: Chen-Yu Tsai > To: Jernej Skrabec > To: Samuel Holland > Cc: Geert Uytterhoeven > Cc: Mateusz Kwiatkowski > Cc: "Noralf Trønnes" > Cc: Dave Stevenson > Cc: Dom Cobley > Cc: Phil Elwell > Cc: > Cc: linux-ker...@vger.kernel.org > Cc: intel-...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-su...@lists.linux.dev > Cc: Hans de Goede > Signed-off-by: Maxime Ripard > > --- > Changes in v7: > - Switch to another implementation of get_modes from Noralf > - Made more checks in VEC's atomic_check > - Fixed typo in a commit log > - Checked for tv_mode_specified in > drm_mode_parse_command_line_for_connector > - Rebased on drm-misc-next-2022-11-03 > - Link to v6: > https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v6-0-e77927341...@cerno.tech > > Changes in v6: > - Add and convert to a new get_modes helper to create the PAL and NTSC > modes in > the proper order, with the right preferred mode flag, depending on the > driver > capabilities and defaults. > - Support PAL60 > - Renamed tests to be consistent with DRM tests naming convention > - Simplified a bit the named mode parsing code > - Add a tv_mode_specified field > - Return 0 in get_modes implementations instead of error codes > - Link to v5: > https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v5-0-d841cc64f...@cerno.tech > > Changes in v5: > - Dropped TV Standard documentation removal > - Switched the TV Mode documentation from CSV to actual documentation > - Switched to kunit assertions where possible > - Switched to KUNIT_ASSERT_NOT_NULL instead of KUNIT_ASSERT_PTR_NE(..., > NULL) > - Shuffled a bit the introduction of > drm_client_modeset_connector_get_modes between patches > - Renamed tv_mode_names to legacy_tv_mode_names > - Removed the count variable in sun4i_tv_comp_get_modes > - Rebased on top of current drm-misc-next > - Link to v4: > https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v4-0-60d38873f...@cerno.tech > > Changes in v4: > - Removed the unused TV Standard property documentation >
Re: [PATCH drm-misc-next v4 0/4] drm/arm/hdlcd: use drm managed resources
On Tue, Nov 08, 2022 at 08:57:55PM +0100, Danilo Krummrich wrote: > Hi Liviu, Hi, > > > The only issue that I'm seeing that is not critical is that at > > reboot/shutdown time > > I'm getting an "Unexpected global fault, this could be serious" from the > > smmu: > > > > [ 6893.467910] arm-smmu 7fb3.iommu: disabling translation > > [ 6893.473550] ohci-platform 7ffb.usb: Removing from iommu group 1 > > [ 6893.479909] ehci-platform 7ffc.usb: Removing from iommu group 1 > > [ 6893.486931] arm-smmu 7fb1.iommu: disabling translation > > [ 6893.492521] hdlcd 7ff5.hdlcd: Removing from iommu group 3 > > [ 6893.492650] arm-smmu 7fb1.iommu: Unexpected global fault, this could > > be serious > > [ 6893.505959] arm-smmu 7fb1.iommu: GFSR 0x8001, GFSYNR0 > > 0x, GFSYNR1 0x, GFSYNR2 0x > > [ 6893.516511] arm-smmu 7fb0.iommu: disabling translation > > [ 6893.522195] dma-pl330 7ff0.dma-controller: Removing from iommu group > > 2 > > [ 6893.529607] arm-smmu 2b50.iommu: disabling translation > > [ 6893.535221] pcieport :00:00.0: Removing from iommu group 0 > > [ 6893.541135] pci :01:00.0: Removing from iommu group 0 > > [ 6893.546604] pcieport :02:01.0: Removing from iommu group 0 > > [ 6893.552511] pcieport :02:02.0: Removing from iommu group 0 > > [ 6893.558418] pcieport :02:03.0: Removing from iommu group 0 > > [ 6893.564329] pcieport :02:0c.0: Removing from iommu group 0 > > [ 6893.570393] pcieport :02:10.0: Removing from iommu group 0 > > [ 6893.576314] pcieport :02:1f.0: Removing from iommu group 0 > > [ 6893.582214] sata_sil24 :03:00.0: Removing from iommu group 0 > > [ 6893.588270] sky2 :08:00.0: Removing from iommu group 0 > > [ 6893.594616] reboot: Power down > > > > > > The reboot/shutdown succeeds, so I'm not too worried about it for now, but > > hope that > > this is something you'll keep in mind in the later series when you do > > drm_dev_unplug(). > > Yes, I'd expect this to be related to the missing protection of platform > device bound resources. > > > > > With that, for the whole series: > > > > Acked-by: Liviu Dudau > > > > Thanks for the patience and going through the series iterations with me. > > > > I can pull this series into drm-misc-next on Monday if you don't have any > > other plans. > Thanks, I saw you already applied the series. > > Have you had a look on the same series for malidp? Yes, I've looked at the code and it looks reasonable, I just wanted to run it once through the minimum of tests that I use, which involves switching some FPGA images around. Hope to do that today or tomorrow. Best regards, Liviu > > - Danilo > > > > > Best regards, > > Liviu > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH] drm/vkms: change min cursor size to accept smaller values
Sorry, for the noise. I had some issues in my git send-email setup. Please, consider this version. - Alaa On 2022-11-09 12:39, Alaa Emad wrote: > change min cursor size of vkms driver from 20 to 10, to increase the IGT test > coverage of vkms by enabling 32x10 cursor size subtests in kms_cursor_crc > > Signed-off-by: Alaa Emad > --- > drivers/gpu/drm/vkms/vkms_drv.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h > index 0a67b8073f7e..4a248567efb2 100644 > --- a/drivers/gpu/drm/vkms/vkms_drv.h > +++ b/drivers/gpu/drm/vkms/vkms_drv.h > @@ -12,8 +12,8 @@ > #include > #include > > -#define XRES_MIN20 > -#define YRES_MIN20 > +#define XRES_MIN10 > +#define YRES_MIN10 > > #define XRES_DEF 1024 > #define YRES_DEF 768
Re: [Intel-gfx] [PATCH v2] drm/i915/mtl: Media GT and Render GT share common GGTT
On Wed, 09 Nov 2022, Aravind Iddamsetty wrote:
> On XE_LPM+ platforms the media engines are carved out into a separate
> GT but have a common GGTMMADR address range which essentially makes
> the GGTT address space to be shared between media and render GT. As a
> result any updates in GGTT shall invalidate TLB of GTs sharing it and
> similarly any operation on GGTT requiring an action on a GT will have to
> involve all GTs sharing it. setup_private_pat was being done on a per
> GGTT based as that doesn't touch any GGTT structures moved it to per GT
> based.
>
> BSPEC: 63834
>
> v2:
> 1. Add details to commit msg
> 2. includes fix for failure to add item to ggtt->gt_list, as suggested
> by Lucas
> 3. as ggtt_flush() is used only for ggtt drop i915_is_ggtt check within
> it.
> 4. setup_private_pat moved out of intel_gt_tiles_init
>
> Cc: Matt Roper
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 47 ++---
> drivers/gpu/drm/i915/gt/intel_gt.c| 13 +-
> drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
> drivers/gpu/drm/i915/gt/intel_gtt.h | 4 ++
> drivers/gpu/drm/i915/i915_driver.c| 22 +++---
> drivers/gpu/drm/i915/i915_gem_evict.c | 51 +--
> drivers/gpu/drm/i915/i915_vma.c | 5 ++-
> drivers/gpu/drm/i915/selftests/i915_gem.c | 2 +
> 8 files changed, 112 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 2518cebbf931..6ba7e9e8e2ca 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -8,6 +8,7 @@
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -196,10 +197,13 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
>
> void i915_ggtt_suspend(struct i915_ggtt *ggtt)
> {
> + struct intel_gt *gt;
> +
> i915_ggtt_suspend_vm(>vm);
> ggtt->invalidate(ggtt);
>
> - intel_gt_check_and_clear_faults(ggtt->vm.gt);
> + list_for_each_entry(gt, >gt_list, ggtt_link)
> + intel_gt_check_and_clear_faults(gt);
> }
>
> void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
> @@ -225,16 +229,21 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
>
> static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
> {
> - struct intel_uncore *uncore = ggtt->vm.gt->uncore;
> struct drm_i915_private *i915 = ggtt->vm.i915;
>
> gen8_ggtt_invalidate(ggtt);
>
> - if (GRAPHICS_VER(i915) >= 12)
> - intel_uncore_write_fw(uncore, GEN12_GUC_TLB_INV_CR,
> - GEN12_GUC_TLB_INV_CR_INVALIDATE);
> - else
> - intel_uncore_write_fw(uncore, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
> + if (GRAPHICS_VER(i915) >= 12) {
> + struct intel_gt *gt;
> +
> + list_for_each_entry(gt, >gt_list, ggtt_link)
> + intel_uncore_write_fw(gt->uncore,
> + GEN12_GUC_TLB_INV_CR,
> + GEN12_GUC_TLB_INV_CR_INVALIDATE);
> + } else {
> + intel_uncore_write_fw(ggtt->vm.gt->uncore,
> + GEN8_GTCR, GEN8_GTCR_INVALIDATE);
> + }
> }
>
> u64 gen8_ggtt_pte_encode(dma_addr_t addr,
> @@ -986,8 +995,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
>
> ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
>
> - setup_private_pat(ggtt->vm.gt);
> -
> return ggtt_probe_common(ggtt, size);
> }
>
> @@ -1186,7 +1193,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
> intel_gt *gt)
> (u64)ggtt->mappable_end >> 20);
> drm_dbg(>drm, "DSM size = %lluM\n",
> (u64)resource_size(_graphics_stolen_res) >> 20);
> -
> + INIT_LIST_HEAD(>gt_list);
> return 0;
> }
>
> @@ -1208,6 +1215,19 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
> return 0;
> }
>
> +struct i915_ggtt *i915_ggtt_create(struct drm_i915_private *i915)
> +{
> + struct i915_ggtt *ggtt;
> +
> + ggtt = drmm_kzalloc(>drm, sizeof(*ggtt), GFP_KERNEL);
> + if (!ggtt)
> + return ERR_PTR(-ENOMEM);
> +
> + INIT_LIST_HEAD(>gt_list);
> +
> + return ggtt;
> +}
> +
> int i915_ggtt_enable_hw(struct drm_i915_private *i915)
> {
> if (GRAPHICS_VER(i915) < 6)
> @@ -1296,9 +1316,11 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
>
> void i915_ggtt_resume(struct i915_ggtt *ggtt)
> {
> + struct intel_gt *gt;
> bool flush;
>
> - intel_gt_check_and_clear_faults(ggtt->vm.gt);
> + list_for_each_entry(gt, >gt_list, ggtt_link)
> + intel_gt_check_and_clear_faults(gt);
>
> flush = i915_ggtt_resume_vm(>vm);
>
> @@ -1307,9 +1329,6 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
> if (flush)
> wbinvd_on_all_cpus();
>
> - if (GRAPHICS_VER(ggtt->vm.i915) >= 8)
>
[PATCH v2] drm/i915/mtl: Media GT and Render GT share common GGTT
On XE_LPM+ platforms the media engines are carved out into a separate
GT but have a common GGTMMADR address range which essentially makes
the GGTT address space to be shared between media and render GT. As a
result any updates in GGTT shall invalidate TLB of GTs sharing it and
similarly any operation on GGTT requiring an action on a GT will have to
involve all GTs sharing it. setup_private_pat was being done on a per
GGTT based as that doesn't touch any GGTT structures moved it to per GT
based.
BSPEC: 63834
v2:
1. Add details to commit msg
2. includes fix for failure to add item to ggtt->gt_list, as suggested
by Lucas
3. as ggtt_flush() is used only for ggtt drop i915_is_ggtt check within
it.
4. setup_private_pat moved out of intel_gt_tiles_init
Cc: Matt Roper
Signed-off-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 47 ++---
drivers/gpu/drm/i915/gt/intel_gt.c| 13 +-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
drivers/gpu/drm/i915/gt/intel_gtt.h | 4 ++
drivers/gpu/drm/i915/i915_driver.c| 22 +++---
drivers/gpu/drm/i915/i915_gem_evict.c | 51 +--
drivers/gpu/drm/i915/i915_vma.c | 5 ++-
drivers/gpu/drm/i915/selftests/i915_gem.c | 2 +
8 files changed, 112 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 2518cebbf931..6ba7e9e8e2ca 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#include
@@ -196,10 +197,13 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
void i915_ggtt_suspend(struct i915_ggtt *ggtt)
{
+ struct intel_gt *gt;
+
i915_ggtt_suspend_vm(>vm);
ggtt->invalidate(ggtt);
- intel_gt_check_and_clear_faults(ggtt->vm.gt);
+ list_for_each_entry(gt, >gt_list, ggtt_link)
+ intel_gt_check_and_clear_faults(gt);
}
void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
@@ -225,16 +229,21 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
{
- struct intel_uncore *uncore = ggtt->vm.gt->uncore;
struct drm_i915_private *i915 = ggtt->vm.i915;
gen8_ggtt_invalidate(ggtt);
- if (GRAPHICS_VER(i915) >= 12)
- intel_uncore_write_fw(uncore, GEN12_GUC_TLB_INV_CR,
- GEN12_GUC_TLB_INV_CR_INVALIDATE);
- else
- intel_uncore_write_fw(uncore, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+ if (GRAPHICS_VER(i915) >= 12) {
+ struct intel_gt *gt;
+
+ list_for_each_entry(gt, >gt_list, ggtt_link)
+ intel_uncore_write_fw(gt->uncore,
+ GEN12_GUC_TLB_INV_CR,
+ GEN12_GUC_TLB_INV_CR_INVALIDATE);
+ } else {
+ intel_uncore_write_fw(ggtt->vm.gt->uncore,
+ GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+ }
}
u64 gen8_ggtt_pte_encode(dma_addr_t addr,
@@ -986,8 +995,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
- setup_private_pat(ggtt->vm.gt);
-
return ggtt_probe_common(ggtt, size);
}
@@ -1186,7 +1193,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
intel_gt *gt)
(u64)ggtt->mappable_end >> 20);
drm_dbg(>drm, "DSM size = %lluM\n",
(u64)resource_size(_graphics_stolen_res) >> 20);
-
+ INIT_LIST_HEAD(>gt_list);
return 0;
}
@@ -1208,6 +1215,19 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
return 0;
}
+struct i915_ggtt *i915_ggtt_create(struct drm_i915_private *i915)
+{
+ struct i915_ggtt *ggtt;
+
+ ggtt = drmm_kzalloc(>drm, sizeof(*ggtt), GFP_KERNEL);
+ if (!ggtt)
+ return ERR_PTR(-ENOMEM);
+
+ INIT_LIST_HEAD(>gt_list);
+
+ return ggtt;
+}
+
int i915_ggtt_enable_hw(struct drm_i915_private *i915)
{
if (GRAPHICS_VER(i915) < 6)
@@ -1296,9 +1316,11 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
void i915_ggtt_resume(struct i915_ggtt *ggtt)
{
+ struct intel_gt *gt;
bool flush;
- intel_gt_check_and_clear_faults(ggtt->vm.gt);
+ list_for_each_entry(gt, >gt_list, ggtt_link)
+ intel_gt_check_and_clear_faults(gt);
flush = i915_ggtt_resume_vm(>vm);
@@ -1307,9 +1329,6 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
if (flush)
wbinvd_on_all_cpus();
- if (GRAPHICS_VER(ggtt->vm.i915) >= 8)
- setup_private_pat(ggtt->vm.gt);
-
intel_ggtt_restore_fences(ggtt);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 8e914c4066ed..d57b10a0e5c8 100644
---
RE: [EXT] Re: [v2 06/10] drm: bridge: cadence: Add MHDP HDMI driver for i.MX8MQ
Thanks for your comments.
> -Original Message-
> From: Alexander Stein
> Sent: 2022年11月8日 21:17
> To: jo...@kwiboo.se; Sandor Yu
> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org;
> linux-...@lists.infradead.org; andrzej.ha...@intel.com;
> neil.armstr...@linaro.org; robert.f...@linaro.org;
> laurent.pinch...@ideasonboard.com; jernej.skra...@gmail.com;
> kis...@ti.com; vk...@kernel.org; Oliver Brown ;
> krzysztof.kozlowski...@linaro.org; s...@ravnborg.org; jani.nik...@intel.com;
> tzimmerm...@suse.de; s.ha...@pengutronix.de; javi...@redhat.com;
> penguin-ker...@i-love.sakura.ne.jp; robh...@kernel.org; dl-linux-imx
> ; ker...@pengutronix.de; Sandor Yu
> ; shawn...@kernel.org; p.ya...@ti.com;
> max...@cerno.tech
> Subject: [EXT] Re: [v2 06/10] drm: bridge: cadence: Add MHDP HDMI driver
> for i.MX8MQ
>
> Caution: EXT Email
>
> Hello,
>
> thanks for working on this and the updated version.
>
> Am Freitag, 4. November 2022, 07:44:56 CET schrieb Sandor Yu:
> > Add a new DRM HDMI bridge driver for Candence MHDP used in i.MX8MQ
> > SOC. MHDP IP could support HDMI or DisplayPort standards according
> > embedded Firmware running in the uCPU.
> >
> > For iMX8MQ SOC, the HDMI FW was loaded and activated by SOC ROM
> code.
> > Bootload binary included HDMI FW was required for the driver.
> >
> > Signed-off-by: Sandor Yu
> > ---
> > drivers/gpu/drm/bridge/cadence/Kconfig| 12 +
> > .../gpu/drm/bridge/cadence/cdns-hdmi-core.c | 1038
> +
> > 2 files changed, 1050 insertions(+)
> > create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-hdmi-core.c
> >
> > diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
> > b/drivers/gpu/drm/bridge/cadence/Kconfig index
> > e79ae1af3765..377452d09992
> > 100644
> > --- a/drivers/gpu/drm/bridge/cadence/Kconfig
> > +++ b/drivers/gpu/drm/bridge/cadence/Kconfig
> > @@ -26,6 +26,18 @@ config DRM_CDNS_MHDP8546_J721E
> > clock and data muxes.
> > endif
> >
> > +config DRM_CDNS_HDMI
> > + tristate "Cadence HDMI DRM driver"
> > + select DRM_KMS_HELPER
> > + select DRM_PANEL_BRIDGE
> > + select DRM_DISPLAY_HELPER
> > + select DRM_CDNS_AUDIO
> > + depends on OF
> > + help
> > + Support Cadence MHDP HDMI driver.
> > + Cadence MHDP Controller support one or more protocols,
> > + HDMI firmware is required for this driver.
> > +
> > config DRM_CDNS_DP
> > tristate "Cadence DP DRM driver"
> > select DRM_KMS_HELPER
> > diff --git a/drivers/gpu/drm/bridge/cadence/cdns-hdmi-core.c
> > b/drivers/gpu/drm/bridge/cadence/cdns-hdmi-core.c new file mode
> 100644
> > index ..b392aac015bd
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/cadence/cdns-hdmi-core.c
> > @@ -0,0 +1,1038 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Cadence High-Definition Multimedia Interface (HDMI) driver
> > + *
> > + * Copyright (C) 2019-2022 NXP Semiconductor, Inc.
> > + *
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include #include
> > + #include
> > + #include
> > +#include #include
> #include
> > + #include #include
> > + #include
> > +
> > +#include "cdns-mhdp-common.h"
> > +
> > +void cdns_mhdp_infoframe_set(struct cdns_mhdp_device *mhdp,
> > + u8 entry_id, u8 packet_len,
> u8 *packet, u8 packet_type)
> > +{
> > + u32 *packet32, len32;
> > + u32 val, i;
> > +
> > + /* invalidate entry */
> > + val = F_ACTIVE_IDLE_TYPE(1) | F_PKT_ALLOC_ADDRESS(entry_id);
> > + writel(val, mhdp->regs + SOURCE_PIF_PKT_ALLOC_REG);
> > + writel(F_PKT_ALLOC_WR_EN(1), mhdp->regs +
> SOURCE_PIF_PKT_ALLOC_WR_EN);
> > +
> > + /* flush fifo 1 */
> > + writel(F_FIFO1_FLUSH(1), mhdp->regs +
> SOURCE_PIF_FIFO1_FLUSH);
> > +
> > + /* write packet into memory */
> > + packet32 = (u32 *)packet;
>
> This only works on little-endian machines, no?
Register SOURCE_PIF_DATA_WR require little-endian data,
I will use get_unaligned_le32() to replace it in the next version.
>
> > + len32 = packet_len / 4;
> > + for (i = 0; i < len32; i++)
> > + writel(F_DATA_WR(packet32[i]), mhdp->regs +
> SOURCE_PIF_DATA_WR);
> > +
> > + /* write entry id */
> > + writel(F_WR_ADDR(entry_id), mhdp->regs +
> SOURCE_PIF_WR_ADDR);
> > +
> > + /* write request */
> > + writel(F_HOST_WR(1), mhdp->regs + SOURCE_PIF_WR_REQ);
> > +
> > + /* update entry */
> > + val = F_ACTIVE_IDLE_TYPE(1) | F_TYPE_VALID(1) |
> > + F_PACKET_TYPE(packet_type) |
> F_PKT_ALLOC_ADDRESS(entry_id);
> > + writel(val, mhdp->regs + SOURCE_PIF_PKT_ALLOC_REG);
> > +
> > + writel(F_PKT_ALLOC_WR_EN(1), mhdp->regs +
> SOURCE_PIF_PKT_ALLOC_WR_EN);
> > +}
> > +
> > +static int cdns_hdmi_get_edid_block(void *data, u8
RE: [PATCH 4/4] drm/msm/disp/dpu1: add color management support for the crtc
>-Original Message-
>From: Dmitry Baryshkov
>Sent: Wednesday, November 9, 2022 6:02 PM
>To: Kalyan Thota (QUIC) ; dri-
>de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
>freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
>Cc: linux-ker...@vger.kernel.org; robdcl...@chromium.org;
>diand...@chromium.org; swb...@chromium.org; Vinod Polimera (QUIC)
>; Abhinav Kumar (QUIC)
>
>Subject: Re: [PATCH 4/4] drm/msm/disp/dpu1: add color management support
>for the crtc
>
>WARNING: This email originated from outside of Qualcomm. Please be wary of
>any links or attachments, and do not enable macros.
>
>On 09/11/2022 15:16, Kalyan Thota wrote:
>> Add color management support for the crtc provided there are enough
>> dspps that can be allocated from the catalogue
>>
>> Signed-off-by: Kalyan Thota
>> ---
>> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 15 ++--
>> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 6
>> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 11 +++---
>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 53
>+
>> 4 files changed, 77 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> index 4170fbe..6bd3a64 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> @@ -18,9 +18,11 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> +#include "../../../drm_crtc_internal.h"
>
>If it's internal, it is not supposed to be used by other parties, including
>the msm
>drm. At least a comment why you are including this file would be helpful.
>
>>
>> #include "dpu_kms.h"
>> #include "dpu_hw_lm.h"
>> @@ -553,6 +555,17 @@ static void _dpu_crtc_complete_flip(struct drm_crtc
>*crtc)
>> spin_unlock_irqrestore(>event_lock, flags);
>> }
>>
>> +bool dpu_crtc_has_color_enabled(struct drm_crtc *crtc) {
>> + u32 ctm_id = crtc->dev->mode_config.ctm_property->base.id;
>> + u32 gamma_id = crtc->dev->mode_config.gamma_lut_property->base.id;
>> + u32 degamma_id =
>> +crtc->dev->mode_config.degamma_lut_property->base.id;
>> +
>> + return !!(drm_mode_obj_find_prop_id(>base, ctm_id) ||
>> +drm_mode_obj_find_prop_id(>base, gamma_id) ||
>> +drm_mode_obj_find_prop_id(>base, degamma_id));
>> +}
>> +
>> enum dpu_intf_mode dpu_crtc_get_intf_mode(struct drm_crtc *crtc)
>> {
>> struct drm_encoder *encoder;
>> @@ -1604,8 +1617,6 @@ struct drm_crtc *dpu_crtc_init(struct drm_device
>> *dev, struct drm_plane *plane,
>>
>> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
>>
>> - drm_crtc_enable_color_mgmt(crtc, 0, true, 0);
>> -
>> /* save user friendly CRTC name for later */
>> snprintf(dpu_crtc->name, DPU_CRTC_NAME_SIZE, "crtc%u",
>> crtc->base.id);
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>> index 539b68b..8bac395 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>> @@ -300,4 +300,10 @@ static inline enum dpu_crtc_client_type
>dpu_crtc_get_client_type(
>> return crtc && crtc->state ? RT_CLIENT : NRT_CLIENT;
>> }
>>
>> +/**
>> + * dpu_crtc_has_color_enabled - check if the crtc has color
>> +management enabled
>> + * @crtc: Pointer to drm crtc object
>> + */
>> +bool dpu_crtc_has_color_enabled(struct drm_crtc *crtc);
>> +
>> #endif /* _DPU_CRTC_H_ */
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> index 4c56a16..ebc3f25 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> @@ -545,7 +545,8 @@ bool dpu_encoder_use_dsc_merge(struct drm_encoder
>*drm_enc)
>> static struct msm_display_topology dpu_encoder_get_topology(
>> struct dpu_encoder_virt *dpu_enc,
>> struct dpu_kms *dpu_kms,
>> - struct drm_display_mode *mode)
>> + struct drm_display_mode *mode,
>> + struct drm_crtc *crtc)
>> {
>> struct msm_display_topology topology = {0};
>> int i, intf_count = 0;
>> @@ -573,11 +574,9 @@ static struct msm_display_topology
>dpu_encoder_get_topology(
>> else
>> topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT)
>> ? 2 : 1;
>>
>> - if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
>> - if (dpu_kms->catalog->dspp &&
>> - (dpu_kms->catalog->dspp_count >= topology.num_lm))
>> + if (dpu_crtc_has_color_enabled(crtc) &&
>> + (dpu_kms->catalog->dspp_count >= topology.num_lm))
>
>See the comment to the previous patch. It still applies here.
>
>> topology.num_dspp = topology.num_lm;
>> - }
>>
>> topology.num_enc = 0;
>>
Re: [PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c
On Wed, Nov 09, 2022 at 03:21:29AM +, Tian, Kevin wrote: > > From: Jason Gunthorpe > > Sent: Wednesday, November 9, 2022 9:05 AM > > > > On Tue, Nov 08, 2022 at 03:55:20PM -0700, Alex Williamson wrote: > > > > > > > So why exactly isn't this an issue for VDPA? Are we just burying our > > > > > head in the sand that such platforms exists and can still be useful > > > > > given the appropriate risk vs reward trade-off? > > > > > > > > Simply that nobody has asked for it, and might never ask for it. This > > > > is all support for old platforms, and there just doesn't seem to be a > > > > "real" use case for very new (and actually rare) NIC hardware stuck > > > > into ancient platforms with this security problem. > > > > > > vIOMMU support for interrupt remapping is relatively new, the nesting > > > case is important as well. > > > > This is where we got hit. In the end we fixed the qemu.. > > but the point is that old qemu could have a much longer lifespan than > old platforms then when running newer kernel which supports vdpa > on old qemu the same tradeoff consideration is then not vfio > specific... I think we are reaching into incredible hypotheticals here. We don't know of any real uses cases where a very new VDPA capable device would be assinged into a VM using an old qemu and the entire system is expected to work. What we are seeing is people using this stuff are making highly engineered systems and will meet the constraints. Today VDPA doesn't support allow_unsafe_interrupts, and I don't see a compelling reason to change that. The threshold for introducing a kernel security hole should be much higher than "someone could possibly do this". > If all agree that VFIO_CONTAINER=n is a process to evolve, does it make > more sense to remove this patch from this series i.e. let it buried in > VFIO_CONTAINER=y for now? Then resolve it in a follow up patch if > no consensus can be made quickly at this point. This is worse, it would make iommufd completely unusable in situations where we need allow_unsafe_interrupts. If we belive that is important we should keep this patch so existing systems on kernels with VFIO_CONTAINER=y continue to work after libvirt/qemu are upgraded to iommufd. Jason
[Bug 216673] Recurring amdgpu freeze on kernel 6.0.6 only
https://bugzilla.kernel.org/show_bug.cgi?id=216673 --- Comment #3 from Stanislav Modrak (stanislav.mod...@gmail.com) --- (In reply to Artem S. Tashkinov from comment #2) > https://gitlab.freedesktop.org is where it should be anyways. Can you please explain why it belongs there and not here? Thx! -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v2 00/11] Connect VFIO to IOMMUFD
On Wed, Nov 09, 2022 at 09:03:52AM +, Tian, Kevin wrote: > every mail in this series is shown thrice in lore: > > https://lore.kernel.org/all/0-v2-65016290f146+33e-vfio_iommufd_...@nvidia.com/ > > not sure what caused it but it's annoying to check the conversation there. It is sort of a lore issue, it only combines messages that are exactly the same together. Several of the mailing lists on CC here mangle the message in various ways, eg adding trailer or whatever. This causes repeated messages in lore. The trick in lore is to replace "/all/" with a good list, like /kvm/ or /linux-iommu/ that shows the original non-mangled version, and only once. Jason
Re: [PATCH 4/4] drm/msm/disp/dpu1: add color management support for the crtc
On 09/11/2022 15:39, Kalyan Thota wrote:
-Original Message-
From: Dmitry Baryshkov
Sent: Wednesday, November 9, 2022 6:02 PM
To: Kalyan Thota (QUIC) ; dri-
de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; robdcl...@chromium.org;
diand...@chromium.org; swb...@chromium.org; Vinod Polimera (QUIC)
; Abhinav Kumar (QUIC)
Subject: Re: [PATCH 4/4] drm/msm/disp/dpu1: add color management support
for the crtc
WARNING: This email originated from outside of Qualcomm. Please be wary of
any links or attachments, and do not enable macros.
On 09/11/2022 15:16, Kalyan Thota wrote:
Add color management support for the crtc provided there are enough
dspps that can be allocated from the catalogue
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 15 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 6
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 11 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 53
+
4 files changed, 77 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 4170fbe..6bd3a64 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -18,9 +18,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include "../../../drm_crtc_internal.h"
If it's internal, it is not supposed to be used by other parties, including the
msm
drm. At least a comment why you are including this file would be helpful.
This header file was included to make use of " drm_mode_obj_find_prop_id"
function from DRM framework.
Should I add a comment near function definition ?
No, it would have been better to add a comment near the #include
directive. However if this is the only user, you don't need it at all.
You see, you know whether the CRTC has color management propreties at
the time of creation. And this can not change. So, you just add a
boolean to dpu_crtc (or dpu_crtc_state, whichever suits better).
#include "dpu_kms.h"
#include "dpu_hw_lm.h"
@@ -553,6 +555,17 @@ static void _dpu_crtc_complete_flip(struct drm_crtc
*crtc)
spin_unlock_irqrestore(>event_lock, flags);
}
+bool dpu_crtc_has_color_enabled(struct drm_crtc *crtc) {
+ u32 ctm_id = crtc->dev->mode_config.ctm_property->base.id;
+ u32 gamma_id = crtc->dev->mode_config.gamma_lut_property->base.id;
+ u32 degamma_id =
+crtc->dev->mode_config.degamma_lut_property->base.id;
+
+ return !!(drm_mode_obj_find_prop_id(>base, ctm_id) ||
+drm_mode_obj_find_prop_id(>base, gamma_id) ||
+drm_mode_obj_find_prop_id(>base, degamma_id));
+}
+
enum dpu_intf_mode dpu_crtc_get_intf_mode(struct drm_crtc *crtc)
{
struct drm_encoder *encoder;
@@ -1604,8 +1617,6 @@ struct drm_crtc *dpu_crtc_init(struct drm_device
*dev, struct drm_plane *plane,
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
- drm_crtc_enable_color_mgmt(crtc, 0, true, 0);
-
/* save user friendly CRTC name for later */
snprintf(dpu_crtc->name, DPU_CRTC_NAME_SIZE, "crtc%u",
crtc->base.id);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 539b68b..8bac395 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -300,4 +300,10 @@ static inline enum dpu_crtc_client_type
dpu_crtc_get_client_type(
return crtc && crtc->state ? RT_CLIENT : NRT_CLIENT;
}
+/**
+ * dpu_crtc_has_color_enabled - check if the crtc has color
+management enabled
+ * @crtc: Pointer to drm crtc object
+ */
+bool dpu_crtc_has_color_enabled(struct drm_crtc *crtc);
+
#endif /* _DPU_CRTC_H_ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 4c56a16..ebc3f25 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -545,7 +545,8 @@ bool dpu_encoder_use_dsc_merge(struct drm_encoder
*drm_enc)
static struct msm_display_topology dpu_encoder_get_topology(
struct dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms,
- struct drm_display_mode *mode)
+ struct drm_display_mode *mode,
+ struct drm_crtc *crtc)
{
struct msm_display_topology topology = {0};
int i, intf_count = 0;
@@ -573,11 +574,9 @@ static struct msm_display_topology
dpu_encoder_get_topology(
else
topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT)
? 2 : 1;
- if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
- if (dpu_kms->catalog->dspp &&
- (dpu_kms->catalog->dspp_count >= topology.num_lm))
+ if
Re: [v8] drm/msm/disp/dpu1: add support for dspp sub block flush in sc7280
On 09/11/2022 15:14, Kalyan Thota wrote:
Flush mechanism for DSPP blocks has changed in sc7280 family, it
allows individual sub blocks to be flushed in coordination with
master flush control.
Representation: master_flush && (PCC_flush | IGC_flush .. etc )
This change adds necessary support for the above design.
Changes in v1:
- Few nits (Doug, Dmitry)
- Restrict sub-block flush programming to dpu_hw_ctl file (Dmitry)
Changes in v2:
- Move the address offset to flush macro (Dmitry)
- Seperate ops for the sub block flush (Dmitry)
Changes in v3:
- Reuse the DPU_DSPP_xx enum instead of a new one (Dmitry)
Changes in v4:
- Use shorter version for unsigned int (Stephen)
Changes in v5:
- Spurious patch please ignore.
Changes in v6:
- Add SOB tag (Doug, Dmitry)
Changes in v7:
- Cache flush mask per dspp (Dmitry)
- Few nits (Marijn)
Changes in v8:
- Few nits (Marijn)
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 5 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 12 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 66 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 7 ++-
5 files changed, 72 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 601d687..4170fbe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -766,7 +766,7 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc *crtc)
/* stage config flush mask */
ctl->ops.update_pending_flush_dspp(ctl,
- mixer[i].hw_dspp->idx);
+ mixer[i].hw_dspp->idx, DPU_DSPP_PCC);
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 27f029f..0eecb2f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -65,7 +65,10 @@
(PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
#define CTL_SC7280_MASK \
- (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
BIT(DPU_CTL_VM_CFG))
+ (BIT(DPU_CTL_ACTIVE_CFG) | \
+BIT(DPU_CTL_FETCH_ACTIVE) | \
+BIT(DPU_CTL_VM_CFG) | \
+BIT(DPU_CTL_DSPP_SUB_BLOCK_FLUSH))
#define MERGE_3D_SM8150_MASK (0)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 38aa38a..35f4810 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -161,10 +161,12 @@ enum {
* DSPP sub-blocks
* @DPU_DSPP_PCC Panel color correction block
* @DPU_DSPP_GC Gamma correction block
+ * @DPU_DSPP_IGC Inverse gamma correction block
*/
enum {
DPU_DSPP_PCC = 0x1,
DPU_DSPP_GC,
+ DPU_DSPP_IGC,
DPU_DSPP_MAX
};
@@ -188,16 +190,18 @@ enum {
/**
* CTL sub-blocks
- * @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
- * @DPU_CTL_FETCH_ACTIVE: Active CTL for fetch HW (SSPPs)
- * @DPU_CTL_VM_CFG:CTL config to support multiple VMs
- * @DPU_CTL_MAX
+ * @DPU_CTL_SPLIT_DISPLAY CTL supports video mode split display
+ * @DPU_CTL_FETCH_ACTIVE Active CTL for fetch HW (SSPPs)
+ * @DPU_CTL_VM_CFGCTL config to support multiple VMs
+ * @DPU_CTL_DSPP_BLOCK_FLUSH CTL config to support dspp sub-block flush
+ * @DPU_CTL_MAX Maximum value
No unnecessary whitespace changes please.
*/
enum {
DPU_CTL_SPLIT_DISPLAY = 0x1,
DPU_CTL_ACTIVE_CFG,
DPU_CTL_FETCH_ACTIVE,
DPU_CTL_VM_CFG,
+ DPU_CTL_DSPP_SUB_BLOCK_FLUSH,
DPU_CTL_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index a35ecb6..29821ea 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -28,22 +28,23 @@
#define CTL_INTF_ACTIVE 0x0F4
#define CTL_MERGE_3D_FLUSH0x100
#define CTL_DSC_ACTIVE0x0E8
-#define CTL_DSC_FLUSH0x104
+#define CTL_DSC_FLUSH 0x104
#define CTL_WB_FLUSH 0x108
#define CTL_INTF_FLUSH0x110
#define CTL_INTF_MASTER 0x134
#define CTL_FETCH_PIPE_ACTIVE 0x0FC
+#define CTL_DSPP_n_FLUSH(n) ((0x13C) + ((n) * 4))
-#define CTL_MIXER_BORDER_OUTBIT(24)
-#define CTL_FLUSH_MASK_CTL BIT(17)
+#define CTL_MIXER_BORDER_OUT BIT(24)
+#define CTL_FLUSH_MASK_CTLBIT(17)
-#define DPU_REG_RESET_TIMEOUT_US2000
-#define MERGE_3D_IDX 23
-#define DSC_IDX22
-#define INTF_IDX 31
-#define WB_IDX 16
-#define CTL_INVALID_BIT
RE: [PATCH 4/4] drm/msm/disp/dpu1: add color management support for the crtc
>-Original Message-
>From: Dmitry Baryshkov
>Sent: Wednesday, November 9, 2022 6:02 PM
>To: Kalyan Thota (QUIC) ; dri-
>de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
>freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
>Cc: linux-ker...@vger.kernel.org; robdcl...@chromium.org;
>diand...@chromium.org; swb...@chromium.org; Vinod Polimera (QUIC)
>; Abhinav Kumar (QUIC)
>
>Subject: Re: [PATCH 4/4] drm/msm/disp/dpu1: add color management support
>for the crtc
>
>WARNING: This email originated from outside of Qualcomm. Please be wary of
>any links or attachments, and do not enable macros.
>
>On 09/11/2022 15:16, Kalyan Thota wrote:
>> Add color management support for the crtc provided there are enough
>> dspps that can be allocated from the catalogue
>>
>> Signed-off-by: Kalyan Thota
>> ---
>> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 15 ++--
>> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 6
>> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 11 +++---
>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 53
>+
>> 4 files changed, 77 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> index 4170fbe..6bd3a64 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> @@ -18,9 +18,11 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> +#include "../../../drm_crtc_internal.h"
>
>If it's internal, it is not supposed to be used by other parties, including
>the msm
>drm. At least a comment why you are including this file would be helpful.
>
This header file was included to make use of " drm_mode_obj_find_prop_id"
function from DRM framework.
Should I add a comment near function definition ?
>>
>> #include "dpu_kms.h"
>> #include "dpu_hw_lm.h"
>> @@ -553,6 +555,17 @@ static void _dpu_crtc_complete_flip(struct drm_crtc
>*crtc)
>> spin_unlock_irqrestore(>event_lock, flags);
>> }
>>
>> +bool dpu_crtc_has_color_enabled(struct drm_crtc *crtc) {
>> + u32 ctm_id = crtc->dev->mode_config.ctm_property->base.id;
>> + u32 gamma_id = crtc->dev->mode_config.gamma_lut_property->base.id;
>> + u32 degamma_id =
>> +crtc->dev->mode_config.degamma_lut_property->base.id;
>> +
>> + return !!(drm_mode_obj_find_prop_id(>base, ctm_id) ||
>> +drm_mode_obj_find_prop_id(>base, gamma_id) ||
>> +drm_mode_obj_find_prop_id(>base, degamma_id));
>> +}
>> +
>> enum dpu_intf_mode dpu_crtc_get_intf_mode(struct drm_crtc *crtc)
>> {
>> struct drm_encoder *encoder;
>> @@ -1604,8 +1617,6 @@ struct drm_crtc *dpu_crtc_init(struct drm_device
>> *dev, struct drm_plane *plane,
>>
>> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
>>
>> - drm_crtc_enable_color_mgmt(crtc, 0, true, 0);
>> -
>> /* save user friendly CRTC name for later */
>> snprintf(dpu_crtc->name, DPU_CRTC_NAME_SIZE, "crtc%u",
>> crtc->base.id);
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>> index 539b68b..8bac395 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>> @@ -300,4 +300,10 @@ static inline enum dpu_crtc_client_type
>dpu_crtc_get_client_type(
>> return crtc && crtc->state ? RT_CLIENT : NRT_CLIENT;
>> }
>>
>> +/**
>> + * dpu_crtc_has_color_enabled - check if the crtc has color
>> +management enabled
>> + * @crtc: Pointer to drm crtc object
>> + */
>> +bool dpu_crtc_has_color_enabled(struct drm_crtc *crtc);
>> +
>> #endif /* _DPU_CRTC_H_ */
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> index 4c56a16..ebc3f25 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> @@ -545,7 +545,8 @@ bool dpu_encoder_use_dsc_merge(struct drm_encoder
>*drm_enc)
>> static struct msm_display_topology dpu_encoder_get_topology(
>> struct dpu_encoder_virt *dpu_enc,
>> struct dpu_kms *dpu_kms,
>> - struct drm_display_mode *mode)
>> + struct drm_display_mode *mode,
>> + struct drm_crtc *crtc)
>> {
>> struct msm_display_topology topology = {0};
>> int i, intf_count = 0;
>> @@ -573,11 +574,9 @@ static struct msm_display_topology
>dpu_encoder_get_topology(
>> else
>> topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT)
>> ? 2 : 1;
>>
>> - if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
>> - if (dpu_kms->catalog->dspp &&
>> - (dpu_kms->catalog->dspp_count >= topology.num_lm))
>> + if (dpu_crtc_has_color_enabled(crtc) &&
>> + (dpu_kms->catalog->dspp_count >= topology.num_lm))
>
>See the comment to the
