Re: [PATCH] drm/exynos/hdmi: add support for 1920x1200@60Hz mode
20. 10. 9. 오후 10:05에 Marek Szyprowski 이(가) 쓴 글:
> Add clock configuration for 154MHz pixelclock to Exynos542x HDMIPHY,
> which is required for 1920x1200@60Hz mode. The PLL configuration data
> has been taken from the vendor's kernel tree for the Odroid XU4 board.
Merged.
Thanks,
Inki Dae
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index dc01c188c0e0..39fa5d3b01ef 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -522,6 +522,15 @@ static const struct hdmiphy_config
> hdmiphy_5420_configs[] = {
> 0x54, 0x4B, 0x25, 0x03, 0x00, 0x80, 0x01, 0x80,
> },
> },
> + {
> + .pixel_clock = 15400,
> + .conf = {
> + 0x01, 0xD1, 0x20, 0x01, 0x40, 0x30, 0x08, 0xCC,
> + 0x8C, 0xE8, 0xC1, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x86,
> + 0x54, 0x3F, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> };
>
> static const struct hdmiphy_config hdmiphy_5433_configs[] = {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v5 1/5] RDMA/umem: Support importing dma-buf as user memory region
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday, October 16, 2020 6:05 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATCH v5 1/5] RDMA/umem: Support importing dma-buf as user
> memory region
>
> On Sat, Oct 17, 2020 at 12:57:21AM +, Xiong, Jianxin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Friday, October 16, 2020 5:28 PM
> > > To: Xiong, Jianxin
> > > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> > > Doug Ledford ; Leon Romanovsky
> > > ; Sumit Semwal ; Christian
> > > Koenig ; Vetter, Daniel
> > >
> > > Subject: Re: [PATCH v5 1/5] RDMA/umem: Support importing dma-buf as
> > > user memory region
> > >
> > > On Thu, Oct 15, 2020 at 03:02:45PM -0700, Jianxin Xiong wrote:
> > > > +struct ib_umem *ib_umem_dmabuf_get(struct ib_device *device,
> > > > + unsigned long addr, size_t size,
> > > > + int dmabuf_fd, int access,
> > > > + const struct ib_umem_dmabuf_ops
> > > > *ops) {
> > > > + struct dma_buf *dmabuf;
> > > > + struct ib_umem_dmabuf *umem_dmabuf;
> > > > + struct ib_umem *umem;
> > > > + unsigned long end;
> > > > + long ret;
> > > > +
> > > > + if (check_add_overflow(addr, (unsigned long)size, ))
> > > > + return ERR_PTR(-EINVAL);
> > > > +
> > > > + if (unlikely(PAGE_ALIGN(end) < PAGE_SIZE))
> > > > + return ERR_PTR(-EINVAL);
> > > > +
> > > > + if (unlikely(!ops || !ops->invalidate || !ops->update))
> > > > + return ERR_PTR(-EINVAL);
> > > > +
> > > > + umem_dmabuf = kzalloc(sizeof(*umem_dmabuf), GFP_KERNEL);
> > > > + if (!umem_dmabuf)
> > > > + return ERR_PTR(-ENOMEM);
> > > > +
> > > > + umem_dmabuf->ops = ops;
> > > > + INIT_WORK(_dmabuf->work, ib_umem_dmabuf_work);
> > > > +
> > > > + umem = _dmabuf->umem;
> > > > + umem->ibdev = device;
> > > > + umem->length = size;
> > > > + umem->address = addr;
> > >
> > > addr here is offset within the dma buf, but this code does nothing with
> > > it.
> > >
> > The current code assumes 0 offset, and 'addr' is the nominal starting
> > address of the buffer. If this is to be changed to offset, then yes,
> > some more handling is needed as you mentioned below.
>
> There is no such thing as 'nominal starting address'
>
> If the user is to provide any argument it can only be offset and length.
>
> > > Also, dma_buf_map_attachment() does not do the correct dma mapping
> > > for RDMA, eg it does not use ib_dma_map(). This is not a problem for
> > > mlx5 but it is troublesome to put in the core code.
> >
> > ib_dma_map() uses dma_map_single(), GPU drivers use dma_map_resource()
> > for dma_buf_map_attachment(). They belong to the same family, but take
> > different address type (kernel address vs MMIO physical address).
> > Could you elaborate what the problem could be for non-mlx5 HCAs?
>
> They use the virtual dma ops which we intend to remove
We can have a check with the dma device before attaching the dma-buf and thus
ib_umem_dmabuf_get() call from such drivers would fail. Something like:
#ifdef CONFIG_DMA_VIRT_OPS
if (device->dma_device->dma_ops == _virt_ops)
return ERR_PTR(-EINVAL);
#endif
>
> Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.10-rc1
Hi Linus, Some fixes queued up already for i915 and amdgpu, I've also included the fix for the clang warning you've seen. Dave. drm-next-2020-10-19: drm fixes for 5.10-rc1 i915: - Set all unused color plane offsets to ~0xfff again (Ville) - Fix TGL DKL PHY DP vswing handling (Ville) amdgpu: - DCN clang warning fix - eDP fix - BACO fix - Kernel documentation fixes - SMU7 mclk fix - VCN1 hw bug workaround amdkfd: - kvfree vs kfree fix The following changes since commit 640eee067d9aae0bb98d8706001976ff1affaf00: Merge tag 'drm-misc-next-fixes-2020-10-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2020-10-14 07:31:53 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-10-19 for you to fetch changes up to 40b99050455b9a6cb8faf15dcd41888312184720: Merge tag 'drm-intel-next-fixes-2020-10-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2020-10-19 09:21:59 +1000) drm fixes for 5.10-rc1 i915: - Set all unused color plane offsets to ~0xfff again (Ville) - Fix TGL DKL PHY DP vswing handling (Ville) amdgpu: - DCN clang warning fix - eDP fix - BACO fix - Kernel documentation fixes - SMU7 mclk fix - VCN1 hw bug workaround amdkfd: - kvfree vs kfree fix Alex Deucher (1): drm/amdgpu/swsmu: init the baco mutex in early_init Dave Airlie (2): Merge tag 'amd-drm-fixes-5.10-2020-10-14' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge tag 'drm-intel-next-fixes-2020-10-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Eryk Brol (1): drm/amd/display: Fix incorrect dsc force enable logic Evan Quan (1): drm/amd/pm: increase mclk switch threshold to 200 us Kent Russell (1): drm/amdkfd: Use kvfree in destroy_crat_image Mauro Carvalho Chehab (2): drm/amd/display: kernel-doc: document force_timing_sync docs: amdgpu: fix a warning when building the documentation Rodrigo Siqueira (1): drm/amd/display: Fix module load hangs when connected to an eDP Veerabadhran G (1): drm/amdgpu: vcn and jpeg ring synchronization Ville Syrjälä (2): drm/i915: Fix TGL DKL PHY DP vswing handling drm/i915: Set all unused color plane offsets to ~0xfff again Documentation/gpu/amdgpu.rst | 4 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c| 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h| 1 + drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.c | 24 +-- drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 28 ++ drivers/gpu/drm/amd/amdgpu/vcn_v1_0.h | 3 ++- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 ++ .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 2 +- drivers/gpu/drm/amd/display/dc/core/dc.c | 10 .../gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c| 2 +- drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 7 +++--- drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- drivers/gpu/drm/i915/display/intel_display.c | 17 - 14 files changed, 72 insertions(+), 34 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] drm/bridge: lvds-codec: Add support for pixel data sampling edge select
Hi Marek,
Thank you for the patch.
On Sat, Oct 03, 2020 at 01:08:23AM +0200, Marek Vasut wrote:
> The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
> select input pixel data sampling edge. Add DT property "pixelclk-active",
> same as the one used by display timings, and configure bus flags based on
> this DT property.
The feature looks good to me. I however wonder if we shouldn't use the
standard pclk-sample endpoint property (documented in [1]) instead of a
custom properly.
The DT bindings for the lvds-codec should be updated accordingly. And
the property should only be taken into account when operating in encoder
mode, as for decoder mode there's no polarity for the sampling of LVDS
signals, as you've explained in a reply to Sam.
[1] Documentation/devicetree/bindings/media/video-interfaces.txt
> Signed-off-by: Marek Vasut
> Cc: Alexandre Torgue
> Cc: Andrzej Hajda
> Cc: Antonio Borneo
> Cc: Benjamin Gaignard
> Cc: Biju Das
> Cc: Laurent Pinchart
> Cc: Maxime Coquelin
> Cc: Philippe Cornu
> Cc: Sam Ravnborg
> Cc: Vincent Abriou
> Cc: Yannick Fertre
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> To: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/bridge/lvds-codec.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> b/drivers/gpu/drm/bridge/lvds-codec.c
> index f52ccffc1bd1..bc941d4fb5b9 100644
> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> @@ -19,6 +19,7 @@ struct lvds_codec {
> struct device *dev;
> struct drm_bridge bridge;
> struct drm_bridge *panel_bridge;
> + struct drm_bridge_timings timings;
> struct regulator *vcc;
> struct gpio_desc *powerdown_gpio;
> u32 connector_type;
> @@ -80,6 +81,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
> struct device_node *panel_node;
> struct drm_panel *panel;
> struct lvds_codec *lvds_codec;
> + u32 val;
> int ret;
>
> lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
> @@ -124,6 +126,12 @@ static int lvds_codec_probe(struct platform_device *pdev)
> if (IS_ERR(lvds_codec->panel_bridge))
> return PTR_ERR(lvds_codec->panel_bridge);
>
> + if (!of_property_read_u32(dev->of_node, "pixelclk-active", )) {
> + lvds_codec->timings.input_bus_flags = val ?
> + DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE :
> + DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE;
> + }
> +
> /*
>* The panel_bridge bridge is attached to the panel's of_node,
>* but we need a bridge attached to our of_node for our user
> @@ -131,6 +139,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
>*/
> lvds_codec->bridge.of_node = dev->of_node;
> lvds_codec->bridge.funcs =
> + lvds_codec->bridge.timings = _codec->timings;
> drm_bridge_add(_codec->bridge);
>
> platform_set_drvdata(pdev, lvds_codec);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
amdgpu: Manual Card Configuration Change
Hello all, Regarding amdgpu, I've been using some Radeon 5700XTs for compute work with kernels through 5.8.14. I recently tried kernel 5.9.0, and found that the following is no longer allowed: echo "m 1 200" | sudo tee /sys/class/drm/card0/device/pp_od_clk_voltage Is this an expected change? If so, where should I look for documentation regarding how to manually configure these cards with this kernel. Note, I've had this working with 5.8 kernels for months. Thanks Josh___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC 11/13] drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder
> -Original Message-
> From: Shankar, Uma
> Sent: Monday, October 19, 2020 5:02 AM
> To: Nautiyal, Ankit K ; intel-
> g...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Kulkarni, Vandita
> ; ville.syrj...@linux.intel.com; Sharma, Swati2
>
> Subject: RE: [RFC 11/13] drm/i915: Read DSC capabilities of the HDMI2.1 PCON
> encoder
Also it would be good to move to DRM Core.
>
>
> > -Original Message-
> > From: Nautiyal, Ankit K
> > Sent: Thursday, October 15, 2020 4:23 PM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org; Shankar, Uma
> > ; Kulkarni, Vandita
> > ; ville.syrj...@linux.intel.com; Sharma,
> > Swati2
> > Subject: [RFC 11/13] drm/i915: Read DSC capabilities of the HDMI2.1
> > PCON encoder
> >
> > This patch adds a helper function to read the DSC capabilities of the
> > HDMI2.1 PCon encoder. It also adds a new structure to store these
> > caps, which can then be used to get the PPS parameters for
> > PCON-HDMI2.1 sink pair. Which inturn will be used to take a call to
> > override the existing PPS-metadata, by either writing the entire new
> > PPS metadata, or by writing only the PPS override parameters.
> >
> > Signed-off-by: Ankit Nautiyal
> > ---
> > .../drm/i915/display/intel_display_types.h| 16 ++
> > drivers/gpu/drm/i915/display/intel_dp.c | 178 ++
> > 2 files changed, 194 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 6c69922313d6..23282695a47f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1292,6 +1292,21 @@ struct intel_dp_pcon_frl {
> > int trained_rate_gbps;
> > };
> >
> > +struct intel_dp_pcon_dsc {
> > + bool enc_support;
> > + bool pps_override_support;
> > + bool blk_prediction_support;
> > + u8 version_major;
> > + u8 version_minor;
> > + u8 color_fmt_mask;
> > + u8 color_depth_mask;
> > + u8 max_slices;;
> > + u8 max_slice_width;
> > + u8 line_buf_bit_depth;
> > + u8 bpp_precision_incr;
> > + int rc_buf_size;
> > +};
> > +
> > struct intel_dp {
> > i915_reg_t output_reg;
> > u32 DP;
> > @@ -1415,6 +1430,7 @@ struct intel_dp {
> > bool hobl_active;
> >
> > struct intel_dp_pcon_frl frl;
> > + struct intel_dp_pcon_dsc pcon_dsc;
> > };
> >
> > enum lspcon_vendor {
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index e6c4cb844e37..b4f8abaea607 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -3882,6 +3882,182 @@ cpt_set_link_train(struct intel_dp *intel_dp,
> > intel_de_posting_read(dev_priv, intel_dp->output_reg); }
> >
> > +void intel_dp_get_pcon_dsc_cap(struct intel_dp *intel_dp) {
> > + u8 buf;
> > + u8 rc_buf_blk_size;
> > + u8 max_slices = 0;
> > +
> > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > + struct intel_dp_pcon_dsc *pcon_dsc = _dp->pcon_dsc;
> > +
> > + if (drm_dp_dpcd_readb(_dp->aux, DP_PCON_DSC_ENCODER, )
> > < 0) {
> > + drm_err(>drm, "Failed to read
> > DP_PCON_DSC_ENCODER\n");
> > + return;
> > + }
> > + pcon_dsc->enc_support = buf & DP_PCON_DSC_ENCODER_SUPPORTED;
> > + pcon_dsc->pps_override_support = buf &
> > DP_PCON_DSC_PPS_ENC_OVERRIDE;
> > +
> > + if (drm_dp_dpcd_readb(_dp->aux, DP_PCON_DSC_VERSION, )
> > < 0) {
> > + drm_err(>drm, "Failed to read
> > DP_PCON_DSC_VERSION\n");
> > + return;
>
> If we fail here or in any of the subsequent calls below shouldn't we reset
> the dsc
> params saying DSC not supported. Else we may return with ex.
> pcon_dsc->enc_support = buf & DP_PCON_DSC_ENCODER_SUPPORTED which
> would ideally not be right.
>
> > + }
> > + pcon_dsc->version_major = (buf & DP_PCON_DSC_MAJOR_MASK) >>
> > + DP_PCON_DSC_MAJOR_SHIFT;
> > + pcon_dsc->version_minor = (buf & DP_PCON_DSC_MINOR_MASK) >>
> > + DP_PCON_DSC_MINOR_SHIFT;
> > +
> > + if (drm_dp_dpcd_readb(_dp->aux,
> > DP_PCON_DSC_RC_BUF_BLK_INFO, ) < 0) {
> > + drm_err(>drm, "Failed to read
> > DP_PCON_DSC_RC_BUF_BLK_INFO\n");
> > + return;
> > + }
> > +
> > + switch (buf & DP_PCON_DSC_RC_BUF_BLK_SIZE) {
> > + case DP_PCON_DSC_RC_BUF_BLK_1KB :
> > + rc_buf_blk_size = 1;
> > + break;
> > + case DP_PCON_DSC_RC_BUF_BLK_4KB :
> > + rc_buf_blk_size = 4;
> > + break;
> > + case DP_PCON_DSC_RC_BUF_BLK_16KB :
> > + rc_buf_blk_size = 16;
> > + break;
> > + case DP_PCON_DSC_RC_BUF_BLK_64KB :
> > + rc_buf_blk_size = 64;
> > + break;
> > + default :
> > + rc_buf_blk_size = 0;
> > + }
>
> It would be good if you create sub-functions for each of these aspects to
> make it
> more
RE: [RFC 11/13] drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 11/13] drm/i915: Read DSC capabilities of the HDMI2.1 PCON
> encoder
>
> This patch adds a helper function to read the DSC capabilities of the
> HDMI2.1 PCon encoder. It also adds a new structure to store these caps, which
> can then be used to get the PPS parameters for PCON-HDMI2.1 sink pair. Which
> inturn will be used to take a call to override the existing PPS-metadata, by
> either
> writing the entire new PPS metadata, or by writing only the PPS override
> parameters.
>
> Signed-off-by: Ankit Nautiyal
> ---
> .../drm/i915/display/intel_display_types.h| 16 ++
> drivers/gpu/drm/i915/display/intel_dp.c | 178 ++
> 2 files changed, 194 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 6c69922313d6..23282695a47f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1292,6 +1292,21 @@ struct intel_dp_pcon_frl {
> int trained_rate_gbps;
> };
>
> +struct intel_dp_pcon_dsc {
> + bool enc_support;
> + bool pps_override_support;
> + bool blk_prediction_support;
> + u8 version_major;
> + u8 version_minor;
> + u8 color_fmt_mask;
> + u8 color_depth_mask;
> + u8 max_slices;;
> + u8 max_slice_width;
> + u8 line_buf_bit_depth;
> + u8 bpp_precision_incr;
> + int rc_buf_size;
> +};
> +
> struct intel_dp {
> i915_reg_t output_reg;
> u32 DP;
> @@ -1415,6 +1430,7 @@ struct intel_dp {
> bool hobl_active;
>
> struct intel_dp_pcon_frl frl;
> + struct intel_dp_pcon_dsc pcon_dsc;
> };
>
> enum lspcon_vendor {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index e6c4cb844e37..b4f8abaea607 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3882,6 +3882,182 @@ cpt_set_link_train(struct intel_dp *intel_dp,
> intel_de_posting_read(dev_priv, intel_dp->output_reg); }
>
> +void intel_dp_get_pcon_dsc_cap(struct intel_dp *intel_dp) {
> + u8 buf;
> + u8 rc_buf_blk_size;
> + u8 max_slices = 0;
> +
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + struct intel_dp_pcon_dsc *pcon_dsc = _dp->pcon_dsc;
> +
> + if (drm_dp_dpcd_readb(_dp->aux, DP_PCON_DSC_ENCODER, )
> < 0) {
> + drm_err(>drm, "Failed to read
> DP_PCON_DSC_ENCODER\n");
> + return;
> + }
> + pcon_dsc->enc_support = buf & DP_PCON_DSC_ENCODER_SUPPORTED;
> + pcon_dsc->pps_override_support = buf &
> DP_PCON_DSC_PPS_ENC_OVERRIDE;
> +
> + if (drm_dp_dpcd_readb(_dp->aux, DP_PCON_DSC_VERSION, )
> < 0) {
> + drm_err(>drm, "Failed to read
> DP_PCON_DSC_VERSION\n");
> + return;
If we fail here or in any of the subsequent calls below shouldn't we reset the
dsc params saying DSC not
supported. Else we may return with ex.
pcon_dsc->enc_support = buf & DP_PCON_DSC_ENCODER_SUPPORTED
which would ideally not be right.
> + }
> + pcon_dsc->version_major = (buf & DP_PCON_DSC_MAJOR_MASK) >>
> + DP_PCON_DSC_MAJOR_SHIFT;
> + pcon_dsc->version_minor = (buf & DP_PCON_DSC_MINOR_MASK) >>
> + DP_PCON_DSC_MINOR_SHIFT;
> +
> + if (drm_dp_dpcd_readb(_dp->aux,
> DP_PCON_DSC_RC_BUF_BLK_INFO, ) < 0) {
> + drm_err(>drm, "Failed to read
> DP_PCON_DSC_RC_BUF_BLK_INFO\n");
> + return;
> + }
> +
> + switch (buf & DP_PCON_DSC_RC_BUF_BLK_SIZE) {
> + case DP_PCON_DSC_RC_BUF_BLK_1KB :
> + rc_buf_blk_size = 1;
> + break;
> + case DP_PCON_DSC_RC_BUF_BLK_4KB :
> + rc_buf_blk_size = 4;
> + break;
> + case DP_PCON_DSC_RC_BUF_BLK_16KB :
> + rc_buf_blk_size = 16;
> + break;
> + case DP_PCON_DSC_RC_BUF_BLK_64KB :
> + rc_buf_blk_size = 64;
> + break;
> + default :
> + rc_buf_blk_size = 0;
> + }
It would be good if you create sub-functions for each of these aspects to make
it more readable.
> + if (drm_dp_dpcd_readb(_dp->aux, DP_PCON_DSC_RC_BUF_SIZE,
> ) < 0) {
> + drm_err(>drm, "Failed to read
> DP_PCON_DSC_RC_BUF_SIZE\n");
> + return;
> + }
> + /* storing rc_buf_size in bytes */
> + pcon_dsc->rc_buf_size = (buf + 1) * rc_buf_blk_size * 1024;
> +
> + if (drm_dp_dpcd_readb(_dp->aux, DP_PCON_DSC_SLICE_CAP_2,
> ) < 0) {
> + drm_err(>drm, "Failed to read
> DP_PCON_DSC_SLICE_CAP_2\n");
> + return;
> + }
> + if (buf &
RE: [RFC 10/13] drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 10/13] drm/dp_helper: Add support for Configuring DSC for
> HDMI2.1 Pcon
>
> This patch adds registers for getting DSC encoder capability for a HDMI2.1
> PCon.
> It also addes helper functions to configure DSC between the PCON and HDMI2.1
> sink.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/drm_dp_helper.c | 93 +++
> include/drm/drm_dp_helper.h | 109
> 2 files changed, 202 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c index 33a4ac2fb225..f10a9c2d6f04 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -2929,3 +2929,96 @@ void drm_dp_pcon_hdmi_frl_link_error_count(struct
> drm_dp_aux *aux,
> }
> }
> EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
> +
> +static
> +int drm_dp_pcon_configure_dsc_enc(struct drm_dp_aux *aux, u8
> +pps_buf_config) {
> + u8 buf = 0;
> + int ret;
> +
> + buf |= DP_PCON_ENABLE_DSC_ENCODER;
Directly assign it.
> + if (pps_buf_config <= DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER) {
> + buf &= ~DP_PCON_ENCODER_PPS_OVERRIDE_MASK;
> + buf |= pps_buf_config << 2;
> + }
> +
> + ret = drm_dp_dpcd_writeb(aux,
> DP_PROTOCOL_CONVERTER_CONTROL_2, buf);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +/**
> + * drm_dp_pcon_pps_default() - Let PCON fill the default pps parameters
> + * for DSC1.2 between PCON & HDMI2.1 sink
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns 0 on success, else returns negative error code.
> + * */
> +int drm_dp_pcon_pps_default(struct drm_dp_aux *aux) {
> + int ret;
> +
> + ret = drm_dp_pcon_configure_dsc_enc(aux,
> DP_PCON_ENC_PPS_OVERRIDE_DISABLED);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_pps_default);
> +
> +/**
> + * drm_dp_pcon_pps_override_buf() - Configure PPS encoder override
> +buffer for
> + * HDMI sink
> + * @aux: DisplayPort AUX channel
> + * @pps_buf: 128 bytes to be written into PPS buffer for HDMI sink by PCON.
> + *
> + * Returns 0 on success, else returns negative error code.
> + * */
> +int drm_dp_pcon_pps_override_buf(struct drm_dp_aux *aux, u8
> +pps_buf[128]) {
> + int ret;
> +
> + ret = drm_dp_dpcd_write(aux, DP_PCON_HDMI_PPS_OVERRIDE_BASE,
> _buf, 128);
> + if (ret < 0)
> + return ret;
> +
> + ret = drm_dp_pcon_configure_dsc_enc(aux,
> DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_pps_override_buf);
> +
> +/*
> + * drm_dp_pcon_pps_override_param() - Write PPS parameters to DSC
> +encoder
> + * override registers
> + * @aux: DisplayPort AUX channel
> + * @pps_param: 3 Parameters (2 Bytes each) : Slice Width, Slice Height,
> + * bits_per_pixel.
> + *
> + * Returns 0 on success, else returns negative error code.
> + * */
> +int drm_dp_pcon_pps_override_param(struct drm_dp_aux *aux, u8
> +pps_param[6]) {
> + int ret;
> +
> + ret = drm_dp_dpcd_write(aux,
> DP_PCON_HDMI_PPS_OVRD_SLICE_HEIGHT, _param[0], 2);
> + if (ret < 0)
> + return ret;
> + ret = drm_dp_dpcd_write(aux,
> DP_PCON_HDMI_PPS_OVRD_SLICE_WIDTH, _param[1], 2);
> + if (ret < 0)
> + return ret;
> + ret = drm_dp_dpcd_write(aux, DP_PCON_HDMI_PPS_OVRD_BPP,
> _param[2], 2);
> + if (ret < 0)
> + return ret;
> +
> + ret = drm_dp_pcon_configure_dsc_enc(aux,
> DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_pps_override_param);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index
> eb26c86dc8ca..3de022d4a65e 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -441,6 +441,83 @@ struct drm_device;
> # define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
> # define DP_FEC_BIT_ERROR_COUNT_CAP (1 << 3)
>
> +/* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
> +#define DP_PCON_DSC_ENCODER 0x092
> +# define DP_PCON_DSC_ENCODER_SUPPORTED (1 << 0)
> +# define DP_PCON_DSC_PPS_ENC_OVERRIDE (1 << 1)
> +
> +/* DP-HDMI2.1 PCON DSC Version */
> +#define DP_PCON_DSC_VERSION 0x093
> +# define DP_PCON_DSC_MAJOR_MASK (0xF << 0)
> +# define DP_PCON_DSC_MINOR_MASK (0xF << 4)
> +# define DP_PCON_DSC_MAJOR_SHIFT 0
> +# define DP_PCON_DSC_MINOR_SHIFT 4
> +
> +/* DP-HDMI2.1 PCON DSC RC Buffer block size */
> +#define DP_PCON_DSC_RC_BUF_BLK_INFO 0x094
> +# define
RE: [RFC 09/13] drm/edid: Parse DSC1.2 cap fields from HFVSDB block
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 09/13] drm/edid: Parse DSC1.2 cap fields from HFVSDB block
Move this also to beginning of series along with all DRM helpers.
> This patch parses HFVSDB fields for DSC1.2 capabilities of an
> HDMI2.1 sink. These fields are required by a source to understand the DSC
> capability of the sink, to set appropriate PPS parameters, before transmitting
> compressed data stream.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/drm_edid.c | 19 +++
> include/drm/drm_connector.h | 32
> 2 files changed, 51 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> 8afb136e73f5..feee19657a7a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4889,10 +4889,29 @@ static void
> drm_parse_hdmi_21_additional_fields(struct drm_connector *connector, {
> struct drm_hdmi_info *hdmi = >display_info.hdmi;
> u8 max_frl_rate;
> + u8 dsc_max_frl_rate;
>
> max_frl_rate = db[7] & DRM_EDID_MAX_FRL_RATE_MASK;
> drm_get_max_frl_rate(max_frl_rate, >max_lanes,
>>max_frl_rate_per_lane);
> +
> + hdmi->dsc_1p2 = db[11] & DRM_EDID_DSC_1P2;
We should right shift them as well to get right values.
> +hdmi->dsc_native_420 = db[11] & DRM_EDID_DSC_NATIVE_420;
Same here. Also Alignment is off.
> + hdmi->dsc_all_bpp = db[11] & DRM_EDID_DSC_ALL_BPP;
> +
> + if (db[11] & DRM_EDID_DSC_16BPC)
> + hdmi->dsc_bpc_supported = 16;
> + else if (db[11] & DRM_EDID_DSC_12BPC)
> + hdmi->dsc_bpc_supported = 12;
> + else if (db[11] & DRM_EDID_DSC_10BPC)
> + hdmi->dsc_bpc_supported = 10;
> + else
> + hdmi->dsc_bpc_supported = 0;
> +
> + dsc_max_frl_rate = db[12] & DRM_EDID_DSC_MAX_FRL_RATE;
This will not give correct value. Fix it.
> + drm_get_max_frl_rate(dsc_max_frl_rate, >dsc_max_lanes,
> + >dsc_max_frl_rate_per_lane);
> + hdmi->dsc_total_chunk_kbytes = db[13] &
> +DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
> }
>
> static void drm_parse_ycbcr420_deep_color_info(struct drm_connector
> *connector, diff --git a/include/drm/drm_connector.h
> b/include/drm/drm_connector.h index f351bf10c076..7100012f9c0f 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -213,6 +213,38 @@ struct drm_hdmi_info {
>
> /** @max_lanes: supported by sink */
> u8 max_lanes;
> +
> + /** @dsc_1p2: flag for dsc1.2 support by sink */
> + bool dsc_1p2;
Add a struct for all these HDMI dsc params.
> +
> + /** @dsc_native_420: Does sink support DSC with 4:2:0 compression */
> + bool dsc_native_420;
> +
> + /**
> + * @dsc_all_bpp: Does sink support all bpp with 4:4:4: or 4:2:2
> + * compressed formats
> + */
> + bool dsc_all_bpp;
> +
> + /**
> + * @dsc_bpc_supported: compressed bpc supported by sink : 10, 12 or 16
> bpc
> + */
> + u8 dsc_bpc_supported;
> +
> + /** @dsc_max_slices: maximum number of Horizontal slices supported
> by */
> + u8 dsc_max_slices;
> +
> + /** @dsc_clk_per_slice : max pixel clock in MHz supported per slice */
> + u8 dsc_clk_per_slice;
> +
> + /** @dsc_max_lanes : dsc max lanes supported for Fixed rate Link
> training */
> + u8 dsc_max_lanes;
> +
> + /** @dsc_max_frl_rate_per_lane : maximum frl rate with DSC per lane */
> + u8 dsc_max_frl_rate_per_lane;
> +
> + /** @dsc_total_chunk_kbytes: max size of chunks in KBs supported per
> line*/
> + u8 dsc_total_chunk_kbytes;
> };
>
> /**
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC 08/13] drm/i915: Add support for enabling link status and recovery
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 08/13] drm/i915: Add support for enabling link status and
> recovery
>
> From: Swati Sharma
>
> In this patch enabled support for link status and recovery in i915 driver.
> HDMI
> link loss indication to upstream DP source is indicated via IRQ_HPD. This is
> followed by reading of HDMI link configuration status
> (HDMI_TX_LINK_ACTIVE_STATUS). If the PCON → HDMI 2.1 link status is off;
> reinitiate frl link training to recover.
> Also, HDMI FRL link error count range for each individual FRL active lane is
> indicated by DOWNSTREAM_HDMI_ERROR_STATUS_LN registers.
>
> Signed-off-by: Swati Sharma
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 47 +++--
> 1 file changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 668165dd2b1a..e6c4cb844e37 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5955,6 +5955,29 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> return link_ok;
> }
>
> +static void
> +intel_dp_handle_hdmi_link_status_change(struct intel_dp *intel_dp) {
> + bool is_active;
> + u8 buf = 0;
> +
> + is_active = drm_dp_pcon_hdmi_link_active(_dp->aux);
> + if (intel_dp->frl.is_trained && !is_active) {
> + if (drm_dp_dpcd_readb(_dp->aux,
> DP_PCON_HDMI_LINK_CONFIG_1, ) < 0)
> + return;
> +
> + buf &= ~DP_PCON_ENABLE_HDMI_LINK;
> + if (drm_dp_dpcd_writeb(_dp->aux,
> DP_PCON_HDMI_LINK_CONFIG_1, buf) < 0)
> + return;
> +
> + intel_dp->frl.is_trained = false;
> + intel_dp->frl.trained_rate_gbps = 0;
> +
> + intel_dp_check_frl_training(intel_dp);
> + drm_dp_pcon_hdmi_frl_link_error_count(_dp->aux,
> _dp->attached_connector->base);
Just printing the error here may not help in recovery. If FRL is failing may be
a TMDS fallback should be
attempted. Also error count should be returned instead of just a print.
> + }
> +}
> +
> static bool
> intel_dp_needs_link_retrain(struct intel_dp *intel_dp) { @@ -6320,7 +6343,7
> @@ intel_dp_hotplug(struct intel_encoder *encoder,
> return state;
> }
>
> -static void intel_dp_check_service_irq(struct intel_dp *intel_dp)
> +static void intel_dp_check_device_service_irq(struct intel_dp
> +*intel_dp)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> u8 val;
> @@ -6344,6 +6367,23 @@ static void intel_dp_check_service_irq(struct intel_dp
> *intel_dp)
> drm_dbg_kms(>drm, "Sink specific irq unhandled\n"); }
>
> +static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
> +{
> + u8 val;
> +
> + if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
> + return;
> +
> + if (drm_dp_dpcd_readb(_dp->aux,
> + DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 ||
> !val)
An error message would be handy here.
> + return;
> +
> + drm_dp_dpcd_writeb(_dp->aux,
> DP_LINK_SERVICE_IRQ_VECTOR_ESI0,
> +val);
Check for error message here.
> +
> + if (val & HDMI_LINK_STATUS_CHANGED)
> + intel_dp_handle_hdmi_link_status_change(intel_dp);
> +}
> +
> /*
> * According to DP spec
> * 5.1.2:
> @@ -6383,7 +6423,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
> return false;
> }
>
> - intel_dp_check_service_irq(intel_dp);
> + intel_dp_check_device_service_irq(intel_dp);
> + intel_dp_check_link_service_irq(intel_dp);
>
> /* Handle CEC interrupts, if any */
> drm_dp_cec_irq(_dp->aux);
> @@ -6815,7 +6856,7 @@ intel_dp_detect(struct drm_connector *connector,
> to_intel_connector(connector)->detect_edid)
> status = connector_status_connected;
>
> - intel_dp_check_service_irq(intel_dp);
> + intel_dp_check_device_service_irq(intel_dp);
>
> out:
> if (status != connector_status_connected && !intel_dp->is_mst)
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC 07/13] drm/dp_helper: Add support for link status and link recovery
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 07/13] drm/dp_helper: Add support for link status and link
> recovery
Move this in the start of the series along with rest of the generic DRM helpers.
> From: Swati Sharma
>
> This patch adds support for link status and link recovery. There are specific
> DPCD’s defined for link status check and recovery in case of any issues. PCON
> will
> communicate the same using an IRQ_HPD to source. HDMI sink would have
> indicated the same to PCON using SCDC interrupt mechanism. While source can
> always read final HDMI sink’s status using I2C over AUX, it’s easier and
> faster to
> read the PCON’s already read HDMI sink’s status registers.
>
> Signed-off-by: Swati Sharma
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/drm_dp_helper.c | 33 +
> include/drm/drm_dp_helper.h | 16
> 2 files changed, 49 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c index df858533dbf7..33a4ac2fb225 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -2896,3 +2896,36 @@ int drm_dp_pcon_hdmi_link_mode(struct
> drm_dp_aux *aux, u8 *frl_trained_mask)
> return mode;
> }
> EXPORT_SYMBOL(drm_dp_pcon_hdmi_link_mode);
> +
> +void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
> +struct drm_connector *connector) {
This just prints a message if error counts are detected. There isn't any
recovery here.
May be you should re-phrase the patch header and description to reflect the
same.
Also what will be the usage of this just prints a message, may be return the
error to caller
to plan a recovery or link reset .
> + u8 buf, error_count;
> + int i, num_error;
> + struct drm_hdmi_info *hdmi = >display_info.hdmi;
> +
> + for (i = 0; i < hdmi->max_lanes; i++)
> + {
> + if (drm_dp_dpcd_readb(aux,
> DP_PCON_HDMI_ERROR_STATUS_LN0 + i , ) < 0)
> + return;
> +
> + error_count = buf & DP_PCON_HDMI_ERROR_COUNT_MASK;
> +
> + switch(error_count) {
Alignment is off.
> + case DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS:
> + num_error = 100;
> + break;
> + case DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS:
> + num_error = 10;
> + break;
> + case DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS:
> + num_error = 3;
> + break;
> + default:
> + num_error = 0;
> + }
> +
> + DRM_ERROR("More than %d errors since the last read for lane
> %d", num_error, i);
> + }
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index
> d6f79b2d1287..eb26c86dc8ca 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -946,6 +946,11 @@ struct drm_device;
> # define DP_CEC_IRQ (1 << 2)
>
> #define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */
> +# define RX_CAP_CHANGED (1 << 0)
> +# define LINK_STATUS_CHANGED (1 << 1)
> +# define STREAM_STATUS_CHANGED (1 << 2)
> +# define HDMI_LINK_STATUS_CHANGED(1 << 3)
> +# define CONNECTED_OFF_ENTRY_REQUESTED (1 << 4)
>
> #define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */
> # define DP_PSR_LINK_CRC_ERROR (1 << 0)
> @@ -1130,6 +1135,16 @@ struct drm_device;
> #define DP_PROTOCOL_CONVERTER_CONTROL_2 0x3052 /* DP 1.3
> */
> # define DP_CONVERSION_TO_YCBCR422_ENABLE(1 << 0) /* DP 1.3 */
>
> +/* PCON Downstream HDMI ERROR Status per Lane */
> +#define DP_PCON_HDMI_ERROR_STATUS_LN0 0x3037
> +#define DP_PCON_HDMI_ERROR_STATUS_LN1 0x3038
> +#define DP_PCON_HDMI_ERROR_STATUS_LN2 0x3039
> +#define DP_PCON_HDMI_ERROR_STATUS_LN3 0x303A
> +# define DP_PCON_HDMI_ERROR_COUNT_MASK (0x7 << 0)
> +# define DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS (1 << 0)
> +# define DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS (1 << 1)
> +# define DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS (1 << 2)
> +
> /* HDCP 1.3 and HDCP 2.2 */
> #define DP_AUX_HDCP_BKSV 0x68000
> #define DP_AUX_HDCP_RI_PRIME 0x68005
> @@ -2047,4 +2062,5 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux);
>
> bool drm_dp_pcon_hdmi_link_active(struct drm_dp_aux *aux); int
> drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux, u8 *frl_trained_mask);
> +void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
> +struct drm_connector *connector);
Leave a blank line.
> #endif /* _DRM_DP_HELPER_H_ */
> --
> 2.17.1
RE: [RFC 06/13] drm/i915: Check for FRL training before DP Link training
> -Original Message- > From: Nautiyal, Ankit K > Sent: Thursday, October 15, 2020 4:23 PM > To: intel-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ; > Kulkarni, Vandita ; ville.syrj...@linux.intel.com; > Sharma, Swati2 > Subject: [RFC 06/13] drm/i915: Check for FRL training before DP Link training > > This patch calls functions to check FRL training requirements for an HDMI2.1 > sink, > when connected through PCON. > The call is made before the DP link training. In case FRL is not required or > failure > during FRL training, the TMDS mode is selected for the pcon. > > Signed-off-by: Ankit Nautiyal > --- > drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ > drivers/gpu/drm/i915/display/intel_dp.c | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > b/drivers/gpu/drm/i915/display/intel_ddi.c > index bb0b9930958f..1834e5de60a7 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > @@ -3484,6 +3484,8 @@ static void tgl_ddi_pre_enable_dp(struct > intel_atomic_state *state, > if (!is_mst) > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); > > + intel_dp_check_frl_training(intel_dp); Good to move it near start_link_training to stay consistent with rest of the calls. > + > intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true); > /* >* DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > index c1342b5e7781..668165dd2b1a 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -4206,6 +4206,7 @@ static void intel_enable_dp(struct intel_atomic_state > *state, > > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); > intel_dp_configure_protocol_converter(intel_dp); > + intel_dp_check_frl_training(intel_dp); > intel_dp_start_link_train(intel_dp, pipe_config); > intel_dp_stop_link_train(intel_dp, pipe_config); > > @@ -6127,6 +6128,7 @@ int intel_dp_retrain_link(struct intel_encoder > *encoder, > !intel_dp_mst_is_master_trans(crtc_state)) > continue; > > + intel_dp_check_frl_training(intel_dp); > intel_dp_start_link_train(intel_dp, crtc_state); > intel_dp_stop_link_train(intel_dp, crtc_state); > break; > -- > 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC 05/13] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 05/13] drm/i915: Add support for starting FRL training for
> HDMI2.1
> via PCON
>
> This patch adds functions to start FRL training for an HDMI2.1 sink,
> connected via
> a PCON as a DP branch device.
> This patch also adds a new structure for storing frl training related data,
> when
> FRL training is completed.
>
> Signed-off-by: Ankit Nautiyal
> ---
> .../drm/i915/display/intel_display_types.h| 7 +
> drivers/gpu/drm/i915/display/intel_dp.c | 200 ++
> drivers/gpu/drm/i915/display/intel_dp.h | 2 +
> 3 files changed, 209 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index e2f58d0575a2..6c69922313d6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1287,6 +1287,11 @@ struct intel_dp_compliance {
> u8 test_lane_count;
> };
>
> +struct intel_dp_pcon_frl {
> + bool is_trained;
> + int trained_rate_gbps;
> +};
> +
> struct intel_dp {
> i915_reg_t output_reg;
> u32 DP;
> @@ -1408,6 +1413,8 @@ struct intel_dp {
>
> bool hobl_failed;
> bool hobl_active;
> +
> + struct intel_dp_pcon_frl frl;
> };
>
> enum lspcon_vendor {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index cd6934f28f32..c1342b5e7781 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2885,6 +2885,9 @@ static void intel_dp_prepare(struct intel_encoder
> *encoder,
> intel_dp->DP |= DP_PIPE_SEL_CHV(crtc->pipe);
> else
> intel_dp->DP |= DP_PIPE_SEL(crtc->pipe);
> +
> + intel_dp->frl.is_trained = false;
> + intel_dp->frl.trained_rate_gbps = 0;
> }
> }
>
> @@ -3781,6 +3784,9 @@ static void intel_disable_dp(struct intel_atomic_state
> *state,
> intel_edp_backlight_off(old_conn_state);
> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> intel_edp_panel_off(intel_dp);
> +
> + intel_dp->frl.is_trained = false;
> + intel_dp->frl.trained_rate_gbps = 0;
> }
>
> static void g4x_disable_dp(struct intel_atomic_state *state, @@ -3876,6
> +3882,200 @@ cpt_set_link_train(struct intel_dp *intel_dp,
> intel_de_posting_read(dev_priv, intel_dp->output_reg); }
>
> +static int intel_dp_get_max_rate_gbps(struct intel_dp *intel_dp) {
> + int max_link_clock, max_lanes, max_rate_khz, max_rate_gbps;
> +
> + max_link_clock = intel_dp_max_link_rate(intel_dp);
> + max_lanes = intel_dp_max_lane_count(intel_dp);
> + max_rate_khz = intel_dp_max_data_rate(max_link_clock, max_lanes);
> + max_rate_gbps = 8 * DIV_ROUND_UP(max_rate_khz, 100);
> +
> + return max_rate_gbps;
> +}
> +
> +static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask) {
> + int bw_gbps[] = {9, 18, 24, 32, 40, 48};
> + int i;
> +
> + for (i = ARRAY_SIZE(bw_gbps) - 1; i >= 0; i--) {
> + if (frl_bw_mask & (1 << i))
> + return bw_gbps[i];
> + }
> + return 0;
> +}
> +
> +static int intel_dp_pcon_set_frl_mask(int max_frl) {
> + int max_frl_mask = 0;
> +
> + switch (max_frl) {
> + case 48:
> + max_frl_mask |= DP_PCON_FRL_BW_MASK_48GBPS;
Just say it as return DP_PCON_FRL_BW_MASK_48GBPS.
Do it universally.
> + break;
> + case 40:
> + max_frl_mask |= DP_PCON_FRL_BW_MASK_40GBPS;
> + break;
> + case 32:
> + max_frl_mask |= DP_PCON_FRL_BW_MASK_32GBPS;
> + break;
> + case 24:
> + max_frl_mask |= DP_PCON_FRL_BW_MASK_24GBPS;
> + break;
> + case 18:
> + max_frl_mask |= DP_PCON_FRL_BW_MASK_18GBPS;
> + break;
> + case 9:
> + max_frl_mask |= DP_PCON_FRL_BW_MASK_9GBPS;
> + break;
> + default:
> + max_frl_mask = 0;
> + }
> +
> + return max_frl_mask;
> +}
> +
> +static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp) {
> + struct intel_connector *intel_connector = intel_dp->attached_connector;
> + struct drm_connector *connector = _connector->base;
> +
> + return (connector->display_info.hdmi.max_frl_rate_per_lane *
> + connector->display_info.hdmi.max_lanes);
> +}
> +
> +static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
> +{ #define PCON_EXTENDED_TRAIN_MODE true#define
> PCON_CONCURRENT_MODE
> +true #define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE #define
> +PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE #define
Don't use true
Re: [PATCH 1/2] Fonts: Support FONT_EXTRA_WORDS macros for font_6x8
On Sun, Oct 18, 2020 at 10:45 PM Peilin Ye wrote: > > On Sun, Oct 18, 2020 at 10:33:11PM +0200, Daniel Vetter wrote: > > On Sun, Oct 18, 2020 at 10:18 PM Peilin Ye wrote: > > > 2/2 is just updating the fb documentation: > > > > > > [PATCH 2/2] docs: fb: Add font_6x8 to available built-in fonts > > > https://lore.kernel.org/lkml/717bb41dda8e2ed615f3faadfbc3e215de726d38.1603037079.git.yepeilin...@gmail.com/ > > > > > > I did `git format-patch -2 --thread=deep`, did I do something wrong when > > > sending it? > > > > No idea, it just didn't arrive anywhere I could find. And I did get > > your previous patch series. Maybe just try again with dri-devel > > included and hope it works then? > > I'm confused, I see it on LKML in the link above. Sure I'll resend soon. My brain didn't work, sorry about the confusion. I'll pick up the patches tomorrow, probably not a good idea I do anything more today :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC 04/13] drm/i915: Capture max frl rate for PCON in dfp cap structure
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 04/13] drm/i915: Capture max frl rate for PCON in dfp cap
> structure
>
> HDMI2.1 PCON advertises Max FRL bandwidth supported by the PCON and by the
> sink.
>
> This patch captures these in dfp cap structure in intel_dp and uses these to
> prune connector modes that cannot be supported by the PCON and sink FRL
> bandwidth.
>
> Signed-off-by: Ankit Nautiyal
> ---
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 33 +--
> 2 files changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 0b5df8e44966..e2f58d0575a2 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1398,6 +1398,7 @@ struct intel_dp {
> struct {
> int min_tmds_clock, max_tmds_clock;
> int max_dotclock;
> + int pcon_max_frl, sink_max_frl;
Append it with bw or rate.
> u8 max_bpc;
> bool ycbcr_444_to_420;
> } dfp;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0902a9aeeda1..cd6934f28f32 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -683,6 +683,24 @@ intel_dp_mode_valid_downstream(struct
> intel_connector *connector,
> const struct drm_display_info *info = >base.display_info;
> int tmds_clock;
>
> + /* If PCON and HDMI2.1 sink both support FRL MODE, check FRL
Use multi line comment style.
> + * bandwidth constraints.
> + */
> + if (intel_dp->dfp.pcon_max_frl) {
> + int target_bw;
> + int max_frl_bw;
> + int bpp = intel_dp_mode_min_output_bpp(>base,
> mode);
> +
> + target_bw = bpp * DIV_ROUND_UP(target_clock, 100);
To avoid any roundup errors, it would be good to multiple max_frl_bw by 100
than dividing target_clock
> +
> + max_frl_bw = min(intel_dp->dfp.pcon_max_frl,
> + intel_dp->dfp.sink_max_frl);
> + if (target_bw > max_frl_bw)
> + return MODE_CLOCK_HIGH;
> +
> + return MODE_OK;
> + }
> +
> if (intel_dp->dfp.max_dotclock &&
> target_clock > intel_dp->dfp.max_dotclock)
> return MODE_CLOCK_HIGH;
> @@ -6383,13 +6401,21 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
>intel_dp->downstream_ports,
>edid);
>
> + intel_dp->dfp.pcon_max_frl =
> + drm_dp_get_pcon_max_frl_bw(intel_dp->dpcd,
> +intel_dp->downstream_ports);
> +
> + intel_dp->dfp.sink_max_frl =
> +drm_dp_get_hdmi_max_frl_bw(_dp->aux);
> +
> drm_dbg_kms(>drm,
> - "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d,
> TMDS clock %d-%d\n",
> + "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d,
> TMDS clock
> +%d-%d, PCON Max FRL BW %dGbps, Sink Max FRL BW %dGbps\n",
> connector->base.base.id, connector->base.name,
> intel_dp->dfp.max_bpc,
> intel_dp->dfp.max_dotclock,
> intel_dp->dfp.min_tmds_clock,
> - intel_dp->dfp.max_tmds_clock);
> + intel_dp->dfp.max_tmds_clock,
> + intel_dp->dfp.pcon_max_frl,
> + intel_dp->dfp.sink_max_frl);
> }
>
> static void
> @@ -6479,6 +6505,9 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> intel_dp->dfp.min_tmds_clock = 0;
> intel_dp->dfp.max_tmds_clock = 0;
>
> + intel_dp->dfp.pcon_max_frl = 0;
> + intel_dp->dfp.sink_max_frl = 0;
> +
> intel_dp->dfp.ycbcr_444_to_420 = false;
> connector->base.ycbcr_420_allowed = false; }
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC 03/13] drm/dp_helper: Add FRL training support for a DP-HDMI2.1 PCON
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 03/13] drm/dp_helper: Add FRL training support for a DP-HDMI2.1
> PCON
You can name this patch as "Add Helpers for FRL Link Training support for
DP-HDMI2.1 PCON"
> This patch adds support for configuring a PCON device, connected as a DP
> branched device to enable FRL Link training with a HDMI2.1 + sink.
>
> v2: Minor changes:
> -removed unnecessary argument supplied to a drm helper function.
> -fixed return value for max frl read from pcon.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/drm_dp_helper.c | 305
> include/drm/drm_dp_helper.h | 80 +
> 2 files changed, 385 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c index 14ddf28ecac0..df858533dbf7 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -2591,3 +2591,308 @@ void drm_dp_vsc_sdp_log(const char *level, struct
> device *dev, #undef DP_SDP_LOG } EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
> +
> +/**
> + * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: port capabilities
> + *
> + * Returns maximum frl bandwidth supported by PCON in GBPS,
> + * returns 0 if not supported.
> + **/
> +int drm_dp_get_pcon_max_frl_bw(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4])
> +{
> + int bw;
> + u8 buf;
> +
> + buf = port_cap[2];
> + bw = buf & DP_PCON_MAX_FRL_BW;
> +
> + switch (bw) {
> + case DP_PCON_MAX_9GBPS:
> + return 9;
> + case DP_PCON_MAX_18GBPS:
> + return 18;
> + case DP_PCON_MAX_24GBPS:
> + return 24;
> + case DP_PCON_MAX_32GBPS:
> + return 32;
> + case DP_PCON_MAX_40GBPS:
> + return 40;
> + case DP_PCON_MAX_48GBPS:
> + return 48;
> + case DP_PCON_MAX_0GBPS:
> + default:
> + return 0;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
> +
> +/**
> + * drm_dp_get_hdmi_max_frl_bw() - maximum frl supported by HDMI Sink
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns maximum frl bandwidth supported by HDMI in Gbps on success,
> + * returns 0, if not supported.
> + **/
> +int drm_dp_get_hdmi_max_frl_bw(struct drm_dp_aux *aux) {
s/hdmi/hdmi_sink/ will make it clear that we are referring to sink here.
> + u8 buf;
> + int bw, ret;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_SINK, );
> + if (ret < 0)
> + return 0;
> + bw = buf & DP_HDMI_SINK_LINK_BW;
> +
> + switch (bw) {
> + case DP_HDMI_SINK_BW_9GBPS:
> + return 9;
> + case DP_HDMI_SINK_BW_18GBPS:
> + return 18;
> + case DP_HDMI_SINK_BW_24GBPS:
> + return 24;
> + case DP_HDMI_SINK_BW_32GBPS:
> + return 32;
> + case DP_HDMI_SINK_BW_40GBPS:
> + return 40;
> + case DP_HDMI_SINK_BW_48GBPS:
> + return 48;
> + case DP_HDMI_SINK_BW_0GBPS:
> + default:
> + return 0;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_get_hdmi_max_frl_bw);
> +
> +/**
> + * drm_dp_pcon_frl_prepare() - Prepare PCON for FRL.
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns 0 if success, else returns negative error code.
> + **/
> +int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool
> +enable_frl_ready_hpd) {
> + int ret;
> + u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
> + DP_PCON_ENABLE_LINK_FRL_MODE;
> +
> + if (enable_frl_ready_hpd)
> + buf |= DP_PCON_ENABLE_HPD_READY;
> +
> + ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
> +
> +/**
> + * drm_dp_pcon_is_frl_ready() - Is PCON ready for FRL
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns true if success, else returns false.
> + **/
> +bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux) {
> + int ret;
> + u8 buf;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_TX_LINK_STATUS, );
> + if (ret < 0)
> + return false;
> +
> + if (buf & DP_PCON_FRL_READY)
> + return true;
> +
> + return false;
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
> +
> +/**
> + * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
> + * @aux: DisplayPort AUX channel
> + * max_frl_mask: mask for selecting the bandwidths supported by source,
@missing from variable and its not a mask here but an absolute value.
> + * to be tried by Pcon f/w.
> + * @concurrent_mode: true if concurrent mode or operation is required,
> + * false
Re: It appears drm-next TTM cleanup broke something . . .
Hi Kevin. On Sun, Oct 18, 2020 at 09:15:17PM +0200, Kevin Brace wrote: > As usual, I pulled in DRM repository code for an out of tree OpenChrome DRM > repository a few days ago. I know you have been working on and off on the openchrome driver for a long time now. Any chance we will see the driver submitted for upstream soon? Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2 RESEND] docs: fb: Add font_6x8 to available built-in fonts
Recently we added a new 6x8 font in commit e2028c8e6bf9 ("lib/fonts: add
font 6x8 for OLED display"). Add its name to the "compiled-in fonts"
list.
Signed-off-by: Peilin Ye
---
Resending +Cc: dri-devel, sorry if I spammed.
Documentation/fb/fbcon.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/fb/fbcon.rst b/Documentation/fb/fbcon.rst
index 9aad964b767c..57f66de2f7e1 100644
--- a/Documentation/fb/fbcon.rst
+++ b/Documentation/fb/fbcon.rst
@@ -81,7 +81,7 @@ C. Boot options
1. fbcon=font:
Select the initial font to use. The value 'name' can be any of the
- compiled-in fonts: 10x18, 6x10, 7x14, Acorn8x8, MINI4x6,
+ compiled-in fonts: 10x18, 6x10, 6x8, 7x14, Acorn8x8, MINI4x6,
PEARL8x8, ProFont6x11, SUN12x22, SUN8x16, TER16x32, VGA8x16, VGA8x8.
Note, not all drivers can handle font with widths not divisible by 8,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC 01/13] drm/edid: Add additional HFVSDB fields for HDMI2.1
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 01/13] drm/edid: Add additional HFVSDB fields for HDMI2.1
>
> From: Swati Sharma
>
> The HDMI2.1 extends HFVSBD (HDMI Forum Vendor Specific Data block) to have
Typo in HFVSDB
> fields related to newly defined methods of FRL (Fixed Rate Link) levels,
> number
> of lanes supported, DSC Color bit depth, VRR min/max, FVA (Fast Vactive), ALLM
> etc.
>
> This patch adds the new HFVSDB fields that are required for HDMI2.1.
>
> Signed-off-by: Sharma, Swati2
> Signed-off-by: Ankit Nautiyal
> ---
> include/drm/drm_edid.h | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index
> b27a0e2169c8..1cc5c2c73282 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -229,6 +229,36 @@ struct detailed_timing {
> DRM_EDID_YCBCR420_DC_36 | \
> DRM_EDID_YCBCR420_DC_30)
>
> +/* HDMI 2.1 additional fields */
> +#define DRM_EDID_MAX_FRL_RATE_MASK 0xf0
> +#define DRM_EDID_FAPA_START_LOCATION (1 << 0)
> +#define DRM_EDID_ALLM(1 << 1)
> +#define DRM_EDID_FVA (1 << 2)
> +
> +/* Deep Color specific */
> +#define DRM_EDID_DC_30BIT_420(1 << 0)
> +#define DRM_EDID_DC_36BIT_420(1 << 1)
> +#define DRM_EDID_DC_48BIT_420(1 << 2)
> +
> +/* VRR specific */
> +#define DRM_EDID_CNMVRR (1 << 3)
> +#define DRM_EDID_CINEMA_VRR (1 << 4)
> +#define DRM_EDID_MDELTA (1 << 5)
> +#define DRM_EDID_VRR_MAX_UPPER_MASK 0xc0
> +#define DRM_EDID_VRR_MAX_LOWER_MASK 0xff
> +#define DRM_EDID_VRR_MIN_MASK0x3f
> +
> +/* DSC specific */
> +#define DRM_EDID_DSC_10BPC (1 << 0)
> +#define DRM_EDID_DSC_12BPC (1 << 1)
> +#define DRM_EDID_DSC_16BPC (1 << 2)
> +#define DRM_EDID_DSC_ALL_BPP (1 << 3)
> +#define DRM_EDID_DSC_NATIVE_420 (1 << 6)
> +#define DRM_EDID_DSC_1P2 (1 << 7)
> +#define DRM_EDID_DSC_MAX_FRL_RATE0xf
This should be set as mask and made it as 0xf0
> +#define DRM_EDID_DSC_MAX_SLICES 0xf
> +#define DRM_EDID_DSC_TOTAL_CHUNK_KBYTES 0x3f
> +
> /* ELD Header Block */
> #define DRM_ELD_HEADER_BLOCK_SIZE4
>
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC 02/13] drm/edid: Parse MAX_FRL field from HFVSDB block
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Thursday, October 15, 2020 4:23 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [RFC 02/13] drm/edid: Parse MAX_FRL field from HFVSDB block
>
> From: Swati Sharma
>
> This patch parses MAX_FRL field to get the MAX rate in Gbps that the HDMI 2.1
> panel can support in FRL mode. Source need this field to determine the optimal
> rate between the source and sink during FRL training.
>
> Signed-off-by: Sharma, Swati2
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/drm_edid.c | 51 +
> include/drm/drm_connector.h | 6 +
> 2 files changed, 57 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> 631125b46e04..8afb136e73f5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4849,6 +4849,52 @@ static void drm_parse_vcdb(struct drm_connector
> *connector, const u8 *db)
> info->rgb_quant_range_selectable = true; }
>
> +static
> +void drm_get_max_frl_rate(int max_frl_rate, u8 *max_lanes, u8
> +*max_rate_per_lane) {
> + switch(max_frl_rate) {
> + case 1:
> + *max_lanes = 3;
> + *max_rate_per_lane = 3;
> + break;
> + case 2:
> + *max_lanes = 3;
> + *max_rate_per_lane = 6;
> + break;
> + case 3:
> + *max_lanes = 4;
> + *max_rate_per_lane = 6;
> + break;
> + case 4:
> + *max_lanes = 4;
> + *max_rate_per_lane = 8;
> + break;
> + case 5:
> + *max_lanes = 4;
> + *max_rate_per_lane = 10;
> + break;
> + case 6:
> + *max_lanes = 4;
> + *max_rate_per_lane = 12;
> + break;
> + case 0:
> + default:
> + *max_lanes = 0;
> + *max_rate_per_lane = 0;
> + }
> +}
> +
> +static void drm_parse_hdmi_21_additional_fields(struct drm_connector
> *connector,
> + const u8 *db)
> +{
> + struct drm_hdmi_info *hdmi = >display_info.hdmi;
> + u8 max_frl_rate;
> +
> + max_frl_rate = db[7] & DRM_EDID_MAX_FRL_RATE_MASK;
This seems wrong, we need to right shift this by 4 to get the max_frl_rate.
> + drm_get_max_frl_rate(max_frl_rate, >max_lanes,
> + >max_frl_rate_per_lane);
We can just pass the connecter and drm_get_max_frl_rate can fill the respective
fields.
> +}
> +
> static void drm_parse_ycbcr420_deep_color_info(struct drm_connector
> *connector,
> const u8 *db)
> {
> @@ -4902,6 +4948,11 @@ static void drm_parse_hdmi_forum_vsdb(struct
> drm_connector *connector,
> }
> }
>
> + if (hf_vsdb[7]) {
> + DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
> + drm_parse_hdmi_21_additional_fields(connector, hf_vsdb);
We can get rid of this extra wrapper.
> + }
> +
> drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb); }
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index
> 928136556174..f351bf10c076 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -207,6 +207,12 @@ struct drm_hdmi_info {
>
> /** @y420_dc_modes: bitmap of deep color support index */
> u8 y420_dc_modes;
> +
> + /** @max_frl_rate_per_lane: support fixed rate link */
> + u8 max_frl_rate_per_lane;
> +
> + /** @max_lanes: supported by sink */
> + u8 max_lanes;
> };
>
> /**
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] Fonts: Support FONT_EXTRA_WORDS macros for font_6x8
On Sun, Oct 18, 2020 at 10:33:11PM +0200, Daniel Vetter wrote: > On Sun, Oct 18, 2020 at 10:18 PM Peilin Ye wrote: > > 2/2 is just updating the fb documentation: > > > > [PATCH 2/2] docs: fb: Add font_6x8 to available built-in fonts > > https://lore.kernel.org/lkml/717bb41dda8e2ed615f3faadfbc3e215de726d38.1603037079.git.yepeilin...@gmail.com/ > > > > I did `git format-patch -2 --thread=deep`, did I do something wrong when > > sending it? > > No idea, it just didn't arrive anywhere I could find. And I did get > your previous patch series. Maybe just try again with dri-devel > included and hope it works then? I'm confused, I see it on LKML in the link above. Sure I'll resend soon. Peilin Ye ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] Fonts: Support FONT_EXTRA_WORDS macros for font_6x8
On Sun, Oct 18, 2020 at 10:18 PM Peilin Ye wrote:
>
> On Sun, Oct 18, 2020 at 10:09:06PM +0200, Daniel Vetter wrote:
> > Adding dri-devel too, not sure anyone is still listening on linux-fbdev.
>
> I see, thanks!
>
> > On Sun, Oct 18, 2020 at 8:13 PM Peilin Ye wrote:
> > >
> > > Recently, in commit 6735b4632def ("Fonts: Support FONT_EXTRA_WORDS macros
> > > for built-in fonts"), we wrapped each of our built-in data buffers in a
> > > `font_data` structure, in order to use the following macros on them, see
> > > include/linux/font.h:
> > >
> > > #define REFCOUNT(fd)(((int *)(fd))[-1])
> > > #define FNTSIZE(fd) (((int *)(fd))[-2])
> > > #define FNTCHARCNT(fd) (((int *)(fd))[-3])
> > > #define FNTSUM(fd) (((int *)(fd))[-4])
> > >
> > > #define FONT_EXTRA_WORDS 4
> > >
> > > Do the same thing to our new 6x8 font. For built-in fonts, currently we
> > > only use FNTSIZE(). Since this is only a temporary solution for an
> > > out-of-bounds issue in the framebuffer layer (see commit 5af08640795b
> > > ("fbcon: Fix global-out-of-bounds read in fbcon_get_font()")), all the
> > > three other fields are intentionally set to zero in order to discourage
> > > using these negative-indexing macros.
> > >
> > > Signed-off-by: Peilin Ye
> >
> > Patch looks good to me, but it says 1/2 and I can't find 2/2 anywhere,
> > not even on lore. Did that get lost?
>
> 2/2 is just updating the fb documentation:
>
> [PATCH 2/2] docs: fb: Add font_6x8 to available built-in fonts
> https://lore.kernel.org/lkml/717bb41dda8e2ed615f3faadfbc3e215de726d38.1603037079.git.yepeilin...@gmail.com/
>
> I did `git format-patch -2 --thread=deep`, did I do something wrong when
> sending it?
No idea, it just didn't arrive anywhere I could find. And I did get
your previous patch series. Maybe just try again with dri-devel
included and hope it works then?
-Daniel
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] Fonts: Support FONT_EXTRA_WORDS macros for font_6x8
On Sun, Oct 18, 2020 at 10:09:06PM +0200, Daniel Vetter wrote:
> Adding dri-devel too, not sure anyone is still listening on linux-fbdev.
I see, thanks!
> On Sun, Oct 18, 2020 at 8:13 PM Peilin Ye wrote:
> >
> > Recently, in commit 6735b4632def ("Fonts: Support FONT_EXTRA_WORDS macros
> > for built-in fonts"), we wrapped each of our built-in data buffers in a
> > `font_data` structure, in order to use the following macros on them, see
> > include/linux/font.h:
> >
> > #define REFCOUNT(fd)(((int *)(fd))[-1])
> > #define FNTSIZE(fd) (((int *)(fd))[-2])
> > #define FNTCHARCNT(fd) (((int *)(fd))[-3])
> > #define FNTSUM(fd) (((int *)(fd))[-4])
> >
> > #define FONT_EXTRA_WORDS 4
> >
> > Do the same thing to our new 6x8 font. For built-in fonts, currently we
> > only use FNTSIZE(). Since this is only a temporary solution for an
> > out-of-bounds issue in the framebuffer layer (see commit 5af08640795b
> > ("fbcon: Fix global-out-of-bounds read in fbcon_get_font()")), all the
> > three other fields are intentionally set to zero in order to discourage
> > using these negative-indexing macros.
> >
> > Signed-off-by: Peilin Ye
>
> Patch looks good to me, but it says 1/2 and I can't find 2/2 anywhere,
> not even on lore. Did that get lost?
2/2 is just updating the fb documentation:
[PATCH 2/2] docs: fb: Add font_6x8 to available built-in fonts
https://lore.kernel.org/lkml/717bb41dda8e2ed615f3faadfbc3e215de726d38.1603037079.git.yepeilin...@gmail.com/
I did `git format-patch -2 --thread=deep`, did I do something wrong when
sending it?
Thank you,
Peilin Ye
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] Fonts: Support FONT_EXTRA_WORDS macros for font_6x8
Adding dri-devel too, not sure anyone is still listening on linux-fbdev.
On Sun, Oct 18, 2020 at 8:13 PM Peilin Ye wrote:
>
> Recently, in commit 6735b4632def ("Fonts: Support FONT_EXTRA_WORDS macros
> for built-in fonts"), we wrapped each of our built-in data buffers in a
> `font_data` structure, in order to use the following macros on them, see
> include/linux/font.h:
>
> #define REFCOUNT(fd)(((int *)(fd))[-1])
> #define FNTSIZE(fd) (((int *)(fd))[-2])
> #define FNTCHARCNT(fd) (((int *)(fd))[-3])
> #define FNTSUM(fd) (((int *)(fd))[-4])
>
> #define FONT_EXTRA_WORDS 4
>
> Do the same thing to our new 6x8 font. For built-in fonts, currently we
> only use FNTSIZE(). Since this is only a temporary solution for an
> out-of-bounds issue in the framebuffer layer (see commit 5af08640795b
> ("fbcon: Fix global-out-of-bounds read in fbcon_get_font()")), all the
> three other fields are intentionally set to zero in order to discourage
> using these negative-indexing macros.
>
> Signed-off-by: Peilin Ye
Patch looks good to me, but it says 1/2 and I can't find 2/2 anywhere,
not even on lore. Did that get lost?
-Daniel
> ---
> lib/fonts/font_6x8.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/lib/fonts/font_6x8.c b/lib/fonts/font_6x8.c
> index e06447788418..700039a9ceae 100644
> --- a/lib/fonts/font_6x8.c
> +++ b/lib/fonts/font_6x8.c
> @@ -3,8 +3,8 @@
>
> #define FONTDATAMAX 2048
>
> -static const unsigned char fontdata_6x8[FONTDATAMAX] = {
> -
> +static struct font_data fontdata_6x8 = {
> + { 0, 0, FONTDATAMAX, 0 }, {
> /* 0 0x00 '^@' */
> 0x00, /* 00 */
> 0x00, /* 00 */
> @@ -2564,13 +2564,13 @@ static const unsigned char fontdata_6x8[FONTDATAMAX]
> = {
> 0x00, /* 00 */
> 0x00, /* 00 */
> 0x00, /* 00 */
> -};
> +} };
>
> const struct font_desc font_6x8 = {
> .idx= FONT6x8_IDX,
> .name = "6x8",
> .width = 6,
> .height = 8,
> - .data = fontdata_6x8,
> + .data = fontdata_6x8.data,
> .pref = 0,
> };
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: It appears drm-next TTM cleanup broke something . . .
On Mon, 19 Oct 2020 at 05:15, Kevin Brace wrote: > > Hi Dave, > > It is a little urgent, so I am writing this right now. > As usual, I pulled in DRM repository code for an out of tree OpenChrome DRM > repository a few days ago. > While going through the changes I need to make to OpenChrome DRM to compile > with the latest Linux kernel, I noticed that ttm_bo_init_mm() was > discontinued, and it was replaced with ttm_range_man_init(). > ttm_range_man_init() has a parameter called "bool use_tt", but honestly, I do > not think it is functioning correctly. > If I keep "ttm_tt_create" member of ttm_bo_driver struct null by not > specifying it, TTM still tries to call it, and crashes due to a null pointer > access. > The workaround I found so far is to specify the "ttm_tt_create" member by > copying bo_driver_ttm_tt_create() from drm/drm_gem_vram_helper.c. > This is what the call trace looks like without specifying the "ttm_tt_create" > member (i.e., this member is null). cc'ing Christian, I can't remember if we did this deliberately or if just worked by accident previously. Either way, you should probably need a ttm_tt_create going forward. Dave. > > ___ > . . . > kernel: [ 34.310674] [drm:openchrome_bo_create [openchrome]] Entered > openchrome_bo_create. > kernel: [ 34.310697] [drm:openchrome_ttm_domain_to_placement [openchrome]] > Entered openchrome_ttm_domain_to_placement. > kernel: [ 34.310706] [drm:openchrome_ttm_domain_to_placement [openchrome]] > Exiting openchrome_ttm_domain_to_placement. > kernel: [ 34.310737] BUG: kernel NULL pointer dereference, address: > > kernel: [ 34.310742] #PF: supervisor instruction fetch in kernel mode > kernel: [ 34.310745] #PF: error_code(0x0010) - not-present page > . . . > kernel: [ 34.310807] Call Trace: > kernel: [ 34.310827] ttm_tt_create+0x5f/0xa0 [ttm] > kernel: [ 34.310839] ttm_bo_validate+0xb8/0x140 [ttm] > kernel: [ 34.310886] ? drm_vma_offset_add+0x56/0x70 [drm] > kernel: [ 34.310897] ? openchrome_gem_create_ioctl+0x150/0x150 [openchrome] > . . . > ___ > > The erroneous call to "ttm_tt_create" member happens right after TTM > placement is performed (openchrome_ttm_domain_to_placement()). > Currently, OpenChrome DRM's TTM implementation does not use "ttm_tt_create" > member, and this arrangement worked fine until Linux 5.9's drm-next code. > It appears that Linux 5.10's drm-next code broke the code. > > Regards, > > Kevin Brace > Brace Computer Laboratory blog > https://bracecomputerlab.com > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 27/33] Fix use after free in get_capset_info callback.
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 06496a1281622..476b9993b0682 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -113,8 +113,10 @@ static void virtio_gpu_get_capsets(struct
virtio_gpu_device *vgdev,
vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+ spin_lock(>display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+ spin_unlock(>display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 772a5a3b0ce1a..18e8fcad6690b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -596,9 +596,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
spin_lock(>display_info_lock);
- vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
- vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
- vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ if (vgdev->capsets) {
+ vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+ vgdev->capsets[i].max_version =
le32_to_cpu(resp->capset_max_version);
+ vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ } else {
+ DRM_ERROR("invalid capset memory.");
+ }
spin_unlock(>display_info_lock);
wake_up(>resp_wq);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 35/41] Fix use after free in get_capset_info callback.
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 036b0fbae0fb7..ba7855da7c7f6 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -113,8 +113,10 @@ static void virtio_gpu_get_capsets(struct
virtio_gpu_device *vgdev,
vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+ spin_lock(>display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+ spin_unlock(>display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 772a5a3b0ce1a..18e8fcad6690b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -596,9 +596,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
spin_lock(>display_info_lock);
- vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
- vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
- vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ if (vgdev->capsets) {
+ vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+ vgdev->capsets[i].max_version =
le32_to_cpu(resp->capset_max_version);
+ vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ } else {
+ DRM_ERROR("invalid capset memory.");
+ }
spin_unlock(>display_info_lock);
wake_up(>resp_wq);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 42/52] Fix use after free in get_capset_info callback.
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 6400506a06b07..bed450fbb2168 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -113,8 +113,10 @@ static void virtio_gpu_get_capsets(struct
virtio_gpu_device *vgdev,
vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+ spin_lock(>display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+ spin_unlock(>display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index a3be65e689fd2..a956c73ea85e5 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -563,9 +563,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
spin_lock(>display_info_lock);
- vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
- vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
- vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ if (vgdev->capsets) {
+ vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+ vgdev->capsets[i].max_version =
le32_to_cpu(resp->capset_max_version);
+ vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ } else {
+ DRM_ERROR("invalid capset memory.");
+ }
spin_unlock(>display_info_lock);
wake_up(>resp_wq);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
On Sun, 2020-10-18 at 20:16 +0100, Matthew Wilcox wrote: > On Sun, Oct 18, 2020 at 12:13:35PM -0700, James Bottomley wrote: > > On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote: > > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: > > > > clang has a number of useful, new warnings see > > > > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$ > > > > > > > > > > Please get your IT department to remove that stupidity. If you > > > can't, please send email from a non-Red Hat email address. > > > > Actually, the problem is at Oracle's end somewhere in the ocfs2 > > list ... if you could fix it, that would be great. The usual real > > mailing lists didn't get this transformation > > > > https://lore.kernel.org/bpf/20201017160928.12698-1-t...@redhat.com/ > > > > but the ocfs2 list archive did: > > > > https://oss.oracle.com/pipermail/ocfs2-devel/2020-October/015330.html > > > > I bet Oracle IT has put some spam filter on the list that mangles > > URLs this way. > > *sigh*. I'm sure there's a way. I've raised it with someone who > should be able to fix it. As someone who works for IBM I can only say I feel your pain ... James ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 45/56] Fix use after free in get_capset_info callback.
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 65060c08522d7..22397a23780c0 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -113,8 +113,10 @@ static void virtio_gpu_get_capsets(struct
virtio_gpu_device *vgdev,
vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+ spin_lock(>display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+ spin_unlock(>display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 608906f06cedd..3e72c6dac0ffe 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -566,9 +566,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
spin_lock(>display_info_lock);
- vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
- vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
- vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ if (vgdev->capsets) {
+ vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+ vgdev->capsets[i].max_version =
le32_to_cpu(resp->capset_max_version);
+ vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ } else {
+ DRM_ERROR("invalid capset memory.");
+ }
spin_unlock(>display_info_lock);
wake_up(>resp_wq);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 49/56] drm/amd/display: Fix a list corruption
From: xinhui pan [ Upstream commit 1545fbf97eafc1dbdc2923e58b4186b16a834784 ] Remove the private obj from the internal list before we free aconnector. [ 56.925828] BUG: unable to handle page fault for address: 8f84a870a560 [ 56.933272] #PF: supervisor read access in kernel mode [ 56.938801] #PF: error_code(0x) - not-present page [ 56.944376] PGD 18e605067 P4D 18e605067 PUD 86a614067 PMD 86a4d0067 PTE 8008578f5060 [ 56.953260] Oops: [#1] SMP DEBUG_PAGEALLOC NOPTI [ 56.958815] CPU: 6 PID: 1407 Comm: bash Tainted: G O 5.9.0-rc2+ #46 [ 56.967092] Hardware name: System manufacturer System Product Name/PRIME Z390-A, BIOS 1401 11/26/2019 [ 56.977162] RIP: 0010:__list_del_entry_valid+0x31/0xa0 [ 56.982768] Code: 00 ad de 55 48 8b 17 4c 8b 47 08 48 89 e5 48 39 c2 74 27 48 b8 22 01 00 00 00 00 ad de 49 39 c0 74 2d 49 8b 30 48 39 fe 75 3d <48> 8b 52 08 48 39 f2 75 4c b8 01 00 00 00 5d c3 48 89 7 [ 57.003327] RSP: 0018:b40c81687c90 EFLAGS: 00010246 [ 57.009048] RAX: dead0122 RBX: 8f84ea41f4f0 RCX: 0006 [ 57.016871] RDX: 8f84a870a558 RSI: 8f84ea41f4f0 RDI: 8f84ea41f4f0 [ 57.024672] RBP: b40c81687c90 R08: 8f84ea400998 R09: 0001 [ 57.032490] R10: R11: R12: 0006 [ 57.040287] R13: 8f84ea422a90 R14: 8f84b4129a20 R15: fff2 [ 57.048105] FS: 7f550d885740() GS:8f850960() knlGS: [ 57.056979] CS: 0010 DS: ES: CR0: 80050033 [ 57.063260] CR2: 8f84a870a560 CR3: 0007e5144001 CR4: 003706e0 [ 57.071053] DR0: DR1: DR2: [ 57.078849] DR3: DR6: fffe0ff0 DR7: 0400 [ 57.086684] Call Trace: [ 57.089381] drm_atomic_private_obj_fini+0x29/0x82 [drm] [ 57.095247] amdgpu_dm_fini+0x83/0x170 [amdgpu] [ 57.100264] dm_hw_fini+0x23/0x30 [amdgpu] [ 57.104814] amdgpu_device_fini+0x1df/0x4fe [amdgpu] [ 57.110271] amdgpu_driver_unload_kms+0x43/0x70 [amdgpu] [ 57.116136] amdgpu_pci_remove+0x3b/0x60 [amdgpu] [ 57.121291] pci_device_remove+0x3e/0xb0 [ 57.125583] device_release_driver_internal+0xff/0x1d0 [ 57.131223] device_release_driver+0x12/0x20 [ 57.135903] pci_stop_bus_device+0x70/0xa0 [ 57.140401] pci_stop_and_remove_bus_device_locked+0x1b/0x30 [ 57.146571] remove_store+0x7b/0x90 [ 57.150429] dev_attr_store+0x17/0x30 [ 57.154441] sysfs_kf_write+0x4b/0x60 [ 57.158479] kernfs_fop_write+0xe8/0x1d0 [ 57.162788] vfs_write+0xf5/0x230 [ 57.166426] ksys_write+0x70/0xf0 [ 57.170087] __x64_sys_write+0x1a/0x20 [ 57.174219] do_syscall_64+0x38/0x90 [ 57.178145] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: xinhui pan Acked-by: Feifei Xu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + 1 file changed, 1 insertion(+) 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 3b07a316680c2..b01f3269595e8 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2877,6 +2877,7 @@ static void amdgpu_dm_connector_destroy(struct drm_connector *connector) struct amdgpu_device *adev = connector->dev->dev_private; struct amdgpu_display_manager *dm = >dm; + drm_atomic_private_obj_fini(>mst_mgr.base); #if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||\ defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 67/80] drm/amd/display: Fix a list corruption
From: xinhui pan [ Upstream commit 1545fbf97eafc1dbdc2923e58b4186b16a834784 ] Remove the private obj from the internal list before we free aconnector. [ 56.925828] BUG: unable to handle page fault for address: 8f84a870a560 [ 56.933272] #PF: supervisor read access in kernel mode [ 56.938801] #PF: error_code(0x) - not-present page [ 56.944376] PGD 18e605067 P4D 18e605067 PUD 86a614067 PMD 86a4d0067 PTE 8008578f5060 [ 56.953260] Oops: [#1] SMP DEBUG_PAGEALLOC NOPTI [ 56.958815] CPU: 6 PID: 1407 Comm: bash Tainted: G O 5.9.0-rc2+ #46 [ 56.967092] Hardware name: System manufacturer System Product Name/PRIME Z390-A, BIOS 1401 11/26/2019 [ 56.977162] RIP: 0010:__list_del_entry_valid+0x31/0xa0 [ 56.982768] Code: 00 ad de 55 48 8b 17 4c 8b 47 08 48 89 e5 48 39 c2 74 27 48 b8 22 01 00 00 00 00 ad de 49 39 c0 74 2d 49 8b 30 48 39 fe 75 3d <48> 8b 52 08 48 39 f2 75 4c b8 01 00 00 00 5d c3 48 89 7 [ 57.003327] RSP: 0018:b40c81687c90 EFLAGS: 00010246 [ 57.009048] RAX: dead0122 RBX: 8f84ea41f4f0 RCX: 0006 [ 57.016871] RDX: 8f84a870a558 RSI: 8f84ea41f4f0 RDI: 8f84ea41f4f0 [ 57.024672] RBP: b40c81687c90 R08: 8f84ea400998 R09: 0001 [ 57.032490] R10: R11: R12: 0006 [ 57.040287] R13: 8f84ea422a90 R14: 8f84b4129a20 R15: fff2 [ 57.048105] FS: 7f550d885740() GS:8f850960() knlGS: [ 57.056979] CS: 0010 DS: ES: CR0: 80050033 [ 57.063260] CR2: 8f84a870a560 CR3: 0007e5144001 CR4: 003706e0 [ 57.071053] DR0: DR1: DR2: [ 57.078849] DR3: DR6: fffe0ff0 DR7: 0400 [ 57.086684] Call Trace: [ 57.089381] drm_atomic_private_obj_fini+0x29/0x82 [drm] [ 57.095247] amdgpu_dm_fini+0x83/0x170 [amdgpu] [ 57.100264] dm_hw_fini+0x23/0x30 [amdgpu] [ 57.104814] amdgpu_device_fini+0x1df/0x4fe [amdgpu] [ 57.110271] amdgpu_driver_unload_kms+0x43/0x70 [amdgpu] [ 57.116136] amdgpu_pci_remove+0x3b/0x60 [amdgpu] [ 57.121291] pci_device_remove+0x3e/0xb0 [ 57.125583] device_release_driver_internal+0xff/0x1d0 [ 57.131223] device_release_driver+0x12/0x20 [ 57.135903] pci_stop_bus_device+0x70/0xa0 [ 57.140401] pci_stop_and_remove_bus_device_locked+0x1b/0x30 [ 57.146571] remove_store+0x7b/0x90 [ 57.150429] dev_attr_store+0x17/0x30 [ 57.154441] sysfs_kf_write+0x4b/0x60 [ 57.158479] kernfs_fop_write+0xe8/0x1d0 [ 57.162788] vfs_write+0xf5/0x230 [ 57.166426] ksys_write+0x70/0xf0 [ 57.170087] __x64_sys_write+0x1a/0x20 [ 57.174219] do_syscall_64+0x38/0x90 [ 57.178145] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: xinhui pan Acked-by: Feifei Xu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + 1 file changed, 1 insertion(+) 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 2384aa018993d..381ecd6a9e94b 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3956,6 +3956,7 @@ static void amdgpu_dm_connector_destroy(struct drm_connector *connector) struct amdgpu_device *adev = connector->dev->dev_private; struct amdgpu_display_manager *dm = >dm; + drm_atomic_private_obj_fini(>mst_mgr.base); #if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||\ defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 60/80] Fix use after free in get_capset_info callback.
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index c190702fab726..6dcc05ab31eba 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -96,8 +96,10 @@ static void virtio_gpu_get_capsets(struct virtio_gpu_device
*vgdev,
vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+ spin_lock(>display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+ spin_unlock(>display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 7ac20490e1b4c..92022a83bbd5e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -572,9 +572,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
spin_lock(>display_info_lock);
- vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
- vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
- vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ if (vgdev->capsets) {
+ vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+ vgdev->capsets[i].max_version =
le32_to_cpu(resp->capset_max_version);
+ vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ } else {
+ DRM_ERROR("invalid capset memory.");
+ }
spin_unlock(>display_info_lock);
wake_up(>resp_wq);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 53/80] drm/msm/a6xx: fix a potential overflow issue
From: Zhenzhong Duan [ Upstream commit 08d3ab4b46339bc6f97e83b54a3fb4f8bf8f4cd9 ] It's allocating an array of a6xx_gpu_state_obj structure rathor than its pointers. This patch fix it. Signed-off-by: Zhenzhong Duan Signed-off-by: Rob Clark Signed-off-by: Sasha Levin --- drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c index 691c1a277d91b..dfcbb2b7cdda3 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c @@ -834,7 +834,7 @@ static void a6xx_get_indexed_registers(struct msm_gpu *gpu, int i; a6xx_state->indexed_regs = state_kcalloc(a6xx_state, count, - sizeof(a6xx_state->indexed_regs)); + sizeof(*a6xx_state->indexed_regs)); if (!a6xx_state->indexed_regs) return; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 45/80] drm/panfrost: add amlogic reset quirk callback
From: Neil Armstrong
[ Upstream commit 110003002291525bb209f47e6dbf121a63249a97 ]
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM,
G12A/SM1 & G12B SoCs needs a quirk in the PWR registers at the GPU reset
time.
Since the Amlogic's integration of the GPU cores with the SoC is not
publicly documented we do not know what does these values, but they
permit having a fully functional GPU running with Panfrost.
Signed-off-by: Neil Armstrong
[Steven: Fix typo in commit log]
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Steven Price
Link:
https://patchwork.freedesktop.org/patch/msgid/20200916150147.25753-3-narmstr...@baylibre.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 11 +++
drivers/gpu/drm/panfrost/panfrost_gpu.h | 2 ++
drivers/gpu/drm/panfrost/panfrost_regs.h | 4
3 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index 8822ec13a0d61..68e046b2f1680 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -75,6 +75,17 @@ int panfrost_gpu_soft_reset(struct panfrost_device *pfdev)
return 0;
}
+void panfrost_gpu_amlogic_quirk(struct panfrost_device *pfdev)
+{
+ /*
+* The Amlogic integrated Mali-T820, Mali-G31 & Mali-G52 needs
+* these undocumented bits in GPU_PWR_OVERRIDE1 to be set in order
+* to operate correctly.
+*/
+ gpu_write(pfdev, GPU_PWR_KEY, GPU_PWR_KEY_UNLOCK);
+ gpu_write(pfdev, GPU_PWR_OVERRIDE1, 0xfff | (0x20 << 16));
+}
+
static void panfrost_gpu_init_quirks(struct panfrost_device *pfdev)
{
u32 quirks = 0;
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.h
b/drivers/gpu/drm/panfrost/panfrost_gpu.h
index 4112412087b27..468c51e7e46db 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.h
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.h
@@ -16,4 +16,6 @@ int panfrost_gpu_soft_reset(struct panfrost_device *pfdev);
void panfrost_gpu_power_on(struct panfrost_device *pfdev);
void panfrost_gpu_power_off(struct panfrost_device *pfdev);
+void panfrost_gpu_amlogic_quirk(struct panfrost_device *pfdev);
+
#endif
diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h
b/drivers/gpu/drm/panfrost/panfrost_regs.h
index ea38ac60581c6..eddaa62ad8b0e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_regs.h
+++ b/drivers/gpu/drm/panfrost/panfrost_regs.h
@@ -51,6 +51,10 @@
#define GPU_STATUS 0x34
#define GPU_STATUS_PRFCNT_ACTIVE BIT(2)
#define GPU_LATEST_FLUSH_ID0x38
+#define GPU_PWR_KEY0x50/* (WO) Power manager key
register */
+#define GPU_PWR_KEY_UNLOCK0x2968A819
+#define GPU_PWR_OVERRIDE0 0x54/* (RW) Power manager override
settings */
+#define GPU_PWR_OVERRIDE1 0x58/* (RW) Power manager override
settings */
#define GPU_FAULT_STATUS 0x3C
#define GPU_FAULT_ADDRESS_LO 0x40
#define GPU_FAULT_ADDRESS_HI 0x44
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 076/101] Fix use after free in get_capset_info callback.
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 0a5c8cf409fb8..dc8cb8dfce58e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -80,8 +80,10 @@ static void virtio_gpu_get_capsets(struct virtio_gpu_device
*vgdev,
vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+ spin_lock(>display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+ spin_unlock(>display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 9e663a5d99526..2517450bf46ba 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -684,9 +684,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
spin_lock(>display_info_lock);
- vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
- vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
- vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ if (vgdev->capsets) {
+ vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+ vgdev->capsets[i].max_version =
le32_to_cpu(resp->capset_max_version);
+ vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ } else {
+ DRM_ERROR("invalid capset memory.");
+ }
spin_unlock(>display_info_lock);
wake_up(>resp_wq);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 098/101] drm/amd/display: Screen corruption on dual displays (DP+USB-C)
From: Qingqing Zhuo
[ Upstream commit ce271b40a91f781af3dee985c39e841ac5148766 ]
[why]
Current pipe merge and split logic only supports cases where new
dc_state is allocated and relies on dc->current_state to gather
information from previous dc_state.
Calls to validate_bandwidth on UPDATE_TYPE_MED would cause an issue
because there is no new dc_state allocated, and data in
dc->current_state would be overwritten during pipe merge.
[how]
Only allow validate_bandwidth when new dc_state space is created.
Signed-off-by: Qingqing Zhuo
Reviewed-by: Nicholas Kazlauskas
Acked-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 3 +++
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 3 +++
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index d016f50e187c8..d261f425b80ec 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2538,7 +2538,7 @@ void dc_commit_updates_for_stream(struct dc *dc,
copy_stream_update_to_stream(dc, context, stream, stream_update);
- if (update_type > UPDATE_TYPE_FAST) {
+ if (update_type >= UPDATE_TYPE_FULL) {
if (!dc->res_pool->funcs->validate_bandwidth(dc, context,
false)) {
DC_ERROR("Mode validation failed for stream update!\n");
dc_release_state(context);
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index 20bdabebbc434..76cd4f3de4eaf 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -3165,6 +3165,9 @@ static noinline bool dcn20_validate_bandwidth_fp(struct
dc *dc,
context->bw_ctx.dml.soc.allow_dram_clock_one_display_vactive =
dc->debug.enable_dram_clock_change_one_display_vactive;
+ /*Unsafe due to current pipe merge and split logic*/
+ ASSERT(context != dc->current_state);
+
if (fast_validate) {
return dcn20_validate_bandwidth_internal(dc, context, true);
}
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index f00a568350848..c6ab3dee4fd69 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -1184,6 +1184,9 @@ bool dcn21_validate_bandwidth(struct dc *dc, struct
dc_state *context,
BW_VAL_TRACE_COUNT();
+ /*Unsafe due to current pipe merge and split logic*/
+ ASSERT(context != dc->current_state);
+
out = dcn20_fast_validate_bw(dc, context, pipes, _cnt,
pipe_split_from, );
if (pipe_cnt == 0)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 084/101] drm/amd/display: Fix a list corruption
From: xinhui pan [ Upstream commit 1545fbf97eafc1dbdc2923e58b4186b16a834784 ] Remove the private obj from the internal list before we free aconnector. [ 56.925828] BUG: unable to handle page fault for address: 8f84a870a560 [ 56.933272] #PF: supervisor read access in kernel mode [ 56.938801] #PF: error_code(0x) - not-present page [ 56.944376] PGD 18e605067 P4D 18e605067 PUD 86a614067 PMD 86a4d0067 PTE 8008578f5060 [ 56.953260] Oops: [#1] SMP DEBUG_PAGEALLOC NOPTI [ 56.958815] CPU: 6 PID: 1407 Comm: bash Tainted: G O 5.9.0-rc2+ #46 [ 56.967092] Hardware name: System manufacturer System Product Name/PRIME Z390-A, BIOS 1401 11/26/2019 [ 56.977162] RIP: 0010:__list_del_entry_valid+0x31/0xa0 [ 56.982768] Code: 00 ad de 55 48 8b 17 4c 8b 47 08 48 89 e5 48 39 c2 74 27 48 b8 22 01 00 00 00 00 ad de 49 39 c0 74 2d 49 8b 30 48 39 fe 75 3d <48> 8b 52 08 48 39 f2 75 4c b8 01 00 00 00 5d c3 48 89 7 [ 57.003327] RSP: 0018:b40c81687c90 EFLAGS: 00010246 [ 57.009048] RAX: dead0122 RBX: 8f84ea41f4f0 RCX: 0006 [ 57.016871] RDX: 8f84a870a558 RSI: 8f84ea41f4f0 RDI: 8f84ea41f4f0 [ 57.024672] RBP: b40c81687c90 R08: 8f84ea400998 R09: 0001 [ 57.032490] R10: R11: R12: 0006 [ 57.040287] R13: 8f84ea422a90 R14: 8f84b4129a20 R15: fff2 [ 57.048105] FS: 7f550d885740() GS:8f850960() knlGS: [ 57.056979] CS: 0010 DS: ES: CR0: 80050033 [ 57.063260] CR2: 8f84a870a560 CR3: 0007e5144001 CR4: 003706e0 [ 57.071053] DR0: DR1: DR2: [ 57.078849] DR3: DR6: fffe0ff0 DR7: 0400 [ 57.086684] Call Trace: [ 57.089381] drm_atomic_private_obj_fini+0x29/0x82 [drm] [ 57.095247] amdgpu_dm_fini+0x83/0x170 [amdgpu] [ 57.100264] dm_hw_fini+0x23/0x30 [amdgpu] [ 57.104814] amdgpu_device_fini+0x1df/0x4fe [amdgpu] [ 57.110271] amdgpu_driver_unload_kms+0x43/0x70 [amdgpu] [ 57.116136] amdgpu_pci_remove+0x3b/0x60 [amdgpu] [ 57.121291] pci_device_remove+0x3e/0xb0 [ 57.125583] device_release_driver_internal+0xff/0x1d0 [ 57.131223] device_release_driver+0x12/0x20 [ 57.135903] pci_stop_bus_device+0x70/0xa0 [ 57.140401] pci_stop_and_remove_bus_device_locked+0x1b/0x30 [ 57.146571] remove_store+0x7b/0x90 [ 57.150429] dev_attr_store+0x17/0x30 [ 57.154441] sysfs_kf_write+0x4b/0x60 [ 57.158479] kernfs_fop_write+0xe8/0x1d0 [ 57.162788] vfs_write+0xf5/0x230 [ 57.166426] ksys_write+0x70/0xf0 [ 57.170087] __x64_sys_write+0x1a/0x20 [ 57.174219] do_syscall_64+0x38/0x90 [ 57.178145] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: xinhui pan Acked-by: Feifei Xu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + 1 file changed, 1 insertion(+) 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 7c1cc0ba30a55..a3b39b6398737 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4862,6 +4862,7 @@ static void amdgpu_dm_connector_destroy(struct drm_connector *connector) struct amdgpu_device *adev = connector->dev->dev_private; struct amdgpu_display_manager *dm = >dm; + drm_atomic_private_obj_fini(>mst_mgr.base); #if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||\ defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 067/101] drm: fix double free for gbo in drm_gem_vram_init and drm_gem_vram_create
From: Jia Yang
[ Upstream commit da62cb7230f0871c30dc9789071f63229158d261 ]
I got a use-after-free report when doing some fuzz test:
If ttm_bo_init() fails, the "gbo" and "gbo->bo.base" will be
freed by ttm_buffer_object_destroy() in ttm_bo_init(). But
then drm_gem_vram_create() and drm_gem_vram_init() will free
"gbo" and "gbo->bo.base" again.
BUG: KMSAN: use-after-free in drm_vma_offset_remove+0xb3/0x150
CPU: 0 PID: 24282 Comm: syz-executor.1 Tainted: GB W
5.7.0-rc4-msan #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
Call Trace:
__dump_stack
dump_stack+0x1c9/0x220
kmsan_report+0xf7/0x1e0
__msan_warning+0x58/0xa0
drm_vma_offset_remove+0xb3/0x150
drm_gem_free_mmap_offset
drm_gem_object_release+0x159/0x180
drm_gem_vram_init
drm_gem_vram_create+0x7c5/0x990
drm_gem_vram_fill_create_dumb
drm_gem_vram_driver_dumb_create+0x238/0x590
drm_mode_create_dumb
drm_mode_create_dumb_ioctl+0x41d/0x450
drm_ioctl_kernel+0x5a4/0x710
drm_ioctl+0xc6f/0x1240
vfs_ioctl
ksys_ioctl
__do_sys_ioctl
__se_sys_ioctl+0x2e9/0x410
__x64_sys_ioctl+0x4a/0x70
do_syscall_64+0xb8/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4689b9
Code: fd e0 fa ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
cb e0 fa ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f368fa4dc98 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 0076bf00 RCX: 004689b9
RDX: 2240 RSI: c02064b2 RDI: 0003
RBP: 0004 R08: R09:
R10: R11: 0246 R12:
R13: 004d17e0 R14: 7f368fa4e6d4 R15: 0076bf0c
Uninit was created at:
kmsan_save_stack_with_flags
kmsan_internal_poison_shadow+0x66/0xd0
kmsan_slab_free+0x6e/0xb0
slab_free_freelist_hook
slab_free
kfree+0x571/0x30a0
drm_gem_vram_destroy
ttm_buffer_object_destroy+0xc8/0x130
ttm_bo_release
kref_put
ttm_bo_put+0x117d/0x23e0
ttm_bo_init_reserved+0x11c0/0x11d0
ttm_bo_init+0x289/0x3f0
drm_gem_vram_init
drm_gem_vram_create+0x775/0x990
drm_gem_vram_fill_create_dumb
drm_gem_vram_driver_dumb_create+0x238/0x590
drm_mode_create_dumb
drm_mode_create_dumb_ioctl+0x41d/0x450
drm_ioctl_kernel+0x5a4/0x710
drm_ioctl+0xc6f/0x1240
vfs_ioctl
ksys_ioctl
__do_sys_ioctl
__se_sys_ioctl+0x2e9/0x410
__x64_sys_ioctl+0x4a/0x70
do_syscall_64+0xb8/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
If ttm_bo_init() fails, the "gbo" will be freed by
ttm_buffer_object_destroy() in ttm_bo_init(). But then
drm_gem_vram_create() and drm_gem_vram_init() will free
"gbo" again.
Reported-by: Hulk Robot
Reported-by: butt3rflyh4ck
Signed-off-by: Jia Yang
Signed-off-by: Thomas Zimmermann
Reviewed-by: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20200714083238.28479-2-tzimmerm...@suse.de
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_gem_vram_helper.c | 28 +++
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 8b2d5c945c95c..1d85af9a481ac 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -175,6 +175,10 @@ static void drm_gem_vram_placement(struct
drm_gem_vram_object *gbo,
}
}
+/*
+ * Note that on error, drm_gem_vram_init will free the buffer object.
+ */
+
static int drm_gem_vram_init(struct drm_device *dev,
struct drm_gem_vram_object *gbo,
size_t size, unsigned long pg_align)
@@ -184,15 +188,19 @@ static int drm_gem_vram_init(struct drm_device *dev,
int ret;
size_t acc_size;
- if (WARN_ONCE(!vmm, "VRAM MM not initialized"))
+ if (WARN_ONCE(!vmm, "VRAM MM not initialized")) {
+ kfree(gbo);
return -EINVAL;
+ }
bdev = >bdev;
gbo->bo.base.funcs = _gem_vram_object_funcs;
ret = drm_gem_object_init(dev, >bo.base, size);
- if (ret)
+ if (ret) {
+ kfree(gbo);
return ret;
+ }
acc_size = ttm_bo_dma_acc_size(bdev, size, sizeof(*gbo));
@@ -203,13 +211,13 @@ static int drm_gem_vram_init(struct drm_device *dev,
>placement, pg_align, false, acc_size,
NULL, NULL, ttm_buffer_object_destroy);
if (ret)
- goto err_drm_gem_object_release;
+ /*
+* A failing ttm_bo_init will call ttm_buffer_object_destroy
+* to release gbo->bo.base and kfree gbo.
+*/
+ return ret;
return 0;
-
-err_drm_gem_object_release:
- drm_gem_object_release(>bo.base);
- return ret;
}
/**
@@ -243,13 +251,9 @@ struct drm_gem_vram_object
[PATCH AUTOSEL 5.8 069/101] drm/msm/a6xx: fix a potential overflow issue
From: Zhenzhong Duan [ Upstream commit 08d3ab4b46339bc6f97e83b54a3fb4f8bf8f4cd9 ] It's allocating an array of a6xx_gpu_state_obj structure rathor than its pointers. This patch fix it. Signed-off-by: Zhenzhong Duan Signed-off-by: Rob Clark Signed-off-by: Sasha Levin --- drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c index d6023ba8033c0..3bb567812b990 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c @@ -864,7 +864,7 @@ static void a6xx_get_indexed_registers(struct msm_gpu *gpu, int i; a6xx_state->indexed_regs = state_kcalloc(a6xx_state, count, - sizeof(a6xx_state->indexed_regs)); + sizeof(*a6xx_state->indexed_regs)); if (!a6xx_state->indexed_regs) return; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 059/101] drm/panfrost: add amlogic reset quirk callback
From: Neil Armstrong
[ Upstream commit 110003002291525bb209f47e6dbf121a63249a97 ]
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM,
G12A/SM1 & G12B SoCs needs a quirk in the PWR registers at the GPU reset
time.
Since the Amlogic's integration of the GPU cores with the SoC is not
publicly documented we do not know what does these values, but they
permit having a fully functional GPU running with Panfrost.
Signed-off-by: Neil Armstrong
[Steven: Fix typo in commit log]
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Steven Price
Link:
https://patchwork.freedesktop.org/patch/msgid/20200916150147.25753-3-narmstr...@baylibre.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 11 +++
drivers/gpu/drm/panfrost/panfrost_gpu.h | 2 ++
drivers/gpu/drm/panfrost/panfrost_regs.h | 4
3 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index f2c1ddc41a9bf..6606643850fc6 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -75,6 +75,17 @@ int panfrost_gpu_soft_reset(struct panfrost_device *pfdev)
return 0;
}
+void panfrost_gpu_amlogic_quirk(struct panfrost_device *pfdev)
+{
+ /*
+* The Amlogic integrated Mali-T820, Mali-G31 & Mali-G52 needs
+* these undocumented bits in GPU_PWR_OVERRIDE1 to be set in order
+* to operate correctly.
+*/
+ gpu_write(pfdev, GPU_PWR_KEY, GPU_PWR_KEY_UNLOCK);
+ gpu_write(pfdev, GPU_PWR_OVERRIDE1, 0xfff | (0x20 << 16));
+}
+
static void panfrost_gpu_init_quirks(struct panfrost_device *pfdev)
{
u32 quirks = 0;
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.h
b/drivers/gpu/drm/panfrost/panfrost_gpu.h
index 4112412087b27..468c51e7e46db 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.h
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.h
@@ -16,4 +16,6 @@ int panfrost_gpu_soft_reset(struct panfrost_device *pfdev);
void panfrost_gpu_power_on(struct panfrost_device *pfdev);
void panfrost_gpu_power_off(struct panfrost_device *pfdev);
+void panfrost_gpu_amlogic_quirk(struct panfrost_device *pfdev);
+
#endif
diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h
b/drivers/gpu/drm/panfrost/panfrost_regs.h
index ea38ac60581c6..eddaa62ad8b0e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_regs.h
+++ b/drivers/gpu/drm/panfrost/panfrost_regs.h
@@ -51,6 +51,10 @@
#define GPU_STATUS 0x34
#define GPU_STATUS_PRFCNT_ACTIVE BIT(2)
#define GPU_LATEST_FLUSH_ID0x38
+#define GPU_PWR_KEY0x50/* (WO) Power manager key
register */
+#define GPU_PWR_KEY_UNLOCK0x2968A819
+#define GPU_PWR_OVERRIDE0 0x54/* (RW) Power manager override
settings */
+#define GPU_PWR_OVERRIDE1 0x58/* (RW) Power manager override
settings */
#define GPU_FAULT_STATUS 0x3C
#define GPU_FAULT_ADDRESS_LO 0x40
#define GPU_FAULT_ADDRESS_HI 0x44
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 058/101] drm/panfrost: add Amlogic GPU integration quirks
From: Neil Armstrong
[ Upstream commit afcd0c7d3d4c22afc8befcfc906db6ce3058d3ee ]
This adds the required GPU quirks, including the quirk in the PWR
registers at the GPU reset time and the IOMMU quirk for shareability
issues observed on G52 in Amlogic G12B SoCs.
Signed-off-by: Neil Armstrong
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Steven Price
Link:
https://patchwork.freedesktop.org/patch/msgid/20200916150147.25753-4-narmstr...@baylibre.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 882fecc33fdb1..6e11a73e81aa3 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -667,7 +667,18 @@ static const struct panfrost_compatible default_data = {
.pm_domain_names = NULL,
};
+static const struct panfrost_compatible amlogic_data = {
+ .num_supplies = ARRAY_SIZE(default_supplies),
+ .supply_names = default_supplies,
+ .vendor_quirk = panfrost_gpu_amlogic_quirk,
+};
+
static const struct of_device_id dt_match[] = {
+ /* Set first to probe before the generic compatibles */
+ { .compatible = "amlogic,meson-gxm-mali",
+ .data = _data, },
+ { .compatible = "amlogic,meson-g12a-mali",
+ .data = _data, },
{ .compatible = "arm,mali-t604", .data = _data, },
{ .compatible = "arm,mali-t624", .data = _data, },
{ .compatible = "arm,mali-t628", .data = _data, },
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote: > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: > > clang has a number of useful, new warnings see > > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$ > > > > Please get your IT department to remove that stupidity. If you > can't, please send email from a non-Red Hat email address. Actually, the problem is at Oracle's end somewhere in the ocfs2 list ... if you could fix it, that would be great. The usual real mailing lists didn't get this transformation https://lore.kernel.org/bpf/20201017160928.12698-1-t...@redhat.com/ but the ocfs2 list archive did: https://oss.oracle.com/pipermail/ocfs2-devel/2020-October/015330.html I bet Oracle IT has put some spam filter on the list that mangles URLs this way. James ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 060/101] drm/panfrost: add support for vendor quirk
From: Neil Armstrong
[ Upstream commit 91e89097b86f566636ea5a7329c79d5521be46d2 ]
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM,
G12A/SM1 & G12B SoCs needs a quirk in the PWR registers after each reset.
This adds a callback in the device compatible struct of permit this.
Signed-off-by: Neil Armstrong
[Steven: Fix typo in commit log]
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Steven Price
Link:
https://patchwork.freedesktop.org/patch/msgid/20200916150147.25753-2-narmstr...@baylibre.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_device.h | 3 +++
drivers/gpu/drm/panfrost/panfrost_gpu.c| 4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index c30c719a80594..3c4a85213c15f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -69,6 +69,9 @@ struct panfrost_compatible {
int num_pm_domains;
/* Only required if num_pm_domains > 1. */
const char * const *pm_domain_names;
+
+ /* Vendor implementation quirks callback */
+ void (*vendor_quirk)(struct panfrost_device *pfdev);
};
struct panfrost_device {
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index 6606643850fc6..502b1f1f7b204 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -146,6 +146,10 @@ static void panfrost_gpu_init_quirks(struct
panfrost_device *pfdev)
if (quirks)
gpu_write(pfdev, GPU_JM_CONFIG, quirks);
+
+ /* Here goes platform specific quirks */
+ if (pfdev->comp->vendor_quirk)
+ pfdev->comp->vendor_quirk(pfdev);
}
#define MAX_HW_REVS 6
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 105/111] drm/amd/display: Screen corruption on dual displays (DP+USB-C)
From: Qingqing Zhuo
[ Upstream commit ce271b40a91f781af3dee985c39e841ac5148766 ]
[why]
Current pipe merge and split logic only supports cases where new
dc_state is allocated and relies on dc->current_state to gather
information from previous dc_state.
Calls to validate_bandwidth on UPDATE_TYPE_MED would cause an issue
because there is no new dc_state allocated, and data in
dc->current_state would be overwritten during pipe merge.
[how]
Only allow validate_bandwidth when new dc_state space is created.
Signed-off-by: Qingqing Zhuo
Reviewed-by: Nicholas Kazlauskas
Acked-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 3 +++
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 3 +++
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 92eb1ca1634fc..22cbfda6ab338 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2621,7 +2621,7 @@ void dc_commit_updates_for_stream(struct dc *dc,
copy_stream_update_to_stream(dc, context, stream, stream_update);
- if (update_type > UPDATE_TYPE_FAST) {
+ if (update_type >= UPDATE_TYPE_FULL) {
if (!dc->res_pool->funcs->validate_bandwidth(dc, context,
false)) {
DC_ERROR("Mode validation failed for stream update!\n");
dc_release_state(context);
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index f31f48dd0da29..aaf9a99f9f045 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -3209,6 +3209,9 @@ static noinline bool dcn20_validate_bandwidth_fp(struct
dc *dc,
context->bw_ctx.dml.soc.allow_dram_clock_one_display_vactive =
dc->debug.enable_dram_clock_change_one_display_vactive;
+ /*Unsafe due to current pipe merge and split logic*/
+ ASSERT(context != dc->current_state);
+
if (fast_validate) {
return dcn20_validate_bandwidth_internal(dc, context, true);
}
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index 88d41a385add8..a4f37d83d5cc9 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -1184,6 +1184,9 @@ bool dcn21_validate_bandwidth(struct dc *dc, struct
dc_state *context,
BW_VAL_TRACE_COUNT();
+ /*Unsafe due to current pipe merge and split logic*/
+ ASSERT(context != dc->current_state);
+
out = dcn20_fast_validate_bw(dc, context, pipes, _cnt,
pipe_split_from, );
if (pipe_cnt == 0)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 090/111] drm/amd/display: Fix a list corruption
From: xinhui pan [ Upstream commit 1545fbf97eafc1dbdc2923e58b4186b16a834784 ] Remove the private obj from the internal list before we free aconnector. [ 56.925828] BUG: unable to handle page fault for address: 8f84a870a560 [ 56.933272] #PF: supervisor read access in kernel mode [ 56.938801] #PF: error_code(0x) - not-present page [ 56.944376] PGD 18e605067 P4D 18e605067 PUD 86a614067 PMD 86a4d0067 PTE 8008578f5060 [ 56.953260] Oops: [#1] SMP DEBUG_PAGEALLOC NOPTI [ 56.958815] CPU: 6 PID: 1407 Comm: bash Tainted: G O 5.9.0-rc2+ #46 [ 56.967092] Hardware name: System manufacturer System Product Name/PRIME Z390-A, BIOS 1401 11/26/2019 [ 56.977162] RIP: 0010:__list_del_entry_valid+0x31/0xa0 [ 56.982768] Code: 00 ad de 55 48 8b 17 4c 8b 47 08 48 89 e5 48 39 c2 74 27 48 b8 22 01 00 00 00 00 ad de 49 39 c0 74 2d 49 8b 30 48 39 fe 75 3d <48> 8b 52 08 48 39 f2 75 4c b8 01 00 00 00 5d c3 48 89 7 [ 57.003327] RSP: 0018:b40c81687c90 EFLAGS: 00010246 [ 57.009048] RAX: dead0122 RBX: 8f84ea41f4f0 RCX: 0006 [ 57.016871] RDX: 8f84a870a558 RSI: 8f84ea41f4f0 RDI: 8f84ea41f4f0 [ 57.024672] RBP: b40c81687c90 R08: 8f84ea400998 R09: 0001 [ 57.032490] R10: R11: R12: 0006 [ 57.040287] R13: 8f84ea422a90 R14: 8f84b4129a20 R15: fff2 [ 57.048105] FS: 7f550d885740() GS:8f850960() knlGS: [ 57.056979] CS: 0010 DS: ES: CR0: 80050033 [ 57.063260] CR2: 8f84a870a560 CR3: 0007e5144001 CR4: 003706e0 [ 57.071053] DR0: DR1: DR2: [ 57.078849] DR3: DR6: fffe0ff0 DR7: 0400 [ 57.086684] Call Trace: [ 57.089381] drm_atomic_private_obj_fini+0x29/0x82 [drm] [ 57.095247] amdgpu_dm_fini+0x83/0x170 [amdgpu] [ 57.100264] dm_hw_fini+0x23/0x30 [amdgpu] [ 57.104814] amdgpu_device_fini+0x1df/0x4fe [amdgpu] [ 57.110271] amdgpu_driver_unload_kms+0x43/0x70 [amdgpu] [ 57.116136] amdgpu_pci_remove+0x3b/0x60 [amdgpu] [ 57.121291] pci_device_remove+0x3e/0xb0 [ 57.125583] device_release_driver_internal+0xff/0x1d0 [ 57.131223] device_release_driver+0x12/0x20 [ 57.135903] pci_stop_bus_device+0x70/0xa0 [ 57.140401] pci_stop_and_remove_bus_device_locked+0x1b/0x30 [ 57.146571] remove_store+0x7b/0x90 [ 57.150429] dev_attr_store+0x17/0x30 [ 57.154441] sysfs_kf_write+0x4b/0x60 [ 57.158479] kernfs_fop_write+0xe8/0x1d0 [ 57.162788] vfs_write+0xf5/0x230 [ 57.166426] ksys_write+0x70/0xf0 [ 57.170087] __x64_sys_write+0x1a/0x20 [ 57.174219] do_syscall_64+0x38/0x90 [ 57.178145] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: xinhui pan Acked-by: Feifei Xu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + 1 file changed, 1 insertion(+) 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 a717a4904268e..57ad6450e20b2 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4882,6 +4882,7 @@ static void amdgpu_dm_connector_destroy(struct drm_connector *connector) struct amdgpu_device *adev = connector->dev->dev_private; struct amdgpu_display_manager *dm = >dm; + drm_atomic_private_obj_fini(>mst_mgr.base); #if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||\ defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 109/111] drm/amd/display: Disconnect pipe separetely when disable pipe split
From: Alvin Lee
[ Upstream commit 81b437f57e35a6caa3a4304e6fff0eba0a9f3266 ]
[Why]
When changing pixel formats for HDR (e.g. ARGB -> FP16)
there are configurations that change from 2 pipes to 1 pipe.
In these cases, it seems that disconnecting MPCC and doing
a surface update at the same time(after unlocking) causes
some registers to be updated slightly faster than others
after unlocking (e.g. if the pixel format is updated to FP16
before the new surface address is programmed, we get
corruption on the screen because the pixel formats aren't
matching). We separate disconnecting MPCC from the rest
of the pipe programming sequence to prevent this.
[How]
Move MPCC disconnect into separate operation than the
rest of the pipe programming.
Signed-off-by: Alvin Lee
Reviewed-by: Aric Cyr
Acked-by: Qingqing Zhuo
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 10 ++
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 146 ++
.../amd/display/dc/dcn10/dcn10_hw_sequencer.h | 6 +
.../gpu/drm/amd/display/dc/dcn10/dcn10_init.c | 2 +
.../gpu/drm/amd/display/dc/dcn20/dcn20_init.c | 2 +
.../gpu/drm/amd/display/dc/dcn21/dcn21_init.c | 2 +
.../gpu/drm/amd/display/dc/dcn30/dcn30_init.c | 2 +
.../gpu/drm/amd/display/dc/inc/hw_sequencer.h | 4 +
8 files changed, 174 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 22cbfda6ab338..95ec8ae5a7739 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2295,6 +2295,7 @@ static void commit_planes_for_stream(struct dc *dc,
enum surface_update_type update_type,
struct dc_state *context)
{
+ bool mpcc_disconnected = false;
int i, j;
struct pipe_ctx *top_pipe_to_program = NULL;
@@ -2325,6 +2326,15 @@ static void commit_planes_for_stream(struct dc *dc,
context_clock_trace(dc, context);
}
+ if (update_type != UPDATE_TYPE_FAST &&
dc->hwss.interdependent_update_lock &&
+ dc->hwss.disconnect_pipes && dc->hwss.wait_for_pending_cleared){
+ dc->hwss.interdependent_update_lock(dc, context, true);
+ mpcc_disconnected = dc->hwss.disconnect_pipes(dc, context);
+ dc->hwss.interdependent_update_lock(dc, context, false);
+ if (mpcc_disconnected)
+ dc->hwss.wait_for_pending_cleared(dc, context);
+ }
+
for (j = 0; j < dc->res_pool->pipe_count; j++) {
struct pipe_ctx *pipe_ctx = >res_ctx.pipe_ctx[j];
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index fa643ec5a8760..4bbfd8a26a606 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -2769,6 +2769,152 @@ static struct pipe_ctx *dcn10_find_top_pipe_for_stream(
return NULL;
}
+bool dcn10_disconnect_pipes(
+ struct dc *dc,
+ struct dc_state *context)
+{
+ bool found_stream = false;
+ int i, j;
+ struct dce_hwseq *hws = dc->hwseq;
+ struct dc_state *old_ctx = dc->current_state;
+ bool mpcc_disconnected = false;
+ struct pipe_ctx *old_pipe;
+ struct pipe_ctx *new_pipe;
+ DC_LOGGER_INIT(dc->ctx->logger);
+
+ /* Set pipe update flags and lock pipes */
+ for (i = 0; i < dc->res_pool->pipe_count; i++) {
+ old_pipe = >current_state->res_ctx.pipe_ctx[i];
+ new_pipe = >res_ctx.pipe_ctx[i];
+ new_pipe->update_flags.raw = 0;
+
+ if (!old_pipe->plane_state && !new_pipe->plane_state)
+ continue;
+
+ if (old_pipe->plane_state && !new_pipe->plane_state)
+ new_pipe->update_flags.bits.disable = 1;
+
+ /* Check for scl update */
+ if (memcmp(_pipe->plane_res.scl_data,
_pipe->plane_res.scl_data, sizeof(struct scaler_data)))
+ new_pipe->update_flags.bits.scaler = 1;
+
+ /* Check for vp update */
+ if (memcmp(_pipe->plane_res.scl_data.viewport,
_pipe->plane_res.scl_data.viewport, sizeof(struct rect))
+ ||
memcmp(_pipe->plane_res.scl_data.viewport_c,
+
_pipe->plane_res.scl_data.viewport_c, sizeof(struct rect)))
+ new_pipe->update_flags.bits.viewport = 1;
+
+ }
+
+ if (!IS_DIAG_DC(dc->ctx->dce_environment)) {
+ /* Disconnect mpcc here only if losing pipe
[PATCH AUTOSEL 5.9 108/111] drm/hisilicon: Code refactoring for hibmc_drv_de
From: Tian Tao
[ Upstream commit 13b0d4a9ae0c2d650993c48be797992eaf621332 ]
The memory used to be allocated with devres helpers and released
automatically. In rare circumstances, the memory's release could
have happened before the DRM device got released, which would have
caused memory corruption of some kind. Now we're embedding the data
structures in struct hibmc_drm_private. The whole release problem
has been resolved, because struct hibmc_drm_private is allocated
with drmm_kzalloc and always released with the DRM device.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
Signed-off-by: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/1597218179-3938-3-git-send-email-tiant...@hisilicon.com
Signed-off-by: Sasha Levin
---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 55 +--
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +
2 files changed, 15 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index cc70e836522f0..8758958e16893 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -160,37 +160,6 @@ static const struct drm_plane_helper_funcs
hibmc_plane_helper_funcs = {
.atomic_update = hibmc_plane_atomic_update,
};
-static struct drm_plane *hibmc_plane_init(struct hibmc_drm_private *priv)
-{
- struct drm_device *dev = priv->dev;
- struct drm_plane *plane;
- int ret = 0;
-
- plane = devm_kzalloc(dev->dev, sizeof(*plane), GFP_KERNEL);
- if (!plane) {
- DRM_ERROR("failed to alloc memory when init plane\n");
- return ERR_PTR(-ENOMEM);
- }
- /*
-* plane init
-* TODO: Now only support primary plane, overlay planes
-* need to do.
-*/
- ret = drm_universal_plane_init(dev, plane, 1, _plane_funcs,
- channel_formats1,
- ARRAY_SIZE(channel_formats1),
- NULL,
- DRM_PLANE_TYPE_PRIMARY,
- NULL);
- if (ret) {
- DRM_ERROR("failed to init plane: %d\n", ret);
- return ERR_PTR(ret);
- }
-
- drm_plane_helper_add(plane, _plane_helper_funcs);
- return plane;
-}
-
static void hibmc_crtc_dpms(struct drm_crtc *crtc, int dpms)
{
struct hibmc_drm_private *priv = crtc->dev->dev_private;
@@ -537,22 +506,24 @@ static const struct drm_crtc_helper_funcs
hibmc_crtc_helper_funcs = {
int hibmc_de_init(struct hibmc_drm_private *priv)
{
struct drm_device *dev = priv->dev;
- struct drm_crtc *crtc;
- struct drm_plane *plane;
+ struct drm_crtc *crtc = >crtc;
+ struct drm_plane *plane = >primary_plane;
int ret;
- plane = hibmc_plane_init(priv);
- if (IS_ERR(plane)) {
- DRM_ERROR("failed to create plane: %ld\n", PTR_ERR(plane));
- return PTR_ERR(plane);
- }
+ ret = drm_universal_plane_init(dev, plane, 1, _plane_funcs,
+ channel_formats1,
+ ARRAY_SIZE(channel_formats1),
+ NULL,
+ DRM_PLANE_TYPE_PRIMARY,
+ NULL);
- crtc = devm_kzalloc(dev->dev, sizeof(*crtc), GFP_KERNEL);
- if (!crtc) {
- DRM_ERROR("failed to alloc memory when init crtc\n");
- return -ENOMEM;
+ if (ret) {
+ DRM_ERROR("failed to init plane: %d\n", ret);
+ return ret;
}
+ drm_plane_helper_add(plane, _plane_helper_funcs);
+
ret = drm_crtc_init_with_planes(dev, crtc, plane,
NULL, _crtc_funcs, NULL);
if (ret) {
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 609768748de65..0a74ba220cac5 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -29,6 +29,8 @@ struct hibmc_drm_private {
/* drm */
struct drm_device *dev;
+ struct drm_plane primary_plane;
+ struct drm_crtc crtc;
struct drm_encoder encoder;
struct drm_connector connector;
bool mode_config_initialized;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 082/111] Fix use after free in get_capset_info callback.
From: Doug Horn
[ Upstream commit e219688fc5c3d0d9136f8d29d7e0498388f01440 ]
If a response to virtio_gpu_cmd_get_capset_info takes longer than
five seconds to return, the callback will access freed kernel memory
in vg->capsets.
Signed-off-by: Doug Horn
Link:
http://patchwork.freedesktop.org/patch/msgid/20200902210847.2689-2-gurchetansi...@chromium.org
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 2 ++
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 4d944a0dff3e9..fdd7671a7b126 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -80,8 +80,10 @@ static void virtio_gpu_get_capsets(struct virtio_gpu_device
*vgdev,
vgdev->capsets[i].id > 0, 5 * HZ);
if (ret == 0) {
DRM_ERROR("timed out waiting for cap set %d\n", i);
+ spin_lock(>display_info_lock);
kfree(vgdev->capsets);
vgdev->capsets = NULL;
+ spin_unlock(>display_info_lock);
return;
}
DRM_INFO("cap set %d: id %d, max-version %d, max-size %d\n",
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 53af60d484a44..9d2abdbd865a7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -684,9 +684,13 @@ static void virtio_gpu_cmd_get_capset_info_cb(struct
virtio_gpu_device *vgdev,
int i = le32_to_cpu(cmd->capset_index);
spin_lock(>display_info_lock);
- vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
- vgdev->capsets[i].max_version = le32_to_cpu(resp->capset_max_version);
- vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ if (vgdev->capsets) {
+ vgdev->capsets[i].id = le32_to_cpu(resp->capset_id);
+ vgdev->capsets[i].max_version =
le32_to_cpu(resp->capset_max_version);
+ vgdev->capsets[i].max_size = le32_to_cpu(resp->capset_max_size);
+ } else {
+ DRM_ERROR("invalid capset memory.");
+ }
spin_unlock(>display_info_lock);
wake_up(>resp_wq);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 110/111] drm/panfrost: perfcnt: fix ref count leak in panfrost_perfcnt_enable_locked
From: Navid Emamdoost
[ Upstream commit 9df0e0c1889677175037445d5ad1654d54176369 ]
in panfrost_perfcnt_enable_locked, pm_runtime_get_sync is called which
increments the counter even in case of failure, leading to incorrect
ref count. In case of failure, decrement the ref count before returning.
Acked-by: Alyssa Rosenzweig
Signed-off-by: Navid Emamdoost
Signed-off-by: Rob Herring
Link:
https://patchwork.freedesktop.org/patch/msgid/20200614063619.44944-1-navid.emamdo...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_perfcnt.c
b/drivers/gpu/drm/panfrost/panfrost_perfcnt.c
index ec4695cf3caf3..fdbc8d9491356 100644
--- a/drivers/gpu/drm/panfrost/panfrost_perfcnt.c
+++ b/drivers/gpu/drm/panfrost/panfrost_perfcnt.c
@@ -83,11 +83,13 @@ static int panfrost_perfcnt_enable_locked(struct
panfrost_device *pfdev,
ret = pm_runtime_get_sync(pfdev->dev);
if (ret < 0)
- return ret;
+ goto err_put_pm;
bo = drm_gem_shmem_create(pfdev->ddev, perfcnt->bosize);
- if (IS_ERR(bo))
- return PTR_ERR(bo);
+ if (IS_ERR(bo)) {
+ ret = PTR_ERR(bo);
+ goto err_put_pm;
+ }
/* Map the perfcnt buf in the address space attached to file_priv. */
ret = panfrost_gem_open(>base, file_priv);
@@ -168,6 +170,8 @@ static int panfrost_perfcnt_enable_locked(struct
panfrost_device *pfdev,
panfrost_gem_close(>base, file_priv);
err_put_bo:
drm_gem_object_put(>base);
+err_put_pm:
+ pm_runtime_put(pfdev->dev);
return ret;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 071/111] drm: fix double free for gbo in drm_gem_vram_init and drm_gem_vram_create
From: Jia Yang
[ Upstream commit da62cb7230f0871c30dc9789071f63229158d261 ]
I got a use-after-free report when doing some fuzz test:
If ttm_bo_init() fails, the "gbo" and "gbo->bo.base" will be
freed by ttm_buffer_object_destroy() in ttm_bo_init(). But
then drm_gem_vram_create() and drm_gem_vram_init() will free
"gbo" and "gbo->bo.base" again.
BUG: KMSAN: use-after-free in drm_vma_offset_remove+0xb3/0x150
CPU: 0 PID: 24282 Comm: syz-executor.1 Tainted: GB W
5.7.0-rc4-msan #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
Call Trace:
__dump_stack
dump_stack+0x1c9/0x220
kmsan_report+0xf7/0x1e0
__msan_warning+0x58/0xa0
drm_vma_offset_remove+0xb3/0x150
drm_gem_free_mmap_offset
drm_gem_object_release+0x159/0x180
drm_gem_vram_init
drm_gem_vram_create+0x7c5/0x990
drm_gem_vram_fill_create_dumb
drm_gem_vram_driver_dumb_create+0x238/0x590
drm_mode_create_dumb
drm_mode_create_dumb_ioctl+0x41d/0x450
drm_ioctl_kernel+0x5a4/0x710
drm_ioctl+0xc6f/0x1240
vfs_ioctl
ksys_ioctl
__do_sys_ioctl
__se_sys_ioctl+0x2e9/0x410
__x64_sys_ioctl+0x4a/0x70
do_syscall_64+0xb8/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4689b9
Code: fd e0 fa ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
cb e0 fa ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f368fa4dc98 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 0076bf00 RCX: 004689b9
RDX: 2240 RSI: c02064b2 RDI: 0003
RBP: 0004 R08: R09:
R10: R11: 0246 R12:
R13: 004d17e0 R14: 7f368fa4e6d4 R15: 0076bf0c
Uninit was created at:
kmsan_save_stack_with_flags
kmsan_internal_poison_shadow+0x66/0xd0
kmsan_slab_free+0x6e/0xb0
slab_free_freelist_hook
slab_free
kfree+0x571/0x30a0
drm_gem_vram_destroy
ttm_buffer_object_destroy+0xc8/0x130
ttm_bo_release
kref_put
ttm_bo_put+0x117d/0x23e0
ttm_bo_init_reserved+0x11c0/0x11d0
ttm_bo_init+0x289/0x3f0
drm_gem_vram_init
drm_gem_vram_create+0x775/0x990
drm_gem_vram_fill_create_dumb
drm_gem_vram_driver_dumb_create+0x238/0x590
drm_mode_create_dumb
drm_mode_create_dumb_ioctl+0x41d/0x450
drm_ioctl_kernel+0x5a4/0x710
drm_ioctl+0xc6f/0x1240
vfs_ioctl
ksys_ioctl
__do_sys_ioctl
__se_sys_ioctl+0x2e9/0x410
__x64_sys_ioctl+0x4a/0x70
do_syscall_64+0xb8/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
If ttm_bo_init() fails, the "gbo" will be freed by
ttm_buffer_object_destroy() in ttm_bo_init(). But then
drm_gem_vram_create() and drm_gem_vram_init() will free
"gbo" again.
Reported-by: Hulk Robot
Reported-by: butt3rflyh4ck
Signed-off-by: Jia Yang
Signed-off-by: Thomas Zimmermann
Reviewed-by: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20200714083238.28479-2-tzimmerm...@suse.de
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_gem_vram_helper.c | 28 +++
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 3296ed3df3580..8b65ca164bf4b 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -167,6 +167,10 @@ static void drm_gem_vram_placement(struct
drm_gem_vram_object *gbo,
}
}
+/*
+ * Note that on error, drm_gem_vram_init will free the buffer object.
+ */
+
static int drm_gem_vram_init(struct drm_device *dev,
struct drm_gem_vram_object *gbo,
size_t size, unsigned long pg_align)
@@ -176,15 +180,19 @@ static int drm_gem_vram_init(struct drm_device *dev,
int ret;
size_t acc_size;
- if (WARN_ONCE(!vmm, "VRAM MM not initialized"))
+ if (WARN_ONCE(!vmm, "VRAM MM not initialized")) {
+ kfree(gbo);
return -EINVAL;
+ }
bdev = >bdev;
gbo->bo.base.funcs = _gem_vram_object_funcs;
ret = drm_gem_object_init(dev, >bo.base, size);
- if (ret)
+ if (ret) {
+ kfree(gbo);
return ret;
+ }
acc_size = ttm_bo_dma_acc_size(bdev, size, sizeof(*gbo));
@@ -195,13 +203,13 @@ static int drm_gem_vram_init(struct drm_device *dev,
>placement, pg_align, false, acc_size,
NULL, NULL, ttm_buffer_object_destroy);
if (ret)
- goto err_drm_gem_object_release;
+ /*
+* A failing ttm_bo_init will call ttm_buffer_object_destroy
+* to release gbo->bo.base and kfree gbo.
+*/
+ return ret;
return 0;
-
-err_drm_gem_object_release:
- drm_gem_object_release(>bo.base);
- return ret;
}
/**
@@ -235,13 +243,9 @@ struct drm_gem_vram_object
[PATCH AUTOSEL 5.9 073/111] drm/msm/a6xx: fix a potential overflow issue
From: Zhenzhong Duan [ Upstream commit 08d3ab4b46339bc6f97e83b54a3fb4f8bf8f4cd9 ] It's allocating an array of a6xx_gpu_state_obj structure rathor than its pointers. This patch fix it. Signed-off-by: Zhenzhong Duan Signed-off-by: Rob Clark Signed-off-by: Sasha Levin --- drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c index b12f5b4a1bea9..e9ede19193b0e 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c @@ -875,7 +875,7 @@ static void a6xx_get_indexed_registers(struct msm_gpu *gpu, int i; a6xx_state->indexed_regs = state_kcalloc(a6xx_state, count, - sizeof(a6xx_state->indexed_regs)); + sizeof(*a6xx_state->indexed_regs)); if (!a6xx_state->indexed_regs) return; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 074/111] drm/xlnx: Use devm_drm_dev_alloc
From: Daniel Vetter
[ Upstream commit 075342ea3d93044d68f821cf91c1a1a7d2fa569e ]
Gets rid of drmm_add_final_kfree, which I want to unexport so that it
stops confusion people about this transitional state of rolling drm
managed memory out.
This also fixes the missing drm_dev_put in the error path of the probe
code.
v2: Drop the misplaced drm_dev_put from zynqmp_dpsub_drm_init (all
other paths leaked on error, this should have been in
zynqmp_dpsub_probe), now that subsumed by the auto-cleanup of
devm_drm_dev_alloc.
Reviewed-by: Hyun Kwon
Signed-off-by: Daniel Vetter
Cc: Hyun Kwon
Cc: Laurent Pinchart
Cc: Michal Simek
Cc: linux-arm-ker...@lists.infradead.org
Link:
https://patchwork.freedesktop.org/patch/msgid/20200907082225.150837-1-daniel.vet...@ffwll.ch
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
index 26328c76305be..8e69303aad3f7 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -111,7 +111,7 @@ static int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub)
/* Initialize mode config, vblank and the KMS poll helper. */
ret = drmm_mode_config_init(drm);
if (ret < 0)
- goto err_dev_put;
+ return ret;
drm->mode_config.funcs = _dpsub_mode_config_funcs;
drm->mode_config.min_width = 0;
@@ -121,7 +121,7 @@ static int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub)
ret = drm_vblank_init(drm, 1);
if (ret)
- goto err_dev_put;
+ return ret;
drm->irq_enabled = 1;
@@ -154,8 +154,6 @@ static int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub)
err_poll_fini:
drm_kms_helper_poll_fini(drm);
-err_dev_put:
- drm_dev_put(drm);
return ret;
}
@@ -208,27 +206,16 @@ static int zynqmp_dpsub_probe(struct platform_device
*pdev)
int ret;
/* Allocate private data. */
- dpsub = kzalloc(sizeof(*dpsub), GFP_KERNEL);
- if (!dpsub)
- return -ENOMEM;
+ dpsub = devm_drm_dev_alloc(>dev, _dpsub_drm_driver,
+ struct zynqmp_dpsub, drm);
+ if (IS_ERR(dpsub))
+ return PTR_ERR(dpsub);
dpsub->dev = >dev;
platform_set_drvdata(pdev, dpsub);
dma_set_mask(dpsub->dev, DMA_BIT_MASK(ZYNQMP_DISP_MAX_DMA_BIT));
- /*
-* Initialize the DRM device early, as the DRM core mandates usage of
-* the managed memory helpers tied to the DRM device.
-*/
- ret = drm_dev_init(>drm, _dpsub_drm_driver, >dev);
- if (ret < 0) {
- kfree(dpsub);
- return ret;
- }
-
- drmm_add_final_kfree(>drm, dpsub);
-
/* Try the reserved memory. Proceed if there's none. */
of_reserved_mem_device_init(>dev);
@@ -286,8 +273,6 @@ static int zynqmp_dpsub_remove(struct platform_device *pdev)
clk_disable_unprepare(dpsub->apb_clk);
of_reserved_mem_device_release(>dev);
- drm_dev_put(drm);
-
return 0;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 063/111] drm/panfrost: add support for vendor quirk
From: Neil Armstrong
[ Upstream commit 91e89097b86f566636ea5a7329c79d5521be46d2 ]
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM,
G12A/SM1 & G12B SoCs needs a quirk in the PWR registers after each reset.
This adds a callback in the device compatible struct of permit this.
Signed-off-by: Neil Armstrong
[Steven: Fix typo in commit log]
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Steven Price
Link:
https://patchwork.freedesktop.org/patch/msgid/20200916150147.25753-2-narmstr...@baylibre.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_device.h | 3 +++
drivers/gpu/drm/panfrost/panfrost_gpu.c| 4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index c30c719a80594..3c4a85213c15f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -69,6 +69,9 @@ struct panfrost_compatible {
int num_pm_domains;
/* Only required if num_pm_domains > 1. */
const char * const *pm_domain_names;
+
+ /* Vendor implementation quirks callback */
+ void (*vendor_quirk)(struct panfrost_device *pfdev);
};
struct panfrost_device {
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index 6606643850fc6..502b1f1f7b204 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -146,6 +146,10 @@ static void panfrost_gpu_init_quirks(struct
panfrost_device *pfdev)
if (quirks)
gpu_write(pfdev, GPU_JM_CONFIG, quirks);
+
+ /* Here goes platform specific quirks */
+ if (pfdev->comp->vendor_quirk)
+ pfdev->comp->vendor_quirk(pfdev);
}
#define MAX_HW_REVS 6
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 062/111] drm/panfrost: add amlogic reset quirk callback
From: Neil Armstrong
[ Upstream commit 110003002291525bb209f47e6dbf121a63249a97 ]
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM,
G12A/SM1 & G12B SoCs needs a quirk in the PWR registers at the GPU reset
time.
Since the Amlogic's integration of the GPU cores with the SoC is not
publicly documented we do not know what does these values, but they
permit having a fully functional GPU running with Panfrost.
Signed-off-by: Neil Armstrong
[Steven: Fix typo in commit log]
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Steven Price
Link:
https://patchwork.freedesktop.org/patch/msgid/20200916150147.25753-3-narmstr...@baylibre.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 11 +++
drivers/gpu/drm/panfrost/panfrost_gpu.h | 2 ++
drivers/gpu/drm/panfrost/panfrost_regs.h | 4
3 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index f2c1ddc41a9bf..6606643850fc6 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -75,6 +75,17 @@ int panfrost_gpu_soft_reset(struct panfrost_device *pfdev)
return 0;
}
+void panfrost_gpu_amlogic_quirk(struct panfrost_device *pfdev)
+{
+ /*
+* The Amlogic integrated Mali-T820, Mali-G31 & Mali-G52 needs
+* these undocumented bits in GPU_PWR_OVERRIDE1 to be set in order
+* to operate correctly.
+*/
+ gpu_write(pfdev, GPU_PWR_KEY, GPU_PWR_KEY_UNLOCK);
+ gpu_write(pfdev, GPU_PWR_OVERRIDE1, 0xfff | (0x20 << 16));
+}
+
static void panfrost_gpu_init_quirks(struct panfrost_device *pfdev)
{
u32 quirks = 0;
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.h
b/drivers/gpu/drm/panfrost/panfrost_gpu.h
index 4112412087b27..468c51e7e46db 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.h
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.h
@@ -16,4 +16,6 @@ int panfrost_gpu_soft_reset(struct panfrost_device *pfdev);
void panfrost_gpu_power_on(struct panfrost_device *pfdev);
void panfrost_gpu_power_off(struct panfrost_device *pfdev);
+void panfrost_gpu_amlogic_quirk(struct panfrost_device *pfdev);
+
#endif
diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h
b/drivers/gpu/drm/panfrost/panfrost_regs.h
index ea38ac60581c6..eddaa62ad8b0e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_regs.h
+++ b/drivers/gpu/drm/panfrost/panfrost_regs.h
@@ -51,6 +51,10 @@
#define GPU_STATUS 0x34
#define GPU_STATUS_PRFCNT_ACTIVE BIT(2)
#define GPU_LATEST_FLUSH_ID0x38
+#define GPU_PWR_KEY0x50/* (WO) Power manager key
register */
+#define GPU_PWR_KEY_UNLOCK0x2968A819
+#define GPU_PWR_OVERRIDE0 0x54/* (RW) Power manager override
settings */
+#define GPU_PWR_OVERRIDE1 0x58/* (RW) Power manager override
settings */
#define GPU_FAULT_STATUS 0x3C
#define GPU_FAULT_ADDRESS_LO 0x40
#define GPU_FAULT_ADDRESS_HI 0x44
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.9 061/111] drm/panfrost: add Amlogic GPU integration quirks
From: Neil Armstrong
[ Upstream commit afcd0c7d3d4c22afc8befcfc906db6ce3058d3ee ]
This adds the required GPU quirks, including the quirk in the PWR
registers at the GPU reset time and the IOMMU quirk for shareability
issues observed on G52 in Amlogic G12B SoCs.
Signed-off-by: Neil Armstrong
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Steven Price
Link:
https://patchwork.freedesktop.org/patch/msgid/20200916150147.25753-4-narmstr...@baylibre.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index ada51df9a7a32..f6d5d03201fad 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -667,7 +667,18 @@ static const struct panfrost_compatible default_data = {
.pm_domain_names = NULL,
};
+static const struct panfrost_compatible amlogic_data = {
+ .num_supplies = ARRAY_SIZE(default_supplies),
+ .supply_names = default_supplies,
+ .vendor_quirk = panfrost_gpu_amlogic_quirk,
+};
+
static const struct of_device_id dt_match[] = {
+ /* Set first to probe before the generic compatibles */
+ { .compatible = "amlogic,meson-gxm-mali",
+ .data = _data, },
+ { .compatible = "amlogic,meson-g12a-mali",
+ .data = _data, },
{ .compatible = "arm,mali-t604", .data = _data, },
{ .compatible = "arm,mali-t624", .data = _data, },
{ .compatible = "arm,mali-t628", .data = _data, },
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
It appears drm-next TTM cleanup broke something . . .
Hi Dave, It is a little urgent, so I am writing this right now. As usual, I pulled in DRM repository code for an out of tree OpenChrome DRM repository a few days ago. While going through the changes I need to make to OpenChrome DRM to compile with the latest Linux kernel, I noticed that ttm_bo_init_mm() was discontinued, and it was replaced with ttm_range_man_init(). ttm_range_man_init() has a parameter called "bool use_tt", but honestly, I do not think it is functioning correctly. If I keep "ttm_tt_create" member of ttm_bo_driver struct null by not specifying it, TTM still tries to call it, and crashes due to a null pointer access. The workaround I found so far is to specify the "ttm_tt_create" member by copying bo_driver_ttm_tt_create() from drm/drm_gem_vram_helper.c. This is what the call trace looks like without specifying the "ttm_tt_create" member (i.e., this member is null). ___ . . . kernel: [ 34.310674] [drm:openchrome_bo_create [openchrome]] Entered openchrome_bo_create. kernel: [ 34.310697] [drm:openchrome_ttm_domain_to_placement [openchrome]] Entered openchrome_ttm_domain_to_placement. kernel: [ 34.310706] [drm:openchrome_ttm_domain_to_placement [openchrome]] Exiting openchrome_ttm_domain_to_placement. kernel: [ 34.310737] BUG: kernel NULL pointer dereference, address: kernel: [ 34.310742] #PF: supervisor instruction fetch in kernel mode kernel: [ 34.310745] #PF: error_code(0x0010) - not-present page . . . kernel: [ 34.310807] Call Trace: kernel: [ 34.310827] ttm_tt_create+0x5f/0xa0 [ttm] kernel: [ 34.310839] ttm_bo_validate+0xb8/0x140 [ttm] kernel: [ 34.310886] ? drm_vma_offset_add+0x56/0x70 [drm] kernel: [ 34.310897] ? openchrome_gem_create_ioctl+0x150/0x150 [openchrome] . . . ___ The erroneous call to "ttm_tt_create" member happens right after TTM placement is performed (openchrome_ttm_domain_to_placement()). Currently, OpenChrome DRM's TTM implementation does not use "ttm_tt_create" member, and this arrangement worked fine until Linux 5.9's drm-next code. It appears that Linux 5.10's drm-next code broke the code. Regards, Kevin Brace Brace Computer Laboratory blog https://bracecomputerlab.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote: > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: > > clang has a number of useful, new warnings see > > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$ > > > > Please get your IT department to remove that stupidity. If you can't, > please send email from a non-Red Hat email address. I didn't get it this way, neither did lore. It's on your end. https://lore.kernel.org/lkml/20201017160928.12698-1-t...@redhat.com/ > I don't understand why this is a useful warning to fix. Precision in coding style intent and code minimization would be the biggest factors IMO. > What actual problem is caused by the code below? Obviously none. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/5] RDMA/umem: Support importing dma-buf as user memory region
On Sat, Oct 17, 2020 at 9:05 PM Jason Gunthorpe wrote:
>
> On Thu, Oct 15, 2020 at 03:02:45PM -0700, Jianxin Xiong wrote:
>
> > +static void ib_umem_dmabuf_invalidate_cb(struct dma_buf_attachment *attach)
> > +{
> > + struct ib_umem_dmabuf *umem_dmabuf = attach->importer_priv;
> > +
> > + dma_resv_assert_held(umem_dmabuf->attach->dmabuf->resv);
> > +
> > + ib_umem_dmabuf_unmap_pages(_dmabuf->umem, true);
> > + queue_work(ib_wq, _dmabuf->work);
>
> Do we really want to queue remapping or should it wait until there is
> a page fault?
>
> What do GPUs do?
Atm no gpu drivers in upstream that use buffer-based memory management
and support page faults in the hw. So we have to pull the entire thing
in anyway and use the dma_fence stuff to track what's busy.
For faulting hardware I'd wait until the first page fault and then map
in the entire range again (you get the entire thing anyway). Since the
move_notify happened because the buffer is moving, you'll end up
stalling anyway. Plus if you prefault right away you need some
thrashing limiter to not do that when you get immediate move_notify
again. As a first thing I'd do the same thing you do for mmu notifier
ranges, since it's kinda similarish.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] treewide: cleanup unreachable breaks
On 10/17/20 10:43 PM, Greg KH wrote: > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: >> From: Tom Rix >> >> This is a upcoming change to clean up a new warning treewide. >> I am wondering if the change could be one mega patch (see below) or >> normal patch per file about 100 patches or somewhere half way by collecting >> early acks. > Please break it up into one-patch-per-subsystem, like normal, and get it > merged that way. OK. Thanks, Tom > > Sending us a patch, without even a diffstat to review, isn't going to > get you very far... > > thanks, > > greg k-h > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/panel: mantix panel reset fixes
Hi Guido > On Sun, Oct 18, 2020 at 03:01:22PM +0200, Guido Günther wrote: > Hi Sam, > On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote: > > Hi Guido. > > > > On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wrote: > > > Hi Sam, > > > On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote: > > > > Hi Guido. > > > > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote: > > > [..snip..] > > > > > > > > > > Changes from v1: > > > > > - As per review comments by Fabio Estevam > > > > > > > > > > https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/ > > > > >- Fix typo in commit messages > > > > > - As per review comments by Rob Herring > > > > >https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/ > > > > >- Don't use an array of reset lines > > > > > > > > > > Guido Günther (3): > > > > > drm/panel: mantix: Don't dereference NULL mode > > > > > drm/panel: mantix: Fix panel reset > > > > > dt-binding: display: Require two resets on mantix panel > > > > > > > > All applied to drm-misc-next and pushed out. > > > > And then I remembered you had commit right - sigh. > > > > > > Thanks! Is there any special care needed to get that into 5.10? The > > > driver landed there in 72967d5616d3f0c714f8eb6c4e258179a9031c45. > > > > As the patches was applied to drm-misc-next the easiet path would > > be to cherry-pick them and apply to drm-misc-fixes. > > dim has cherry-pick support - try to use it rahter than doing it by > > hand. > > Does that require any further ACKs or just cherry-pick and push out? To the best of my knowledge just cherry-pick, test and push out. Sam > > > When you apply to drm-misc-fixes include a Fixes: tag so the tooling > > will pick the patches automagically. > > Will do. It was unfortunate that the initial ones didn't get them but > i think the drm merge happened while v2 was out on the list. I'll try > add that relevant information to the cover letter in the future. > > Cheers, > -- Guido > > > > > In hindsight the patches should have carried a Fixes: tag from a start > > and should have been applied to drm-misc-fixes from a start too. > > > > I have done something like above once or twice but anyway reach out if > > you have questions. Or ask at #dri-devel. > > > > Sam > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/panel/oneplus6: Add panel-oneplus6
Hi Caleb.
I have missed to provice review feedback so here goes.
There is some improvements that can be made as the infrastructure has
evolved since the driver was started.
But despite the number of comments below it is all trivial and the
driver looks good in general.
I look forward to see the next revision.
Sam
On Wed, Oct 07, 2020 at 05:49:08PM +, Caleb Connolly wrote:
> This commit adds support for the display panels used in the OnePlus 6 /
> T devices.
>
> The OnePlus 6/T devices use different panels however they are
> functionally identical with much of the commands being shared. The
> panels don't appear to be used by any other devices some combine them as
> one driver that is specific to the devices.
>
> The panels are: samsung,sofef00
> and samsung,s6e3fc2x01
>
> Signed-off-by: Caleb Connolly
> ---
> drivers/gpu/drm/panel/Kconfig | 12 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-oneplus6.c | 418 +
It would be better to name the driver after the panels and not their
user. So something like panel-samsung-sofef00.
It is OK to name it after one panel and let it support mroe than one
panel. The Kconfig description could then expain where it is used.
> 3 files changed, 431 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-oneplus6.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index de2f2a452be5..d72862265400 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -229,6 +229,18 @@ config DRM_PANEL_OLIMEX_LCD_OLINUXINO
> Say Y here if you want to enable support for Olimex Ltd.
> LCD-OLinuXino panel.
>
> +config DRM_PANEL_ONEPLUS6
> + tristate "OnePlus 6/6T Samsung AMOLED DSI command mode panels"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + select VIDEOMODE_HELPERS
> + help
> + Say Y or M here if you want to enable support for the Samsung AMOLED
> + command mode panels found in the OnePlus 6/6T smartphones.
> +
> + The panels are 2280x1080@60Hz and 2340x1080@60Hz respectively
> +
> config DRM_PANEL_ORISETECH_OTM8009A
> tristate "Orise Technology otm8009a 480x800 dsi 2dl panel"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index e45ceac6286f..017539056f53 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) +=
> panel-nec-nl8048hl11.o
> obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
> obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
> obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
> +obj-$(CONFIG_DRM_PANEL_ONEPLUS6) += panel-oneplus6.o
> obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
> obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) += panel-osd-osd101t2587-53ts.o
> obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
> panel-panasonic-vvx10f034n00.o
> diff --git a/drivers/gpu/drm/panel/panel-oneplus6.c
> b/drivers/gpu/drm/panel/panel-oneplus6.c
> new file mode 100644
> index ..5e212774b1e0
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-oneplus6.c
> @@ -0,0 +1,418 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright (c) 2020 Caleb Connolly
> + * Generated with linux-mdss-dsi-panel-driver-generator from vendor device
> tree:
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + *
> + * Caleb Connolly
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
Keep all linux include together.
> +
> +struct oneplus6_panel {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> + struct backlight_device *backlight;
Use drm_panel backlight support - so you can drop this variable and
simplify some of the code below.
> + struct regulator *supply;
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *enable_gpio;
The enable_gpio is not used.
> + const struct drm_display_mode *mode;
> + bool prepared;
> + bool enabled;
> +};
> +
> +static inline
> +struct oneplus6_panel *to_oneplus6_panel(struct drm_panel *panel)
> +{
> + return container_of(panel, struct oneplus6_panel, panel);
> +}
> +
> +#define dsi_dcs_write_seq(dsi, seq...) do { \
> + static const u8 d[] = { seq }; \
> + int ret;\
> + ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
> + if (ret < 0)\
> + return ret; \
> + } while (0)
> +
> +static void
Re: [PATCH v2 0/3] drm/panel: mantix panel reset fixes
Hi Sam, On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote: > Hi Guido. > > On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wrote: > > Hi Sam, > > On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote: > > > Hi Guido. > > > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote: > > [..snip..] > > > > > > > > Changes from v1: > > > > - As per review comments by Fabio Estevam > > > > > > > > https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/ > > > >- Fix typo in commit messages > > > > - As per review comments by Rob Herring > > > >https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/ > > > >- Don't use an array of reset lines > > > > > > > > Guido Günther (3): > > > > drm/panel: mantix: Don't dereference NULL mode > > > > drm/panel: mantix: Fix panel reset > > > > dt-binding: display: Require two resets on mantix panel > > > > > > All applied to drm-misc-next and pushed out. > > > And then I remembered you had commit right - sigh. > > > > Thanks! Is there any special care needed to get that into 5.10? The > > driver landed there in 72967d5616d3f0c714f8eb6c4e258179a9031c45. > > As the patches was applied to drm-misc-next the easiet path would > be to cherry-pick them and apply to drm-misc-fixes. > dim has cherry-pick support - try to use it rahter than doing it by > hand. Does that require any further ACKs or just cherry-pick and push out? > When you apply to drm-misc-fixes include a Fixes: tag so the tooling > will pick the patches automagically. Will do. It was unfortunate that the initial ones didn't get them but i think the drm merge happened while v2 was out on the list. I'll try add that relevant information to the cover letter in the future. Cheers, -- Guido > > In hindsight the patches should have carried a Fixes: tag from a start > and should have been applied to drm-misc-fixes from a start too. > > I have done something like above once or twice but anyway reach out if > you have questions. Or ask at #dri-devel. > > Sam > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] treewide: cleanup unreachable breaks
Hi Tom,
Quick self intro: I have take over drivers/platform/x86
maintainership from Andy.
On 10/17/20 6:09 PM, t...@redhat.com wrote:
> From: Tom Rix
>
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
> early acks.
>
> clang has a number of useful, new warnings see
> https://clang.llvm.org/docs/DiagnosticsReference.html
>
> This change cleans up -Wunreachable-code-break
> https://clang.llvm.org/docs/DiagnosticsReference.html#wunreachable-code-break
> for 266 of 485 warnings in this week's linux-next, allyesconfig on x86_64.
>
> The method of fixing was to look for warnings where the preceding statement
> was a simple statement and by inspection made the subsequent break unneeded.
> In order of frequency these look like
>
> return and break
>
> switch (c->x86_vendor) {
> case X86_VENDOR_INTEL:
> intel_p5_mcheck_init(c);
> return 1;
> - break;
>
> goto and break
>
> default:
> operation = 0; /* make gcc happy */
> goto fail_response;
> - break;
>
> break and break
> case COLOR_SPACE_SRGB:
> /* by pass */
> REG_SET(OUTPUT_CSC_CONTROL, 0,
> OUTPUT_CSC_GRPH_MODE, 0);
> break;
> - break;
>
> The exception to the simple statement, is a switch case with a block
> and the end of block is a return
>
> struct obj_buffer *buff = r->ptr;
> return scnprintf(str, PRIV_STR_SIZE,
> "size=%u\naddr=0x%X\n", buff->size,
> buff->addr);
> }
> - break;
>
> Not considered obvious and excluded, breaks after
> multi level switches
> complicated if-else if-else blocks
> panic() or similar calls
>
> And there is an odd addition of a 'fallthrough' in drivers/tty/nozomi.c
As Greg already mentioned please split this out into per subsystem patches.
I would be happy to take all the changes to drivers/platform/x86
code upstream as a single patch for all the files there.
Regards,
Hans
> ---
>
> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
> index 1c08cb9eb9f6..16ce86aed8e2 100644
> --- a/arch/x86/kernel/cpu/mce/core.c
> +++ b/arch/x86/kernel/cpu/mce/core.c
> @@ -1809,15 +1809,13 @@ static int __mcheck_cpu_ancient_init(struct
> cpuinfo_x86 *c)
>
> switch (c->x86_vendor) {
> case X86_VENDOR_INTEL:
> intel_p5_mcheck_init(c);
> return 1;
> - break;
> case X86_VENDOR_CENTAUR:
> winchip_mcheck_init(c);
> return 1;
> - break;
> default:
> return 0;
> }
>
> return 0;
> diff --git a/arch/x86/kernel/cpu/microcode/amd.c
> b/arch/x86/kernel/cpu/microcode/amd.c
> index 3f6b137ef4e6..3d4a48336084 100644
> --- a/arch/x86/kernel/cpu/microcode/amd.c
> +++ b/arch/x86/kernel/cpu/microcode/amd.c
> @@ -213,11 +213,10 @@ static unsigned int __verify_patch_size(u8 family, u32
> sh_psize, size_t buf_size
> max_size = F14H_MPB_MAX_SIZE;
> break;
> default:
> WARN(1, "%s: WTF family: 0x%x\n", __func__, family);
> return 0;
> - break;
> }
>
> if (sh_psize > min_t(u32, buf_size, max_size))
> return 0;
>
> diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
> index 838b719ec7ce..d5411a166685 100644
> --- a/drivers/acpi/utils.c
> +++ b/drivers/acpi/utils.c
> @@ -102,11 +102,10 @@ acpi_extract_package(union acpi_object *package,
> printk(KERN_WARNING PREFIX "Invalid package
> element"
> " [%d]: got number, expecting"
> " [%c]\n",
> i, format_string[i]);
> return AE_BAD_DATA;
> - break;
> }
> break;
>
> case ACPI_TYPE_STRING:
> case ACPI_TYPE_BUFFER:
> @@ -127,11 +126,10 @@ acpi_extract_package(union acpi_object *package,
> printk(KERN_WARNING PREFIX "Invalid package
> element"
> " [%d] got string/buffer,"
> " expecting [%c]\n",
> i, format_string[i]);
> return AE_BAD_DATA;
> - break;
> }
> break;
> case ACPI_TYPE_LOCAL_REFERENCE:
> switch (format_string[i]) {
>
