Re: [DPU PATCH v5 1/5] dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon
Hi Tanmay Reviewing the yaml bindings triggered a few comments. See below. Sam On Tue, Mar 31, 2020 at 05:30:27PM -0700, Tanmay Shah wrote: > From: Chandan Uddaraju > > Add bindings for Snapdragon DisplayPort and > display-port PLL driver. > > Changes in V2: > Provide details about sel-gpio > > Changes in V4: > Provide details about max dp lanes > Change the commit text > > Changes in V5: > Moved dp.txt to yaml file. > > Signed-off-by: Chandan Uddaraju > Signed-off-by: Vara Reddy As you handle the patch, thus the patch passed throgh you, you are supposed to sign-off the patch. The changes to dpu.txt is not explained in the changelog. > --- > .../devicetree/bindings/display/msm/dp-sc7180.yaml | 325 > + > .../devicetree/bindings/display/msm/dpu.txt| 16 +- > 2 files changed, 337 insertions(+), 4 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/msm/dp-sc7180.yaml > > diff --git a/Documentation/devicetree/bindings/display/msm/dp-sc7180.yaml > b/Documentation/devicetree/bindings/display/msm/dp-sc7180.yaml > new file mode 100644 > index 000..761a01d > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/msm/dp-sc7180.yaml > @@ -0,0 +1,325 @@ > +# SPDX-License-Identifier: GPL-2.0-only For new bindings please use: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/msm/dp-sc7180.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Description of Qualcomm Display Port dt properties. > + > +maintainers: > + - Chandan Uddaraju > + - Vara Reddy > + > +description: | > + Device tree bindings for MSM Display Port which supports DP host > controllers > + that are compatible with VESA Display Port interface specification. > + > +properties: > + "msm_dp": The quotes seems not necessary. This describes the name of the node. The typical way to identify a node is using a compatible. So I think that the right solution here is to drop "msm_dp". > +type: object > +description: | > + Node containing Display port register address bases, clocks, power > supplies. > + And start here. > +properties: > + compatible: > + items: > + - const: qcom,dp-display > + > + cell-index: > + description: Specifies the controller instance. > + > + reg: > + description: Physical base address and length of controller's > registers. This description is generic and can be omitted. But it would be good with a descrition of the individual registers like this: reg: items: - description: AHB bla bla - description: aux bla bla > + > + reg-names: > + description: | > + Names for different register regions defined above. The required > region > + is mentioned below. > + items: > + - const: dp_ahb > + - const: dp_aux > + - const: dp_link > + - const: dp_p0 > + - const: dp_phy > + - const: dp_ln_tx0 > + - const: dp_ln_tx1 > + - const: afprom_physical > + - const: dp_pll > + - const: usb3_dp_com > + - const: hdcp_physical > + > + interrupts: > + description: The interrupt signal from the DP block. > + > + clocks: > + description: List of clock specifiers for clocks needed by the device. items: - description: aux clock bla bla - description: ref clock bla bla > + > + clock-names: > + description: | > + Device clock names in the same order as mentioned in clocks > property. > + The required clocks are mentioned below. > + items: > + - const: core_aux_clk > + - const: core_ref_clk_src > + - const: core_usb_ref_clk > + - const: core_usb_cfg_ahb_clk > + - const: core_usb_pipe_clk > + - const: ctrl_link_clk > + - const: ctrl_link_iface_clk > + - const: ctrl_pixel_clk > + - const: crypto_clk > + - const: pixel_clk_rcg > + > + pll-node: > + description: phandle to DP PLL node. Add type (phandle) > + > + vdda-1p2-supply: > + description: phandle to vdda 1.2V regulator node. > + > + vdda-0p9-supply: > + description: phandle to vdda 0.9V regulator node. > + > + aux-cfg0-settings: > + description: | > + Specifies the DP AUX configuration 0 settings. > + The first entry in this array corresponds to the register offset > + within DP AUX, while the remaining entries indicate the > + programmable values. Add type, goes for all *-settings > + > + aux-cfg1-settings: > + description: | > + Specifies the DP AUX configuration 1 settings. > + The first entry in this array corresponds to the register offset > + within DP AUX, while the remaining entries indicate the > + programmable values. > + > +
Re: [PATCH 1/6] dma-buf: add peer2peer flag
Hi Christian,
On Tue, 31 Mar 2020, 14:16 Daniel Vetter, wrote:
> On Mon, Mar 30, 2020 at 03:55:31PM +0200, Christian König wrote:
> > Add a peer2peer flag noting that the importer can deal with device
> > resources which are not backed by pages.
> >
> > Signed-off-by: Christian König
>
> On the series:
>
> Acked-by: Daniel Vetter
>
Fwiw, for the series,
Acked-by: Sumit Semwal
> ---
> > drivers/dma-buf/dma-buf.c | 2 ++
> > include/linux/dma-buf.h | 10 ++
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index ccc9eda1bc28..570c923023e6 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -690,6 +690,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf,
> struct device *dev,
> >
> > attach->dev = dev;
> > attach->dmabuf = dmabuf;
> > + if (importer_ops)
> > + attach->peer2peer = importer_ops->allow_peer2peer;
> > attach->importer_ops = importer_ops;
> > attach->importer_priv = importer_priv;
> >
> > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > index 1ade486fc2bb..82e0a4a64601 100644
> > --- a/include/linux/dma-buf.h
> > +++ b/include/linux/dma-buf.h
> > @@ -334,6 +334,14 @@ struct dma_buf {
> > * Attachment operations implemented by the importer.
> > */
> > struct dma_buf_attach_ops {
> > + /**
> > + * @allow_peer2peer:
> > + *
> > + * If this is set to true the importer must be able to handle peer
> > + * resources without struct pages.
> > + */
> > + bool allow_peer2peer;
> > +
> > /**
> >* @move_notify
> >*
> > @@ -362,6 +370,7 @@ struct dma_buf_attach_ops {
> > * @node: list of dma_buf_attachment, protected by dma_resv lock of the
> dmabuf.
> > * @sgt: cached mapping.
> > * @dir: direction of cached mapping.
> > + * @peer2peer: true if the importer can handle peer resources without
> pages.
> > * @priv: exporter specific attachment data.
> > * @importer_ops: importer operations for this attachment, if provided
> > * dma_buf_map/unmap_attachment() must be called with the dma_resv lock
> held.
> > @@ -382,6 +391,7 @@ struct dma_buf_attachment {
> > struct list_head node;
> > struct sg_table *sgt;
> > enum dma_data_direction dir;
> > + bool peer2peer;
> > const struct dma_buf_attach_ops *importer_ops;
> > void *importer_priv;
> > void *priv;
> > --
> > 2.17.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
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH v5 5/5] drm/msm/dpu: add display port support in DPU
From: Jeykumar Sankaran
Add display port support in DPU by creating hooks
for DP encoder enumeration and encoder mode
initialization.
This change is based on the Snapdragon Display port
driver changes[1].
changes in v2:
- rebase on [2] (Sean Paul)
- remove unwanted error checks and
switch cases (Jordan Crouse)
[1] https://lwn.net/Articles/768265/
[2] https://lkml.org/lkml/2018/11/17/87
changes in V3:
-- Moved this change as part of the DP driver changes.
-- Addressed compilation issues on the latest code base.
Signed-off-by: Jeykumar Sankaran
Signed-off-by: Chandan Uddaraju
Signed-off-by: Vara Reddy
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 65 -
2 files changed, 58 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index b063243..7c95f72 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2025,7 +2025,7 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
{
int ret = 0;
int i = 0;
- enum dpu_intf_type intf_type;
+ enum dpu_intf_type intf_type = INTF_NONE;
struct dpu_enc_phys_init_params phys_params;
if (!dpu_enc) {
@@ -2047,9 +2047,9 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
case DRM_MODE_ENCODER_DSI:
intf_type = INTF_DSI;
break;
- default:
- DPU_ERROR_ENC(dpu_enc, "unsupported display interface type\n");
- return -EINVAL;
+ case DRM_MODE_ENCODER_TMDS:
+ intf_type = INTF_DP;
+ break;
}
WARN_ON(disp_info->num_of_h_tiles < 1);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index cb08faf..441c274a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -421,6 +421,33 @@ static int _dpu_kms_initialize_dsi(struct drm_device *dev,
return rc;
}
+static int _dpu_kms_initialize_displayport(struct drm_device *dev,
+ struct msm_drm_private *priv,
+ struct dpu_kms *dpu_kms)
+{
+ struct drm_encoder *encoder = NULL;
+ int rc = 0;
+
+ if (!priv->dp)
+ return rc;
+
+ encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_TMDS);
+ if (IS_ERR(encoder)) {
+ DPU_ERROR("encoder init failed for dsi display\n");
+ return PTR_ERR(encoder);;
+ }
+
+ rc = msm_dp_modeset_init(priv->dp, dev, encoder);
+ if (rc) {
+ DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
+ drm_encoder_cleanup(encoder);
+ return rc;
+ }
+
+ priv->encoders[priv->num_encoders++] = encoder;
+ return rc;
+}
+
/**
* _dpu_kms_setup_displays - create encoders, bridges and connectors
* for underlying displays
@@ -433,12 +460,21 @@ static int _dpu_kms_setup_displays(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
{
- /**
-* Extend this function to initialize other
-* types of displays
-*/
+ int rc = 0;
+
+ rc = _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+ if (rc) {
+ DPU_ERROR("initialize_dsi failed, rc = %d\n", rc);
+ return rc;
+ }
- return _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+ rc = _dpu_kms_initialize_displayport(dev, priv, dpu_kms);
+ if (rc) {
+ DPU_ERROR("initialize_DP failed, rc = %d\n", rc);
+ return rc;
+ }
+
+ return rc;
}
static void _dpu_kms_drm_obj_destroy(struct dpu_kms *dpu_kms)
@@ -626,13 +662,20 @@ static void _dpu_kms_set_encoder_mode(struct msm_kms *kms,
info.capabilities = cmd_mode ? MSM_DISPLAY_CAP_CMD_MODE :
MSM_DISPLAY_CAP_VID_MODE;
- /* TODO: No support for DSI swap */
- for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
- if (priv->dsi[i]) {
- info.h_tile_instance[info.num_of_h_tiles] = i;
- info.num_of_h_tiles++;
+ switch (info.intf_type) {
+ case DRM_MODE_ENCODER_DSI:
+ /* TODO: No support for DSI swap */
+ for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
+ if (priv->dsi[i]) {
+ info.h_tile_instance[info.num_of_h_tiles] = i;
+ info.num_of_h_tiles++;
+ }
}
- }
+ break;
+ case DRM_MODE_ENCODER_TMDS:
+ info.num_of_h_tiles = 1;
+
[DPU PATCH v5 4/5] drm/msm/dp: add support for DP PLL driver
From: Chandan Uddaraju
Add the needed DP PLL specific files to support
display port interface on msm targets.
The DP driver calls the DP PLL driver registration.
The DP driver sets the link and pixel clock sources.
Changes in v2:
-- Update copyright markings on all relevant files.
-- Use DRM_DEBUG_DP for debug msgs.
Changes in v4:
-- Update the DP link clock provider names
Changes in V5:
-- Addressed comments from Stephen Boyd, Rob clark.
Signed-off-by: Chandan Uddaraju
Signed-off-by: Vara Reddy
---
drivers/gpu/drm/msm/Kconfig | 13 +
drivers/gpu/drm/msm/Makefile | 4 +
drivers/gpu/drm/msm/dp/dp_catalog.c | 34 +-
drivers/gpu/drm/msm/dp/dp_display.c | 46 +++
drivers/gpu/drm/msm/dp/dp_display.h | 3 +
drivers/gpu/drm/msm/dp/dp_parser.c| 37 +-
drivers/gpu/drm/msm/dp/dp_parser.h| 6 +-
drivers/gpu/drm/msm/dp/dp_power.h | 71 +++-
drivers/gpu/drm/msm/dp/pll/dp_pll.c | 127 +++
drivers/gpu/drm/msm/dp/pll/dp_pll.h | 57 +++
drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c | 401
drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h | 86 +
drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c | 524 ++
13 files changed, 1375 insertions(+), 34 deletions(-)
create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll.c
create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll.h
create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c
create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h
create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index ea3c4d0..43544c1 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -65,6 +65,19 @@ config DRM_MSM_DP
display support is enabled through this config option. It can
be primary or secondary display on device.
+config DRM_MSM_DP_PLL
+ bool "Enable DP PLL driver in MSM DRM"
+ depends on DRM_MSM_DP && COMMON_CLK
+ help
+ Choose this option to enable DP PLL driver which provides DP
+ source clocks under common clock framework.
+
+config DRM_MSM_DP_10NM_PLL
+ bool "Enable DP 10nm PLL driver in MSM DRM (used by SDM845)"
+ depends on DRM_MSM_DP_PLL
+ help
+ Choose this option if DP PLL on SDM845 is used on the platform.
+
config DRM_MSM_DSI
bool "Enable DSI support in MSM DRM driver"
depends on DRM_MSM
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 3e078d5..a6f68fb 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -139,4 +139,8 @@ msm-$(CONFIG_DRM_MSM_DSI_14NM_PHY) += dsi/pll/dsi_pll_14nm.o
msm-$(CONFIG_DRM_MSM_DSI_10NM_PHY) += dsi/pll/dsi_pll_10nm.o
endif
+msm-$(CONFIG_DRM_MSM_DP_PLL)+= dp/pll/dp_pll.o
+msm-$(CONFIG_DRM_MSM_DP_10NM_PLL)+= dp/pll/dp_pll_10nm.o \
+ dp/pll/dp_pll_10nm_util.o
+
obj-$(CONFIG_DRM_MSM) += msm.o
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 01e1833..0714868 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -5,6 +5,7 @@
#define pr_fmt(fmt)"[drm-dp] %s: " fmt, __func__
+#include
#include
#include
#include
@@ -121,11 +122,6 @@ static inline void dp_write_ahb(struct dp_catalog_private
*catalog,
writel(data, catalog->io->dp_ahb.base + offset);
}
-static inline u32 dp_read_cc(struct dp_catalog_private *catalog, u32 offset)
-{
- return readl_relaxed(catalog->io->dp_cc_io.base + offset);
-}
-
static inline void dp_write_phy(struct dp_catalog_private *catalog,
u32 offset, u32 data)
{
@@ -542,17 +538,37 @@ void dp_catalog_ctrl_config_msa(struct dp_catalog
*dp_catalog,
bool fixed_nvid)
{
u32 pixel_m, pixel_n;
- u32 mvid, nvid;
+ u32 mvid, nvid, div, pixel_div = 0, dispcc_input_rate;
u32 const nvid_fixed = DP_LINK_CONSTANT_N_VALUE;
u32 const link_rate_hbr2 = 54;
u32 const link_rate_hbr3 = 81;
+ unsigned long den, num;
struct dp_catalog_private *catalog = container_of(dp_catalog,
struct dp_catalog_private, dp_catalog);
- pixel_m = dp_read_cc(catalog, MMSS_DP_PIXEL_M);
- pixel_n = dp_read_cc(catalog, MMSS_DP_PIXEL_N);
- DRM_DEBUG_DP("pixel_m=0x%x, pixel_n=0x%x\n", pixel_m, pixel_n);
+ div = dp_read_phy(catalog, REG_DP_PHY_VCO_DIV);
+ div &= 0x03;
+
+ if (div == 0)
+ pixel_div = 6;
+ else if (div == 1)
+ pixel_div = 2;
+ else if (div == 2)
+ pixel_div = 4;
+ else
+ DRM_ERROR("Invalid pixel mux divider\n");
+
+ dispcc_input_rate = (rate * 10) / pixel_div;
+
+
[DPU PATCH v5 2/5] drm: add constant N value in helper file
From: Chandan Uddaraju The constant N value (0x8000) is used by multiple DP drivers. Define this value in header file and use this in the existing i915 display driver. Signed-off-by: Chandan Uddaraju Signed-off-by: Vara Reddy --- drivers/gpu/drm/i915/display/intel_display.c | 2 +- include/drm/drm_dp_helper.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index effc425..3c016f3 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -7618,7 +7618,7 @@ static void compute_m_n(unsigned int m, unsigned int n, * which the devices expect also in synchronous clock mode. */ if (constant_n) - *ret_n = 0x8000; + *ret_n = DP_LINK_CONSTANT_N_VALUE; else *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX); diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 51ecb51..b509e74 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -1455,6 +1455,8 @@ static inline ssize_t drm_dp_dpcd_writeb(struct drm_dp_aux *aux, int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux, u8 status[DP_LINK_STATUS_SIZE]); +#define DP_LINK_CONSTANT_N_VALUE 0x8000 + int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE], const u8 port_cap[4]); int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE], -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH v5 0/5] Add support for DisplayPort driver on SnapDragon.
These patches add support for Display-Port driver on SnapDragon 845 hardware. It adds DP driver and DP PLL driver files along with the needed device-tree bindings. The block diagram of DP driver is shown below: +-+ |DRM FRAMEWORK| +--+--+ | +v+ | DP DRM | +++ | +v+ ++| DP+--++--+ + | DISPLAY |+---+ | | | +-+-+-+| | | | | | | | | | | | | | | | | | | | | v v v v v v +--+ +---+ ++ ++ +---+ +-+ | DP | |DP | | DP | | DP | |DP | | DP | |PARSER| |AUX| |LINK| |CTRL| |PHY| |POWER| +--+---+ +---+ ++ +--+-+ +-+-+ +-+ | | | +--v---+ +v-v+ |DEVICE| | DP | | TREE | |CATALOG| +--+ +---+---+ | +---v+ |CTRL/PHY| | HW | ++ These patches have dependency on clock driver changes mentioned below: https://patchwork.kernel.org/patch/10632753/ https://patchwork.kernel.org/patch/10632757/ Chandan Uddaraju (4): dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon drm: add constant N value in helper file drm/msm/dp: add displayPort driver support drm/msm/dp: add support for DP PLL driver Jeykumar Sankaran (1): drm/msm/dpu: add display port support in DPU .../devicetree/bindings/display/msm/dp-sc7180.yaml | 325 .../devicetree/bindings/display/msm/dpu.txt| 16 +- drivers/gpu/drm/i915/display/intel_display.c |2 +- drivers/gpu/drm/msm/Kconfig| 21 + drivers/gpu/drm/msm/Makefile | 16 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 28 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c |8 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 65 +- drivers/gpu/drm/msm/dp/dp_aux.c| 531 ++ drivers/gpu/drm/msm/dp/dp_aux.h| 35 + drivers/gpu/drm/msm/dp/dp_catalog.c| 988 +++ drivers/gpu/drm/msm/dp/dp_catalog.h| 86 + drivers/gpu/drm/msm/dp/dp_ctrl.c | 1707 drivers/gpu/drm/msm/dp/dp_ctrl.h | 35 + drivers/gpu/drm/msm/dp/dp_display.c| 943 +++ drivers/gpu/drm/msm/dp/dp_display.h| 31 + drivers/gpu/drm/msm/dp/dp_drm.c| 170 ++ drivers/gpu/drm/msm/dp/dp_drm.h| 19 + drivers/gpu/drm/msm/dp/dp_hpd.c| 69 + drivers/gpu/drm/msm/dp/dp_hpd.h| 79 + drivers/gpu/drm/msm/dp/dp_link.c | 1216 ++ drivers/gpu/drm/msm/dp/dp_link.h | 132 ++ drivers/gpu/drm/msm/dp/dp_panel.c | 490 ++ drivers/gpu/drm/msm/dp/dp_panel.h | 95 ++ drivers/gpu/drm/msm/dp/dp_parser.c | 473 ++ drivers/gpu/drm/msm/dp/dp_parser.h | 220 +++ drivers/gpu/drm/msm/dp/dp_power.c | 545 +++ drivers/gpu/drm/msm/dp/dp_power.h | 115 ++ drivers/gpu/drm/msm/dp/dp_reg.h| 489 ++ drivers/gpu/drm/msm/dp/pll/dp_pll.c| 127 ++ drivers/gpu/drm/msm/dp/pll/dp_pll.h| 57 + drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c | 401 + drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h | 86 + drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c | 524 ++ drivers/gpu/drm/msm/msm_drv.c |2 + drivers/gpu/drm/msm/msm_drv.h | 53 +- include/drm/drm_dp_helper.h|2 + 37 files changed, 10178 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/dp-sc7180.yaml create mode 100644 drivers/gpu/drm/msm/dp/dp_aux.c create mode 100644 drivers/gpu/drm/msm/dp/dp_aux.h create mode 100644 drivers/gpu/drm/msm/dp/dp_catalog.c create mode 100644 drivers/gpu/drm/msm/dp/dp_catalog.h create mode 100644 drivers/gpu/drm/msm/dp/dp_ctrl.c create mode 100644 drivers/gpu/drm/msm/dp/dp_ctrl.h create mode 100644 drivers/gpu/drm/msm/dp/dp_display.c create mode 100644 drivers/gpu/drm/msm/dp/dp_display.h create mode 100644 drivers/gpu/drm/msm/dp/dp_drm.c create mode 100644 drivers/gpu/drm/msm/dp/dp_drm.h create
[DPU PATCH v5 1/5] dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon
From: Chandan Uddaraju Add bindings for Snapdragon DisplayPort and display-port PLL driver. Changes in V2: Provide details about sel-gpio Changes in V4: Provide details about max dp lanes Change the commit text Changes in V5: Moved dp.txt to yaml file. Signed-off-by: Chandan Uddaraju Signed-off-by: Vara Reddy --- .../devicetree/bindings/display/msm/dp-sc7180.yaml | 325 + .../devicetree/bindings/display/msm/dpu.txt| 16 +- 2 files changed, 337 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/dp-sc7180.yaml diff --git a/Documentation/devicetree/bindings/display/msm/dp-sc7180.yaml b/Documentation/devicetree/bindings/display/msm/dp-sc7180.yaml new file mode 100644 index 000..761a01d --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dp-sc7180.yaml @@ -0,0 +1,325 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dp-sc7180.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Description of Qualcomm Display Port dt properties. + +maintainers: + - Chandan Uddaraju + - Vara Reddy + +description: | + Device tree bindings for MSM Display Port which supports DP host controllers + that are compatible with VESA Display Port interface specification. + +properties: + "msm_dp": +type: object +description: | + Node containing Display port register address bases, clocks, power supplies. + +properties: + compatible: + items: + - const: qcom,dp-display + + cell-index: + description: Specifies the controller instance. + + reg: + description: Physical base address and length of controller's registers. + + reg-names: + description: | + Names for different register regions defined above. The required region + is mentioned below. + items: + - const: dp_ahb + - const: dp_aux + - const: dp_link + - const: dp_p0 + - const: dp_phy + - const: dp_ln_tx0 + - const: dp_ln_tx1 + - const: afprom_physical + - const: dp_pll + - const: usb3_dp_com + - const: hdcp_physical + + interrupts: + description: The interrupt signal from the DP block. + + clocks: + description: List of clock specifiers for clocks needed by the device. + + clock-names: + description: | + Device clock names in the same order as mentioned in clocks property. + The required clocks are mentioned below. + items: + - const: core_aux_clk + - const: core_ref_clk_src + - const: core_usb_ref_clk + - const: core_usb_cfg_ahb_clk + - const: core_usb_pipe_clk + - const: ctrl_link_clk + - const: ctrl_link_iface_clk + - const: ctrl_pixel_clk + - const: crypto_clk + - const: pixel_clk_rcg + + pll-node: + description: phandle to DP PLL node. + + vdda-1p2-supply: + description: phandle to vdda 1.2V regulator node. + + vdda-0p9-supply: + description: phandle to vdda 0.9V regulator node. + + aux-cfg0-settings: + description: | + Specifies the DP AUX configuration 0 settings. + The first entry in this array corresponds to the register offset + within DP AUX, while the remaining entries indicate the + programmable values. + + aux-cfg1-settings: + description: | + Specifies the DP AUX configuration 1 settings. + The first entry in this array corresponds to the register offset + within DP AUX, while the remaining entries indicate the + programmable values. + + aux-cfg2-settings: + description: | + Specifies the DP AUX configuration 2 settings. + The first entry in this array corresponds to the register offset + within DP AUX, while the remaining entries indicate the + programmable values. + + aux-cfg3-settings: + description: | + Specifies the DP AUX configuration 3 settings. + The first entry in this array corresponds to the register offset + within DP AUX, while the remaining entries indicate the + programmable values. + + aux-cfg4-settings: + description: | + Specifies the DP AUX configuration 4 settings. + The first entry in this array corresponds to the register offset + within DP AUX, while the remaining entries indicate the + programmable values. + + aux-cfg5-settings: + description: | + Specifies the DP AUX configuration 5 settings. + The first entry in this array corresponds to the register offset + within DP AUX, while the remaining entries indicate the + programmable values. + + aux-cfg6-settings: + description: | + Specifies the DP AUX configuration 6 settings. + The first entry in this
[Bug 207047] New: Crash after failed to pin userptr on amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=207047 Bug ID: 207047 Summary: Crash after failed to pin userptr on amdgpu Product: Drivers Version: 2.5 Kernel Version: 5.5.13 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: m...@artem.ist Regression: No Created attachment 288139 --> https://bugzilla.kernel.org/attachment.cgi?id=288139=edit dmesg output since usermode crash that caused bug When a user-mode program crashes while using amdgpu resources amdgpu fails to pin userptr then segfaults in the GPU scheduler. This occured while attempting to port a program to use Wayland and Vulkan on AMD Ryzen 3700X and AMD RX580 using unmodified amdgpu drivers. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: meson-vpu: fix indentation of reg-names' "items"
On Sat, 28 Mar 2020 01:41:57 +0100, Martin Blumenstingl wrote:
> Use two spaces for indentation instead of one to be consistent with the
> rest of the file. No functional changes.
>
> Fixes: 6b9ebf1e0e678b ("dt-bindings: display: amlogic, meson-vpu: convert to
> yaml")
> Signed-off-by: Martin Blumenstingl
> ---
> .../devicetree/bindings/display/amlogic,meson-vpu.yaml | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Applied, thanks.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] dt-bindings: display: rockchip-vop: add additional properties
On Wed, 25 Mar 2020 11:38:28 +0100, Johan Jonker wrote: > In the old txt situation we add/describe only properties that are used > by the driver/hardware itself. With yaml it also filters things in a > node that are used by other drivers like 'assigned-clocks' and > 'assigned-clock-rates' for rk3399 and 'power-domains' for most > Rockchip Socs in 'vop' nodes, so add them to 'rockchip-vop.yaml'. > > Signed-off-by: Johan Jonker > --- > .../devicetree/bindings/display/rockchip/rockchip-vop.yaml| 11 > +++ > 1 file changed, 11 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] dt-bindings: display: convert rockchip vop bindings to yaml
On Wed, 25 Mar 2020 11:38:27 +0100, Johan Jonker wrote: > Current dts files with 'vop' nodes are manually verified. > In order to automate this process rockchip-vop.txt > has to be converted to yaml. > > Signed-off-by: Johan Jonker > --- > Changes v4: > Change description > Replace compatible oneOf by enum > Change interrupts description > Remove resets minItems > > Changes v3: > Change description > > Changes v2: > No new properties > --- > .../bindings/display/rockchip/rockchip-vop.txt | 74 > .../bindings/display/rockchip/rockchip-vop.yaml| 124 > + > 2 files changed, 124 insertions(+), 74 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt > create mode 100644 > Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/amd/amdgpu_dm/mst: Remove useless sideband tracing
We already trace DPCD reads/writes on both MST and SST, there's no
reason to have this code here (plus, toggling these things with a
define at the top of the file isn't how we do things in the kernel).
Signed-off-by: Lyude Paul
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 43 ---
1 file changed, 43 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index e8208df420d9..7f2293016446 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -41,53 +41,10 @@
#include "amdgpu_dm_debugfs.h"
#endif
-
#if defined(CONFIG_DRM_AMD_DC_DCN)
#include "dc/dcn20/dcn20_resource.h"
#endif
-/* #define TRACE_DPCD */
-
-#ifdef TRACE_DPCD
-#define SIDE_BAND_MSG(address) (address >= DP_SIDEBAND_MSG_DOWN_REQ_BASE &&
address < DP_SINK_COUNT_ESI)
-
-static inline char *side_band_msg_type_to_str(uint32_t address)
-{
- static char str[10] = {0};
-
- if (address < DP_SIDEBAND_MSG_UP_REP_BASE)
- strcpy(str, "DOWN_REQ");
- else if (address < DP_SIDEBAND_MSG_DOWN_REP_BASE)
- strcpy(str, "UP_REP");
- else if (address < DP_SIDEBAND_MSG_UP_REQ_BASE)
- strcpy(str, "DOWN_REP");
- else
- strcpy(str, "UP_REQ");
-
- return str;
-}
-
-static void log_dpcd(uint8_t type,
-uint32_t address,
-uint8_t *data,
-uint32_t size,
-bool res)
-{
- DRM_DEBUG_KMS("Op: %s, addr: %04x, SideBand Msg: %s, Op res: %s\n",
- (type == DP_AUX_NATIVE_READ) ||
- (type == DP_AUX_I2C_READ) ?
- "Read" : "Write",
- address,
- SIDE_BAND_MSG(address) ?
- side_band_msg_type_to_str(address) :
"Nop",
- res ? "OK" : "Fail");
-
- if (res) {
- print_hex_dump(KERN_INFO, "Body: ", DUMP_PREFIX_NONE, 16, 1,
data, size, false);
- }
-}
-#endif
-
static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg)
{
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/amd/dc: Kill dc_conn_log_hex_linux()
DRM already supports tracing DPCD transactions, there's no reason for
the existence of this function. Also, it prints one byte per-line which
is way too loud. So, just remove it.
Signed-off-by: Lyude Paul
---
.../gpu/drm/amd/display/dc/basics/Makefile| 3 +-
.../drm/amd/display/dc/basics/log_helpers.c | 39 ---
.../amd/display/include/logger_interface.h| 4 --
3 files changed, 1 insertion(+), 45 deletions(-)
delete mode 100644 drivers/gpu/drm/amd/display/dc/basics/log_helpers.c
diff --git a/drivers/gpu/drm/amd/display/dc/basics/Makefile
b/drivers/gpu/drm/amd/display/dc/basics/Makefile
index 7ad0cad0f4ef..01b99e0d788e 100644
--- a/drivers/gpu/drm/amd/display/dc/basics/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/basics/Makefile
@@ -24,8 +24,7 @@
# It provides the general basic services required by other DAL
# subcomponents.
-BASICS = conversion.o fixpt31_32.o \
- log_helpers.o vector.o dc_common.o
+BASICS = conversion.o fixpt31_32.o vector.o dc_common.o
AMD_DAL_BASICS = $(addprefix $(AMDDALPATH)/dc/basics/,$(BASICS))
diff --git a/drivers/gpu/drm/amd/display/dc/basics/log_helpers.c
b/drivers/gpu/drm/amd/display/dc/basics/log_helpers.c
deleted file mode 100644
index 26583f346c39..
--- a/drivers/gpu/drm/amd/display/dc/basics/log_helpers.c
+++ /dev/null
@@ -1,39 +0,0 @@
-/*
- * Copyright 2012-16 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
- * Authors: AMD
- *
- */
-
-#include "core_types.h"
-#include "logger.h"
-#include "include/logger_interface.h"
-#include "dm_helpers.h"
-
-void dc_conn_log_hex_linux(const uint8_t *hex_data, int hex_data_count)
-{
- int i;
-
- if (hex_data)
- for (i = 0; i < hex_data_count; i++)
- DC_LOG_DEBUG("%2.2X ", hex_data[i]);
-}
-
diff --git a/drivers/gpu/drm/amd/display/include/logger_interface.h
b/drivers/gpu/drm/amd/display/include/logger_interface.h
index 6e008de25629..02c23b04d34b 100644
--- a/drivers/gpu/drm/amd/display/include/logger_interface.h
+++ b/drivers/gpu/drm/amd/display/include/logger_interface.h
@@ -40,8 +40,6 @@ struct dc_state;
*
*/
-void dc_conn_log_hex_linux(const uint8_t *hex_data, int hex_data_count);
-
void pre_surface_trace(
struct dc *dc,
const struct dc_plane_state *const *plane_states,
@@ -102,14 +100,12 @@ void context_clock_trace(
#define CONN_DATA_DETECT(link, hex_data, hex_len, ...) \
do { \
(void)(link); \
- dc_conn_log_hex_linux(hex_data, hex_len); \
DC_LOG_EVENT_DETECTION(__VA_ARGS__); \
} while (0)
#define CONN_DATA_LINK_LOSS(link, hex_data, hex_len, ...) \
do { \
(void)(link); \
- dc_conn_log_hex_linux(hex_data, hex_len); \
DC_LOG_EVENT_LINK_LOSS(__VA_ARGS__); \
} while (0)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/amdgpu: Remove duplicated DPCD logging
There's a bunch of messy DPCD tracing code in amdgpu that isn't needed since we already support this in DRM. Plus, it's really spammy. So, just get rid of it. Lyude Paul (2): drm/amd/amdgpu_dm/mst: Remove useless sideband tracing drm/amd/dc: Kill dc_conn_log_hex_linux() .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 43 --- .../gpu/drm/amd/display/dc/basics/Makefile| 3 +- .../drm/amd/display/dc/basics/log_helpers.c | 39 - .../amd/display/include/logger_interface.h| 4 -- 4 files changed, 1 insertion(+), 88 deletions(-) delete mode 100644 drivers/gpu/drm/amd/display/dc/basics/log_helpers.c -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp_mst: make build_clear_payload_id_table return void
Reviewed-by: Lyude Paul
I'll go ahead and push it to drm-misc-next, thanks!
On Sat, 2020-03-21 at 22:29 +, Maya Rashish wrote:
> Nothing uses the always-0 return value.
>
> Signed-off-by: Maya Rashish
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 4b255e25e4a1..398da29ba1bd 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1060,13 +1060,12 @@ static void build_link_address(struct
> drm_dp_sideband_msg_tx *msg)
> drm_dp_encode_sideband_req(, msg);
> }
>
> -static int build_clear_payload_id_table(struct drm_dp_sideband_msg_tx *msg)
> +static void build_clear_payload_id_table(struct drm_dp_sideband_msg_tx
> *msg)
> {
> struct drm_dp_sideband_msg_req_body req;
>
> req.req_type = DP_CLEAR_PAYLOAD_ID_TABLE;
> drm_dp_encode_sideband_req(, msg);
> - return 0;
> }
>
> static int build_enum_path_resources(struct drm_dp_sideband_msg_tx *msg,
--
Cheers,
Lyude Paul (she/her)
Associate Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/amd/amdgpu_dm/mst: Remove ->destroy_connector() callback
Pankaj Bharadiya started cleaning up the MST connector callbacks a while
ago, as I pointed out that they are the same across every driver and
don't serve much purpose. There was one callback that was left over
though from amdgpu, that we delayed removing due to not being completely
sure as to whether or not it was needed.
So, I've read through said callback and can confirm it's not at all
needed. Pretty much all of the work that is done in
dm_dp_destroy_mst_connector() can be done in
dm_dp_mst_connector_destroy(). Additionally, I've removed some bits that
didn't actually do anything:
* Removed DRM_INFO message we were printing, this shouldn't be info
level and there's more appropriate drm debugging flags that should be
used instead
* Removed amdgpu_dm_update_freesync_caps() - reading into this function,
it doesn't actually do anything important and I'm not sure why it was
ever being called here
* Stop clearing aconnector->dc_sink - this also doesn't do anything
* Stop clearing link settings in dc_link - this also doesn't do anything
* Also, use shorter variable
Signed-off-by: Lyude Paul
Cc: Pankaj Bharadiya
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 39 ++-
1 file changed, 12 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 7b3303efb1ff..09025ccc68ca 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -136,16 +136,23 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
static void
dm_dp_mst_connector_destroy(struct drm_connector *connector)
{
- struct amdgpu_dm_connector *amdgpu_dm_connector =
to_amdgpu_dm_connector(connector);
- struct amdgpu_encoder *amdgpu_encoder =
amdgpu_dm_connector->mst_encoder;
+ struct amdgpu_dm_connector *aconnector =
+ to_amdgpu_dm_connector(connector);
+ struct amdgpu_encoder *amdgpu_encoder = aconnector->mst_encoder;
- kfree(amdgpu_dm_connector->edid);
+ if (aconnector->dc_sink) {
+ dc_link_remove_remote_sink(aconnector->dc_link,
+ aconnector->dc_sink);
+ dc_sink_release(aconnector->dc_sink);
+ }
+
+ kfree(aconnector->edid);
drm_encoder_cleanup(_encoder->base);
kfree(amdgpu_encoder);
drm_connector_cleanup(connector);
- drm_dp_mst_put_port_malloc(amdgpu_dm_connector->port);
- kfree(amdgpu_dm_connector);
+ drm_dp_mst_put_port_malloc(aconnector->port);
+ kfree(aconnector);
}
static int
@@ -436,30 +443,8 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
return connector;
}
-static void dm_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
- struct drm_connector *connector)
-{
- struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
-
- DRM_INFO("DM_MST: Disabling connector: %p [id: %d] [master: %p]\n",
-aconnector, connector->base.id, aconnector->mst_port);
-
- if (aconnector->dc_sink) {
- amdgpu_dm_update_freesync_caps(connector, NULL);
- dc_link_remove_remote_sink(aconnector->dc_link,
- aconnector->dc_sink);
- dc_sink_release(aconnector->dc_sink);
- aconnector->dc_sink = NULL;
- aconnector->dc_link->cur_link_settings.lane_count = 0;
- }
-
- drm_connector_unregister(connector);
- drm_connector_put(connector);
-}
-
static const struct drm_dp_mst_topology_cbs dm_mst_cbs = {
.add_connector = dm_dp_add_mst_connector,
- .destroy_connector = dm_dp_destroy_mst_connector,
};
void amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/dp_mst: Remove ->destroy_connector() callback
This finishes up the work that Pankaj Bharadiya started in: https://patchwork.freedesktop.org/series/74412/ And allows us to entirely remove ->destroy_connector() Lyude Paul (4): drm/amd/amdgpu_dm/mst: Remove unneeded edid assignment when destroying connectors drm/amd/amdgpu_dm/mst: Remove ->destroy_connector() callback drm/amd/amdgpu_dm/mst: Stop printing extra messages in dm_dp_add_mst_connector() drm/dp_mst: Remove drm_dp_mst_topology_cbs.destroy_connector .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 45 +-- drivers/gpu/drm/drm_dp_mst_topology.c | 16 ++- include/drm/drm_dp_mst_helper.h | 2 - 3 files changed, 15 insertions(+), 48 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/amd/amdgpu_dm/mst: Remove unneeded edid assignment when destroying connectors
Doesn't do anything, noticed this while cleaning up some unrelated stuff. Signed-off-by: Lyude Paul --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c index e8208df420d9..7b3303efb1ff 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c @@ -140,7 +140,6 @@ dm_dp_mst_connector_destroy(struct drm_connector *connector) struct amdgpu_encoder *amdgpu_encoder = amdgpu_dm_connector->mst_encoder; kfree(amdgpu_dm_connector->edid); - amdgpu_dm_connector->edid = NULL; drm_encoder_cleanup(_encoder->base); kfree(amdgpu_encoder); -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 32/36] dt-bindings: display: convert sharp, ls037v7dw01 to DT Schema
On Tue, Mar 31, 2020 at 1:14 PM Sam Ravnborg wrote: > > Hi Rob. > > On Tue, Mar 31, 2020 at 11:20:13AM -0600, Rob Herring wrote: > > On Sun, Mar 29, 2020 at 1:04 PM Sam Ravnborg wrote: > > > > > > Hi Rob. > > > > > > > > + > > > > > + mode-gpios: > > > > > +description: | > > > > > + GPIO ordered MO, LR, and UD as specified in LS037V7DW01.pdf > > > > > > > > 3 or... > > > > > > > > > + change configuration between QVGA and VGA mode and the > > > > > + scan direction. As these pins can be also configured > > > > > + with external pulls, all the GPIOs are considered > > > > > + optional with holes in the array. > > > > > > > > minItems: 3 > > > > maxItems: 5 > > > > > > This binding can specify up to three GPIOs like this: > > > > So it should be: > > > > minItems: 1 > > maxItems: 3 > > > > > > > +mode-gpios = < 26 GPIO_ACTIVE_HIGH/* gpio154, > > > > > lcd MO */ > > > > > + 2 GPIO_ACTIVE_HIGH /* gpio2, > > > > > lcd LR */ > > > > > + 3 GPIO_ACTIVE_HIGH>; /* gpio3, > > > > > lcd UD */ > > > > > > They are in the linux kernel driver accessed like this: > > > > > > devm_gpiod_get_index(>dev, "mode", 2, GPIOD_OUT_LOW); > > > > > > The following is OK in the DT file: > > > > > > mode-gpios = < 26 GPIO_ACTIVE_HIGH>; > > > > > > mode-gpios = < 26 GPIO_ACTIVE_HIGH > > >2 GPIO_ACTIVE_HIGH>; > > > > > > mode-gpios = < 26 GPIO_ACTIVE_HIGH > > >2 GPIO_ACTIVE_HIGH > > >3 GPIO_ACTIVE_HIGH>; > > > > With the above, the 2nd 2 should fail... > > > > > But the following is not OK: > > > mode-gpios = < 26 GPIO_ACTIVE_HIGH>, < 2 > > > GPIO_ACTIVE_HIGH>; > > > > And this should pass. We want phandle+arg type properties to be > > bracketed like this. > > OK, so if I get you right you say that we should accept the: > , ... syntax. > > And then ignore that current DT files uses: > > > > A binding like this: > mode-gpios: > minItems: 1 > maxItems: 3 > description: | > GPIO ordered MO, LR, and UD as specified in LS037V7DW01.pdf > This panel can have zero to three GPIOs to configure to > > > Do not error out when the example looks like this: > > mode-gpios = < 26 GPIO_ACTIVE_HIGH/* gpio154, lcd MO */ >2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */ >3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */ That's because we can't distinguish between this and 1 entry as the schema doesn't have visibility of what #gpio-cells value is. dtc does check that the cell sizes are correct. We'll need to somehow combine that and the schema to check this form correctly. > > So if I get you right this is a bug in the tooling. Limitation I guess. I thought you where saying the bracketed form was not working. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/dp_mst: Remove drm_dp_mst_topology_cbs.destroy_connector
Now that we've removed the last user of this callback, get rid of it and
drm_dp_destroy_connector().
Signed-off-by: Lyude Paul
Cc: Pankaj Bharadiya
---
drivers/gpu/drm/drm_dp_mst_topology.c | 16 +++-
include/drm/drm_dp_mst_helper.h | 2 --
2 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 31b7a8f5309d..e235b2b29f59 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4692,23 +4692,13 @@ static void drm_dp_tx_work(struct work_struct *work)
mutex_unlock(>qlock);
}
-static inline void drm_dp_destroy_connector(struct drm_dp_mst_port *port)
+static inline void
+drm_dp_delayed_destroy_port(struct drm_dp_mst_port *port)
{
- if (!port->connector)
- return;
-
- if (port->mgr->cbs->destroy_connector) {
- port->mgr->cbs->destroy_connector(port->mgr, port->connector);
- } else {
+ if (port->connector) {
drm_connector_unregister(port->connector);
drm_connector_put(port->connector);
}
-}
-
-static inline void
-drm_dp_delayed_destroy_port(struct drm_dp_mst_port *port)
-{
- drm_dp_destroy_connector(port);
drm_dp_port_set_pdt(port, DP_PEER_DEVICE_NONE, port->mcs);
drm_dp_mst_put_port_malloc(port);
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 13461db1444a..7af51c947b81 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -488,8 +488,6 @@ struct drm_dp_mst_topology_mgr;
struct drm_dp_mst_topology_cbs {
/* create a connector for a port */
struct drm_connector *(*add_connector)(struct drm_dp_mst_topology_mgr
*mgr, struct drm_dp_mst_port *port, const char *path);
- void (*destroy_connector)(struct drm_dp_mst_topology_mgr *mgr,
- struct drm_connector *connector);
};
#define DP_MAX_PAYLOAD (sizeof(unsigned long) * 8)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/amd/amdgpu_dm/mst: Stop printing extra messages in dm_dp_add_mst_connector()
You can already trace the creation and destruction of connectors using
DRM, and we definitely don't need to be printing info messages on
connector hotplugs as well. So, get rid of these.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 09025ccc68ca..d56b758bcce5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -433,13 +433,8 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
*/
amdgpu_dm_connector_funcs_reset(connector);
- DRM_INFO("DM_MST: added connector: %p [id: %d] [master: %p]\n",
-aconnector, connector->base.id, aconnector->mst_port);
-
drm_dp_mst_get_port_malloc(port);
- DRM_DEBUG_KMS(":%d\n", connector->base.id);
-
return connector;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: boe,tv101wum-n16: Add compatible for boe tv105wum-nw0.
On Tue, Mar 24, 2020 at 05:45:25PM +0800, David Lu wrote: > Add bindings documentation for BOE TV105WUM-NW0 10.5" WUXGA TFT LCD > panel. > > Signed-off-by: David Lu > Change-Id: I450c0e52aae080728d4794bdffc50bb0d2f39f40 Drop this. > --- > .../devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml | 2 ++ > 1 file changed, 2 insertions(+) With that fixed, Acked-by: Rob Herring > > diff --git > a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml > b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml > index 740213459134..7f5df5851017 100644 > --- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml > +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml > @@ -24,6 +24,8 @@ properties: >- boe,tv101wum-n53 > # AUO B101UAN08.3 10.1" WUXGA TFT LCD panel >- auo,b101uan08.3 > +# BOE TV105WUM-NW0 10.5" WUXGA TFT LCD panel > + - boe,tv105wum-nw0 > >reg: > description: the virtual channel number of a DSI peripheral > -- > 2.24.1 > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 32/36] dt-bindings: display: convert sharp, ls037v7dw01 to DT Schema
Hi Rob. On Tue, Mar 31, 2020 at 11:20:13AM -0600, Rob Herring wrote: > On Sun, Mar 29, 2020 at 1:04 PM Sam Ravnborg wrote: > > > > Hi Rob. > > > > > > + > > > > + mode-gpios: > > > > +description: | > > > > + GPIO ordered MO, LR, and UD as specified in LS037V7DW01.pdf > > > > > > 3 or... > > > > > > > + change configuration between QVGA and VGA mode and the > > > > + scan direction. As these pins can be also configured > > > > + with external pulls, all the GPIOs are considered > > > > + optional with holes in the array. > > > > > > minItems: 3 > > > maxItems: 5 > > > > This binding can specify up to three GPIOs like this: > > So it should be: > > minItems: 1 > maxItems: 3 > > > > > +mode-gpios = < 26 GPIO_ACTIVE_HIGH/* gpio154, > > > > lcd MO */ > > > > + 2 GPIO_ACTIVE_HIGH /* gpio2, lcd > > > > LR */ > > > > + 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd > > > > UD */ > > > > They are in the linux kernel driver accessed like this: > > > > devm_gpiod_get_index(>dev, "mode", 2, GPIOD_OUT_LOW); > > > > The following is OK in the DT file: > > > > mode-gpios = < 26 GPIO_ACTIVE_HIGH>; > > > > mode-gpios = < 26 GPIO_ACTIVE_HIGH > >2 GPIO_ACTIVE_HIGH>; > > > > mode-gpios = < 26 GPIO_ACTIVE_HIGH > >2 GPIO_ACTIVE_HIGH > >3 GPIO_ACTIVE_HIGH>; > > With the above, the 2nd 2 should fail... > > > But the following is not OK: > > mode-gpios = < 26 GPIO_ACTIVE_HIGH>, < 2 GPIO_ACTIVE_HIGH>; > > And this should pass. We want phandle+arg type properties to be > bracketed like this. OK, so if I get you right you say that we should accept the: , ... syntax. And then ignore that current DT files uses: A binding like this: mode-gpios: minItems: 1 maxItems: 3 description: | GPIO ordered MO, LR, and UD as specified in LS037V7DW01.pdf This panel can have zero to three GPIOs to configure to Do not error out when the example looks like this: mode-gpios = < 26 GPIO_ACTIVE_HIGH/* gpio154, lcd MO */ 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */ 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */ So if I get you right this is a bug in the tooling. I have updated the tooling a few days ago, should be on the latest. In the actual example I go for the snip you see above. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 3/4] backlight: qcom-wled: Add WLED5 bindings
On Mon, Mar 23, 2020 at 11:16:57PM +0530, Kiran Gunda wrote: > Add WLED5 specific bindings. > More of the same comments here... > Signed-off-by: Kiran Gunda > Signed-off-by: Subbaraman Narayanamurthy > --- > .../bindings/leds/backlight/qcom-wled.yaml | 39 > ++ > 1 file changed, 39 insertions(+) > > diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > index 8a388bf..159115f 100644 > --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > @@ -20,6 +20,7 @@ properties: > - qcom,pm8941-wled > - qcom,pmi8998-wled > - qcom,pm660l-wled > + - qcom,pm8150l-wled > >reg: > maxItems: 1 > @@ -28,10 +29,23 @@ properties: > maxItems: 1 > description: >brightness value on boot, value from 0-4095. > + For pm8150l this value vary from 0-4095 or 0-32767 > + depending on the brightness control mode. If CABC is > + enabled 0-4095 range is used. Constraints. > allOf: >- $ref: /schemas/types.yaml#/definitions/uint32 > default: 2048 > > + max-brightness: > +maxItems: 1 > +description: > + Maximum brightness level. Allowed values are, > + for pmi8998 it is 0-4095. > + For pm8150l, this can be either 4095 or 32767. Constraints! > + If CABC is enabled, this is capped to 4095. > +allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 Standard property. Assume it has a type definition.' > + >label: > maxItems: 1 > description: > @@ -124,6 +138,31 @@ properties: >value for PM8941 from 1 to 3. Default 2 >For PMI8998 from 1 to 4. > > + qcom,modulator-sel: > +maxItems: 1 > +allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 > +description: > + Selects the modulator used for brightness modulation. > + Allowed values are, > + 0 - Modulator A > + 1 - Modulator B > + If not specified, then modulator A will be used by default. > + This property is applicable only to WLED5 peripheral. > + > + qcom,cabc-sel: > +maxItems: 1 > +allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 > +description: > + Selects the CABC pin signal used for brightness modulation. > + Allowed values are, > + 0 - CABC disabled > + 1 - CABC 1 > + 2 - CABC 2 > + 3 - External signal (e.g. LPG) is used for dimming > + This property is applicable only to WLED5 peripheral. > + >interrupts: > maxItems: 2 > description: > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 1/4] backlight: qcom-wled: convert the wled bindings to .yaml format
On Mon, Mar 23, 2020 at 11:16:55PM +0530, Kiran Gunda wrote: > Convert the qcom-wled bindings from .txt to .yaml format. > > Signed-off-by: Kiran Gunda > Signed-off-by: Subbaraman Narayanamurthy > Acked-by: Daniel Thompson > --- > .../bindings/leds/backlight/qcom-wled.txt | 154 - > .../bindings/leds/backlight/qcom-wled.yaml | 184 > + > 2 files changed, 184 insertions(+), 154 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt > create mode 100644 > Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > new file mode 100644 > index 000..8a388bf > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > @@ -0,0 +1,184 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/leds/backlight/qcom-wled.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Binding for Qualcomm Technologies, Inc. WLED driver > + > +maintainers: > + - Lee Jones Should be the h/w owner (you), not who applies patches. > + > +description: | > + WLED (White Light Emitting Diode) driver is used for controlling display > + backlight that is part of PMIC on Qualcomm Technologies, Inc. reference > + platforms. The PMIC is connected to the host processor via SPMI bus. > + > +properties: > + compatible : Drop the space ^ > +enum: > + - qcom,pm8941-wled > + - qcom,pmi8998-wled > + - qcom,pm660l-wled Wrong indent (1 space too many). > + > + reg: > +maxItems: 1 > + > + default-brightness: > +maxItems: 1 maxItems is for arrays and this is a single scalar. > +description: > + brightness value on boot, value from 0-4095. 0-4095 sounds like a constraint. > +allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 There should be a common definition for this. > +default: 2048 > + > + label: > +maxItems: 1 > +description: > + The name of the backlight device. > +allOf: > + - $ref: /schemas/types.yaml#/definitions/string Already has a type. Just 'label: true' is enough. > + > + qcom,cs-out: > +description: > + enable current sink output. > + This property is supported only for PM8941. > +type: boolean > + > + qcom,cabc: > +description: > + enable content adaptive backlight control. > +type: boolean > + > + qcom,ext-gen: > +description: > + use externally generated modulator signal to dim. > + This property is supported only for PM8941. > +type: boolean > + > + qcom,current-limit: > +maxItems: 1 Not an array. > +allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 > +description: > + mA; per-string current limit; value from 0 to 25 with 25 sounds like a constraint. > + 1 mA step. This property is supported only for pm8941. > +default: 20 > + > + qcom,current-limit-microamp: > +maxItems: 1 > +allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 properties with unit suffix already have a type. > +description: > + uA; per-string current limit; value from 0 to 3 with > + 2500 uA step. steps can be expressed using 'multipleOf' > +default: 25 25 can never be a multiple of 2500 > + > + qcom,current-boost-limit: > +maxItems: 1 > +allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 > +description: > + mA; boost current limit. > + For pm8941 one of 105, 385, 525, 805, 980, 1260, 1400, 1680. > + Default, 805 mA. > + For pmi8998 one of 105, 280, 450, 620, 970, 1150, 1300, > + 1500. Default 970 mA. Constraints. > + > + qcom,switching-freq: > +maxItems: 1 > +allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 > +description: > + kHz; switching frequency; one of 600, 640, 685, 738, > + 800, 872, 960, 1066, 1200, 1371, 1600, 1920, 2400, 3200, > + 4800, 9600. > + Default for pm8941 1600 kHz > + for pmi8998 800 kHz Constraints! > + > + qcom,ovp: > +maxItems: 1 > +allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 > +description: > + V; Over-voltage protection limit; one of 27, 29, 32, 35. Default 29V > + This property is supported only for PM8941. > + > + qcom,ovp-millivolt: > +maxItems: 1 > +allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 > +description: > + mV; Over-voltage protection limit; > + For pmi8998 one of 18100, 19600, 29600, 31100. > + Default 29600 mV. > + If this property is not specified for PM8941, it > + falls back to "qcom,ovp" property. > + > + qcom,num-strings: > +maxItems: 1 > +allOf: > + - $ref:
Re: [PATCH 3/5] drm: msm: scale DDR BW along with GPU frequency
On Tue, Mar 31, 2020 at 01:25:51PM +0530, Sharat Masetty wrote:
> This patch adds support to parse the OPP tables attached the GPU device,
> the main opp table and the DDR bandwidth opp table. Additionally, vote
> for the GPU->DDR bandwidth when setting the GPU frequency by querying
> the linked DDR BW opp to the GPU opp.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 41 ++
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 44
> +
> drivers/gpu/drm/msm/msm_gpu.h | 9 +++
> 3 files changed, 84 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index 748cd37..489d9b6 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -100,6 +100,40 @@ bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
> A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
> }
>
> +void a6xx_gmu_set_icc_vote(struct msm_gpu *gpu, unsigned long gpu_freq)
> +{
> + struct dev_pm_opp *gpu_opp, *ddr_opp;
> + struct opp_table **tables = gpu->opp_tables;
> + unsigned long peak_bw;
> +
> + if (!gpu->opp_tables[GPU_DDR_OPP_TABLE_INDEX])
> + goto done;
> +
> + gpu_opp = dev_pm_opp_find_freq_exact(>pdev->dev, gpu_freq, true);
> + if (IS_ERR_OR_NULL(gpu_opp))
> + goto done;
> +
> + ddr_opp = dev_pm_opp_xlate_required_opp(tables[GPU_OPP_TABLE_INDEX],
> + tables[GPU_DDR_OPP_TABLE_INDEX],
> + gpu_opp);
> + dev_pm_opp_put(gpu_opp);
> +
> + if (IS_ERR_OR_NULL(ddr_opp))
> + goto done;
I think that the final approach is still up in the air but either way we're
going to pull the bandwidth from an OPP, its just a question of which OPP.
> + peak_bw = dev_pm_opp_get_bw(ddr_opp, NULL);
> + dev_pm_opp_put(ddr_opp);
> +
> + icc_set_bw(gpu->icc_path, 0, peak_bw);
> + return;
> +done:
> + /*
> + * If there is a problem, for now leave it at max so that the
> + * performance is nominal.
> + */
> + icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
> +}
> +
> static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
> {
> struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
> @@ -128,11 +162,8 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu,
> int index)
>
> gmu->freq = gmu->gpu_freqs[index];
>
> - /*
> - * Eventually we will want to scale the path vote with the frequency but
> - * for now leave it at max so that the performance is nominal.
> - */
> - icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
> + if (gpu->icc_path)
> + a6xx_gmu_set_icc_vote(gpu, gmu->freq);
This function is annoying because we call it from two different spots, but it
feels wasteful that devfreq gives us an OPP pointer and we go out of our way to
not use it only to search for it again in the set_icc_vote function. I think
maybe we should pass the OPP through from msm_gpu.c. We could have a helper
function to pull the initial opp in a6xx_gmu_resume to make it clean.
> }
>
> void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 2d13694..bbbcc7a 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -882,7 +882,7 @@ static int adreno_get_pwrlevels(struct device *dev,
> {
> unsigned long freq = ULONG_MAX;
> struct dev_pm_opp *opp;
> - int ret;
> + int ret, i;
>
> gpu->fast_rate = 0;
>
> @@ -890,9 +890,29 @@ static int adreno_get_pwrlevels(struct device *dev,
> if (!of_find_property(dev->of_node, "operating-points-v2", NULL))
> ret = adreno_get_legacy_pwrlevels(dev);
> else {
> - ret = dev_pm_opp_of_add_table(dev);
> - if (ret)
> - DRM_DEV_ERROR(dev, "Unable to set the OPP table\n");
> + int count = of_count_phandle_with_args(dev->of_node,
> + "operating-points-v2", NULL);
> +
> + count = min(count, GPU_DDR_OPP_TABLE_INDEX + 1);
> + count = max(count, 1);
> +
> + for (i = 0; i < count; i++) {
> + ret = dev_pm_opp_of_add_table_indexed(dev, i);
> + if (ret) {
> + DRM_DEV_ERROR(dev, "Add OPP table %d: failed
> %d\n",
> + i, ret);
> + goto err;
> + }
> +
> + gpu->opp_tables[i] =
> + dev_pm_opp_get_opp_table_indexed(dev, i);
> + if (!gpu->opp_tables[i]) {
> + DRM_DEV_ERROR(dev, "Get OPP table
Re: [PATCH v1 32/36] dt-bindings: display: convert sharp, ls037v7dw01 to DT Schema
On Sun, Mar 29, 2020 at 1:04 PM Sam Ravnborg wrote: > > Hi Rob. > > > > + > > > + mode-gpios: > > > +description: | > > > + GPIO ordered MO, LR, and UD as specified in LS037V7DW01.pdf > > > > 3 or... > > > > > + change configuration between QVGA and VGA mode and the > > > + scan direction. As these pins can be also configured > > > + with external pulls, all the GPIOs are considered > > > + optional with holes in the array. > > > > minItems: 3 > > maxItems: 5 > > This binding can specify up to three GPIOs like this: So it should be: minItems: 1 maxItems: 3 > > > +mode-gpios = < 26 GPIO_ACTIVE_HIGH/* gpio154, lcd > > > MO */ > > > + 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR > > > */ > > > + 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD > > > */ > > They are in the linux kernel driver accessed like this: > > devm_gpiod_get_index(>dev, "mode", 2, GPIOD_OUT_LOW); > > The following is OK in the DT file: > > mode-gpios = < 26 GPIO_ACTIVE_HIGH>; > > mode-gpios = < 26 GPIO_ACTIVE_HIGH >2 GPIO_ACTIVE_HIGH>; > > mode-gpios = < 26 GPIO_ACTIVE_HIGH >2 GPIO_ACTIVE_HIGH >3 GPIO_ACTIVE_HIGH>; With the above, the 2nd 2 should fail... > But the following is not OK: > mode-gpios = < 26 GPIO_ACTIVE_HIGH>, < 2 GPIO_ACTIVE_HIGH>; And this should pass. We want phandle+arg type properties to be bracketed like this. If that's not working, then it's a bug in the tooling. Please confirm and I'll investigate. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: panel-orientation-quirks: 320 FHD and D330 HD
Hi,
On 3/31/20 6:44 PM, Jani Nikula wrote:
On Fri, 27 Mar 2020, David Santamaría Rogado wrote:
This patch is still valid as no changes to panel orientation quirks
have been done. Someone can review this to merge?
Cc: Hans.
Looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
El mar., 30 jul. 2019 a las 21:49, David Santamaría Rogado
() escribió:
This adds the HD version of Lenovo Ideapad D330
and FHD version of Lenovo Ideapad Miix 320.
This should work despite the dmi data is the same because
the resolution checks.
Signed-off-by: David Santamaría Rogado
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index ffd95bfeaa94..896c783ce135 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -191,14 +191,28 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "MIIX 310-10ICR"),
},
.driver_data = (void *)_rightside_up,
- }, {/* Lenovo Ideapad Miix 320 */
+ }, {/* Lenovo Ideapad Miix 320 (HD) */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80XF"),
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX
320-10ICR"),
},
.driver_data = (void *)_rightside_up,
- }, {/* Lenovo Ideapad D330 */
+ }, {/* Lenovo Ideapad Miix 320 (FHD) */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80XF"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX 320-10ICR"),
+ },
+ .driver_data = (void *)_rightside_up,
+ }, {/* Lenovo Ideapad D330 (HD) */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "81H3"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
D330-10IGM"),
+ },
+ .driver_data = (void *)_rightside_up,
+ }, {/* Lenovo Ideapad D330 (FHD) */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "81H3"),
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: panel-orientation-quirks: 320 FHD and D330 HD
On Fri, 27 Mar 2020, David Santamaría Rogado wrote:
> This patch is still valid as no changes to panel orientation quirks
> have been done. Someone can review this to merge?
Cc: Hans.
>
> El mar., 30 jul. 2019 a las 21:49, David Santamaría Rogado
> () escribió:
>>
>> This adds the HD version of Lenovo Ideapad D330
>> and FHD version of Lenovo Ideapad Miix 320.
>>
>> This should work despite the dmi data is the same because
>> the resolution checks.
>>
>> Signed-off-by: David Santamaría Rogado
>> ---
>> drivers/gpu/drm/drm_panel_orientation_quirks.c | 18 --
>> 1 file changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
>> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
>> index ffd95bfeaa94..896c783ce135 100644
>> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
>> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
>> @@ -191,14 +191,28 @@ static const struct dmi_system_id orientation_data[] =
>> {
>> DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "MIIX 310-10ICR"),
>> },
>> .driver_data = (void *)_rightside_up,
>> - }, {/* Lenovo Ideapad Miix 320 */
>> + }, {/* Lenovo Ideapad Miix 320 (HD) */
>> .matches = {
>> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80XF"),
>> DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX
>> 320-10ICR"),
>> },
>> .driver_data = (void *)_rightside_up,
>> - }, {/* Lenovo Ideapad D330 */
>> + }, {/* Lenovo Ideapad Miix 320 (FHD) */
>> + .matches = {
>> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "80XF"),
>> + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX
>> 320-10ICR"),
>> + },
>> + .driver_data = (void *)_rightside_up,
>> + }, {/* Lenovo Ideapad D330 (HD) */
>> + .matches = {
>> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "81H3"),
>> + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
>> D330-10IGM"),
>> + },
>> + .driver_data = (void *)_rightside_up,
>> + }, {/* Lenovo Ideapad D330 (FHD) */
>> .matches = {
>> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "81H3"),
>> --
>> 2.21.0
>>
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm: msm: a6xx: Fix off by one error when setting GPU freq
On Tue, Mar 31, 2020 at 01:25:52PM +0530, Sharat Masetty wrote: > This patch fixes an error in the for loop, thereby allowing search on > the full list of possible GPU power levels. > > Signed-off-by: Sharat Masetty Oh fun. This qualifies for drm-fixes. Can you pull this out of the stack and CC stable? Reviewed-by: Jordan Crouse > --- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > index 489d9b6..81b8559 100644 > --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > @@ -176,7 +176,7 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long > freq) > if (freq == gmu->freq) > return; > > - for (perf_index = 0; perf_index < gmu->nr_gpu_freqs - 1; perf_index++) > + for (perf_index = 0; perf_index < gmu->nr_gpu_freqs; perf_index++) > if (freq == gmu->gpu_freqs[perf_index]) > break; > > -- > 2.7.4 > -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 0/2] Add support for rm69299 Visionox panel driver and add devicetree bindings for visionox panel
On Mon, Mar 30, 2020 at 09:25:11PM +0200, Sam Ravnborg wrote: > Hi Matthias. > > On Sun, Mar 29, 2020 at 10:44:17AM -0700, Matthias Kaehlcke wrote: > > Hi Sam, > > > > On Sat, Mar 28, 2020 at 09:40:47PM +0100, Sam Ravnborg wrote: > > > Hi Harigovindan > > > > > > On Fri, Mar 27, 2020 at 01:06:34PM +0530, Harigovindan P wrote: > > > > Adding support for visionox rm69299 panel driver and adding bindings > > > > for the same panel. > > > > > > > > Harigovindan P (2): > > > > dt-bindings: display: add visionox rm69299 panel variant > > > > drm/panel: add support for rm69299 visionox panel driver > > > > > > I have only the first patch, which is now applied. > > > Please resend second patch as it is lost somewhere. > > > > Yes, it seems for v8, v9 and v10 only the bindings were sent, even > > though the cover letter and subject say it's a series of two patches. > > > > To my knowledge the latest version of the driver patch is this: > > > > https://patchwork.kernel.org/patch/11439689/ > > I did not go back and check, but I recall there was > review feedback that is not yet addressed. > > I applied the patch here and checkpatch was not happy: > total: 14 errors, 22 warnings, 11 checks, 314 lines checked > > Many of these are trivial indent or spaces used where tabs should be > used. > These needs to be fixed before the driver will be applied. > > And there was too much that I just did it while applying. Oh, I totally missed these, sure this needs to be addressed. Harigovindan, please also double check if there is any outstanding feedback that still needs to be addressed. Thanks Matthias ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep
Hi,
On Tue, Mar 31, 2020 at 6:58 AM Kalyan Thota wrote:
>
> "The PM core always increments the runtime usage counter
> before calling the ->suspend() callback and decrements it
> after calling the ->resume() callback"
>
> DPU and DSI are managed as runtime devices. When
> suspend is triggered, PM core adds a refcount on all the
> devices and calls device suspend, since usage count is
> already incremented, runtime suspend was not getting called
> and it kept the clocks on which resulted in target not
> entering into XO shutdown.
>
> Add changes to force suspend on runtime devices during pm sleep.
>
> Changes in v1:
> - Remove unnecessary checks in the function
> _dpu_kms_disable_dpu (Rob Clark).
>
> Changes in v2:
> - Avoid using suspend_late to reset the usagecount
>as suspend_late might not be called during suspend
>call failures (Doug).
>
> Changes in v3:
> - Use force suspend instead of managing device usage_count
>via runtime put and get API's to trigger callbacks (Doug).
>
> Signed-off-by: Kalyan Thota
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 ++
> drivers/gpu/drm/msm/dsi/dsi.c | 2 ++
> drivers/gpu/drm/msm/msm_drv.c | 4
> 3 files changed, 8 insertions(+)
This looks much saner to me. Thanks! I assume it still works fine
for you? I'm still no expert on how all the pieces of DRM drivers
work together, but at least there's not a bunch of strange fiddling
with pm_runtime state and hopefully it will avoid weird corner
cases...
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index ce19f1d..b886d9d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -1123,6 +1123,8 @@ static int __maybe_unused dpu_runtime_resume(struct
> device *dev)
>
> static const struct dev_pm_ops dpu_pm_ops = {
> SET_RUNTIME_PM_OPS(dpu_runtime_suspend, dpu_runtime_resume, NULL)
> + SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> + pm_runtime_force_resume)
> };
>
> static const struct of_device_id dpu_dt_match[] = {
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
> index 55ea4bc2..62704885 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi.c
> @@ -161,6 +161,8 @@ static int dsi_dev_remove(struct platform_device *pdev)
>
> static const struct dev_pm_ops dsi_pm_ops = {
> SET_RUNTIME_PM_OPS(msm_dsi_runtime_suspend, msm_dsi_runtime_resume,
> NULL)
> + SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> + pm_runtime_force_resume)
> };
>
> static struct platform_driver dsi_driver = {
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 7d985f8..2b8c99c 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -1051,6 +1051,8 @@ static int msm_pm_suspend(struct device *dev)
> return ret;
> }
>
> + pm_runtime_force_suspend(dev);
nit: check return value of pm_runtime_force_suspend()?
> +
> return 0;
> }
>
> @@ -1063,6 +1065,8 @@ static int msm_pm_resume(struct device *dev)
> if (WARN_ON(!priv->pm_state))
> return -ENOENT;
>
> + pm_runtime_force_resume(dev);
nit: check return value of pm_runtime_force_resume()?
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] phy: mediatek: Move mtk_hdmi_phy driver into drivers/phy/mediatek folder
From: CK Hu
mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
more suitable to place a phy driver into phy driver folder, so move
mtk_hdmi_phy driver into phy driver folder.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/Kconfig | 7 ---
drivers/gpu/drm/mediatek/Makefile | 6 --
drivers/phy/mediatek/Kconfig | 7 +++
drivers/phy/mediatek/Makefile | 7 +++
.../mediatek/phy-mtk-hdmi-mt2701.c}| 2 +-
.../mediatek/phy-mtk-hdmi-mt8173.c}| 2 +-
.../mtk_hdmi_phy.c => phy/mediatek/phy-mtk-hdmi.c} | 2 +-
.../mtk_hdmi_phy.h => phy/mediatek/phy-mtk-hdmi.h} | 0
8 files changed, 17 insertions(+), 16 deletions(-)
rename drivers/{gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c =>
phy/mediatek/phy-mtk-hdmi-mt2701.c} (99%)
rename drivers/{gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c =>
phy/mediatek/phy-mtk-hdmi-mt8173.c} (99%)
rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.c =>
phy/mediatek/phy-mtk-hdmi.c} (99%)
rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.h =>
phy/mediatek/phy-mtk-hdmi.h} (100%)
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index ff6a1eb4ae83..2427d5bf699d 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -26,10 +26,3 @@ config DRM_MEDIATEK_HDMI
select PHY_MTK_HDMI
help
DRM/KMS HDMI driver for Mediatek SoCs
-
-config PHY_MTK_HDMI
-tristate "MediaTek HDMI-PHY Driver"
-depends on ARCH_MEDIATEK && OF
-select GENERIC_PHY
-help
- Enable this to support HDMI-PHY
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index fcbef23aa6ce..77b0fd86063d 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -22,9 +22,3 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
mtk_hdmi_ddc.o
obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
-
-phy-mtk-hdmi-drv-objs := mtk_hdmi_phy.o \
-mtk_mt2701_hdmi_phy.o \
-mtk_mt8173_hdmi_phy.o
-
-obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
index dee757c957f2..10f0ec2d5b54 100644
--- a/drivers/phy/mediatek/Kconfig
+++ b/drivers/phy/mediatek/Kconfig
@@ -35,3 +35,10 @@ config PHY_MTK_XSPHY
Enable this to support the SuperSpeedPlus XS-PHY transceiver for
USB3.1 GEN2 controllers on MediaTek chips. The driver supports
multiple USB2.0, USB3.1 GEN2 ports.
+
+config PHY_MTK_HDMI
+tristate "MediaTek HDMI-PHY Driver"
+depends on ARCH_MEDIATEK && OF
+select GENERIC_PHY
+help
+ Enable this to support HDMI-PHY
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
index 08a8e6a97b1e..cda074c53235 100644
--- a/drivers/phy/mediatek/Makefile
+++ b/drivers/phy/mediatek/Makefile
@@ -6,3 +6,10 @@
obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
obj-$(CONFIG_PHY_MTK_UFS) += phy-mtk-ufs.o
obj-$(CONFIG_PHY_MTK_XSPHY)+= phy-mtk-xsphy.o
+
+phy-mtk-hdmi-drv-objs := phy-mtk-hdmi.o \
+phy-mtk-hdmi-mt2701.o \
+phy-mtk-hdmi-mt8173.o
+
+obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
+
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
similarity index 99%
rename from drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
rename to drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
index 99fe05cd3598..a6cb1dea3d0c 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
@@ -4,7 +4,7 @@
* Author: Chunhui Dai
*/
-#include "mtk_hdmi_phy.h"
+#include "phy-mtk-hdmi.h"
#define HDMI_CON0 0x00
#define RG_HDMITX_DRV_IBIAS0
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
similarity index 99%
rename from drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
rename to drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
index b55f51675205..3521c4893c53 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
@@ -4,7 +4,7 @@
* Author: Jie Qiu
*/
-#include "mtk_hdmi_phy.h"
+#include "phy-mtk-hdmi.h"
#define HDMI_CON0 0x00
#define RG_HDMITX_PLL_EN BIT(31)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/phy/mediatek/phy-mtk-hdmi.c
similarity index 99%
rename from drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
rename to drivers/phy/mediatek/phy-mtk-hdmi.c
index fe022acddbef..8fc83f01a720 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
@@ -4,7 +4,7 @@
* Author: Jie Qiu
*/
-#include "mtk_hdmi_phy.h"
[PATCH v3 0/4] Move Mediatek HDMI PHY driver from DRM folder to PHY folder
mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
more suitable to place a phy driver into phy driver folder, so move
mtk_hdmi_phy driver into phy driver folder.
Changes in v3:
- Modify [PATCH v2 3/4] prefix.
Changes in v2:
- include module.h in mtk_hdmi.c
CK Hu (3):
drm/mediatek: Move tz_disabled from mtk_hdmi_phy to mtk_hdmi driver
drm/mediatek: Separate mtk_hdmi_phy to an independent module
phy: mediatek: Move mtk_hdmi_phy driver into drivers/phy/mediatek
folder
Chun-Kuang Hu (1):
MAINTAINERS: add files for Mediatek DRM drivers
MAINTAINERS | 1 +
drivers/gpu/drm/mediatek/Kconfig | 2 +-
drivers/gpu/drm/mediatek/Makefile | 5 +---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 24 +++
drivers/gpu/drm/mediatek/mtk_hdmi.h | 1 -
drivers/phy/mediatek/Kconfig | 7 ++
drivers/phy/mediatek/Makefile | 7 ++
.../mediatek/phy-mtk-hdmi-mt2701.c} | 3 +--
.../mediatek/phy-mtk-hdmi-mt8173.c} | 2 +-
.../mediatek/phy-mtk-hdmi.c} | 3 ++-
.../mediatek/phy-mtk-hdmi.h} | 2 --
11 files changed, 41 insertions(+), 16 deletions(-)
rename drivers/{gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c =>
phy/mediatek/phy-mtk-hdmi-mt2701.c} (99%)
rename drivers/{gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c =>
phy/mediatek/phy-mtk-hdmi-mt8173.c} (99%)
rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.c =>
phy/mediatek/phy-mtk-hdmi.c} (98%)
rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.h =>
phy/mediatek/phy-mtk-hdmi.h} (95%)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] drm/mediatek: Move tz_disabled from mtk_hdmi_phy to mtk_hdmi driver
From: CK Hu
tz_disabled is used to control mtk_hdmi output signal, but this variable
is stored in mtk_hdmi_phy and mtk_hdmi_phy does not use it. So move
tz_disabled to mtk_hdmi where it's used.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 22 ---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h | 1 -
.../gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c| 1 -
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 5e4a4dbda443..878433c09c9b 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -144,11 +144,16 @@ struct hdmi_audio_param {
struct hdmi_codec_params codec_params;
};
+struct mtk_hdmi_conf {
+ bool tz_disabled;
+};
+
struct mtk_hdmi {
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
struct drm_connector conn;
struct device *dev;
+ const struct mtk_hdmi_conf *conf;
struct phy *phy;
struct device *cec_dev;
struct i2c_adapter *ddc_adpt;
@@ -230,7 +235,6 @@ static void mtk_hdmi_hw_vid_black(struct mtk_hdmi *hdmi,
bool black)
static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi *hdmi, bool enable)
{
struct arm_smccc_res res;
- struct mtk_hdmi_phy *hdmi_phy = phy_get_drvdata(hdmi->phy);
/*
* MT8173 HDMI hardware has an output control bit to enable/disable HDMI
@@ -238,7 +242,7 @@ static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi
*hdmi, bool enable)
* The ARM trusted firmware provides an API for the HDMI driver to set
* this control bit to enable HDMI output in supervisor mode.
*/
- if (hdmi_phy->conf && hdmi_phy->conf->tz_disabled)
+ if (hdmi->conf->tz_disabled)
regmap_update_bits(hdmi->sys_regmap,
hdmi->sys_offset + HDMI_SYS_CFG20,
0x80008005, enable ? 0x8005 : 0x8000);
@@ -1688,6 +1692,7 @@ static int mtk_drm_hdmi_probe(struct platform_device
*pdev)
return -ENOMEM;
hdmi->dev = dev;
+ hdmi->conf = of_device_get_match_data(dev);
ret = mtk_hdmi_dt_parse_pdata(hdmi, pdev);
if (ret)
@@ -1765,8 +1770,19 @@ static int mtk_hdmi_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mtk_hdmi_pm_ops,
mtk_hdmi_suspend, mtk_hdmi_resume);
+static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 = {
+ .tz_disabled = true,
+};
+
+static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8173;
+
static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
- { .compatible = "mediatek,mt8173-hdmi", },
+ { .compatible = "mediatek,mt2701-hdmi",
+ .data = _hdmi_conf_mt2701,
+ },
+ { .compatible = "mediatek,mt8173-hdmi",
+ .data = _hdmi_conf_mt8173,
+ },
{}
};
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index 2d8b3182470d..fc1c2efd1128 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -20,7 +20,6 @@
struct mtk_hdmi_phy;
struct mtk_hdmi_phy_conf {
- bool tz_disabled;
unsigned long flags;
const struct clk_ops *hdmi_phy_clk_ops;
void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index d3cc4022e988..99fe05cd3598 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -237,7 +237,6 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
}
struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
- .tz_disabled = true,
.flags = CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/4] MAINTAINERS: add files for Mediatek DRM drivers
Mediatek HDMI phy driver is moved from drivers/gpu/drm/mediatek to drivers/phy/mediatek, so add the new folder to the Mediatek DRM drivers' information. Signed-off-by: Chun-Kuang Hu --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 38fe2f3f7b6f..129777037538 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5612,6 +5612,7 @@ M:Philipp Zabel L: dri-devel@lists.freedesktop.org S: Supported F: drivers/gpu/drm/mediatek/ +F: drivers/phy/mediatek/phy-mtk-hdmi* F: Documentation/devicetree/bindings/display/mediatek/ DRM DRIVERS FOR NVIDIA TEGRA -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/4] drm/mediatek: Separate mtk_hdmi_phy to an independent module
From: CK Hu
mtk_hdmi_phy is a part of mtk_hdmi module, but phy driver should be an
independent module rather than be part of drm module, so separate the phy
driver to an independent module.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/Kconfig| 9 -
drivers/gpu/drm/mediatek/Makefile | 11 +++
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
drivers/gpu/drm/mediatek/mtk_hdmi.h | 1 -
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c | 1 +
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h | 1 -
6 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index fa5ffc4fe823..ff6a1eb4ae83 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -23,6 +23,13 @@ config DRM_MEDIATEK_HDMI
tristate "DRM HDMI Support for Mediatek SoCs"
depends on DRM_MEDIATEK
select SND_SOC_HDMI_CODEC if SND_SOC
- select GENERIC_PHY
+ select PHY_MTK_HDMI
help
DRM/KMS HDMI driver for Mediatek SoCs
+
+config PHY_MTK_HDMI
+tristate "MediaTek HDMI-PHY Driver"
+depends on ARCH_MEDIATEK && OF
+select GENERIC_PHY
+help
+ Enable this to support HDMI-PHY
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index b7a82ed5788f..fcbef23aa6ce 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -19,9 +19,12 @@ obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
mediatek-drm-hdmi-objs := mtk_cec.o \
mtk_hdmi.o \
- mtk_hdmi_ddc.o \
- mtk_mt2701_hdmi_phy.o \
- mtk_mt8173_hdmi_phy.o \
- mtk_hdmi_phy.o
+ mtk_hdmi_ddc.o
obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
+
+phy-mtk-hdmi-drv-objs := mtk_hdmi_phy.o \
+mtk_mt2701_hdmi_phy.o \
+mtk_mt8173_hdmi_phy.o
+
+obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 878433c09c9b..ee72ece0e54d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1797,7 +1798,6 @@ static struct platform_driver mtk_hdmi_driver = {
};
static struct platform_driver * const mtk_hdmi_drivers[] = {
- _hdmi_phy_driver,
_hdmi_ddc_driver,
_cec_driver,
_hdmi_driver,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.h
b/drivers/gpu/drm/mediatek/mtk_hdmi.h
index bb3653de6bd1..472bf141c92b 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.h
@@ -5,7 +5,6 @@
*/
#ifndef _MTK_HDMI_CTRL_H
#define _MTK_HDMI_CTRL_H
-#include "mtk_hdmi_phy.h"
struct platform_driver;
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 5223498502c4..fe022acddbef 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -205,6 +205,7 @@ struct platform_driver mtk_hdmi_phy_driver = {
.of_match_table = mtk_hdmi_phy_match,
},
};
+module_platform_driver(mtk_hdmi_phy_driver);
MODULE_DESCRIPTION("MediaTek HDMI PHY Driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index fc1c2efd1128..b13e1d5f8e78 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -49,7 +49,6 @@ void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32
offset,
u32 val, u32 mask);
struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
-extern struct platform_driver mtk_hdmi_phy_driver;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/core: Use proper debugging macro
Use drm_dbg_kms() instead of DRM_DEBUG_KMS.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 7e3982c36baa..6fb1841fa71c 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -331,9 +331,9 @@ static int drm_gem_afbc_min_size(struct drm_device *dev,
case AFBC_FORMAT_MOD_BLOCK_SIZE_64x4:
case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8_64x4:
default:
- DRM_DEBUG_KMS("Invalid AFBC_FORMAT_MOD_BLOCK_SIZE: %lld.\n",
- mode_cmd->modifier[0]
- & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK);
+ drm_dbg_kms(dev, "Invalid AFBC_FORMAT_MOD_BLOCK_SIZE: %lld.\n",
+ mode_cmd->modifier[0]
+ & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK);
return -EINVAL;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] AFBC fixes
This short series addresses the way bpp value is made available for drm_gem_afbc_min_size(). It can be inferred from the format if a driver hasn't set anything in cpp[0] (patch 2/2). While at it, use proper debugging macro (patch 1/2). Andrzej Pietrasiewicz (2): drm/core: Use proper debugging macro drm/core: Calculate bpp in afbc helper Documentation/gpu/todo.rst | 15 --- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 45 +++- include/drm/drm_framebuffer.h| 7 --- 3 files changed, 35 insertions(+), 32 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/core: Calculate bpp in afbc helper
Some drivers (komeda, malidp) don't set anything in cpp. If that is the
case the right value can be inferred from the format. Then the "bpp" member
can be eliminated from struct drm_afbc_framebuffer.
Signed-off-by: Andrzej Pietrasiewicz
---
Documentation/gpu/todo.rst | 15
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 39
include/drm/drm_framebuffer.h| 7
3 files changed, 32 insertions(+), 29 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 37a3a023c114..439656f55c5d 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -404,21 +404,6 @@ Contact: Laurent Pinchart, respective driver maintainers
Level: Intermediate
-Encode cpp properly in malidp
--
-
-cpp (chars per pixel) is not encoded properly in malidp, zero is
-used instead. afbc implementation needs bpp or cpp, but if it is
-zero it needs to be provided elsewhere, and so the bpp field exists
-in struct drm_afbc_framebuffer.
-
-Properly encode cpp in malidp and remove the bpp field in struct
-drm_afbc_framebuffer.
-
-Contact: malidp maintainers
-
-Level: Intermediate
-
Core refactorings
=
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 6fb1841fa71c..cac15294aef6 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -309,11 +309,37 @@ drm_gem_fb_create_with_dirty(struct drm_device *dev,
struct drm_file *file,
}
EXPORT_SYMBOL_GPL(drm_gem_fb_create_with_dirty);
+static __u32 drm_gem_afbc_get_bpp(struct drm_device *dev,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ const struct drm_format_info *info;
+
+ info = drm_get_format_info(dev, mode_cmd);
+
+ /* use whatever a driver has set */
+ if (info->cpp[0])
+ return info->cpp[0] * 8;
+
+ /* guess otherwise */
+ switch (info->format) {
+ case DRM_FORMAT_YUV420_8BIT:
+ return 12;
+ case DRM_FORMAT_YUV420_10BIT:
+ return 15;
+ case DRM_FORMAT_VUY101010:
+ return 30;
+ default:
+ break;
+ }
+
+ /* all attempts failed */
+ return 0;
+}
+
static int drm_gem_afbc_min_size(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_afbc_framebuffer *afbc_fb)
{
- const struct drm_format_info *info;
__u32 n_blocks, w_alignment, h_alignment, hdr_alignment;
/* remove bpp when all users properly encode cpp in drm_format_info */
__u32 bpp;
@@ -351,12 +377,11 @@ static int drm_gem_afbc_min_size(struct drm_device *dev,
afbc_fb->aligned_height = ALIGN(mode_cmd->height, h_alignment);
afbc_fb->offset = mode_cmd->offsets[0];
- info = drm_get_format_info(dev, mode_cmd);
- /*
-* Change to always using info->cpp[0]
-* when all users properly encode it
-*/
- bpp = info->cpp[0] ? info->cpp[0] * 8 : afbc_fb->bpp;
+ bpp = drm_gem_afbc_get_bpp(dev, mode_cmd);
+ if (!bpp) {
+ drm_dbg_kms(dev, "Invalid AFBC bpp value: %d\n", bpp);
+ return -EINVAL;
+ }
n_blocks = (afbc_fb->aligned_width * afbc_fb->aligned_height)
/ AFBC_SUPERBLOCK_PIXELS;
diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
index b53c0332f040..be658ebbec72 100644
--- a/include/drm/drm_framebuffer.h
+++ b/include/drm/drm_framebuffer.h
@@ -331,13 +331,6 @@ struct drm_afbc_framebuffer {
* @afbc_size: minimum size of afbc buffer
*/
u32 afbc_size;
- /**
-* @bpp: bpp value for this afbc buffer
-* To be removed when users such as malidp
-* properly store the cpp in drm_format_info.
-* New users should not start using this field.
-*/
- u32 bpp;
};
#define fb_to_afbc_fb(x) container_of(x, struct drm_afbc_framebuffer, base)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH] drm/xen: fix passing zero to 'PTR_ERR' warning
On Tue, Mar 31, 2020 at 05:50:10PM +0300, Oleksandr Andrushchenko wrote:
> On 3/30/20 12:59, Ding Xiang wrote:
> > Fix a static code checker warning:
> > drivers/gpu/drm/xen/xen_drm_front.c:404 xen_drm_drv_dumb_create()
> > warn: passing zero to 'PTR_ERR'
> >
> > Signed-off-by: Ding Xiang
> Reviewed-by: Oleksandr Andrushchenko
merged to drm-misc-next-fixese.
-Daniel
> > ---
> > drivers/gpu/drm/xen/xen_drm_front.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
> > b/drivers/gpu/drm/xen/xen_drm_front.c
> > index 4be49c1..3741420 100644
> > --- a/drivers/gpu/drm/xen/xen_drm_front.c
> > +++ b/drivers/gpu/drm/xen/xen_drm_front.c
> > @@ -401,7 +401,7 @@ static int xen_drm_drv_dumb_create(struct drm_file
> > *filp,
> > obj = xen_drm_front_gem_create(dev, args->size);
> > if (IS_ERR_OR_NULL(obj)) {
> > - ret = PTR_ERR(obj);
> > + ret = PTR_ERR_OR_ZERO(obj);
> > goto fail;
> > }
--
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 0/4] drm/amd/display: more code cleanup in the dc_link file
On Tue, Mar 31, 2020 at 6:55 AM Melissa Wen wrote: > > These patches address many code style issues on dc_link for readability > and cleaning up warnings. Change suggested by checkpatch.pl. > Some issues remain and need some minor code refactoring for proper handling. > > Melissa Wen (4): > drm/amd/display: cleanup codestyle type BLOCK_COMMENT_STYLE on dc_link > drm/amd/display: codestyle cleanup on dc_link file until detect_dp > func > drm/amd/display: code cleanup on dc_link from is_same_edid to > get_ddc_line > drm/amd/display: code cleanup of dc_link file on func > dc_link_construct > Applied. Thanks! Alex > drivers/gpu/drm/amd/display/dc/core/dc_link.c | 358 +- > 1 file changed, 176 insertions(+), 182 deletions(-) > > -- > 2.25.1 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH] drm/xen: fix passing zero to 'PTR_ERR' warning
On 3/30/20 12:59, Ding Xiang wrote:
Fix a static code checker warning:
drivers/gpu/drm/xen/xen_drm_front.c:404 xen_drm_drv_dumb_create()
warn: passing zero to 'PTR_ERR'
Signed-off-by: Ding Xiang
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 4be49c1..3741420 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -401,7 +401,7 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
obj = xen_drm_front_gem_create(dev, args->size);
if (IS_ERR_OR_NULL(obj)) {
- ret = PTR_ERR(obj);
+ ret = PTR_ERR_OR_ZERO(obj);
goto fail;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dt-bindings: iio/accel: Drop duplicate adi, adxl345/6 from trivial-devices.yaml
On Fri, Mar 27, 2020 at 2:22 PM Sam Ravnborg wrote: > > Hi Rob. > > On Wed, Mar 25, 2020 at 04:05:38PM -0600, Rob Herring wrote: > > The 'adi,adxl345' definition is a duplicate as there's a full binding in: > > Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > > > > The trivial-devices binding doesn't capture that 'adi,adxl346' has a > > fallback compatible 'adi,adxl345', so let's add it to adi,adxl345.yaml. > > > > Cc: Michael Hennerich > > Cc: Jonathan Cameron > > Cc: Hartmut Knaack > > Cc: Lars-Peter Clausen > > Cc: Peter Meerwald-Stadler > > Cc: linux-...@vger.kernel.org > > Signed-off-by: Rob Herring > > --- > > .../devicetree/bindings/iio/accel/adi,adxl345.yaml | 10 +++--- > > Documentation/devicetree/bindings/trivial-devices.yaml | 4 > > 2 files changed, 7 insertions(+), 7 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > > b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > > index c602b6fe1c0c..d124eba1ce54 100644 > > --- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > > +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > > @@ -17,9 +17,13 @@ description: | > > > > properties: > >compatible: > > -enum: > > - - adi,adxl345 > > - - adi,adxl375 > > +oneOf: > > + - items: > > + - const: adi,adxl346 > > + - const: adi,adxl345 > > + - enum: > > + - adi,adxl345 > > + - adi,adxl375 > > I assume it is my schema understanding that is poor. > But I cannot parse the above. > > The mix of items, enum and const confuses me. compatible can be one of 3 possibilities: "adi,adxl346", "adi,adxl345" "adi,adxl345" "adi,adxl375" For a single entry, 'items' can be omitted. > I guess that if I am confused then others may end in the same situation. > Can we improve readability here or amybe add a comment? example-schema.yaml explains this to some extent. I'd rather improve that. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] dt-bindings: Add missing 'additionalProperties: false'
On Mon, Mar 30, 2020 at 2:38 AM Masahiro Yamada wrote: > > Hi Rob, > > On Mon, Mar 30, 2020 at 4:09 PM Masahiro Yamada wrote: > > > > On Thu, Mar 26, 2020 at 7:06 AM Rob Herring wrote: > > > > > > Setting 'additionalProperties: false' is frequently omitted, but is > > > important in order to check that there aren't extra undocumented > > > properties in a binding. > > > > > > Ideally, we'd just add this automatically and make this the default, but > > > there's some cases where it doesn't work. For example, if a common > > > schema is referenced, then properties in the common schema aren't part > > > of what's considered for 'additionalProperties'. Also, sometimes there > > > are bus specific properties such as 'spi-max-frequency' that go into > > > bus child nodes, but aren't defined in the child node's schema. > > > > > > So let's stick with the json-schema defined default and add > > > 'additionalProperties: false' where needed. This will be a continual > > > review comment and game of wack-a-mole. > > > > > > Signed-off-by: Rob Herring > > > --- > > > > > > > .../devicetree/bindings/gpio/socionext,uniphier-gpio.yaml | 2 ++ > > > > > > You may have already queue this up, but just in case. > > > > Acked-by: Masahiro Yamada > > > > I take back Ack for socionext,uniphier-gpio.yaml > > > > Now "make dt_binding_check" produces a new warning. > > gpio@5500: 'interrupt-parent' does not match any of the regexes: > 'pinctrl-[0-9]+' > > > This binding uses 'interrupt-parent' > without 'interrupts'. > > Instead, the mapping of the interrupt numbers > is specified by the vendor-specific property > socionext,interrupt-ranges > > > > I cannot add "interrupt-parent: true" because > dt-schema/meta-schemas/interrupts.yaml > has "interrupt-parent: false". > > > Is there any solution? I'd meant to just drop socionext,uniphier-gpio.yaml. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Fix 64-bit division error on 32-bit platforms in mod_freesync_build_vrr_params
On Tue, Mar 31, 2020 at 3:38 AM Nathan Chancellor
wrote:
>
> When building arm32 allyesconfig,
>
> ld.lld: error: undefined symbol: __aeabi_uldivmod
> >>> referenced by freesync.c
> >>>
> >>> gpu/drm/amd/display/modules/freesync/freesync.o:(mod_freesync_build_vrr_params)
> >>> in archive drivers/built-in.a
> >>> did you mean: __aeabi_uidivmod
> >>> defined in: arch/arm/lib/lib.a(lib1funcs.o)
>
> Use div_u64 in the two locations that do 64-bit divisior, which both
> have a u64 dividend and u32 divisor.
>
> Fixes: 349a370781de ("drm/amd/display: LFC not working on 2.0x range
> monitors")
> Signed-off-by: Nathan Chancellor
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> index 8911f01671aa..c33454a9e0b4 100644
> --- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> +++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> @@ -761,10 +761,10 @@ void mod_freesync_build_vrr_params(struct mod_freesync
> *mod_freesync,
>
> // If a monitor reports exactly max refresh of 2x of min, enforce it
> on nominal
> rounded_nominal_in_uhz =
> - ((nominal_field_rate_in_uhz + 5) / 10) *
> 10;
> + div_u64(nominal_field_rate_in_uhz + 5, 10) *
> 10;
> if (in_config->max_refresh_in_uhz == (2 *
> in_config->min_refresh_in_uhz) &&
> in_config->max_refresh_in_uhz == rounded_nominal_in_uhz)
> - min_refresh_in_uhz = nominal_field_rate_in_uhz / 2;
> + min_refresh_in_uhz = div_u64(nominal_field_rate_in_uhz, 2);
>
> if (!vrr_settings_require_update(core_freesync,
> in_config, (unsigned int)min_refresh_in_uhz,
> (unsigned int)max_refresh_in_uhz,
> --
> 2.26.0
>
> ___
> 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: [v4,1/3] drm/prime: use dma length macro when mapping sg
Hi Alex,
On 2020-03-31 16:10, Alex Deucher wrote:
> On Tue, Mar 31, 2020 at 1:25 AM Marek Szyprowski
> wrote:
>> Hi Alex,
>>
>> On 2020-03-30 15:23, Alex Deucher wrote:
>>> On Mon, Mar 30, 2020 at 4:18 AM Marek Szyprowski
>>> wrote:
Hi
On 2020-03-27 10:10, Marek Szyprowski wrote:
> Hi Christian,
>
> On 2020-03-27 09:11, Christian König wrote:
>> Am 27.03.20 um 08:54 schrieb Marek Szyprowski:
>>> On 2020-03-25 10:07, Shane Francis wrote:
As dma_map_sg can reorganize scatter-gather lists in a
way that can cause some later segments to be empty we should
always use the sg_dma_len macro to fetch the actual length.
This could now be 0 and not need to be mapped to a page or
address array
Signed-off-by: Shane Francis
Reviewed-by: Michael J. Ruhl
>>> This patch landed in linux-next 20200326 and it causes a kernel
>>> panic on
>>> various Exynos SoC based boards.
---
drivers/gpu/drm/drm_prime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 86d9b0e45c8c..1de2cde2277c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -967,7 +967,7 @@ int drm_prime_sg_to_page_addr_arrays(struct
sg_table *sgt, struct page **pages,
index = 0;
for_each_sg(sgt->sgl, sg, sgt->nents, count) {
-len = sg->length;
+len = sg_dma_len(sg);
page = sg_page(sg);
addr = sg_dma_address(sg);
>>> Sorry, but this code is wrong :(
>> Well it is at least better than before because it makes most drivers
>> work correctly again.
> Well, I'm not sure that a half-broken fix should be considered as a
> fix ;)
>
> Anyway, I just got the comment from Shane, that my patch is fixing the
> issues with amdgpu and radeon, while still working fine for exynos, so
> it is indeed a proper fix.
Today I've noticed that this patch went to final v5.6 without even a day
of testing in linux-next, so v5.6 is broken on Exynos and probably a few
other ARM archs, which rely on the drm_prime_sg_to_page_addr_arrays
function.
>>> Please commit your patch and cc stable.
>> I've already did that: https%3A%2F%2Flkml.org%2Flkml%2F2020%2F3%2F27%2F555
> Do you have drm-misc commit rights or do you need someone to commit
> this for you?
I have no access to drm-misc.
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v4,1/3] drm/prime: use dma length macro when mapping sg
On Tue, Mar 31, 2020 at 1:25 AM Marek Szyprowski
wrote:
>
> Hi Alex,
>
> On 2020-03-30 15:23, Alex Deucher wrote:
> > On Mon, Mar 30, 2020 at 4:18 AM Marek Szyprowski
> > wrote:
> >> Hi
> >>
> >> On 2020-03-27 10:10, Marek Szyprowski wrote:
> >>> Hi Christian,
> >>>
> >>> On 2020-03-27 09:11, Christian König wrote:
> Am 27.03.20 um 08:54 schrieb Marek Szyprowski:
> > On 2020-03-25 10:07, Shane Francis wrote:
> >> As dma_map_sg can reorganize scatter-gather lists in a
> >> way that can cause some later segments to be empty we should
> >> always use the sg_dma_len macro to fetch the actual length.
> >>
> >> This could now be 0 and not need to be mapped to a page or
> >> address array
> >>
> >> Signed-off-by: Shane Francis
> >> Reviewed-by: Michael J. Ruhl
> > This patch landed in linux-next 20200326 and it causes a kernel
> > panic on
> > various Exynos SoC based boards.
> >> ---
> >> drivers/gpu/drm/drm_prime.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> >> index 86d9b0e45c8c..1de2cde2277c 100644
> >> --- a/drivers/gpu/drm/drm_prime.c
> >> +++ b/drivers/gpu/drm/drm_prime.c
> >> @@ -967,7 +967,7 @@ int drm_prime_sg_to_page_addr_arrays(struct
> >> sg_table *sgt, struct page **pages,
> >>index = 0;
> >> for_each_sg(sgt->sgl, sg, sgt->nents, count) {
> >> -len = sg->length;
> >> +len = sg_dma_len(sg);
> >> page = sg_page(sg);
> >> addr = sg_dma_address(sg);
> > Sorry, but this code is wrong :(
> Well it is at least better than before because it makes most drivers
> work correctly again.
> >>> Well, I'm not sure that a half-broken fix should be considered as a
> >>> fix ;)
> >>>
> >>> Anyway, I just got the comment from Shane, that my patch is fixing the
> >>> issues with amdgpu and radeon, while still working fine for exynos, so
> >>> it is indeed a proper fix.
> >> Today I've noticed that this patch went to final v5.6 without even a day
> >> of testing in linux-next, so v5.6 is broken on Exynos and probably a few
> >> other ARM archs, which rely on the drm_prime_sg_to_page_addr_arrays
> >> function.
> > Please commit your patch and cc stable.
>
> I've already did that: https://lkml.org/lkml/2020/3/27/555
Do you have drm-misc commit rights or do you need someone to commit
this for you?
Alex
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R Institute Poland
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 00/12] Convert PWM period and duty cycle to u64
On Mon, Mar 30, 2020 at 02:00:12PM -0700, Guru Das Srinagesh wrote: > On Mon, Mar 30, 2020 at 09:26:36PM +0100, Daniel Thompson wrote: > > On Mon, Mar 30, 2020 at 12:15:07PM -0700, Guru Das Srinagesh wrote: > > > On Sat, Mar 21, 2020 at 02:47:03PM +0300, Dan Carpenter wrote: > > > > This is a giant CC list. > > > > > > Yes, this is because I received feedback [1] on an earlier patchset > > > directing me to add the reviewers of patches to the cover letter as > > > well so that they get some context for the patch. > > > ... > > > [1] https://www.spinics.net/lists/linux-pwm/msg11735.html > > > > Strictly speaking I only asked for backlight maintainers to be Cc:ed. > > I was fairly careful to be specific since I'm aware there are a variety > > of differing habits when putting together the Cc: list for covering > > letters. > > > > With the original patch header the purpose of the patch I was Cc:ed on > > was impossible to determine without the covering letter. > > I suspect this might be the case for all the other reviewers as well - > that they also would appreciate context for the specific patch they are > being added to review. > > I wasn't entirely sure what the convention was, so I applied your > suggestion to all the files. How do you suggest I handle this in my next > patchset? I fully agree that such a large CC list does look really > ungainly. IHMO there should not be a mechanical convention. Instead your goal needs to be how to make it as easy as possible to review your patches. Think about it this way: Each person in the To: of a patch (and maybe also Cc: depending on how you construct things) is a person you are asking to review and comment on the patch. If that person will find it easier to review the patch if they are included in the cover letter then either they should be included or you should improve the patch description of the patch itself (sometimes both). Either way it is about optimizing the patchset for readability. More people read them than write them. Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mm: Break long searches in fragmented address spaces
We try hard to select a suitable hole in the drm_mm first time. But if
that is unsuccessful, we then have to look at neighbouring nodes, and
this requires traversing the rbtree. Walking the rbtree can be slow
(much slower than a linear list for deep trees), and if the drm_mm has
been purposefully fragmented our search can be trapped for a long, long
time. For non-preemptible kernels, we need to break up long CPU bound
sections by manually checking for cond_resched(); similarly we should
also bail out if we have been told to terminate. (In an ideal world, we
would break for any signal, but we need to trade off having to perform
the search again after ERESTARTSYS, which again may form a trap of
making no forward progress.)
Reported-by: Zbigniew Kempczyński
Signed-off-by: Chris Wilson
Cc: Zbigniew Kempczyński
Cc: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 23 ---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 4 +++-
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +---
include/drm/drm_mm.h | 12 ++
6 files changed, 41 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 8981abe8b7c9..794d9d4c2d36 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
#include
@@ -343,7 +344,7 @@ first_hole(struct drm_mm *mm,
u64 start, u64 end, u64 size,
enum drm_mm_insert_mode mode)
{
- switch (mode) {
+ switch (mode & DRM_MM_INSERT_MODE) {
default:
case DRM_MM_INSERT_BEST:
return best_hole(mm, size);
@@ -366,7 +367,17 @@ next_hole(struct drm_mm *mm,
struct drm_mm_node *node,
enum drm_mm_insert_mode mode)
{
- switch (mode) {
+ if (mode & DRM_MM_INSERT_ONCE)
+ return NULL; /* check only the first hit */
+
+ /* Searching is slow; check if we ran out of time/patience */
+ if (mode & DRM_MM_INSERT_INTERRUPTIBLE) {
+ cond_resched();
+ if (fatal_signal_pending(current))
+ return NULL;
+ }
+
+ switch (mode & DRM_MM_INSERT_MODE) {
default:
case DRM_MM_INSERT_BEST:
return rb_hole_size_to_node(rb_prev(>rb_hole_size));
@@ -470,7 +481,6 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
{
struct drm_mm_node *hole;
u64 remainder_mask;
- bool once;
DRM_MM_BUG_ON(range_start > range_end);
@@ -483,13 +493,10 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
if (alignment <= 1)
alignment = 0;
- once = mode & DRM_MM_INSERT_ONCE;
- mode &= ~DRM_MM_INSERT_ONCE;
-
remainder_mask = is_power_of_2(alignment) ? alignment - 1 : 0;
for (hole = first_hole(mm, range_start, range_end, size, mode);
hole;
-hole = once ? NULL : next_hole(mm, hole, mode)) {
+hole = next_hole(mm, hole, mode)) {
u64 hole_start = __drm_mm_hole_node_start(hole);
u64 hole_end = hole_start + hole->hole_size;
u64 adj_start, adj_end;
@@ -557,7 +564,7 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
return 0;
}
- return -ENOSPC;
+ return signal_pending(current) ? -ERESTARTSYS : -ENOSPC;
}
EXPORT_SYMBOL(drm_mm_insert_node_in_range);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index cda35e6dfc44..21bdfa91b603 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1080,7 +1080,8 @@ static void *reloc_iomap(struct drm_i915_gem_object *obj,
(>vm.mm, >node,
PAGE_SIZE, 0, I915_COLOR_UNEVICTABLE,
0, ggtt->mappable_end,
-DRM_MM_INSERT_LOW);
+DRM_MM_INSERT_LOW |
+DRM_MM_INSERT_INTERRUPTIBLE);
mutex_unlock(>vm.mutex);
if (err) /* no inactive aperture space, use cpu reloc */
return NULL;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 5557dfa83a7b..04403f8a7d3a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -43,7 +43,9 @@ int i915_gem_stolen_insert_node_in_range(struct
drm_i915_private *i915,
mutex_lock(>mm.stolen_lock);
ret = drm_mm_insert_node_in_range(>mm.stolen, node,
size, alignment, 0,
-
Re: [PATCH] drm/mm: revert "Break long searches in fragmented address spaces"
Quoting Daniel Vetter (2020-03-31 11:38:50) > On Tue, Mar 31, 2020 at 11:20 AM Chris Wilson > wrote: > > Quoting Daniel Vetter (2020-03-31 10:16:18) > > > On Tue, Mar 31, 2020 at 10:59:45AM +0200, Christian König wrote: > > > > A not so gentle ping, since this pretty much broke all TTM based > > > > drivers. > > > > > > > > Could we revert this for now? > > > > > > Always ack for revert. > > > > > > Acked-by: Daniel Vetter > > > > So you didn't check the earlier patch either? > > I did, but wasn't super sold on the idea of more flags to smack an r-b > onto it, so figured I'll throw the default ack-for-revert on this > meanwhile. We allow userspace to poison the drm_mm at roughly 8K intervals, a search space of 35b with typically O(N^2) behaviour and each node traversal (rb_next/rb_prev) will itself be costly. Even our simple tests can generate a search of several minutes before our patience runs out.o Any drm_mm that allows for userspace to control alignment can be arbitrarily fragmented, hence a raised eyebrow that this search would be allowed in atomic context. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/mediatek: Move mtk_hdmi_phy driver into drivers/phy/mediatek folder
Hi, Neil:
Neil Armstrong 於 2020年3月31日 週二 下午4:05寫道：
>
> Hi,
>
> On 30/03/2020 16:12, Chun-Kuang Hu wrote:
> > From: CK Hu
> >
> > mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
> > more suitable to place a phy driver into phy driver folder, so move
> > mtk_hdmi_phy driver into phy driver folder.
>
> Pretty sure the subject should start with "phy: " and have an ack from Kishon.
I would modify the subject in next version and wait for Kishon's ack.
Regards,
Chun-Kuang.
>
> Neil
>
> >
> > Signed-off-by: CK Hu
> > Signed-off-by: Chun-Kuang Hu
> > ---
> > drivers/gpu/drm/mediatek/Kconfig | 7 ---
> > drivers/gpu/drm/mediatek/Makefile | 6 --
> > drivers/phy/mediatek/Kconfig | 7 +++
> > drivers/phy/mediatek/Makefile | 7 +++
> > .../mediatek/phy-mtk-hdmi-mt2701.c}| 2 +-
> > .../mediatek/phy-mtk-hdmi-mt8173.c}| 2 +-
> > .../mtk_hdmi_phy.c => phy/mediatek/phy-mtk-hdmi.c} | 2 +-
> > .../mtk_hdmi_phy.h => phy/mediatek/phy-mtk-hdmi.h} | 0
> > 8 files changed, 17 insertions(+), 16 deletions(-)
> > rename drivers/{gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c =>
> > phy/mediatek/phy-mtk-hdmi-mt2701.c} (99%)
> > rename drivers/{gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c =>
> > phy/mediatek/phy-mtk-hdmi-mt8173.c} (99%)
> > rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.c =>
> > phy/mediatek/phy-mtk-hdmi.c} (99%)
> > rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.h =>
> > phy/mediatek/phy-mtk-hdmi.h} (100%)
> >
> > diff --git a/drivers/gpu/drm/mediatek/Kconfig
> > b/drivers/gpu/drm/mediatek/Kconfig
> > index ff6a1eb4ae83..2427d5bf699d 100644
> > --- a/drivers/gpu/drm/mediatek/Kconfig
> > +++ b/drivers/gpu/drm/mediatek/Kconfig
> > @@ -26,10 +26,3 @@ config DRM_MEDIATEK_HDMI
> > select PHY_MTK_HDMI
> > help
> > DRM/KMS HDMI driver for Mediatek SoCs
> > -
> > -config PHY_MTK_HDMI
> > -tristate "MediaTek HDMI-PHY Driver"
> > -depends on ARCH_MEDIATEK && OF
> > -select GENERIC_PHY
> > -help
> > - Enable this to support HDMI-PHY
> > diff --git a/drivers/gpu/drm/mediatek/Makefile
> > b/drivers/gpu/drm/mediatek/Makefile
> > index fcbef23aa6ce..77b0fd86063d 100644
> > --- a/drivers/gpu/drm/mediatek/Makefile
> > +++ b/drivers/gpu/drm/mediatek/Makefile
> > @@ -22,9 +22,3 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
> > mtk_hdmi_ddc.o
> >
> > obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> > -
> > -phy-mtk-hdmi-drv-objs := mtk_hdmi_phy.o \
> > - mtk_mt2701_hdmi_phy.o \
> > - mtk_mt8173_hdmi_phy.o
> > -
> > -obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
> > diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> > index dee757c957f2..10f0ec2d5b54 100644
> > --- a/drivers/phy/mediatek/Kconfig
> > +++ b/drivers/phy/mediatek/Kconfig
> > @@ -35,3 +35,10 @@ config PHY_MTK_XSPHY
> > Enable this to support the SuperSpeedPlus XS-PHY transceiver for
> > USB3.1 GEN2 controllers on MediaTek chips. The driver supports
> > multiple USB2.0, USB3.1 GEN2 ports.
> > +
> > +config PHY_MTK_HDMI
> > +tristate "MediaTek HDMI-PHY Driver"
> > +depends on ARCH_MEDIATEK && OF
> > +select GENERIC_PHY
> > +help
> > + Enable this to support HDMI-PHY
> > diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> > index 08a8e6a97b1e..cda074c53235 100644
> > --- a/drivers/phy/mediatek/Makefile
> > +++ b/drivers/phy/mediatek/Makefile
> > @@ -6,3 +6,10 @@
> > obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
> > obj-$(CONFIG_PHY_MTK_UFS)+= phy-mtk-ufs.o
> > obj-$(CONFIG_PHY_MTK_XSPHY) += phy-mtk-xsphy.o
> > +
> > +phy-mtk-hdmi-drv-objs := phy-mtk-hdmi.o \
> > + phy-mtk-hdmi-mt2701.o \
> > + phy-mtk-hdmi-mt8173.o
> > +
> > +obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
> > +
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> > similarity index 99%
> > rename from drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > rename to drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> > index 99fe05cd3598..a6cb1dea3d0c 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > +++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> > @@ -4,7 +4,7 @@
> > * Author: Chunhui Dai
> > */
> >
> > -#include "mtk_hdmi_phy.h"
> > +#include "phy-mtk-hdmi.h"
> >
> > #define HDMI_CON00x00
> > #define RG_HDMITX_DRV_IBIAS 0
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > b/drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
> > similarity index 99%
> > rename from drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > rename to drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
> > index b55f51675205..3521c4893c53
Re: INFO: trying to register non-static key in try_to_wake_up
On Tue, Mar 31, 2020 at 2:50 PM Daniel Vetter wrote: > > On Tue, Mar 31, 2020 at 2:18 PM Bartlomiej Zolnierkiewicz > wrote: > > > > > > On 3/31/20 12:18 PM, Dmitry Vyukov wrote: > > > On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra > > > wrote: > > >> > > >> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote: > > >>> Hello, > > >>> > > >>> syzbot found the following crash on: > > >>> > > >>> HEAD commit:9420e8ad Merge tag 'for-linus' of > > >>> git://git.kernel.org/pub.. > > >>> git tree: upstream > > >>> console output: > > >>> https://protect2.fireeye.com/url?k=0756a78d-5a9a6c49-07572cc2-0cc47a314e9a-e4dc8b657d340686=https://syzkaller.appspot.com/x/log.txt?x=1206ed4be0 > > >>> kernel config: > > >>> https://protect2.fireeye.com/url?k=43211072-1eeddbb6-43209b3d-0cc47a314e9a-3bd45a19932c37c8=https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692 > > >>> dashboard link: > > >>> https://protect2.fireeye.com/url?k=bf7a6153-e2b6aa97-bf7bea1c-0cc47a314e9a-c64073ee605efb7b=https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356 > > >>> compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > >>> > > >>> Unfortunately, I don't have any reproducer for this crash yet. > > >>> > > >>> IMPORTANT: if you fix the bug, please add the following tag to the > > >>> commit: > > >>> Reported-by: syzbot+e84d7ebd1361da13c...@syzkaller.appspotmail.com > > >>> > > >>> INFO: trying to register non-static key. > > >>> the code is fine but needs lockdep annotation. > > >>> turning off the locking correctness validator. > > >>> CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0 > > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > >>> Google 01/01/2011 > > >>> Call Trace: > > >>> > > >>> __dump_stack lib/dump_stack.c:77 [inline] > > >>> dump_stack+0x188/0x20d lib/dump_stack.c:118 > > >>> assign_lock_key kernel/locking/lockdep.c:880 [inline] > > >>> register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189 > > >>> __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836 > > >>> lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484 > > >>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] > > >>> _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159 > > >>> try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547 > > >> > > >> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in > > >> copy_process(). This should be impossible. Very odd. > > > > > > The stack mentions fbdev, which is a red flag at the moment. There are > > > a dozen of bad bugs in fbdev and around. Just few days ago Andy > > > pointed to another "impossible" crash "general protection fault in > > > do_syscall_64" which is related to dri: > > > https://protect2.fireeye.com/url?k=0cb8ad06-517466c2-0cb92649-0cc47a314e9a-a20c11191483c65b=https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9 > > > https://protect2.fireeye.com/url?k=614292e3-3c8e5927-614319ac-0cc47a314e9a-aeda6d72c01a7b0e=https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ > > > > > > There are probably more random manifestations of these bugs already, > > > and I guess we will be getting more. > > > > > > +fbdev maintainers > > > > Thank you for the report. > > > > fbdev is in the maintenance mode and no new features or drivers are > > being added so syzbot reports are not for a new bugs (regressions) and > > are not a priority (at least to me). > > Yup same here, I've seen a pile of syzbot reports for fbdev (and also > vt, or combinations of them since fbdev is linked to vt through fbcon) > fly by. But I really don't have to deal with these, my recommendation > to anyone who cares about security are: > - Don't enable vt > - Don't enable fbdev > > All that code has been developed long ago, in a much more innocent > time. If someone wants to fix this you'd not just need to fix all the > syzbot stuff, but also ramp up a full testsuite for all the ioctl, and > all the corner-cases. Plus also fix some of the horrendous locking in > there, probably. > > Multi-year effort, easily. > > Regressions I'll obviously try to handle, but none of these are. It's > just syzbot has become smarter at hitting bugs in fbdev and vt > subsystems (or maybe the hw the virtual machines emulate has become > more varied, some of the reports are for fun stuff like vgacon ...). Forgot to mention: Just yesterday I did merge an fbcon overflow bugfix: commit b139f8b00db4a8ea75a4174346eafa48041aa489 (HEAD -> drm-misc-next-fixes, drm-misc/for-linux-next, drm-misc/drm-misc-next-fixes) Author: Qiujun Huang Date: Sun Mar 29 16:56:47 2020 +0800 fbcon: fix null-ptr-deref in fbcon_switch There's also a pending patch in the vt subsystem to catch overflow for unicode fonts on consoles, that's reviewed and waiting for Greg to pick it up. -Daniel > Cheers, Daniel > > > I have only resources to review/merge pending fbdev patches from time >
Re: INFO: trying to register non-static key in try_to_wake_up
On Tue, Mar 31, 2020 at 2:18 PM Bartlomiej Zolnierkiewicz wrote: > > > On 3/31/20 12:18 PM, Dmitry Vyukov wrote: > > On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra > > wrote: > >> > >> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote: > >>> Hello, > >>> > >>> syzbot found the following crash on: > >>> > >>> HEAD commit:9420e8ad Merge tag 'for-linus' of > >>> git://git.kernel.org/pub.. > >>> git tree: upstream > >>> console output: > >>> https://protect2.fireeye.com/url?k=0756a78d-5a9a6c49-07572cc2-0cc47a314e9a-e4dc8b657d340686=https://syzkaller.appspot.com/x/log.txt?x=1206ed4be0 > >>> kernel config: > >>> https://protect2.fireeye.com/url?k=43211072-1eeddbb6-43209b3d-0cc47a314e9a-3bd45a19932c37c8=https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692 > >>> dashboard link: > >>> https://protect2.fireeye.com/url?k=bf7a6153-e2b6aa97-bf7bea1c-0cc47a314e9a-c64073ee605efb7b=https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356 > >>> compiler: gcc (GCC) 9.0.0 20181231 (experimental) > >>> > >>> Unfortunately, I don't have any reproducer for this crash yet. > >>> > >>> IMPORTANT: if you fix the bug, please add the following tag to the commit: > >>> Reported-by: syzbot+e84d7ebd1361da13c...@syzkaller.appspotmail.com > >>> > >>> INFO: trying to register non-static key. > >>> the code is fine but needs lockdep annotation. > >>> turning off the locking correctness validator. > >>> CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0 > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > >>> Google 01/01/2011 > >>> Call Trace: > >>> > >>> __dump_stack lib/dump_stack.c:77 [inline] > >>> dump_stack+0x188/0x20d lib/dump_stack.c:118 > >>> assign_lock_key kernel/locking/lockdep.c:880 [inline] > >>> register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189 > >>> __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836 > >>> lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484 > >>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] > >>> _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159 > >>> try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547 > >> > >> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in > >> copy_process(). This should be impossible. Very odd. > > > > The stack mentions fbdev, which is a red flag at the moment. There are > > a dozen of bad bugs in fbdev and around. Just few days ago Andy > > pointed to another "impossible" crash "general protection fault in > > do_syscall_64" which is related to dri: > > https://protect2.fireeye.com/url?k=0cb8ad06-517466c2-0cb92649-0cc47a314e9a-a20c11191483c65b=https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9 > > https://protect2.fireeye.com/url?k=614292e3-3c8e5927-614319ac-0cc47a314e9a-aeda6d72c01a7b0e=https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ > > > > There are probably more random manifestations of these bugs already, > > and I guess we will be getting more. > > > > +fbdev maintainers > > Thank you for the report. > > fbdev is in the maintenance mode and no new features or drivers are > being added so syzbot reports are not for a new bugs (regressions) and > are not a priority (at least to me). Yup same here, I've seen a pile of syzbot reports for fbdev (and also vt, or combinations of them since fbdev is linked to vt through fbcon) fly by. But I really don't have to deal with these, my recommendation to anyone who cares about security are: - Don't enable vt - Don't enable fbdev All that code has been developed long ago, in a much more innocent time. If someone wants to fix this you'd not just need to fix all the syzbot stuff, but also ramp up a full testsuite for all the ioctl, and all the corner-cases. Plus also fix some of the horrendous locking in there, probably. Multi-year effort, easily. Regressions I'll obviously try to handle, but none of these are. It's just syzbot has become smarter at hitting bugs in fbdev and vt subsystems (or maybe the hw the virtual machines emulate has become more varied, some of the reports are for fun stuff like vgacon ...). Cheers, Daniel > I have only resources to review/merge pending fbdev patches from time > to time so any help in fixing these syzbot reports is welcomed (there > have been a few fbdev related syzbot reports recently). > > Also please note that fbdev is maintained through drm-misc tree so > patches can also be handled by other drm-misc maintainers in case I'm > not available / busy with other things. > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R Institute Poland > Samsung Electronics > > >>> wake_up_worker kernel/workqueue.c:836 [inline] > >>> insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337 > >>> __queue_work+0x50d/0x1280 kernel/workqueue.c:1488 > >>> call_timer_fn+0x195/0x760 kernel/time/timer.c:1404 > >>> expire_timers kernel/time/timer.c:1444 [inline] > >>>
Re: [PATCH] drm/mm: revert "Break long searches in fragmented address spaces"
Am 31.03.20 um 12:38 schrieb Daniel Vetter: On Tue, Mar 31, 2020 at 11:20 AM Chris Wilson wrote: Quoting Daniel Vetter (2020-03-31 10:16:18) On Tue, Mar 31, 2020 at 10:59:45AM +0200, Christian König wrote: A not so gentle ping, since this pretty much broke all TTM based drivers. Could we revert this for now? Always ack for revert. Acked-by: Daniel Vetter So you didn't check the earlier patch either? I did, but wasn't super sold on the idea of more flags to smack an r-b onto it, so figured I'll throw the default ack-for-revert on this meanwhile. Mhm, and there is something wrong with either dri-devel or patchwork (I suspect the former). I can't see your reply on patchwork and it entered my inbox much later than Daniels mails. Christian. -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: framebuffer bug (Re: general protection fault in do_syscall_64)
[ please remember to include dri-devel ML & me on fbdev issues, thank you ] On 3/29/20 1:37 AM, Andy Lutomirski wrote: > On Sat, Mar 28, 2020 at 12:34 PM syzbot > wrote: >> >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit:69c5eea3 Merge branch 'parisc-5.6-2' of git://git.kernel.o.. >> git tree: upstream >> console output: https://syzkaller.appspot.com/x/log.txt?x=14d3517be0 >> kernel config: https://syzkaller.appspot.com/x/.config?x=4ac76c43beddbd9 >> dashboard link: https://syzkaller.appspot.com/bug?extid=f9b2c53f55a9270fc778 >> compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ >> c2443155a0fb245c8f17f2c1c72b6ea391e86e81) >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15059d05e0 >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16e5d5a3e0 >> >> IMPORTANT: if you fix the bug, please add the following tag to the commit: >> Reported-by: syzbot+f9b2c53f55a9270fc...@syzkaller.appspotmail.com > > Hi framebuffer people- Hi Andy, > Somewhere in the framebuffer code is a horrible bug that spews zeros > over kernel memory (including text, suggesting a *physical* memory > overrun). My suspicion is that there is insufficient validation in > the ioctls that set font parameters. fbdev is in the maintenance mode and no new features or drivers are being added so syzbot reports are not for a new bugs (regressions) and are not a priority (at least to me). > Could someone who is actually familiar with this code take a look? Unfortunately I'm not familiar with this part of fbdev and I have only resources to review/merge pending fbdev patches from time to time so any help in fixing this and other syzbot reports is welcomed. PS fbdev is maintained through drm-misc tree so patches can also be handled by other drm-misc maintainers in case I'm not available. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics > --Andy > >> >> general protection fault, probably for non-canonical address >> 0x11215a85: [#1] PREEMPT SMP KASAN >> CPU: 1 PID: 7207 Comm: syz-executor045 Not tainted 5.6.0-rc7-syzkaller #0 >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >> Google 01/01/2011 >> RIP: 0010:__read_once_size include/linux/compiler.h:199 [inline] >> RIP: 0010:do_syscall_64+0x5f/0x1b0 arch/x86/entry/common.c:289 >> Code: 48 c7 c7 28 d4 0a 89 e8 bf 5d b0 00 48 83 3d af 5b 0a 08 00 0f 84 58 >> 01 00 00 fb 66 0f 1f 44 00 00 65 48 8b 1c 25 c0 1d 02 00 <48> 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> RSP: 0018:c90001617f28 EFLAGS: 00010282 >> RAX: 11215a85 RBX: 888095530380 RCX: 888095530380 >> RDX: dc00 RSI: RDI: 888095530bc4 >> RBP: R08: 817a2210 R09: >> R10: R11: R12: 0023 >> R13: dc00 R14: c90001617f58 R15: >> FS: 01333880() GS:8880ae90() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: 7f87bf9aae78 CR3: a6a3f000 CR4: 001406e0 >> DR0: DR1: DR2: >> DR3: DR6: fffe0ff0 DR7: 0400 >> Call Trace: >> entry_SYSCALL_64_after_hwframe+0x49/0xbe >> RIP: 0033:0x4454e1 >> Code: 75 14 b8 23 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 64 1f fc ff c3 48 >> 83 ec 08 e8 9a 42 00 00 48 89 04 24 b8 23 00 00 00 0f 05 <48> 8b 3c 24 48 89 >> c2 e8 e3 42 00 00 48 89 d0 48 83 c4 08 48 3d 01 >> RSP: 002b:7ffd72d164b0 EFLAGS: 0293 ORIG_RAX: 0023 >> RAX: ffda RBX: 000c RCX: 004454e1 >> RDX: RSI: RDI: 7ffd72d164c0 >> RBP: 006dbc20 R08: R09: >> R10: 7ffd72d164e0 R11: 0293 R12: >> R13: 006dbc2c R14: 000a R15: >> Modules linked in: >> ---[ end trace 3da67f82bf6bae14 ]--- >> RIP: 0010:__read_once_size include/linux/compiler.h:199 [inline] >> RIP: 0010:do_syscall_64+0x5f/0x1b0 arch/x86/entry/common.c:289 >> Code: 48 c7 c7 28 d4 0a 89 e8 bf 5d b0 00 48 83 3d af 5b 0a 08 00 0f 84 58 >> 01 00 00 fb 66 0f 1f 44 00 00 65 48 8b 1c 25 c0 1d 02 00 <48> 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> RSP: 0018:c90001617f28 EFLAGS: 00010282 >> RAX: 11215a85 RBX: 888095530380 RCX: 888095530380 >> RDX: dc00 RSI: RDI: 888095530bc4 >> RBP: R08: 817a2210 R09: >> R10: R11: R12: 0023 >> R13: dc00 R14: c90001617f58 R15: >> FS: 01333880() GS:8880ae90() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >>
Re: INFO: trying to register non-static key in try_to_wake_up
On 3/31/20 12:18 PM, Dmitry Vyukov wrote: > On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra wrote: >> >> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote: >>> Hello, >>> >>> syzbot found the following crash on: >>> >>> HEAD commit:9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub.. >>> git tree: upstream >>> console output: >>> https://protect2.fireeye.com/url?k=0756a78d-5a9a6c49-07572cc2-0cc47a314e9a-e4dc8b657d340686=https://syzkaller.appspot.com/x/log.txt?x=1206ed4be0 >>> kernel config: >>> https://protect2.fireeye.com/url?k=43211072-1eeddbb6-43209b3d-0cc47a314e9a-3bd45a19932c37c8=https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692 >>> dashboard link: >>> https://protect2.fireeye.com/url?k=bf7a6153-e2b6aa97-bf7bea1c-0cc47a314e9a-c64073ee605efb7b=https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356 >>> compiler: gcc (GCC) 9.0.0 20181231 (experimental) >>> >>> Unfortunately, I don't have any reproducer for this crash yet. >>> >>> IMPORTANT: if you fix the bug, please add the following tag to the commit: >>> Reported-by: syzbot+e84d7ebd1361da13c...@syzkaller.appspotmail.com >>> >>> INFO: trying to register non-static key. >>> the code is fine but needs lockdep annotation. >>> turning off the locking correctness validator. >>> CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0 >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >>> Google 01/01/2011 >>> Call Trace: >>> >>> __dump_stack lib/dump_stack.c:77 [inline] >>> dump_stack+0x188/0x20d lib/dump_stack.c:118 >>> assign_lock_key kernel/locking/lockdep.c:880 [inline] >>> register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189 >>> __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836 >>> lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484 >>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] >>> _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159 >>> try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547 >> >> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in >> copy_process(). This should be impossible. Very odd. > > The stack mentions fbdev, which is a red flag at the moment. There are > a dozen of bad bugs in fbdev and around. Just few days ago Andy > pointed to another "impossible" crash "general protection fault in > do_syscall_64" which is related to dri: > https://protect2.fireeye.com/url?k=0cb8ad06-517466c2-0cb92649-0cc47a314e9a-a20c11191483c65b=https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9 > https://protect2.fireeye.com/url?k=614292e3-3c8e5927-614319ac-0cc47a314e9a-aeda6d72c01a7b0e=https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ > > There are probably more random manifestations of these bugs already, > and I guess we will be getting more. > > +fbdev maintainers Thank you for the report. fbdev is in the maintenance mode and no new features or drivers are being added so syzbot reports are not for a new bugs (regressions) and are not a priority (at least to me). I have only resources to review/merge pending fbdev patches from time to time so any help in fixing these syzbot reports is welcomed (there have been a few fbdev related syzbot reports recently). Also please note that fbdev is maintained through drm-misc tree so patches can also be handled by other drm-misc maintainers in case I'm not available / busy with other things. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics >>> wake_up_worker kernel/workqueue.c:836 [inline] >>> insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337 >>> __queue_work+0x50d/0x1280 kernel/workqueue.c:1488 >>> call_timer_fn+0x195/0x760 kernel/time/timer.c:1404 >>> expire_timers kernel/time/timer.c:1444 [inline] >>> __run_timers kernel/time/timer.c:1773 [inline] >>> __run_timers kernel/time/timer.c:1740 [inline] >>> run_timer_softirq+0x412/0x1600 kernel/time/timer.c:1786 >>> __do_softirq+0x26c/0x99d kernel/softirq.c:292 >>> invoke_softirq kernel/softirq.c:373 [inline] >>> irq_exit+0x192/0x1d0 kernel/softirq.c:413 >>> exiting_irq arch/x86/include/asm/apic.h:546 [inline] >>> smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1146 >>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829 >>> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] video: Use scnprintf() for avoiding potential buffer overflow
On Tue, Mar 31, 2020 at 01:59:32PM +0200, Bartlomiej Zolnierkiewicz wrote: > > On 3/27/20 9:25 AM, Takashi Iwai wrote: > > On Fri, 20 Mar 2020 14:42:51 +0100, > > Bartlomiej Zolnierkiewicz wrote: > >> > >> > >> On 3/19/20 4:49 PM, Takashi Iwai wrote: > >>> On Wed, 11 Mar 2020 10:32:27 +0100, > >>> Takashi Iwai wrote: > > Hi, > > here is a series of trivial patches just to convert suspicious > snprintf() usages with the more safer one, scnprintf(). > > > Takashi > > === > > Takashi Iwai (3): > video: omapfb: Use scnprintf() for avoiding potential buffer overflow > video: omap2: Use scnprintf() for avoiding potential buffer overflow > video: uvesafb: Use scnprintf() for avoiding potential buffer overflow > > drivers/video/fbdev/omap/omapfb_main.c | 14 +++--- > drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c | 8 > drivers/video/fbdev/uvesafb.c | 2 +- > 3 files changed, 12 insertions(+), 12 deletions(-) > >>> > >>> Just a gentle ping about those patches. > >>> Let me know if any further changes needed. > >> Patches #1-3 queued for v5.7, thanks! > > > > I still don't see those in linux-next as of today. > > Could you check it? > They are in drm-misc/drm-misc-next branch but for some reason linux-next > uses drm-misc/for-linux-next one. > > Daniel, is this correct? > > [ I couldn't find anything about for-linux-next branch at > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html ] Yup, once drm is frozen for features we push drm-misc-next-fixes to for-linux-next, but the main branch drm-misc-next is still open (but will be delayed to the subsequent kernel merge window). That's why the "where do I apply a bugfix" diagram in our docs isn't that simply (if you pick the wrong branch it's going to be one kernel release too late). This freeze generally happans around -rc6/7 or so, a bit ahead of when the merge windo opens. iow the above stuff is queued for 5.8, and should show up in linux-next right after -rc1 is out. -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 0/3] video: Use scnprintf() for avoiding potential buffer overflow
On 3/27/20 9:25 AM, Takashi Iwai wrote: > On Fri, 20 Mar 2020 14:42:51 +0100, > Bartlomiej Zolnierkiewicz wrote: >> >> >> On 3/19/20 4:49 PM, Takashi Iwai wrote: >>> On Wed, 11 Mar 2020 10:32:27 +0100, >>> Takashi Iwai wrote: Hi, here is a series of trivial patches just to convert suspicious snprintf() usages with the more safer one, scnprintf(). Takashi === Takashi Iwai (3): video: omapfb: Use scnprintf() for avoiding potential buffer overflow video: omap2: Use scnprintf() for avoiding potential buffer overflow video: uvesafb: Use scnprintf() for avoiding potential buffer overflow drivers/video/fbdev/omap/omapfb_main.c | 14 +++--- drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c | 8 drivers/video/fbdev/uvesafb.c | 2 +- 3 files changed, 12 insertions(+), 12 deletions(-) >>> >>> Just a gentle ping about those patches. >>> Let me know if any further changes needed. >> Patches #1-3 queued for v5.7, thanks! > > I still don't see those in linux-next as of today. > Could you check it? They are in drm-misc/drm-misc-next branch but for some reason linux-next uses drm-misc/for-linux-next one. Daniel, is this correct? [ I couldn't find anything about for-linux-next branch at https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html ] Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] powerpc: Remove Xilinx PPC405/PPC440 support
On 3/30/20 3:32 PM, Michal Simek wrote:
> The latest Xilinx design tools called ISE and EDK has been released in
> October 2013. New tool doesn't support any PPC405/PPC440 new designs.
> These platforms are no longer supported and tested.
>
> PowerPC 405/440 port is orphan from 2013 by
> commit cdeb89943bfc ("MAINTAINERS: Fix incorrect status tag") and
> commit 19624236cce1 ("MAINTAINERS: Update Grant's email address and
> maintainership")
> that's why it is time to remove the support fot these platforms.
>
> Signed-off-by: Michal Simek
> Acked-by: Arnd Bergmann
Acked-by: Bartlomiej Zolnierkiewicz # for fbdev
> ---
>
> Changes in v2:
> - Based on my chat with Arnd I removed arch/powerpc/xmon/ changes done in
> v1 to keep them the same as before. (kbuild reported some issues with it
> too)
>
> Documentation/devicetree/bindings/xilinx.txt | 143 --
> Documentation/powerpc/bootwrapper.rst| 28 +-
> MAINTAINERS | 6 -
> arch/powerpc/Kconfig.debug | 2 +-
> arch/powerpc/boot/Makefile | 7 +-
> arch/powerpc/boot/dts/Makefile | 1 -
> arch/powerpc/boot/dts/virtex440-ml507.dts| 406
> arch/powerpc/boot/dts/virtex440-ml510.dts| 466 ---
> arch/powerpc/boot/ops.h | 1 -
> arch/powerpc/boot/serial.c | 5 -
> arch/powerpc/boot/uartlite.c | 79
> arch/powerpc/boot/virtex.c | 97
> arch/powerpc/boot/virtex405-head.S | 31 --
> arch/powerpc/boot/wrapper| 8 -
> arch/powerpc/configs/40x/virtex_defconfig| 75 ---
> arch/powerpc/configs/44x/virtex5_defconfig | 74 ---
> arch/powerpc/configs/ppc40x_defconfig| 8 -
> arch/powerpc/configs/ppc44x_defconfig| 8 -
> arch/powerpc/include/asm/xilinx_intc.h | 16 -
> arch/powerpc/include/asm/xilinx_pci.h| 21 -
> arch/powerpc/kernel/cputable.c | 39 --
> arch/powerpc/platforms/40x/Kconfig | 31 --
> arch/powerpc/platforms/40x/Makefile | 1 -
> arch/powerpc/platforms/40x/virtex.c | 54 ---
> arch/powerpc/platforms/44x/Kconfig | 37 --
> arch/powerpc/platforms/44x/Makefile | 2 -
> arch/powerpc/platforms/44x/virtex.c | 60 ---
> arch/powerpc/platforms/44x/virtex_ml510.c| 30 --
> arch/powerpc/platforms/Kconfig | 4 -
> arch/powerpc/sysdev/Makefile | 2 -
> arch/powerpc/sysdev/xilinx_intc.c| 88
> arch/powerpc/sysdev/xilinx_pci.c | 132 --
> drivers/char/Kconfig | 2 +-
> drivers/video/fbdev/Kconfig | 2 +-
> 34 files changed, 7 insertions(+), 1959 deletions(-)
> delete mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts
> delete mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
> delete mode 100644 arch/powerpc/boot/uartlite.c
> delete mode 100644 arch/powerpc/boot/virtex.c
> delete mode 100644 arch/powerpc/boot/virtex405-head.S
> delete mode 100644 arch/powerpc/configs/40x/virtex_defconfig
> delete mode 100644 arch/powerpc/configs/44x/virtex5_defconfig
> delete mode 100644 arch/powerpc/include/asm/xilinx_intc.h
> delete mode 100644 arch/powerpc/include/asm/xilinx_pci.h
> delete mode 100644 arch/powerpc/platforms/40x/virtex.c
> delete mode 100644 arch/powerpc/platforms/44x/virtex.c
> delete mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
> delete mode 100644 arch/powerpc/sysdev/xilinx_intc.c
> delete mode 100644 arch/powerpc/sysdev/xilinx_pci.c
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/panel: add panel driver for Leadtek LTK050H3146W
From: Heiko Stuebner
The LTK500HD1829W is 5.0" 720x1280 DSI display.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-leadtek-ltk050h3146w.c| 589 ++
3 files changed, 601 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a1723c1b5fbf..d56258b9fcaf 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -137,6 +137,17 @@ config DRM_PANEL_KINGDISPLAY_KD097D04
24 bit RGB per pixel. It provides a MIPI DSI interface to
the host and has a built-in LED backlight.
+config DRM_PANEL_LEADTEK_LTK050H3146W
+ tristate "Leadtek LTK050H3146W panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Leadtek LTK050H3146W
+ TFT-LCD modules. The panel has a 720x1280 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
config DRM_PANEL_LEADTEK_LTK500HD1829
tristate "Leadtek LTK500HD1829 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 96a883cd6630..2335a1e32ae0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) +=
panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
+obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
new file mode 100644
index ..d7afcdf5538a
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
@@ -0,0 +1,589 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct ltk050h3146w_cmd {
+ char cmd;
+ char data;
+};
+
+static const struct ltk050h3146w_cmd page1_cmds[] = {
+ { 0x22, 0x0A }, /* BGR SS GS */
+ { 0x31, 0x00 }, /* column inversion */
+ { 0x53, 0x8A }, /* VCOM1 */
+ { 0x55, 0xA2 }, /* VCOM2 */
+ { 0x50, 0x81 }, /* VREG1OUT=5V */
+ { 0x51, 0x85 }, /* VREG2OUT=-5V */
+ { 0x62, 0x0D }, /* EQT Time setting */
+/*
+ * For whatever reason the vendor init selected page 1 here _again_
+ * Is this supposed to be page 2?
+ */
+ { 0xA0, 0x00 },
+ { 0xA1, 0x1A },
+ { 0xA2, 0x28 },
+ { 0xA3, 0x13 },
+ { 0xA4, 0x16 },
+ { 0xA5, 0x29 },
+ { 0xA6, 0x1D },
+ { 0xA7, 0x1E },
+ { 0xA8, 0x84 },
+ { 0xA9, 0x1C },
+ { 0xAA, 0x28 },
+ { 0xAB, 0x75 },
+ { 0xAC, 0x1A },
+ { 0xAD, 0x19 },
+ { 0xAE, 0x4D },
+ { 0xAF, 0x22 },
+ { 0xB0, 0x28 },
+ { 0xB1, 0x54 },
+ { 0xB2, 0x66 },
+ { 0xB3, 0x39 },
+ { 0xC0, 0x00 },
+ { 0xC1, 0x1A },
+ { 0xC2, 0x28 },
+ { 0xC3, 0x13 },
+ { 0xC4, 0x16 },
+ { 0xC5, 0x29 },
+ { 0xC6, 0x1D },
+ { 0xC7, 0x1E },
+ { 0xC8, 0x84 },
+ { 0xC9, 0x1C },
+ { 0xCA, 0x28 },
+ { 0xCB, 0x75 },
+ { 0xCC, 0x1A },
+ { 0xCD, 0x19 },
+ { 0xCE, 0x4D },
+ { 0xCF, 0x22 },
+ { 0xD0, 0x28 },
+ { 0xD1, 0x54 },
+ { 0xD2, 0x66 },
+ { 0xD3, 0x39 },
+};
+
+static const struct ltk050h3146w_cmd page3_cmds[] = {
+ { 0x01, 0x00 },
+ { 0x02, 0x00 },
+ { 0x03, 0x73 },
+ { 0x04, 0x00 },
+ { 0x05, 0x00 },
+ { 0x06, 0x0a },
+ { 0x07, 0x00 },
+ { 0x08, 0x00 },
+ { 0x09, 0x01 },
+ { 0x0a, 0x00 },
+ { 0x0b, 0x00 },
+ { 0x0c, 0x01 },
+ { 0x0d, 0x00 },
+ { 0x0e, 0x00 },
+ { 0x0f, 0x1d },
+ { 0x10, 0x1d },
+ { 0x11, 0x00 },
+ { 0x12, 0x00 },
+ { 0x13, 0x00 },
+ { 0x14, 0x00 },
+ { 0x15, 0x00 },
+ { 0x16, 0x00 },
+ { 0x17, 0x00 },
+ { 0x18, 0x00 },
+ { 0x19, 0x00 },
+ { 0x1a, 0x00 },
+ { 0x1b, 0x00 },
+ { 0x1c, 0x00 },
+ { 0x1d, 0x00 },
+ { 0x1e, 0x40 },
+ { 0x1f, 0x80 },
+ { 0x20, 0x06 },
+ { 0x21, 0x02 },
+ { 0x22, 0x00 },
+ {
[PATCH 1/2] dt-bindings: display: panel: Add binding document for Leadtek LTK050H3146W
From: Heiko Stuebner
The LTK050H3146W is a 5.0" 720x1280 DSI display.
Signed-off-by: Heiko Stuebner
---
.../display/panel/leadtek,ltk050h3146w.yaml | 49 +++
1 file changed, 49 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
new file mode 100644
index ..91a0212b63b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/leadtek,ltk050h3146w.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Leadtek LTK050H3146W 5.0in 720x1280 DSI panel
+
+maintainers:
+ - Heiko Stuebner
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: leadtek,ltk050h3146w
+ reg: true
+ backlight: true
+ reset-gpios: true
+ iovcc-supply:
+ description: regulator that supplies the iovcc voltage
+ vci-supply:
+ description: regulator that supplies the vci voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - iovcc-supply
+ - vci-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "leadtek,ltk050h3146w";
+reg = <0>;
+backlight = <>;
+iovcc-supply = <_1v8>;
+vci-supply = <_lcd>;
+};
+};
+
+...
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/amd/display: code cleanup on dc_link from is_same_edid to get_ddc_line
Removes codestyle issues on the file dc_link between is_same_edid and
get_ddc_line as suggested by checkpatch.pl.
Types covered:
CHECK: Blank lines aren't necessary after an open brace '{'
CHECK: Blank lines aren't necessary before a close brace '}'
WARNING: braces {} are not necessary for single statement blocks
CHECK: Comparison to NULL could be written
CHECK: Lines should not end with a '('
CHECK: Alignment should match open parenthesis
CHECK: Using comparison to false is error prone
CHECK: Using comparison to true is error prone
WARNING: Avoid multiple line dereference - prefer
'link->dpcd_caps.sink_count.bits.SINK_COUNT'
CHECK: Unnecessary parentheses around
WARNING: Missing a blank line after declarations
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 130 +-
1 file changed, 62 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 0b303d17e543..b5b202bd9d7c 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -677,12 +677,12 @@ static bool is_same_edid(struct dc_edid *old_edid, struct
dc_edid *new_edid)
if (new_edid->length == 0)
return false;
- return (memcmp(old_edid->raw_edid, new_edid->raw_edid,
new_edid->length) == 0);
+ return (memcmp(old_edid->raw_edid,
+ new_edid->raw_edid, new_edid->length) == 0);
}
static bool wait_for_alt_mode(struct dc_link *link)
{
-
/**
* something is terribly wrong if time out is > 200ms. (5Hz)
* 500 microseconds * 400 tries us 200 ms
@@ -697,7 +697,7 @@ static bool wait_for_alt_mode(struct dc_link *link)
DC_LOGGER_INIT(link->ctx->logger);
- if (link->link_enc->funcs->is_in_alt_mode == NULL)
+ if (!link->link_enc->funcs->is_in_alt_mode)
return true;
is_in_alt_mode = link->link_enc->funcs->is_in_alt_mode(link->link_enc);
@@ -712,21 +712,21 @@ static bool wait_for_alt_mode(struct dc_link *link)
udelay(sleep_time_in_microseconds);
/* ask the link if alt mode is enabled, if so return ok */
if (link->link_enc->funcs->is_in_alt_mode(link->link_enc)) {
-
finish_timestamp = dm_get_timestamp(link->ctx);
- time_taken_in_ns = dm_get_elapse_time_in_ns(
- link->ctx, finish_timestamp, enter_timestamp);
+ time_taken_in_ns =
+ dm_get_elapse_time_in_ns(link->ctx,
+finish_timestamp,
+enter_timestamp);
DC_LOG_WARNING("Alt mode entered finished after %llu
ms\n",
div_u64(time_taken_in_ns, 100));
return true;
}
-
}
finish_timestamp = dm_get_timestamp(link->ctx);
time_taken_in_ns = dm_get_elapse_time_in_ns(link->ctx, finish_timestamp,
enter_timestamp);
DC_LOG_WARNING("Alt mode has timed out after %llu ms\n",
- div_u64(time_taken_in_ns, 100));
+ div_u64(time_taken_in_ns, 100));
return false;
}
@@ -762,30 +762,30 @@ static bool dc_link_detect_helper(struct dc_link *link,
return false;
if ((link->connector_signal == SIGNAL_TYPE_LVDS ||
- link->connector_signal == SIGNAL_TYPE_EDP) &&
- link->local_sink) {
-
+link->connector_signal == SIGNAL_TYPE_EDP) &&
+ link->local_sink) {
// need to re-write OUI and brightness in resume case
if (link->connector_signal == SIGNAL_TYPE_EDP) {
dpcd_set_source_specific_data(link);
- dc_link_set_default_brightness_aux(link); //TODO: use
cached
+ dc_link_set_default_brightness_aux(link);
+ //TODO: use cached
}
return true;
}
- if (false == dc_link_detect_sink(link, _connection_type)) {
+ if (!dc_link_detect_sink(link, _connection_type)) {
BREAK_TO_DEBUGGER();
return false;
}
prev_sink = link->local_sink;
- if (prev_sink != NULL) {
+ if (prev_sink) {
dc_sink_retain(prev_sink);
memcpy(_dpcd_caps, >dpcd_caps, sizeof(struct
dpcd_caps));
}
- link_disconnect_sink(link);
+ link_disconnect_sink(link);
if (new_connection_type != dc_connection_none) {
link->type = new_connection_type;
link->link_state_valid = false;
@@ -832,35 +832,31 @@ static bool dc_link_detect_helper(struct
[PATCH 4/4] drm/amd/display: code cleanup of dc_link file on func dc_link_construct
Removes codestyle issues in dc_link file, on dc_link_construct and
translate_encoder_to_transmitter as suggested by checkpatch.pl.
Types covered:
CHECK: Lines should not end with a '('
WARNING: Missing a blank line after declarations
CHECK: Alignment should match open parenthesis
CHECK: Comparison to NULL could be written
CHECK: Logical continuations should be on the previous line
CHECK: Blank lines aren't necessary after an open brace '{'
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 94 ++-
1 file changed, 50 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index b5b202bd9d7c..a93997ff0419 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -1098,13 +1098,13 @@ bool dc_link_get_hpd_state(struct dc_link *dc_link)
return state;
}
-static enum hpd_source_id get_hpd_line(
- struct dc_link *link)
+static enum hpd_source_id get_hpd_line(struct dc_link *link)
{
struct gpio *hpd;
enum hpd_source_id hpd_id = HPD_SOURCEID_UNKNOWN;
- hpd = get_hpd_gpio(link->ctx->dc_bios, link->link_id,
link->ctx->gpio_service);
+ hpd = get_hpd_gpio(link->ctx->dc_bios, link->link_id,
+ link->ctx->gpio_service);
if (hpd) {
switch (dal_irq_get_source(hpd)) {
@@ -1179,8 +1179,7 @@ static enum channel_id get_ddc_line(struct dc_link *link)
return channel;
}
-static enum transmitter translate_encoder_to_transmitter(
- struct graphics_object_id encoder)
+static enum transmitter translate_encoder_to_transmitter(struct
graphics_object_id encoder)
{
switch (encoder.id) {
case ENCODER_ID_INTERNAL_UNIPHY:
@@ -1244,9 +1243,8 @@ static enum transmitter translate_encoder_to_transmitter(
}
}
-static bool dc_link_construct(
- struct dc_link *link,
- const struct link_init_data *init_params)
+static bool dc_link_construct(struct dc_link *link,
+ const struct link_init_data *init_params)
{
uint8_t i;
struct ddc_service_init_data ddc_service_init_data = { { 0 } };
@@ -1255,6 +1253,7 @@ static bool dc_link_construct(
struct integrated_info info = {{{ 0 }}};
struct dc_bios *bios = init_params->dc->ctx->dc_bios;
const struct dc_vbios_funcs *bp_funcs = bios->funcs;
+
DC_LOGGER_INIT(dc_ctx->logger);
link->irq_source_hpd = DC_IRQ_SOURCE_INVALID;
@@ -1266,23 +1265,27 @@ static bool dc_link_construct(
link->ctx = dc_ctx;
link->link_index = init_params->link_index;
- memset(>preferred_training_settings, 0, sizeof(struct
dc_link_training_overrides));
- memset(>preferred_link_setting, 0, sizeof(struct
dc_link_settings));
+ memset(>preferred_training_settings, 0,
+ sizeof(struct dc_link_training_overrides));
+ memset(>preferred_link_setting, 0,
+ sizeof(struct dc_link_settings));
- link->link_id = bios->funcs->get_connector_id(bios,
init_params->connector_index);
+ link->link_id =
+ bios->funcs->get_connector_id(bios,
init_params->connector_index);
if (link->link_id.type != OBJECT_TYPE_CONNECTOR) {
dm_output_to_console("%s: Invalid Connector ObjectID from
Adapter Service for connector index:%d! type %d expected %d\n",
-__func__, init_params->connector_index,
-link->link_id.type, OBJECT_TYPE_CONNECTOR);
+__func__, init_params->connector_index,
+link->link_id.type, OBJECT_TYPE_CONNECTOR);
goto create_fail;
}
if (link->dc->res_pool->funcs->link_init)
link->dc->res_pool->funcs->link_init(link);
- link->hpd_gpio = get_hpd_gpio(link->ctx->dc_bios, link->link_id,
link->ctx->gpio_service);
- if (link->hpd_gpio != NULL) {
+ link->hpd_gpio = get_hpd_gpio(link->ctx->dc_bios, link->link_id,
+ link->ctx->gpio_service);
+ if (link->hpd_gpio) {
dal_gpio_open(link->hpd_gpio, GPIO_MODE_INTERRUPT);
dal_gpio_unlock_pin(link->hpd_gpio);
link->irq_source_hpd = dal_irq_get_source(link->hpd_gpio);
@@ -1302,9 +1305,9 @@ static bool dc_link_construct(
link->connector_signal = SIGNAL_TYPE_DVI_DUAL_LINK;
break;
case CONNECTOR_ID_DISPLAY_PORT:
- link->connector_signal =SIGNAL_TYPE_DISPLAY_PORT;
+ link->connector_signal = SIGNAL_TYPE_DISPLAY_PORT;
- if (link->hpd_gpio != NULL)
+ if (link->hpd_gpio)
link->irq_source_hpd_rx =
dal_irq_get_rx_source(link->hpd_gpio);
@@
[PATCH 2/4] drm/amd/display: codestyle cleanup on dc_link file until detect_dp func
Removes codestyle issues on the file dc_link until detect_dp func as
suggested by checkpatch.pl.
Types covered:
CHECK: Please don't use multiple blank lines
CHECK: Comparison to NULL could be written
ERROR: space required before the open parenthesis '('
CHECK: Alignment should match open parenthesis
CHECK: Lines should not end with a '('
WARNING: please, no space before tabs
WARNING: Comparisons should place the constant on the right side of the test
WARNING: braces {} are not necessary for single statement blocks
CHECK: Please don't use multiple blank lines
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 109 --
1 file changed, 49 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index f580b533db5f..0b303d17e543 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -49,7 +49,6 @@
#define DC_LOGGER_INIT(logger)
-
#define LINK_INFO(...) \
DC_LOG_HW_HOTPLUG( \
__VA_ARGS__)
@@ -79,7 +78,7 @@ static void dc_link_destruct(struct dc_link *link)
{
int i;
- if (link->hpd_gpio != NULL) {
+ if (link->hpd_gpio) {
dal_gpio_destroy_irq(>hpd_gpio);
link->hpd_gpio = NULL;
}
@@ -87,7 +86,7 @@ static void dc_link_destruct(struct dc_link *link)
if (link->ddc)
dal_ddc_service_destroy(>ddc);
- if(link->link_enc)
+ if (link->link_enc)
link->link_enc->funcs->destroy(>link_enc);
if (link->local_sink)
@@ -98,8 +97,8 @@ static void dc_link_destruct(struct dc_link *link)
}
struct gpio *get_hpd_gpio(struct dc_bios *dcb,
- struct graphics_object_id link_id,
- struct gpio_service *gpio_service)
+ struct graphics_object_id link_id,
+ struct gpio_service *gpio_service)
{
enum bp_result bp_result;
struct graphics_object_hpd_info hpd_info;
@@ -116,10 +115,9 @@ struct gpio *get_hpd_gpio(struct dc_bios *dcb,
return NULL;
}
- return dal_gpio_service_create_irq(
- gpio_service,
- pin_info.offset,
- pin_info.mask);
+ return dal_gpio_service_create_irq(gpio_service,
+ pin_info.offset,
+ pin_info.mask);
}
/*
@@ -134,13 +132,10 @@ struct gpio *get_hpd_gpio(struct dc_bios *dcb,
* @return
* true on success, false otherwise
*/
-static bool program_hpd_filter(
- const struct dc_link *link)
+static bool program_hpd_filter(const struct dc_link *link)
{
bool result = false;
-
struct gpio *hpd;
-
int delay_on_connect_in_ms = 0;
int delay_on_disconnect_in_ms = 0;
@@ -159,10 +154,10 @@ static bool program_hpd_filter(
case SIGNAL_TYPE_DISPLAY_PORT_MST:
/* Program hpd filter to allow DP signal to settle */
/* 500: not able to detect MST <-> SST switch as HPD is low for
-* only 100ms on DELL U2413
-* 0: some passive dongle still show aux mode instead of i2c
-* 20-50:not enough to hide bouncing HPD with passive dongle.
-* also see intermittent i2c read issues.
+* only 100ms on DELL U2413
+* 0: some passive dongle still show aux mode instead of i2c
+* 20-50: not enough to hide bouncing HPD with passive dongle.
+* also see intermittent i2c read issues.
*/
delay_on_connect_in_ms = 80;
delay_on_disconnect_in_ms = 0;
@@ -175,7 +170,8 @@ static bool program_hpd_filter(
}
/* Obtain HPD handle */
- hpd = get_hpd_gpio(link->ctx->dc_bios, link->link_id,
link->ctx->gpio_service);
+ hpd = get_hpd_gpio(link->ctx->dc_bios, link->link_id,
+ link->ctx->gpio_service);
if (!hpd)
return result;
@@ -226,8 +222,9 @@ bool dc_link_detect_sink(struct dc_link *link, enum
dc_connection_type *type)
}
/* todo: may need to lock gpio access */
- hpd_pin = get_hpd_gpio(link->ctx->dc_bios, link->link_id,
link->ctx->gpio_service);
- if (hpd_pin == NULL)
+ hpd_pin = get_hpd_gpio(link->ctx->dc_bios, link->link_id,
+ link->ctx->gpio_service);
+ if (!hpd_pin)
goto hpd_gpio_failure;
dal_gpio_open(hpd_pin, GPIO_MODE_INTERRUPT);
@@ -248,8 +245,7 @@ bool dc_link_detect_sink(struct dc_link *link, enum
dc_connection_type *type)
return false;
}
-static enum ddc_transaction_type get_ddc_transaction_type(
- enum signal_type sink_signal)
+static enum ddc_transaction_type get_ddc_transaction_type(enum signal_type
[PATCH 1/4] drm/amd/display: cleanup codestyle type BLOCK_COMMENT_STYLE on dc_link
Solve comments alignment problems on dc_link file
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 25 +++
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 67cfff1586e9..f580b533db5f 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -64,11 +64,11 @@
enum {
PEAK_FACTOR_X1000 = 1006,
/*
- * Some receivers fail to train on first try and are good
- * on subsequent tries. 2 retries should be plenty. If we
- * don't have a successful training then we don't expect to
- * ever get one.
- */
+* Some receivers fail to train on first try and are good
+* on subsequent tries. 2 retries should be plenty. If we
+* don't have a successful training then we don't expect to
+* ever get one.
+*/
LINK_TRAINING_MAX_VERIFY_RETRY = 2
};
@@ -270,7 +270,8 @@ static enum ddc_transaction_type get_ddc_transaction_type(
case SIGNAL_TYPE_DISPLAY_PORT_MST:
/* MST does not use I2COverAux, but there is the
* SPECIAL use case for "immediate dwnstrm device
-* access" (EPR#370830). */
+* access" (EPR#370830).
+*/
transaction_type = DDC_TRANSACTION_TYPE_I2C_OVER_AUX;
break;
@@ -369,7 +370,8 @@ bool dc_link_is_dp_sink_present(struct dc_link *link)
/* Open GPIO and set it to I2C mode */
/* Note: this GpioMode_Input will be converted
* to GpioConfigType_I2cAuxDualMode in GPIO component,
-* which indicates we need additional delay */
+* which indicates we need additional delay
+*/
if (GPIO_RESULT_OK != dal_ddc_open(
ddc, GPIO_MODE_INPUT, GPIO_DDC_CONFIG_TYPE_MODE_I2C)) {
@@ -414,14 +416,16 @@ static enum signal_type link_detect_sink(
link->link_enc->id, link->link_id);
/* Internal digital encoder will detect only dongles
-* that require digital signal */
+* that require digital signal
+*/
/* Detection mechanism is different
* for different native connectors.
* LVDS connector supports only LVDS signal;
* PCIE is a bus slot, the actual connector needs to be detected first;
* eDP connector supports only eDP signal;
-* HDMI should check straps for audio */
+* HDMI should check straps for audio
+*/
/* PCIE detects the actual connector on add-on board */
@@ -432,7 +436,8 @@ static enum signal_type link_detect_sink(
switch (link->link_id.id) {
case CONNECTOR_ID_HDMI_TYPE_A: {
/* check audio support:
-* if native HDMI is not supported, switch to DVI */
+* if native HDMI is not supported, switch to DVI
+*/
struct audio_support *aud_support =
>dc->res_pool->audio_support;
if (!aud_support->hdmi_audio_native)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/amd/display: more code cleanup in the dc_link file
These patches address many code style issues on dc_link for readability and cleaning up warnings. Change suggested by checkpatch.pl. Some issues remain and need some minor code refactoring for proper handling. Melissa Wen (4): drm/amd/display: cleanup codestyle type BLOCK_COMMENT_STYLE on dc_link drm/amd/display: codestyle cleanup on dc_link file until detect_dp func drm/amd/display: code cleanup on dc_link from is_same_edid to get_ddc_line drm/amd/display: code cleanup of dc_link file on func dc_link_construct drivers/gpu/drm/amd/display/dc/core/dc_link.c | 358 +- 1 file changed, 176 insertions(+), 182 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mm: revert "Break long searches in fragmented address spaces"
On Tue, Mar 31, 2020 at 11:20 AM Chris Wilson wrote: > Quoting Daniel Vetter (2020-03-31 10:16:18) > > On Tue, Mar 31, 2020 at 10:59:45AM +0200, Christian König wrote: > > > A not so gentle ping, since this pretty much broke all TTM based drivers. > > > > > > Could we revert this for now? > > > > Always ack for revert. > > > > Acked-by: Daniel Vetter > > So you didn't check the earlier patch either? I did, but wasn't super sold on the idea of more flags to smack an r-b onto it, so figured I'll throw the default ack-for-revert on this meanwhile. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/vram-helpers: Set plane fence for display update
Calling the VRAM helper's prepare_fb() helper now sets the plane's fence object. This will be useful for PRIME support. VRAM helpers don't support buffer sharing ATM, so for now there are no drivers requiring this change. v2: * removed a TODO comment about buffer synchronization Signed-off-by: Thomas Zimmermann Reviewed-by: Daniel Vetter --- drivers/gpu/drm/drm_gem_vram_helper.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c index b3201a70cbfcb..cdf710be39da4 100644 --- a/drivers/gpu/drm/drm_gem_vram_helper.c +++ b/drivers/gpu/drm/drm_gem_vram_helper.c @@ -5,6 +5,7 @@ #include #include #include +#include #include #include #include @@ -670,9 +671,9 @@ EXPORT_SYMBOL(drm_gem_vram_driver_dumb_mmap_offset); * @plane: a DRM plane * @new_state: the plane's new state * - * During plane updates, this function pins the GEM VRAM - * objects of the plane's new framebuffer to VRAM. Call - * drm_gem_vram_plane_helper_cleanup_fb() to unpin them. + * During plane updates, this function sets the plane's fence and + * pins the GEM VRAM objects of the plane's new framebuffer to VRAM. + * Call drm_gem_vram_plane_helper_cleanup_fb() to unpin them. * * Returns: * 0 on success, or @@ -698,6 +699,10 @@ drm_gem_vram_plane_helper_prepare_fb(struct drm_plane *plane, goto err_drm_gem_vram_unpin; } + ret = drm_gem_fb_prepare_fb(plane, new_state); + if (ret) + goto err_drm_gem_vram_unpin; + return 0; err_drm_gem_vram_unpin: -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vram-helpers: Set plane fence for display update
Hi
Am 31.03.20 um 10:50 schrieb Daniel Vetter:
> On Tue, Mar 31, 2020 at 10:11:30AM +0200, Thomas Zimmermann wrote:
>> Calling the VRAM helper's prepare_fb() helper now sets the plane's
>> fence object. The helper still has to synchronize with other users
>> of the GEM object. Leave a related TODO comment in the code.
>>
>> This will be useful for PRIME support. VRAM helpers don't support
>> buffer sharing ATM, so there are no drivers requiring this change.
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>> drivers/gpu/drm/drm_gem_vram_helper.c | 18 +++---
>> 1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>> b/drivers/gpu/drm/drm_gem_vram_helper.c
>> index b3201a70cbfcb..d4e4f80d3a6c1 100644
>> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
>> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>> @@ -5,6 +5,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -670,9 +671,9 @@ EXPORT_SYMBOL(drm_gem_vram_driver_dumb_mmap_offset);
>> * @plane: a DRM plane
>> * @new_state: the plane's new state
>> *
>> - * During plane updates, this function pins the GEM VRAM
>> - * objects of the plane's new framebuffer to VRAM. Call
>> - * drm_gem_vram_plane_helper_cleanup_fb() to unpin them.
>> + * During plane updates, this function sets the plane's fence and
>> + * pins the GEM VRAM objects of the plane's new framebuffer to VRAM.
>> + * Call drm_gem_vram_plane_helper_cleanup_fb() to unpin them.
>> *
>> * Returns:
>> * 0 on success, or
>> @@ -689,6 +690,13 @@ drm_gem_vram_plane_helper_prepare_fb(struct drm_plane
>> *plane,
>> if (!new_state->fb)
>> return 0;
>>
>> +/*
>> + * TODO: Synchronize with other users of the buffer. Buffers
>> + * cannot be pinned to VRAM while they are in use by other
>> + * drivers for DMA. We should probably wait for each GEM
>> + * object's fence before attempting to pin the buffer.
>> + * There are currently no users of this functionality.
>> + */
>
> Not sure this is warranted, we have lots of drivers with these kind of
> restrictions ... It's a big can of worms, I'd just leave this all out.
Well, OK. Adding PRIME support would require a rework of these helpers
anyway.
Best regards
Thomas
>
>> for (i = 0; i < ARRAY_SIZE(new_state->fb->obj); ++i) {
>> if (!new_state->fb->obj[i])
>> continue;
>> @@ -698,6 +706,10 @@ drm_gem_vram_plane_helper_prepare_fb(struct drm_plane
>> *plane,
>> goto err_drm_gem_vram_unpin;
>> }
>>
>> +ret = drm_gem_fb_prepare_fb(plane, new_state);
>> +if (ret)
>> +goto err_drm_gem_vram_unpin;
>
> Reviewed-by: Daniel Vetter
>
>> +
>> return 0;
>>
>> err_drm_gem_vram_unpin:
>> --
>> 2.26.0
>>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mm: revert "Break long searches in fragmented address spaces"
Quoting Daniel Vetter (2020-03-31 10:16:18) > On Tue, Mar 31, 2020 at 10:59:45AM +0200, Christian König wrote: > > A not so gentle ping, since this pretty much broke all TTM based drivers. > > > > Could we revert this for now? > > Always ack for revert. > > Acked-by: Daniel Vetter So you didn't check the earlier patch either? -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mm: revert "Break long searches in fragmented address spaces"
Quoting Christian König (2020-03-31 09:59:45) > A not so gentle ping, since this pretty much broke all TTM based drivers. > > Could we revert this for now? Ping??? https://patchwork.freedesktop.org/patch/358535/?series=74984=1 -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 20/22] drm/vkms: Use simple encoder
Hi
Am 24.03.20 um 12:59 schrieb Rodrigo Siqueira:
> Hi Thomas,
>
> First of all, thanks for your patch!
>
> I applied all your series, compiled it, and when I tried
> `make INSTALL_MOD_PATH=/PATH/ modules_instal` I got the following
> message:
>
> depmod: ERROR: Cycle detected: drm_kms_helper -> drm -> drm_kms_helper
> depmod: ERROR: Found 2 modules in dependency cycles!
> make: *** [Makefile:1317: _modinst_post] Error 1
>
> I cleaned up my local files and tried again, but I got the same error;
> If I just use `drm-misc-next` everything is fine. Did I miss something?
I didn't change any module dependencies. Does it happen without this
patches?
Best regards
Thomas
>
> Thanks
>
> On 03/05, Thomas Zimmermann wrote:
>> The vkms driver uses an empty implementation for its encoder. Replace
>> the code with the generic simple encoder.
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>> drivers/gpu/drm/vkms/vkms_output.c | 8 ++--
>> 1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vkms/vkms_output.c
>> b/drivers/gpu/drm/vkms/vkms_output.c
>> index fb1941a6522c..85afb77e97f0 100644
>> --- a/drivers/gpu/drm/vkms/vkms_output.c
>> +++ b/drivers/gpu/drm/vkms/vkms_output.c
>> @@ -3,6 +3,7 @@
>> #include "vkms_drv.h"
>> #include
>> #include
>> +#include
>>
>> static void vkms_connector_destroy(struct drm_connector *connector)
>> {
>> @@ -17,10 +18,6 @@ static const struct drm_connector_funcs
>> vkms_connector_funcs = {
>> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>> };
>>
>> -static const struct drm_encoder_funcs vkms_encoder_funcs = {
>> -.destroy = drm_encoder_cleanup,
>> -};
>> -
>> static int vkms_conn_get_modes(struct drm_connector *connector)
>> {
>> int count;
>> @@ -70,8 +67,7 @@ int vkms_output_init(struct vkms_device *vkmsdev, int
>> index)
>>
>> drm_connector_helper_add(connector, _conn_helper_funcs);
>>
>> -ret = drm_encoder_init(dev, encoder, _encoder_funcs,
>> - DRM_MODE_ENCODER_VIRTUAL, NULL);
>> +ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_VIRTUAL);
>> if (ret) {
>> DRM_ERROR("Failed to init encoder\n");
>> goto err_encoder;
>> --
>> 2.25.1
>>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mm: revert "Break long searches in fragmented address spaces"
On Tue, Mar 31, 2020 at 10:59:45AM +0200, Christian König wrote:
> A not so gentle ping, since this pretty much broke all TTM based drivers.
>
> Could we revert this for now?
Always ack for revert.
Acked-by: Daniel Vetter
Needs to go to drm-misc-next-fixes, and then maybe also ask for a
backmerge since the patch landed pre-split. Also ping Maarten to do
another pull request (there's other stuff in there already anyway).
-Daniel
>
> Thanks,
> Christian.
>
> Am 30.03.20 um 14:34 schrieb Christian König:
> > This reverts commit 7be1b9b8e9d1e9ef0342d2e001f44eec4030aa4d.
> >
> > The drm_mm is supposed to work in atomic context, so calling schedule()
> > or in this case cond_resched() is illegal.
> >
> > Signed-off-by: Christian König
> > ---
> > drivers/gpu/drm/drm_mm.c | 8 +---
> > 1 file changed, 1 insertion(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> > index bc6e208949e8..8981abe8b7c9 100644
> > --- a/drivers/gpu/drm/drm_mm.c
> > +++ b/drivers/gpu/drm/drm_mm.c
> > @@ -45,7 +45,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > @@ -367,11 +366,6 @@ next_hole(struct drm_mm *mm,
> > struct drm_mm_node *node,
> > enum drm_mm_insert_mode mode)
> > {
> > - /* Searching is slow; check if we ran out of time/patience */
> > - cond_resched();
> > - if (fatal_signal_pending(current))
> > - return NULL;
> > -
> > switch (mode) {
> > default:
> > case DRM_MM_INSERT_BEST:
> > @@ -563,7 +557,7 @@ int drm_mm_insert_node_in_range(struct drm_mm * const
> > mm,
> > return 0;
> > }
> > - return signal_pending(current) ? -ERESTARTSYS : -ENOSPC;
> > + return -ENOSPC;
> > }
> > EXPORT_SYMBOL(drm_mm_insert_node_in_range);
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: add docs about the IN_FORMATS plane property
On Sun, Mar 29, 2020 at 02:45:08PM +, Simon Ser wrote: > This is a standard property attached to planes in drm_universal_plane_init > when drm_mode_config.allow_fb_modifiers is true. > > Signed-off-by: Simon Ser > Cc: Daniel Vetter > Cc: Daniel Stone > --- > drivers/gpu/drm/drm_blend.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > index 121481f6aa71..88eedee018d3 100644 > --- a/drivers/gpu/drm/drm_blend.c > +++ b/drivers/gpu/drm/drm_blend.c > @@ -183,6 +183,12 @@ > *plane does not expose the "alpha" property, then this is > *assumed to be 1.0 > * > + * IN_FORMATS: > + * Blob property which contains the set of buffer format and modifier > + * pairs supported by this plane. The blob is a drm_format_modifier_blob > + * struct. Without this property the plane doesn't support buffers with > + * modifiers. Userspace cannot change this property. Feels mildly misplaced among the blending properties, but we don't (yet) have a section to describe all the modifer/pixel format stuff and how it's all supposed to work together. So for now probably as good as it gets. Merged to drm-misc-next, thanks for your patch. -Daniel > + * > * Note that all the property extensions described here apply either to the > * plane or the CRTC (e.g. for the background color, which currently is not > * exposed and assumed to be black). > -- > 2.26.0 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mm: revert "Break long searches in fragmented address spaces"
A not so gentle ping, since this pretty much broke all TTM based drivers.
Could we revert this for now?
Thanks,
Christian.
Am 30.03.20 um 14:34 schrieb Christian König:
This reverts commit 7be1b9b8e9d1e9ef0342d2e001f44eec4030aa4d.
The drm_mm is supposed to work in atomic context, so calling schedule()
or in this case cond_resched() is illegal.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_mm.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index bc6e208949e8..8981abe8b7c9 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -45,7 +45,6 @@
#include
#include
#include
-#include
#include
#include
@@ -367,11 +366,6 @@ next_hole(struct drm_mm *mm,
struct drm_mm_node *node,
enum drm_mm_insert_mode mode)
{
- /* Searching is slow; check if we ran out of time/patience */
- cond_resched();
- if (fatal_signal_pending(current))
- return NULL;
-
switch (mode) {
default:
case DRM_MM_INSERT_BEST:
@@ -563,7 +557,7 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
return 0;
}
- return signal_pending(current) ? -ERESTARTSYS : -ENOSPC;
+ return -ENOSPC;
}
EXPORT_SYMBOL(drm_mm_insert_node_in_range);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vram-helpers: Set plane fence for display update
On Tue, Mar 31, 2020 at 10:11:30AM +0200, Thomas Zimmermann wrote:
> Calling the VRAM helper's prepare_fb() helper now sets the plane's
> fence object. The helper still has to synchronize with other users
> of the GEM object. Leave a related TODO comment in the code.
>
> This will be useful for PRIME support. VRAM helpers don't support
> buffer sharing ATM, so there are no drivers requiring this change.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index b3201a70cbfcb..d4e4f80d3a6c1 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -5,6 +5,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -670,9 +671,9 @@ EXPORT_SYMBOL(drm_gem_vram_driver_dumb_mmap_offset);
> * @plane: a DRM plane
> * @new_state: the plane's new state
> *
> - * During plane updates, this function pins the GEM VRAM
> - * objects of the plane's new framebuffer to VRAM. Call
> - * drm_gem_vram_plane_helper_cleanup_fb() to unpin them.
> + * During plane updates, this function sets the plane's fence and
> + * pins the GEM VRAM objects of the plane's new framebuffer to VRAM.
> + * Call drm_gem_vram_plane_helper_cleanup_fb() to unpin them.
> *
> * Returns:
> * 0 on success, or
> @@ -689,6 +690,13 @@ drm_gem_vram_plane_helper_prepare_fb(struct drm_plane
> *plane,
> if (!new_state->fb)
> return 0;
>
> + /*
> + * TODO: Synchronize with other users of the buffer. Buffers
> + * cannot be pinned to VRAM while they are in use by other
> + * drivers for DMA. We should probably wait for each GEM
> + * object's fence before attempting to pin the buffer.
> + * There are currently no users of this functionality.
> + */
Not sure this is warranted, we have lots of drivers with these kind of
restrictions ... It's a big can of worms, I'd just leave this all out.
> for (i = 0; i < ARRAY_SIZE(new_state->fb->obj); ++i) {
> if (!new_state->fb->obj[i])
> continue;
> @@ -698,6 +706,10 @@ drm_gem_vram_plane_helper_prepare_fb(struct drm_plane
> *plane,
> goto err_drm_gem_vram_unpin;
> }
>
> + ret = drm_gem_fb_prepare_fb(plane, new_state);
> + if (ret)
> + goto err_drm_gem_vram_unpin;
Reviewed-by: Daniel Vetter
> +
> return 0;
>
> err_drm_gem_vram_unpin:
> --
> 2.26.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vram-helpers: Merge code into a single file
On Tue, Mar 31, 2020 at 10:12:38AM +0200, Thomas Zimmermann wrote: > Most of the documentation was in an otherwise empty file, which was > probably just left from a previous clean-up effort. So move code and > documentation into a single file. > > Signed-off-by: Thomas Zimmermann Acked-by: Gerd Hoffmann cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vram-helpers: Set plane fence for display update
Hi, > + * TODO: Synchronize with other users of the buffer. Buffers > + * cannot be pinned to VRAM while they are in use by other > + * drivers for DMA. We should probably wait for each GEM > + * object's fence before attempting to pin the buffer. The other option is p2p (Documentation/driver-api/pci/p2pdma.rst). cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] dma-buf: add peer2peer flag
On Mon, Mar 30, 2020 at 03:55:31PM +0200, Christian König wrote:
> Add a peer2peer flag noting that the importer can deal with device
> resources which are not backed by pages.
>
> Signed-off-by: Christian König
On the series:
Acked-by: Daniel Vetter
> ---
> drivers/dma-buf/dma-buf.c | 2 ++
> include/linux/dma-buf.h | 10 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index ccc9eda1bc28..570c923023e6 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -690,6 +690,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
> device *dev,
>
> attach->dev = dev;
> attach->dmabuf = dmabuf;
> + if (importer_ops)
> + attach->peer2peer = importer_ops->allow_peer2peer;
> attach->importer_ops = importer_ops;
> attach->importer_priv = importer_priv;
>
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 1ade486fc2bb..82e0a4a64601 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -334,6 +334,14 @@ struct dma_buf {
> * Attachment operations implemented by the importer.
> */
> struct dma_buf_attach_ops {
> + /**
> + * @allow_peer2peer:
> + *
> + * If this is set to true the importer must be able to handle peer
> + * resources without struct pages.
> + */
> + bool allow_peer2peer;
> +
> /**
>* @move_notify
>*
> @@ -362,6 +370,7 @@ struct dma_buf_attach_ops {
> * @node: list of dma_buf_attachment, protected by dma_resv lock of the
> dmabuf.
> * @sgt: cached mapping.
> * @dir: direction of cached mapping.
> + * @peer2peer: true if the importer can handle peer resources without pages.
> * @priv: exporter specific attachment data.
> * @importer_ops: importer operations for this attachment, if provided
> * dma_buf_map/unmap_attachment() must be called with the dma_resv lock held.
> @@ -382,6 +391,7 @@ struct dma_buf_attachment {
> struct list_head node;
> struct sg_table *sgt;
> enum dma_data_direction dir;
> + bool peer2peer;
> const struct dma_buf_attach_ops *importer_ops;
> void *importer_priv;
> void *priv;
> --
> 2.17.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
[PATCH v4 0/4] Config mipi tx current and impedance
Changes since v3: - refine drive-strength-microamp as from 3000 to 6000. Changes since v2: - fix the title of commit message. - rename mipitx-current-drive to drive-strength-microamp Changes since v1: - fix coding style. - change mtk_mipi_tx_config_calibration_data() to void Jitao Shi (4): dt-bindings: display: mediatek: add property to control mipi tx drive current dt-bindings: display: mediatek: get mipitx calibration data from nvmem drm/mediatek: add the mipitx driving control drm/mediatek: config mipitx impedance with calibration data .../display/mediatek/mediatek,dsi.txt | 10 +++ drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 14 drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 1 + drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 64 +++ 4 files changed, 89 insertions(+) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/4] dt-bindings: display: mediatek: get mipitx calibration data from nvmem
Add properties to get get mipitx calibration data.
Reviewed-by: Rob Herring
Signed-off-by: Jitao Shi
---
.../devicetree/bindings/display/mediatek/mediatek,dsi.txt| 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
index d78b6d6d8fab..8e4729de8c85 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
@@ -36,6 +36,9 @@ Required properties:
Optional properties:
- drive-strength-microamp: adjust driving current, should be 3000 ~ 6000. And
the step is 200.
+- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
+ unspecified default values shall be used.
+- nvmem-cell-names: Should be "calibration-data"
Example:
@@ -47,6 +50,8 @@ mipi_tx0: mipi-dphy@10215000 {
#clock-cells = <0>;
#phy-cells = <0>;
drive-strength-microamp = <4600>;
+ nvmem-cells= <_tx_calibration>;
+ nvmem-cell-names = "calibration-data";
};
dsi0: dsi@1401b000 {
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/4] drm/mediatek: config mipitx impedance with calibration data
Read calibration data from nvmem, and config mipitx impedance with
calibration data to make sure their impedance are 100ohm.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 57 +++
1 file changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
index e4cc967750cb..0f87cd3d1d7d 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
@@ -5,6 +5,8 @@
*/
#include "mtk_mipi_tx.h"
+#include
+#include
#define MIPITX_LANE_CON0x000c
#define RG_DSI_CPHY_T1DRV_EN BIT(0)
@@ -28,6 +30,7 @@
#define MIPITX_PLL_CON40x003c
#define RG_DSI_PLL_IBIAS (3 << 10)
+#define MIPITX_D2P_RTCODE 0x0100
#define MIPITX_D2_SW_CTL_EN0x0144
#define MIPITX_D0_SW_CTL_EN0x0244
#define MIPITX_CK_CKMODE_EN0x0328
@@ -108,6 +111,58 @@ static const struct clk_ops mtk_mipi_tx_pll_ops = {
.recalc_rate = mtk_mipi_tx_pll_recalc_rate,
};
+static void mtk_mipi_tx_config_calibration_data(struct mtk_mipi_tx *mipi_tx)
+{
+ u32 *buf;
+ u32 rt_code[5];
+ int i, j;
+ struct nvmem_cell *cell;
+ struct device *dev = mipi_tx->dev;
+ size_t len;
+
+ cell = nvmem_cell_get(dev, "calibration-data");
+ if (IS_ERR(cell)) {
+ dev_info(dev, "nvmem_cell_get fail\n");
+ return;
+ }
+
+ buf = (u32 *)nvmem_cell_read(cell, );
+
+ nvmem_cell_put(cell);
+
+ if (IS_ERR(buf)) {
+ dev_info(dev, "can't get data\n");
+ return;
+ }
+
+ if (len < 3 * sizeof(u32)) {
+ dev_info(dev, "invalid calibration data\n");
+ kfree(buf);
+ return;
+ }
+
+ rt_code[0] = ((buf[0] >> 6 & 0x1f) << 5) | (buf[0] >> 11 & 0x1f);
+ rt_code[1] = ((buf[1] >> 27 & 0x1f) << 5) | (buf[0] >> 1 & 0x1f);
+ rt_code[2] = ((buf[1] >> 17 & 0x1f) << 5) | (buf[1] >> 22 & 0x1f);
+ rt_code[3] = ((buf[1] >> 7 & 0x1f) << 5) | (buf[1] >> 12 & 0x1f);
+ rt_code[4] = ((buf[2] >> 27 & 0x1f) << 5) | (buf[1] >> 2 & 0x1f);
+
+ for (i = 0; i < 5; i++) {
+ if ((rt_code[i] & 0x1f) == 0)
+ rt_code[i] |= 0x10;
+
+ if ((rt_code[i] >> 5 & 0x1f) == 0)
+ rt_code[i] |= 0x10 << 5;
+
+ for (j = 0; j < 10; j++)
+ mtk_mipi_tx_update_bits(mipi_tx,
+ MIPITX_D2P_RTCODE * (i + 1) + j * 4,
+ 1, rt_code[i] >> j & 1);
+ }
+
+ kfree(buf);
+}
+
static void mtk_mipi_tx_power_on_signal(struct phy *phy)
{
struct mtk_mipi_tx *mipi_tx = phy_get_drvdata(phy);
@@ -130,6 +185,8 @@ static void mtk_mipi_tx_power_on_signal(struct phy *phy)
RG_DSI_HSTX_LDO_REF_SEL,
(mipi_tx->mipitx_drive - 3000) / 200 << 6);
+ mtk_mipi_tx_config_calibration_data(mipi_tx);
+
mtk_mipi_tx_set_bits(mipi_tx, MIPITX_CK_CKMODE_EN, DSI_CK_CKMODE_EN);
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/4] drm/mediatek: add the mipitx driving control
Add a property in device tree to control the driving by different
board.
Reviewed-by: Matthias Brugger
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 14 ++
drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 1 +
drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 7 +++
3 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
index e4d34484ecc8..e301af64809e 100644
--- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
+++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
@@ -125,6 +125,20 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
return ret;
}
+ ret = of_property_read_u32(dev->of_node, "drive-strength-microamp",
+ _tx->mipitx_drive);
+ /* If can't get the "mipi_tx->mipitx_drive", set it default 0x8 */
+ if (ret < 0)
+ mipi_tx->mipitx_drive = 4600;
+
+ /* check the mipitx_drive valid */
+ if (mipi_tx->mipitx_drive > 6000 || mipi_tx->mipitx_drive < 3000) {
+ dev_warn(dev, "drive-strength-microamp is invalid %d, not in
3000 ~ 6000\n",
+mipi_tx->mipitx_drive);
+ mipi_tx->mipitx_drive = clamp_val(mipi_tx->mipitx_drive, 3000,
+ 6000);
+ }
+
ref_clk_name = __clk_get_name(ref_clk);
ret = of_property_read_string(dev->of_node, "clock-output-names",
diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
index 413f35d86219..eea44327fe9f 100644
--- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
+++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
@@ -27,6 +27,7 @@ struct mtk_mipi_tx {
struct device *dev;
void __iomem *regs;
u32 data_rate;
+ u32 mipitx_drive;
const struct mtk_mipitx_data *driver_data;
struct clk_hw pll_hw;
struct clk *pll;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
index 91f08a351fd0..e4cc967750cb 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
@@ -17,6 +17,9 @@
#define RG_DSI_BG_CORE_EN BIT(7)
#define RG_DSI_PAD_TIEL_SELBIT(8)
+#define MIPITX_VOLTAGE_SEL 0x0010
+#define RG_DSI_HSTX_LDO_REF_SEL(0xf << 6)
+
#define MIPITX_PLL_PWR 0x0028
#define MIPITX_PLL_CON00x002c
#define MIPITX_PLL_CON10x0030
@@ -123,6 +126,10 @@ static void mtk_mipi_tx_power_on_signal(struct phy *phy)
mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_D3_SW_CTL_EN, DSI_SW_CTL_EN);
mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_CK_SW_CTL_EN, DSI_SW_CTL_EN);
+ mtk_mipi_tx_update_bits(mipi_tx, MIPITX_VOLTAGE_SEL,
+ RG_DSI_HSTX_LDO_REF_SEL,
+ (mipi_tx->mipitx_drive - 3000) / 200 << 6);
+
mtk_mipi_tx_set_bits(mipi_tx, MIPITX_CK_CKMODE_EN, DSI_CK_CKMODE_EN);
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/4] dt-bindings: display: mediatek: add property to control mipi tx drive current
Add a property to control mipi tx drive current:
"drive-strength-microamp"
Signed-off-by: Jitao Shi
---
.../devicetree/bindings/display/mediatek/mediatek,dsi.txt| 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
index a19a6cc375ed..d78b6d6d8fab 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
@@ -33,6 +33,10 @@ Required properties:
- #clock-cells: must be <0>;
- #phy-cells: must be <0>.
+Optional properties:
+- drive-strength-microamp: adjust driving current, should be 3000 ~ 6000. And
+ the step is 200.
+
Example:
mipi_tx0: mipi-dphy@10215000 {
@@ -42,6 +46,7 @@ mipi_tx0: mipi-dphy@10215000 {
clock-output-names = "mipi_tx0_pll";
#clock-cells = <0>;
#phy-cells = <0>;
+ drive-strength-microamp = <4600>;
};
dsi0: dsi@1401b000 {
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vram-helpers: Merge code into a single file
Most of the documentation was in an otherwise empty file, which was
probably just left from a previous clean-up effort. So move code and
documentation into a single file.
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/drm-mm.rst | 9 ---
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_gem_vram_helper.c| 95 ++--
drivers/gpu/drm/drm_vram_helper_common.c | 94 ---
4 files changed, 91 insertions(+), 110 deletions(-)
delete mode 100644 drivers/gpu/drm/drm_vram_helper_common.c
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index c77b326012606..1839762044be1 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -373,15 +373,6 @@ GEM CMA Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c
:export:
-VRAM Helper Function Reference
-==
-
-.. kernel-doc:: drivers/gpu/drm/drm_vram_helper_common.c
- :doc: overview
-
-.. kernel-doc:: include/drm/drm_gem_vram_helper.h
- :internal:
-
GEM VRAM Helper Functions Reference
---
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 183c600483073..f34d08c834851 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -33,8 +33,7 @@ drm-$(CONFIG_PCI) += drm_pci.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
-drm_vram_helper-y := drm_gem_vram_helper.o \
-drm_vram_helper_common.o
+drm_vram_helper-y := drm_gem_vram_helper.o
obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
drm_ttm_helper-y := drm_gem_ttm_helper.o
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index d4e4f80d3a6c1..d70e335f7ee3e 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-or-later
+#include
+
#include
#include
#include
@@ -19,13 +21,93 @@ static const struct drm_gem_object_funcs
drm_gem_vram_object_funcs;
/**
* DOC: overview
*
- * This library provides a GEM buffer object that is backed by video RAM
- * (VRAM). It can be used for framebuffer devices with dedicated memory.
+ * This library provides drm_gem_vram_object (GEM VRAM), a GEM
+ * buffer object that is backed by video RAM (VRAM). It can be used for
+ * framebuffer devices with dedicated memory.
*
* The data structure drm_vram_mm and its helpers implement a memory
- * manager for simple framebuffer devices with dedicated video memory. Buffer
- * objects are either placed in video RAM or evicted to system memory. The rsp.
- * buffer object is provided by drm_gem_vram_object.
+ * manager for simple framebuffer devices with dedicated video memory. GEM
+ * VRAM buffer objects are either placed in the video memory or remain evicted
+ * to system memory.
+ *
+ * With the GEM interface userspace applications create, manage and destroy
+ * graphics buffers, such as an on-screen framebuffer. GEM does not provide
+ * an implementation of these interfaces. It's up to the DRM driver to
+ * provide an implementation that suits the hardware. If the hardware device
+ * contains dedicated video memory, the DRM driver can use the VRAM helper
+ * library. Each active buffer object is stored in video RAM. Active
+ * buffer are used for drawing the current frame, typically something like
+ * the frame's scanout buffer or the cursor image. If there's no more space
+ * left in VRAM, inactive GEM objects can be moved to system memory.
+ *
+ * The easiest way to use the VRAM helper library is to call
+ * drm_vram_helper_alloc_mm(). The function allocates and initializes an
+ * instance of drm_vram_mm in drm_device.vram_mm . Use
+ * _GEM_VRAM_DRIVER to initialize drm_driver and
+ * _VRAM_MM_FILE_OPERATIONS to initialize file_operations;
+ * as illustrated below.
+ *
+ * .. code-block:: c
+ *
+ * struct file_operations fops ={
+ * .owner = THIS_MODULE,
+ * DRM_VRAM_MM_FILE_OPERATION
+ * };
+ * struct drm_driver drv = {
+ * .driver_feature = DRM_ ... ,
+ * .fops = ,
+ * DRM_GEM_VRAM_DRIVER
+ * };
+ *
+ * int init_drm_driver()
+ * {
+ * struct drm_device *dev;
+ * uint64_t vram_base;
+ * unsigned long vram_size;
+ * int ret;
+ *
+ * // setup device, vram base and size
+ * // ...
+ *
+ * ret = drm_vram_helper_alloc_mm(dev, vram_base, vram_size);
+ * if (ret)
+ * return ret;
+ * return 0;
+ * }
+ *
+ * This creates an instance of drm_vram_mm, exports DRM userspace
+ * interfaces for GEM buffer management and initializes file operations to
+ * allow for accessing created GEM buffers. With this setup, the DRM driver
+ * manages an area
[PATCH] drm/vram-helpers: Set plane fence for display update
Calling the VRAM helper's prepare_fb() helper now sets the plane's
fence object. The helper still has to synchronize with other users
of the GEM object. Leave a related TODO comment in the code.
This will be useful for PRIME support. VRAM helpers don't support
buffer sharing ATM, so there are no drivers requiring this change.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index b3201a70cbfcb..d4e4f80d3a6c1 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -670,9 +671,9 @@ EXPORT_SYMBOL(drm_gem_vram_driver_dumb_mmap_offset);
* @plane: a DRM plane
* @new_state: the plane's new state
*
- * During plane updates, this function pins the GEM VRAM
- * objects of the plane's new framebuffer to VRAM. Call
- * drm_gem_vram_plane_helper_cleanup_fb() to unpin them.
+ * During plane updates, this function sets the plane's fence and
+ * pins the GEM VRAM objects of the plane's new framebuffer to VRAM.
+ * Call drm_gem_vram_plane_helper_cleanup_fb() to unpin them.
*
* Returns:
* 0 on success, or
@@ -689,6 +690,13 @@ drm_gem_vram_plane_helper_prepare_fb(struct drm_plane
*plane,
if (!new_state->fb)
return 0;
+ /*
+* TODO: Synchronize with other users of the buffer. Buffers
+* cannot be pinned to VRAM while they are in use by other
+* drivers for DMA. We should probably wait for each GEM
+* object's fence before attempting to pin the buffer.
+* There are currently no users of this functionality.
+*/
for (i = 0; i < ARRAY_SIZE(new_state->fb->obj); ++i) {
if (!new_state->fb->obj[i])
continue;
@@ -698,6 +706,10 @@ drm_gem_vram_plane_helper_prepare_fb(struct drm_plane
*plane,
goto err_drm_gem_vram_unpin;
}
+ ret = drm_gem_fb_prepare_fb(plane, new_state);
+ if (ret)
+ goto err_drm_gem_vram_unpin;
+
return 0;
err_drm_gem_vram_unpin:
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/mediatek: Move mtk_hdmi_phy driver into drivers/phy/mediatek folder
Hi,
On 30/03/2020 16:12, Chun-Kuang Hu wrote:
> From: CK Hu
>
> mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
> more suitable to place a phy driver into phy driver folder, so move
> mtk_hdmi_phy driver into phy driver folder.
Pretty sure the subject should start with "phy: " and have an ack from Kishon.
Neil
>
> Signed-off-by: CK Hu
> Signed-off-by: Chun-Kuang Hu
> ---
> drivers/gpu/drm/mediatek/Kconfig | 7 ---
> drivers/gpu/drm/mediatek/Makefile | 6 --
> drivers/phy/mediatek/Kconfig | 7 +++
> drivers/phy/mediatek/Makefile | 7 +++
> .../mediatek/phy-mtk-hdmi-mt2701.c}| 2 +-
> .../mediatek/phy-mtk-hdmi-mt8173.c}| 2 +-
> .../mtk_hdmi_phy.c => phy/mediatek/phy-mtk-hdmi.c} | 2 +-
> .../mtk_hdmi_phy.h => phy/mediatek/phy-mtk-hdmi.h} | 0
> 8 files changed, 17 insertions(+), 16 deletions(-)
> rename drivers/{gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c =>
> phy/mediatek/phy-mtk-hdmi-mt2701.c} (99%)
> rename drivers/{gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c =>
> phy/mediatek/phy-mtk-hdmi-mt8173.c} (99%)
> rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.c =>
> phy/mediatek/phy-mtk-hdmi.c} (99%)
> rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.h =>
> phy/mediatek/phy-mtk-hdmi.h} (100%)
>
> diff --git a/drivers/gpu/drm/mediatek/Kconfig
> b/drivers/gpu/drm/mediatek/Kconfig
> index ff6a1eb4ae83..2427d5bf699d 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -26,10 +26,3 @@ config DRM_MEDIATEK_HDMI
> select PHY_MTK_HDMI
> help
> DRM/KMS HDMI driver for Mediatek SoCs
> -
> -config PHY_MTK_HDMI
> -tristate "MediaTek HDMI-PHY Driver"
> -depends on ARCH_MEDIATEK && OF
> -select GENERIC_PHY
> -help
> - Enable this to support HDMI-PHY
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index fcbef23aa6ce..77b0fd86063d 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -22,9 +22,3 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
> mtk_hdmi_ddc.o
>
> obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> -
> -phy-mtk-hdmi-drv-objs := mtk_hdmi_phy.o \
> - mtk_mt2701_hdmi_phy.o \
> - mtk_mt8173_hdmi_phy.o
> -
> -obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
> diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> index dee757c957f2..10f0ec2d5b54 100644
> --- a/drivers/phy/mediatek/Kconfig
> +++ b/drivers/phy/mediatek/Kconfig
> @@ -35,3 +35,10 @@ config PHY_MTK_XSPHY
> Enable this to support the SuperSpeedPlus XS-PHY transceiver for
> USB3.1 GEN2 controllers on MediaTek chips. The driver supports
> multiple USB2.0, USB3.1 GEN2 ports.
> +
> +config PHY_MTK_HDMI
> +tristate "MediaTek HDMI-PHY Driver"
> +depends on ARCH_MEDIATEK && OF
> +select GENERIC_PHY
> +help
> + Enable this to support HDMI-PHY
> diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> index 08a8e6a97b1e..cda074c53235 100644
> --- a/drivers/phy/mediatek/Makefile
> +++ b/drivers/phy/mediatek/Makefile
> @@ -6,3 +6,10 @@
> obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
> obj-$(CONFIG_PHY_MTK_UFS)+= phy-mtk-ufs.o
> obj-$(CONFIG_PHY_MTK_XSPHY) += phy-mtk-xsphy.o
> +
> +phy-mtk-hdmi-drv-objs := phy-mtk-hdmi.o \
> + phy-mtk-hdmi-mt2701.o \
> + phy-mtk-hdmi-mt8173.o
> +
> +obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
> +
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> similarity index 99%
> rename from drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> rename to drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> index 99fe05cd3598..a6cb1dea3d0c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> @@ -4,7 +4,7 @@
> * Author: Chunhui Dai
> */
>
> -#include "mtk_hdmi_phy.h"
> +#include "phy-mtk-hdmi.h"
>
> #define HDMI_CON00x00
> #define RG_HDMITX_DRV_IBIAS 0
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> b/drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
> similarity index 99%
> rename from drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> rename to drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
> index b55f51675205..3521c4893c53 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> +++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
> @@ -4,7 +4,7 @@
> * Author: Jie Qiu
> */
>
> -#include "mtk_hdmi_phy.h"
> +#include "phy-mtk-hdmi.h"
>
> #define HDMI_CON00x00
> #define RG_HDMITX_PLL_EN BIT(31)
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
>
Re: [PATCH v2] fbcon: fix null-ptr-deref in fbcon_switch
On Mon, Mar 30, 2020 at 09:16:19PM +0200, Sam Ravnborg wrote: > Hi Qiujun > > On Sun, Mar 29, 2020 at 04:56:47PM +0800, Qiujun Huang wrote: > > Set logo_shown to FBCON_LOGO_CANSHOW when the vc was deallocated. > > > > syzkaller report: https://lkml.org/lkml/2020/3/27/403 > > general protection fault, probably for non-canonical address > > 0xdc6c: [#1] SMP KASAN > > KASAN: null-ptr-deref in range [0x0360-0x0367] > > RIP: 0010:fbcon_switch+0x28f/0x1740 > > drivers/video/fbdev/core/fbcon.c:2260 > > > > Call Trace: > > redraw_screen+0x2a8/0x770 drivers/tty/vt/vt.c:1008 > > vc_do_resize+0xfe7/0x1360 drivers/tty/vt/vt.c:1295 > > fbcon_init+0x1221/0x1ab0 drivers/video/fbdev/core/fbcon.c:1219 > > visual_init+0x305/0x5c0 drivers/tty/vt/vt.c:1062 > > do_bind_con_driver+0x536/0x890 drivers/tty/vt/vt.c:3542 > > do_take_over_console+0x453/0x5b0 drivers/tty/vt/vt.c:4122 > > do_fbcon_takeover+0x10b/0x210 drivers/video/fbdev/core/fbcon.c:588 > > fbcon_fb_registered+0x26b/0x340 drivers/video/fbdev/core/fbcon.c:3259 > > do_register_framebuffer drivers/video/fbdev/core/fbmem.c:1664 [inline] > > register_framebuffer+0x56e/0x980 drivers/video/fbdev/core/fbmem.c:1832 > > dlfb_usb_probe.cold+0x1743/0x1ba3 drivers/video/fbdev/udlfb.c:1735 > > usb_probe_interface+0x310/0x800 drivers/usb/core/driver.c:374 > > > > accessing vc_cons[logo_shown].d->vc_top causes the bug. > > > > Reported-by: syzbot+732528bae351682f1...@syzkaller.appspotmail.com > > Signed-off-by: Qiujun Huang > > --- > > drivers/video/fbdev/core/fbcon.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/video/fbdev/core/fbcon.c > > b/drivers/video/fbdev/core/fbcon.c > > index bb6ae995c2e5..5eb3fc90f9f6 100644 > > --- a/drivers/video/fbdev/core/fbcon.c > > +++ b/drivers/video/fbdev/core/fbcon.c > > @@ -1283,6 +1283,9 @@ static void fbcon_deinit(struct vc_data *vc) > > if (!con_is_bound(_con)) > > fbcon_exit(); > > > > + if (vc->vc_num == logo_shown) > > + logo_shown = FBCON_LOGO_CANSHOW; > > + > > return; > > } > > Looks much better than the previous version. > Acked-by: Sam Ravnborg > > I expect Bartlomiej to review/apply. Especially for bugfixes I think better to push quicker than wait for others to ... the point with drm-misc is real group maintainership and benefitting from the flexibility, not reflecting the same strict hierarchy but in a flat tree to make it look like it doesn't exist :-) Applied to drm-misc-next-fixes with a cc: stable. -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
[PATCH 3/5] drm: msm: scale DDR BW along with GPU frequency
This patch adds support to parse the OPP tables attached the GPU device,
the main opp table and the DDR bandwidth opp table. Additionally, vote
for the GPU->DDR bandwidth when setting the GPU frequency by querying
the linked DDR BW opp to the GPU opp.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 41 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 44 +
drivers/gpu/drm/msm/msm_gpu.h | 9 +++
3 files changed, 84 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 748cd37..489d9b6 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -100,6 +100,40 @@ bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
}
+void a6xx_gmu_set_icc_vote(struct msm_gpu *gpu, unsigned long gpu_freq)
+{
+ struct dev_pm_opp *gpu_opp, *ddr_opp;
+ struct opp_table **tables = gpu->opp_tables;
+ unsigned long peak_bw;
+
+ if (!gpu->opp_tables[GPU_DDR_OPP_TABLE_INDEX])
+ goto done;
+
+ gpu_opp = dev_pm_opp_find_freq_exact(>pdev->dev, gpu_freq, true);
+ if (IS_ERR_OR_NULL(gpu_opp))
+ goto done;
+
+ ddr_opp = dev_pm_opp_xlate_required_opp(tables[GPU_OPP_TABLE_INDEX],
+ tables[GPU_DDR_OPP_TABLE_INDEX],
+ gpu_opp);
+ dev_pm_opp_put(gpu_opp);
+
+ if (IS_ERR_OR_NULL(ddr_opp))
+ goto done;
+
+ peak_bw = dev_pm_opp_get_bw(ddr_opp, NULL);
+ dev_pm_opp_put(ddr_opp);
+
+ icc_set_bw(gpu->icc_path, 0, peak_bw);
+ return;
+done:
+ /*
+* If there is a problem, for now leave it at max so that the
+* performance is nominal.
+*/
+ icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+}
+
static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
{
struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
@@ -128,11 +162,8 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
index)
gmu->freq = gmu->gpu_freqs[index];
- /*
-* Eventually we will want to scale the path vote with the frequency but
-* for now leave it at max so that the performance is nominal.
-*/
- icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+ if (gpu->icc_path)
+ a6xx_gmu_set_icc_vote(gpu, gmu->freq);
}
void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 2d13694..bbbcc7a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -882,7 +882,7 @@ static int adreno_get_pwrlevels(struct device *dev,
{
unsigned long freq = ULONG_MAX;
struct dev_pm_opp *opp;
- int ret;
+ int ret, i;
gpu->fast_rate = 0;
@@ -890,9 +890,29 @@ static int adreno_get_pwrlevels(struct device *dev,
if (!of_find_property(dev->of_node, "operating-points-v2", NULL))
ret = adreno_get_legacy_pwrlevels(dev);
else {
- ret = dev_pm_opp_of_add_table(dev);
- if (ret)
- DRM_DEV_ERROR(dev, "Unable to set the OPP table\n");
+ int count = of_count_phandle_with_args(dev->of_node,
+ "operating-points-v2", NULL);
+
+ count = min(count, GPU_DDR_OPP_TABLE_INDEX + 1);
+ count = max(count, 1);
+
+ for (i = 0; i < count; i++) {
+ ret = dev_pm_opp_of_add_table_indexed(dev, i);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "Add OPP table %d: failed
%d\n",
+ i, ret);
+ goto err;
+ }
+
+ gpu->opp_tables[i] =
+ dev_pm_opp_get_opp_table_indexed(dev, i);
+ if (!gpu->opp_tables[i]) {
+ DRM_DEV_ERROR(dev, "Get OPP table failed index
%d\n",
+ i);
+ ret = -EINVAL;
+ goto err;
+ }
+ }
}
if (!ret) {
@@ -919,12 +939,24 @@ static int adreno_get_pwrlevels(struct device *dev,
gpu->icc_path = NULL;
return 0;
+err:
+ for (; i >= 0; i--) {
+ if (gpu->opp_tables[i]) {
+ dev_pm_opp_put_opp_table(gpu->opp_tables[i]);
+ gpu->opp_tables[i] = NULL;
+ }
+ }
+
+ dev_pm_opp_remove_table(dev);
+ return ret;
}
int adreno_gpu_init(struct drm_device *drm,
[PATCH 4/5] drm: msm: a6xx: Fix off by one error when setting GPU freq
This patch fixes an error in the for loop, thereby allowing search on the full list of possible GPU power levels. Signed-off-by: Sharat Masetty --- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index 489d9b6..81b8559 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c @@ -176,7 +176,7 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq) if (freq == gmu->freq) return; - for (perf_index = 0; perf_index < gmu->nr_gpu_freqs - 1; perf_index++) + for (perf_index = 0; perf_index < gmu->nr_gpu_freqs; perf_index++) if (freq == gmu->gpu_freqs[perf_index]) break; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] dt-bindings: drm/msm/gpu: Document OPP phandle list for the GPU
Update the documentation for listing the multiple optional GPU and the
DDR OPP tables to help enable DDR scaling.
Signed-off-by: Sharat Masetty
---
.../devicetree/bindings/display/msm/gpu.txt| 63 +-
1 file changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 70025cb..ff3ae1b 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -21,7 +21,10 @@ Required properties:
following devices should not list clocks:
- qcom,adreno-630.2
- iommus: optional phandle to an adreno iommu instance
-- operating-points-v2: optional phandle to the OPP operating points
+- operating-points-v2: optional phandles to the OPP operating point tables
+ one for the GPU OPPs and the other for the GPU->DDR OPPs. Note that if
+ multiple OPP tables are specified, the GPU OPP table(considered primary)
+ should be the first in the phandle list.
- interconnects: optional phandle to an interconnect provider. See
../interconnect/interconnect.txt for details.
- qcom,gmu: For GMU attached devices a phandle to the GMU device that will
@@ -75,7 +78,7 @@ Example a6xx (with GMU):
iommus = <_smmu 0>;
- operating-points-v2 = <_opp_table>;
+ operating-points-v2 = <_opp_table>, <_ddr_bw_opp_table>;
interconnects = <_hlos MASTER_GFX3D _hlos SLAVE_EBI1>;
@@ -85,5 +88,61 @@ Example a6xx (with GMU):
memory-region = <_shader_region>;
firmware-name = "qcom/LENOVO/81JL/qcdxkmsuc850.mbn"
};
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-43000 {
+ opp-hz = /bits/ 64 <43000>;
+ opp-level = ;
+ required-opps = <_ddr_bw_opp6>;
+ };
+
+ opp-35500 {
+ opp-hz = /bits/ 64 <35500>;
+ opp-level = ;
+ required-opps = <_ddr_bw_opp4>;
+ };
+
+ opp-26700 {
+ opp-hz = /bits/ 64 <26700>;
+ opp-level = ;
+ required-opps = <_ddr_bw_opp4>;
+ };
+
+ opp-18000 {
+ opp-hz = /bits/ 64 <18000>;
+ opp-level = ;
+ required-opps = <_ddr_bw_opp2>;
+ };
+ };
+
+ gpu_ddr_bw_opp_table: gpu-ddr-bw-opp-table {
+ compatible = "operating-points-v2";
+
+ gpu_ddr_bw_opp1: opp-3 {
+ opp-peak-kBps =/bits/ 32 <120>;
+ };
+
+ gpu_ddr_bw_opp2: opp-45100 {
+ opp-peak-kBps =/bits/ 32 <1804000>;
+ };
+
+ gpu_ddr_bw_opp3: opp-54700 {
+ opp-peak-kBps =/bits/ 32 <2188000>;
+ };
+
+ gpu_ddr_bw_opp4: opp-76800 {
+ opp-peak-kBps =/bits/ 32 <3072000>;
+ };
+
+ gpu_ddr_bw_opp5: opp-101700 {
+ opp-peak-kBps =/bits/ 32 <4068000>;
+ };
+
+ gpu_ddr_bw_opp6: opp-135300 {
+ opp-peak-kBps =/bits/ 32 <5412000>;
+ };
+ };
};
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] arm64: dts: qcom: sc7180: Add interconnect bindings for GPU
This patch adds the interconnect bindings to the GPU node. This enables
the GPU->DDR path bandwidth voting.
Signed-off-by: Sharat Masetty
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 1097e8b..51630dd 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1718,6 +1718,8 @@
operating-points-v2 = <_opp_table>;
qcom,gmu = <>;
+ interconnects = <_noc MASTER_GFX3D _virt
SLAVE_EBI1>;
+
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] arm64: dts: qcom: sc7180: Add GPU DDR BW opp table
This patch adds a new opp table listing the GPU DDR bandwidth opps. Also
adds a required_opp binding to the GPUs main OPP table which holds a
phandle to a bandwidth opp in the new table. This enables linking the
GPU power level opp to the DDR bandwidth opp and helps with scaling
DDR along with GPU frequency.
Signed-off-by: Sharat Masetty
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 50 +++-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 51630dd..74b023b 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1715,7 +1715,8 @@
reg-names = "kgsl_3d0_reg_memory", "cx_mem", "cx_dbgc";
interrupts = ;
iommus = <_smmu 0>;
- operating-points-v2 = <_opp_table>;
+ operating-points-v2 = <_opp_table>,
+ <_ddr_bw_opp_table>;
qcom,gmu = <>;
interconnects = <_noc MASTER_GFX3D _virt
SLAVE_EBI1>;
@@ -1726,40 +1727,87 @@
opp-8 {
opp-hz = /bits/ 64 <8>;
opp-level =
;
+ required-opps = <_ddr_bw_opp9>;
};
opp-65000 {
opp-hz = /bits/ 64 <65000>;
opp-level =
;
+ required-opps = <_ddr_bw_opp8>;
};
opp-56500 {
opp-hz = /bits/ 64 <56500>;
opp-level = ;
+ required-opps = <_ddr_bw_opp6>;
};
opp-43000 {
opp-hz = /bits/ 64 <43000>;
opp-level =
;
+ required-opps = <_ddr_bw_opp6>;
};
opp-35500 {
opp-hz = /bits/ 64 <35500>;
opp-level = ;
+ required-opps = <_ddr_bw_opp4>;
};
opp-26700 {
opp-hz = /bits/ 64 <26700>;
opp-level =
;
+ required-opps = <_ddr_bw_opp4>;
};
opp-18000 {
opp-hz = /bits/ 64 <18000>;
opp-level =
;
+ required-opps = <_ddr_bw_opp2>;
};
};
};
+ gpu_ddr_bw_opp_table: gpu-ddr-bw-opp-table {
+ compatible = "operating-points-v2";
+
+ gpu_ddr_bw_opp1: opp-3 {
+ opp-peak-kBps =/bits/ 32 <120>;
+ };
+
+ gpu_ddr_bw_opp2: opp-45100 {
+ opp-peak-kBps =/bits/ 32 <1804000>;
+ };
+
+ gpu_ddr_bw_opp3: opp-54700 {
+ opp-peak-kBps =/bits/ 32 <2188000>;
+ };
+
+ gpu_ddr_bw_opp4: opp-76800 {
+ opp-peak-kBps =/bits/ 32 <3072000>;
+ };
+
+ gpu_ddr_bw_opp5: opp-101700 {
+ opp-peak-kBps =/bits/ 32 <4068000>;
+ };
+
+ gpu_ddr_bw_opp6: opp-135300 {
+ opp-peak-kBps =/bits/ 32 <5412000>;
+ };
+
+ gpu_ddr_bw_opp7: opp-155500 {
+ opp-peak-kBps =/bits/ 32 <622>;
+ };
+
+ gpu_ddr_bw_opp8: opp-180400 {
+ opp-peak-kBps =/bits/ 32 <7216000>;
+ };
+
+ gpu_ddr_bw_opp9: opp-213300 {
+ opp-peak-kBps =/bits/ 32 <8532000>;
+ };
+ };
+
adreno_smmu: iommu@504 {
compatible = "qcom,sc7180-smmu-v2", "qcom,smmu-v2";
reg = <0 0x0504 0 0x1>;
--
2.7.4
[PATCH 0/5] Add support for GPU DDR BW scaling
This series adds support for GPU DDR bandwidth scaling and is based on the bindings from Sarvana[1]. This work is based on Sibi's work for CPU side [2] which also lists all the needed dependencies to get this series working. My workspace is based on a chrome tag [3]. Although the bindings add support for both peak and average bandwidth votes, I have only added support for peak bandwidth votes. [1]: https://patchwork.kernel.org/cover/11277199/ [2]: https://patchwork.kernel.org/cover/11353185/ (this lists further dependencies) [3]: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2097039/3 Sharat Masetty (5): arm64: dts: qcom: sc7180: Add interconnect bindings for GPU arm64: dts: qcom: sc7180: Add GPU DDR BW opp table drm: msm: scale DDR BW along with GPU frequency drm: msm: a6xx: Fix off by one error when setting GPU freq dt-bindings: drm/msm/gpu: Document OPP phandle list for the GPU .../devicetree/bindings/display/msm/gpu.txt| 63 +- arch/arm64/boot/dts/qcom/sc7180.dtsi | 52 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 43 --- drivers/gpu/drm/msm/adreno/adreno_gpu.c| 44 +-- drivers/gpu/drm/msm/msm_gpu.h | 9 5 files changed, 197 insertions(+), 14 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/6] drm/vblank: Add intro to documentation
On Mon, Mar 30, 2020 at 05:51:26PM -0400, Lyude Paul wrote: > I am glad that my explanation of vblanks made sense! Some comments below on > things I think we could improve here > > On Mon, 2020-03-30 at 20:57 +0200, Sam Ravnborg wrote: > > Lyude Paul wrote a very good intro to vblank here: > > > https://lore.kernel.org/dri-devel/faf63d8a9ed23c16af69762f59d0dca6b2bf085f.ca...@redhat.com/T/#mce6480be738160e9d07c5d023e88fd78d7a06d27 > > > > Add this to the intro chapter in drm_vblank.c so others > > can benefit from it too. > > > > v2: > > - Reworded to improve readability (Thomas) > > > > Signed-off-by: Sam Ravnborg > > Co-developed-by: Lyude Paul > > Cc: Lyude Paul > > Acked-by: Thomas Zimmermann > > Cc: Thomas Zimmermann > > Cc: Daniel Vetter > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: Thomas Zimmermann > > Cc: David Airlie > > --- > > drivers/gpu/drm/drm_vblank.c | 17 + > > 1 file changed, 17 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > index bcf346b3e486..ec2c2083b186 100644 > > --- a/drivers/gpu/drm/drm_vblank.c > > +++ b/drivers/gpu/drm/drm_vblank.c > > @@ -41,6 +41,23 @@ > > /** > > * DOC: vblank handling > > * > > + * From the computer's perspective, every time the monitor displays > > + * a new frame the scanout engine have "scanned out" the display image > > + * from top to bottom, one row of pixels at a time. > > + * The current row of pixels is referred to as the current scanline. > > + * > > + * In addition to the display's visible area, there's usually a couple of > > + * extra scanlines which aren't actually displayed on the screen > > + * (the extra scanlines are sometimes used by HDMI audio and friends). > > + * The period where the extra scanlines are "scanned out" is referred > > + * to as the vertical blanking period (vblank for short). > > I'd reword this, starting from "(the extra scanlines…" (I'd also remove the > paranthesis): > > These extra scanlines don't contain image data, and are occasionally used > for features like audio and infoframes. The region made up of these > scanlines is referred to as the vertical blanking region, or vblank for > short. > > I'd also add a simple ascii-art diagram here, since this might make a lot more > sense to some people if there's a visual reference. Probably something like > this (feel free to get a little creative) > > > || > || > | New frame| > || > || > || ← Scanline, updates the > || frame as it travels > || down (AKA "scans > out") > || > || > | Old frame| > || > || > || > || > || physical bottom of > || ← display > ┆┆ > ┆┆ ← vertical blanking > ┆┆ region > Oh if we go with a nice asci-art picture, can we please also make a note that top of the frame is where the corrected/high-precision timestamp should match? -Daniel > > + * > > + * On a lot of display hardware, programming needs to take effect during > > the > > + * vertical blanking period so that settings like gamma, what frame being > > s/what frame being/which frame is being/ > > > + * scanned out, etc. can be safely changed without showing visual tearing > > + * on the screen. In some unforgiving hardware, some of this programming > > has > > + * to both start and end in the same vblank - vertical blanking period. > > You can just say vblank here, since we already explained what the vertical > blanking period is up above. > > Alex Deucher pointed out to me that it's probably also worth mentioning that > not > all hardware actually fires off the vblank interrupt at the start of the > vertical blank, depending on the hardware the interrupt could also happen a > few > scanlines after the start of vblank, a few scanlines before the start, > somewhere > in the middle, at the end of the vblank, etc. > > Other then that, this looks great so
Re: [PATCH v1 3/6] drm/sched: fix kernel-doc in gpu_scheduler.h
On Sat, Mar 28, 2020 at 02:20:22PM +0100, Sam Ravnborg wrote:
> Fix following warning:
> gpu_scheduler.h:103: warning: Function parameter or member 'priority' not
> described in 'drm_sched_entity'
>
> Signed-off-by: Sam Ravnborg
> Cc: Nirmoy Das
> Cc: David Airlie
> Cc: Daniel Vetter
Inline struct comments would be really nice here. Otherwise
Acked-by: Daniel Vetter
> ---
> include/drm/gpu_scheduler.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index 26b04ff62676..a21b3b92135a 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -56,6 +56,7 @@ enum drm_sched_priority {
> * Jobs from this entity can be scheduled on any scheduler
> * on this list.
> * @num_sched_list: number of drm_gpu_schedulers in the sched_list.
> + * @priority: priority of the entity
> * @rq_lock: lock to modify the runqueue to which this entity belongs.
> * @job_queue: the list of jobs of this entity.
> * @fence_seq: a linearly increasing seqno incremented with each
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 4/6] drm: writeback: document callbacks
On Sat, Mar 28, 2020 at 02:20:23PM +0100, Sam Ravnborg wrote:
> Document the callbacks:
> drm_connector_helper_funcs.prepare_writeback_job
> drm_connector_helper_funcs.cleanup_writeback_job
>
> The documentation was pulled from the changelong introducing the
> callbacks, originally written by Laurent.
>
> Addign the missing documentation fixes the following warnings:
> drm_modeset_helper_vtables.h:1052: warning: Function parameter or member
> 'prepare_writeback_job' not described in 'drm_connector_helper_funcs'
> drm_modeset_helper_vtables.h:1052: warning: Function parameter or member
> 'cleanup_writeback_job' not described in 'drm_connector_helper_funcs'
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Liviu Dudau
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> ---
> include/drm/drm_modeset_helper_vtables.h | 31
> 1 file changed, 31 insertions(+)
>
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> index 7c20b1c8b6a7..c51bca1ffec7 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -1075,8 +1075,39 @@ struct drm_connector_helper_funcs {
> void (*atomic_commit)(struct drm_connector *connector,
> struct drm_connector_state *state);
>
> + /**
> + * @prepare_writeback_job:
Formatting looks funny, your linebreaks here won't go into the generated
html and are a bit unusual. I'd remove them and just flow this as a full
paragraph.
> + *
> + * As writeback jobs contain a framebuffer, drivers may need to
> + * prepare and cleanup them the same way they can prepare and
> + * cleanup framebuffers for planes.
> + * This optional connector operation is used to support the
> + * preparation of writeback jobs.
> + * The job prepare operation is called from
> + * drm_atomic_helper_prepare_planes() to avoid a new atomic commit
> + * helper that would need to be called by all drivers not using
> + * drm_atomic_helper_commit().
I'd delete "to avoid a new ..." until the end of the sentence. That feels
more like stuff in the commit message/review than kernel docs for driver
writers.
Instead maybe add "... for struct _writeback_connector connectors
only." This gives us a nice link to the writeback docs, and makes it clear
that this isn't some general prep/cleanup thing. Similar addition below.
> + *
> + * This hook is optional.
> + *
> + * This callback is used by the atomic modeset helpers.
> + */
> int (*prepare_writeback_job)(struct drm_writeback_connector *connector,
>struct drm_writeback_job *job);
> + /**
> + * @cleanup_writeback_job:
> + *
> + * This optional connector operation is used to support the
> + * cleanup of writeback jobs.
> + * The job cleanup operation is called from the existing
> + * drm_writeback_cleanup_job() function, invoked both when
> + * destroying the job as part of a aborted commit, or when
> + * the job completes.
> + *
> + * This hook is optional.
> + *
> + * This callback is used by the atomic modeset helpers.
> + */
> void (*cleanup_writeback_job)(struct drm_writeback_connector *connector,
> struct drm_writeback_job *job);
With the bikesheds addressed as you see fit:
Reviewed-by: Daniel Vetter
Also Laurent owes you one, I've been pestering to fill this gap in his
docs since forever ...
Cheers, Daniel
> };
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 6/6] drm/bridge: fix kernel-doc warning in panel.c
On Sat, Mar 28, 2020 at 02:20:25PM +0100, Sam Ravnborg wrote: > Add missing documentation to fix following warning: > panel.c:303: warning: Function parameter or member 'bridge' not described in > 'drm_panel_bridge_connector' > > Signed-off-by: Sam Ravnborg > Cc: Laurent Pinchart > Cc: Boris Brezillon > Cc: Mihail Atanassov > Cc: Andrzej Hajda > Cc: Neil Armstrong > Cc: Jonas Karlman > Cc: Jernej Skrabec Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/bridge/panel.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c > index 8461ee8304ba..e933f1c47f5d 100644 > --- a/drivers/gpu/drm/bridge/panel.c > +++ b/drivers/gpu/drm/bridge/panel.c > @@ -311,6 +311,7 @@ EXPORT_SYMBOL(devm_drm_panel_bridge_add_typed); > > /** > * drm_panel_bridge_connector - return the connector for the panel bridge > + * @bridge: The drm_bridge. > * > * drm_panel_bridge creates the connector. > * This function gives external access to the connector. > -- > 2.20.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fix ifnullfree.cocci warnings
On Fri, Mar 27, 2020 at 09:11:44AM +0100, Julia Lawall wrote:
> NULL check before kfree is not needed.
>
> Generated by: scripts/coccinelle/free/ifnullfree.cocci
>
> Fixes: c6603c740e0e ("drm: add managed resources tied to drm_device")
> Signed-off-by: kbuild test robot
> Signed-off-by: Julia Lawall
> ---
>
> tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
Hm this doesn't apply anymore, the patch is for an interim state (because
bisectability). Care to regen (the pattern still exists), I'm happy to
apply.
-Daniel
> head: 9e1ed9fb1eb0a4bc43a26365c592d3095286038b
> commit: c6603c740e0e3492c9c95fdab833375bf7117b6b [1587/1636] drm: add managed
> resources tied to drm_device
> :: branch date: 8 hours ago
> :: commit date: 9 hours ago
>
> Up to you, if you tihnk it is useful...
>
> drm_drv.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -837,8 +837,9 @@ static void drm_dev_release(struct kref
> if (!dev->driver->release && !dev->managed.final_kfree) {
> WARN_ON(!list_empty(>managed.resources));
> kfree(dev);
> - } else if (dev->managed.final_kfree)
> + } else {
> kfree(dev->managed.final_kfree);
> + }
> }
>
> /**
--
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
