dri-devel June 2020

dri-devel@lists.freedesktop.org

315 participants
731 discussions

linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
by Stephen Rothwell 06 Jul '20

06 Jul '20

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/gvt/handlers.c between commit: fc1e3aa0337c ("drm/i915/gvt: Fix incorrect check of enabled bits in mask registers") from the drm-intel-fixes tree and commit: 5f4ae2704d59 ("drm/i915: Identify Cometlake platform") from the drm-intel tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/gpu/drm/i915/gvt/handlers.c index fadd2adb8030,26cae4846c82..000000000000 --- a/drivers/gpu/drm/i915/gvt/handlers.c +++ b/drivers/gpu/drm/i915/gvt/handlers.c @@@ -1731,8 -1734,9 +1734,9 @@@ static int ring_mode_mmio_write(struct return 0; } - if (IS_COFFEELAKE(vgpu->gvt->gt->i915) && + if ((IS_COFFEELAKE(vgpu->gvt->gt->i915) || + IS_COMETLAKE(vgpu->gvt->gt->i915)) && - data & _MASKED_BIT_ENABLE(2)) { + IS_MASKED_BITS_ENABLED(data, 2)) { enter_failsafe_mode(vgpu, GVT_FAILSAFE_UNSUPPORTED_GUEST); return 0; }

1 1

[RESEND PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge
by Enric Balletbo i Serra 05 Jul '20

05 Jul '20

(This resend is to fix some trivial conflicts due the merge window) The PS8640 dsi-to-eDP bridge driver is using the panel bridge API, however, not all the components in the chain have been ported to the drm_bridge API. Actually, when a panel is attached the default panel's mode is used, but in some cases we can't get display up if mode getting from eDP control EDID is not chosen. This series address that problem, first implements the .get_edid() callback in the PS8640 driver (which is not used until the conversion is done) and then, converts the Mediatek DSI driver to use the drm_bridge API. As far as I know, we're the only users of the mediatek dsi driver in mainline, so should be safe to switch to the new chain of drm_bridge API unconditionally. The patches has been tested on a Acer Chromebook R13 (Elm) running a Chrome OS userspace and checking that the valid EDID mode reported by the bridge is selected. Changes in v4: - Remove double call to drm_encoder_init(). (Chun-Kuang Hu) - Cleanup the encoder in mtk_dsi_unbind(). (Chun-Kuang Hu) Changes in v3: - Replace s/bridge/next bridge/ for comment. (Laurent Pinchart) - Add the bridge.type. (Laurent Pinchart) - Use next_bridge field to store the panel bridge. (Laurent Pinchart) - Add the bridge.type field. (Laurent Pinchart) - This patch requires https://lkml.org/lkml/2020/4/16/2080 to work properly. - Move the bridge.type line to the patch that adds drm_bridge support. (Laurent Pinchart) Changes in v2: - Do not set connector_type for panel here. (Sam Ravnborg) Enric Balletbo i Serra (7): drm/bridge: ps8640: Get the EDID from eDP control drm/bridge_connector: Set default status connected for eDP connectors drm/mediatek: mtk_dsi: Rename bridge to next_bridge drm/mediatek: mtk_dsi: Convert to bridge driver drm/mediatek: mtk_dsi: Use simple encoder drm/mediatek: mtk_dsi: Use the drm_panel_bridge API drm/mediatek: mtk_dsi: Create connector for bridges drivers/gpu/drm/bridge/parade-ps8640.c | 12 ++ drivers/gpu/drm/drm_bridge_connector.c | 1 + drivers/gpu/drm/mediatek/mtk_dsi.c | 269 ++++++++----------------- 3 files changed, 97 insertions(+), 185 deletions(-) -- 2.27.0

3 17

[PATCH] drm/mediatek: mtk_hdmi: Remove debug messages for function calls
by Enric Balletbo i Serra 04 Jul '20

04 Jul '20

Equivalent information can be nowadays obtained using function tracer Signed-off-by: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> --- drivers/gpu/drm/mediatek/mtk_hdmi.c | 12 +----------- drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 4 ---- 2 files changed, 1 insertion(+), 15 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c index b0555a7cb3b4..172d67294435 100644 --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c @@ -1634,8 +1634,6 @@ static int mtk_hdmi_audio_startup(struct device *dev, void *data) { struct mtk_hdmi *hdmi = dev_get_drvdata(dev); - dev_dbg(dev, "%s\n", __func__); - mtk_hdmi_audio_enable(hdmi); return 0; @@ -1645,8 +1643,6 @@ static void mtk_hdmi_audio_shutdown(struct device *dev, void *data) { struct mtk_hdmi *hdmi = dev_get_drvdata(dev); - dev_dbg(dev, "%s\n", __func__); - mtk_hdmi_audio_disable(hdmi); } @@ -1655,8 +1651,6 @@ mtk_hdmi_audio_digital_mute(struct device *dev, void *data, bool enable) { struct mtk_hdmi *hdmi = dev_get_drvdata(dev); - dev_dbg(dev, "%s(%d)\n", __func__, enable); - if (enable) mtk_hdmi_hw_aud_mute(hdmi); else @@ -1669,8 +1663,6 @@ static int mtk_hdmi_audio_get_eld(struct device *dev, void *data, uint8_t *buf, { struct mtk_hdmi *hdmi = dev_get_drvdata(dev); - dev_dbg(dev, "%s\n", __func__); - memcpy(buf, hdmi->conn.eld, min(sizeof(hdmi->conn.eld), len)); return 0; @@ -1770,7 +1762,6 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev) goto err_bridge_remove; } - dev_dbg(dev, "mediatek hdmi probe success\n"); return 0; err_bridge_remove: @@ -1793,7 +1784,7 @@ static int mtk_hdmi_suspend(struct device *dev) struct mtk_hdmi *hdmi = dev_get_drvdata(dev); mtk_hdmi_clk_disable_audio(hdmi); - dev_dbg(dev, "hdmi suspend success!\n"); + return 0; } @@ -1808,7 +1799,6 @@ static int mtk_hdmi_resume(struct device *dev) return ret; } - dev_dbg(dev, "hdmi resume success!\n"); return 0; } #endif diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c index b55f51675205..1c3575372230 100644 --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c @@ -159,8 +159,6 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw) { struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw); - dev_dbg(hdmi_phy->dev, "%s\n", __func__); - mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON1, RG_HDMITX_PLL_AUTOK_EN); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_PLL_POSDIV); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3, RG_HDMITX_MHLCK_EN); @@ -178,8 +176,6 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw) { struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw); - dev_dbg(hdmi_phy->dev, "%s\n", __func__); - mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON1, RG_HDMITX_PLL_TXDIV_EN); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON1, RG_HDMITX_PLL_BIAS_LPF_EN); usleep_range(100, 150); -- 2.26.2

2 2

[PATCH] drm/mediatek: mtk_mt8173_hdmi_phy: Remove unnused const variables
by Enric Balletbo i Serra 04 Jul '20

04 Jul '20

There are some `static const u8` variables that are not used, this triggers a warning building with `make W=1`, it is safe to remove them, so do it and make the compiler more happy. Signed-off-by: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> --- .../gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 48 ------------------- 1 file changed, 48 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c index 1c3575372230..827b93786fac 100644 --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c @@ -107,54 +107,6 @@ #define RGS_HDMITX_5T1_EDG (0xf << 4) #define RGS_HDMITX_PLUG_TST BIT(0) -static const u8 PREDIV[3][4] = { - {0x0, 0x0, 0x0, 0x0}, /* 27Mhz */ - {0x1, 0x1, 0x1, 0x1}, /* 74Mhz */ - {0x1, 0x1, 0x1, 0x1} /* 148Mhz */ -}; - -static const u8 TXDIV[3][4] = { - {0x3, 0x3, 0x3, 0x2}, /* 27Mhz */ - {0x2, 0x1, 0x1, 0x1}, /* 74Mhz */ - {0x1, 0x0, 0x0, 0x0} /* 148Mhz */ -}; - -static const u8 FBKSEL[3][4] = { - {0x1, 0x1, 0x1, 0x1}, /* 27Mhz */ - {0x1, 0x0, 0x1, 0x1}, /* 74Mhz */ - {0x1, 0x0, 0x1, 0x1} /* 148Mhz */ -}; - -static const u8 FBKDIV[3][4] = { - {19, 24, 29, 19}, /* 27Mhz */ - {19, 24, 14, 19}, /* 74Mhz */ - {19, 24, 14, 19} /* 148Mhz */ -}; - -static const u8 DIVEN[3][4] = { - {0x2, 0x1, 0x1, 0x2}, /* 27Mhz */ - {0x2, 0x2, 0x2, 0x2}, /* 74Mhz */ - {0x2, 0x2, 0x2, 0x2} /* 148Mhz */ -}; - -static const u8 HTPLLBP[3][4] = { - {0xc, 0xc, 0x8, 0xc}, /* 27Mhz */ - {0xc, 0xf, 0xf, 0xc}, /* 74Mhz */ - {0xc, 0xf, 0xf, 0xc} /* 148Mhz */ -}; - -static const u8 HTPLLBC[3][4] = { - {0x2, 0x3, 0x3, 0x2}, /* 27Mhz */ - {0x2, 0x3, 0x3, 0x2}, /* 74Mhz */ - {0x2, 0x3, 0x3, 0x2} /* 148Mhz */ -}; - -static const u8 HTPLLBR[3][4] = { - {0x1, 0x1, 0x0, 0x1}, /* 27Mhz */ - {0x1, 0x2, 0x2, 0x1}, /* 74Mhz */ - {0x1, 0x2, 0x2, 0x1} /* 148Mhz */ -}; - static int mtk_hdmi_pll_prepare(struct clk_hw *hw) { struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw); -- 2.26.2

2 2

[PATCH] drm/mediatek: Delete not used of_device_get_match_data
by matthias.bgg＠kernel.org 04 Jul '20

04 Jul '20

From: Matthias Brugger <matthias.bgg(a)gmail.com> The driver will be loaded by via a platform device. So we will need to get the device_node from the parent device. Depending on this we will set the driver data. As all this is done later already, just delete the call to of_device_get_match_data. Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com> --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index e2bb0d19ef99..63ec92ba0e92 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -447,7 +447,6 @@ static int mtk_drm_probe(struct platform_device *pdev) if (!private) return -ENOMEM; - private->data = of_device_get_match_data(dev); private->mmsys_dev = dev->parent; if (!private->mmsys_dev) { dev_err(dev, "Failed to get MMSYS device\n"); -- 2.26.2

3 3

DSI probe/bind ordering in vc4
by Maxime Ripard 03 Jul '20

03 Jul '20

Hi, I've tried to bring-up the DSI controller on the RaspberryPi4, and I've just encountered something that could make it troublesome to support. For context, the RaspberryPi has an official panel that uses a DSI->DPI bridge, a DPI panel, a touchscreen and a small micro-controller. That microcontroller controls the power management on the screen, so communicating with it is very much needed, and it's done through an i2c bus. To reflect that, the entire panel has been described in the Device Tree as an I2C device (since that's how you would control it), together with an OF-Graph endpoint linking that i2c device to the DSI controller[1]. That deviates a bit from the generic DSI binding though[2], since it requires that the panel should be a subnode of the DSI controller (which also makes sense since DCS commands is usually how you would control that device). This is where the trouble begins. Since the two devices are on entirely different buses, there's basically no guarantee on the probe order. The driver has tried to address this by using the OF-Graph and the component framework. Indeed, the DSI driver (component-based) will register a MIPI-DSI host in its probe, and call component_add[3]. If component_add fails, it will remove the DSI host and return the error code. It makes sense. The panel on the other hand will probe, and look for a DSI host through the OF-Graph [4]. If it isn't there, it will return EPROBE_DEFER, hoping that it will be available at some point. It also makes complete sense. Where the issue lies is that component_add has two very different behaviours here that will create the bug that we see on the RPi4: - If there's still components to probe, component_add will simply return 0 [5][6] - And if we're the last component to probe, component_add will then run all the bind callbacks and return the result on error of the master bind callback[7]. That master bind will usually have component_bind_all that will return the result of the bind callback of each component. Now, on the RPi4, the last component to probe is the DSI controller since it relies on a power-domain exposed by the firmware driver, so the driver core will defer its probe function until the power-domain is there [8]. We're thus pretty much guaranteed to fall in the second case above and run through all the bind callbacks. The DSI bind callback however will try to find and attach its panel, and return EPROBE_DEFER if it doesn't find it[9]. That error will then be propagated to the return code of component_bind_all, then to the master bind callback, and finally will be the return code of component_add. And since component_add is failing, we remove the DSI host. Since the DSI host isn't there, on the next occasion the i2c panel driver will not probe either, and we enter a loop that cannot really be broken, since one depends on the other. This was working on the RPi3 because the DSI is not the last driver to probe: indeed the v3d is depending on the same power domain[10][11] and is further down the list of components to add in the driver [12], so we're always in the first component_add case for DSI above, the DSI host sticks around, and the i2c driver can probe. I'm not entirely sure how we can fix that though. I guess the real flaw here is the assumption that component_add will not fail if one of the bind fails, which isn't true, but we can't really ignore those errors either since it might be something else than DSI that returns that error. One way to work around it is to make the mailbox, firmware and power domain drivers probe earlier by tweaking the initcalls at which they register, but it's not really fixing anything and compiling them as module would make it broken again. Maxime 1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc… 2: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc… 3: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… 4: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… 5: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… 6: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… 7: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… 8: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… 9: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… 10: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arc… 11: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arc… 12: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri…

2 2

[PATCH 1/2] drm/msm: Garbage collect unused resource _len fields.
by Eric Anholt 03 Jul '20

03 Jul '20

Nothing was using the lengths of these ioremaps. Signed-off-by: Eric Anholt <eric(a)anholt.net> --- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 21 --------------------- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 9 --------- 3 files changed, 31 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c index 680527e28d09..a4ab802fee6d 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c @@ -45,20 +45,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms); static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms); -static unsigned long dpu_iomap_size(struct platform_device *pdev, - const char *name) -{ - struct resource *res; - - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name); - if (!res) { - DRM_ERROR("failed to get memory resource: %s\n", name); - return 0; - } - - return resource_size(res); -} - #ifdef CONFIG_DEBUG_FS static int _dpu_danger_signal_status(struct seq_file *s, bool danger_status) @@ -844,7 +830,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms) goto error; } DRM_DEBUG("mapped dpu address space @%pK\n", dpu_kms->mmio); - dpu_kms->mmio_len = dpu_iomap_size(dpu_kms->pdev, "mdp"); dpu_kms->vbif[VBIF_RT] = msm_ioremap(dpu_kms->pdev, "vbif", "vbif"); if (IS_ERR(dpu_kms->vbif[VBIF_RT])) { @@ -853,22 +838,16 @@ static int dpu_kms_hw_init(struct msm_kms *kms) dpu_kms->vbif[VBIF_RT] = NULL; goto error; } - dpu_kms->vbif_len[VBIF_RT] = dpu_iomap_size(dpu_kms->pdev, "vbif"); dpu_kms->vbif[VBIF_NRT] = msm_ioremap(dpu_kms->pdev, "vbif_nrt", "vbif_nrt"); if (IS_ERR(dpu_kms->vbif[VBIF_NRT])) { dpu_kms->vbif[VBIF_NRT] = NULL; DPU_DEBUG("VBIF NRT is not defined"); - } else { - dpu_kms->vbif_len[VBIF_NRT] = dpu_iomap_size(dpu_kms->pdev, - "vbif_nrt"); } dpu_kms->reg_dma = msm_ioremap(dpu_kms->pdev, "regdma", "regdma"); if (IS_ERR(dpu_kms->reg_dma)) { dpu_kms->reg_dma = NULL; DPU_DEBUG("REG_DMA is not defined"); - } else { - dpu_kms->reg_dma_len = dpu_iomap_size(dpu_kms->pdev, "regdma"); } pm_runtime_get_sync(&dpu_kms->pdev->dev); diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h index 4e32d040f1e6..13034cdb8665 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h @@ -100,7 +100,6 @@ struct dpu_kms { /* io/register spaces: */ void __iomem *mmio, *vbif[VBIF_MAX], *reg_dma; - unsigned long mmio_len, vbif_len[VBIF_MAX], reg_dma_len; struct regulator *vdd; struct regulator *mmagic; diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c index 80d3cfc14007..9f20b84d5c0a 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c @@ -37,7 +37,6 @@ struct dpu_mdss_hw_init_handler { struct dpu_mdss { struct msm_mdss base; void __iomem *mmio; - unsigned long mmio_len; struct dss_module_power mp; struct dpu_irq_controller irq_controller; struct icc_path *path[2]; @@ -292,7 +291,6 @@ int dpu_mdss_init(struct drm_device *dev) { struct platform_device *pdev = to_platform_device(dev->dev); struct msm_drm_private *priv = dev->dev_private; - struct resource *res; struct dpu_mdss *dpu_mdss; struct dss_module_power *mp; int ret = 0; @@ -308,13 +306,6 @@ int dpu_mdss_init(struct drm_device *dev) DRM_DEBUG("mapped mdss address space @%pK\n", dpu_mdss->mmio); - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mdss"); - if (!res) { - DRM_ERROR("failed to get memory resource for mdss\n"); - return -ENOMEM; - } - dpu_mdss->mmio_len = resource_size(res); - ret = dpu_mdss_parse_data_bus_icc_path(dev, dpu_mdss); if (ret) return ret; -- 2.26.2

3 3

[PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline
by Maxime Ripard 03 Jul '20

03 Jul '20

Hi everyone, Here's a (pretty long) series to introduce support in the VC4 DRM driver for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4). The main differences are that there's two HDMI controllers and that there's more pixelvalve now. Those pixelvalve come with a mux in the HVS that still have only 3 FIFOs. Both of those differences are breaking a bunch of expectations in the driver, so we first need a good bunch of cleanup and reworks to introduce support for the new controllers. Similarly, the HDMI controller has all its registers shuffled and split in multiple controllers now, so we need a bunch of changes to support this as well. Only the HDMI support is enabled for now (even though the DPI output has been tested too). There's a couple of rough edges still that should be addressed in the next versions: - After a modeset, it's likely that the pixels will be shifted by one. - Dual output doesn't work - The transposer (and thus writeback) doesn't work either and conflicts with the output mux too. Let me know if you have any comments Maxime Cc: bcm-kernel-feedback-list(a)broadcom.com Cc: devicetree(a)vger.kernel.org Cc: Kamal Dasu <kdasu.kdev(a)gmail.com> Cc: linux-clk(a)vger.kernel.org Cc: linux-i2c(a)vger.kernel.org Cc: Michael Turquette <mturquette(a)baylibre.com> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: Stephen Boyd <sboyd(a)kernel.org> Cc: Wolfram Sang <wsa(a)the-dreams.de> Changes from v1: - Rebased on top of 5.7-rc1 - Run checkpatch - Added audio support - Fixed some HDMI timeouts - Swiched to clk_hw_register_gate_parent_data - Reorder Kconfig symbols in drivers/i2c/busses - Make the firmware clocks a child of the firmware node - Switch DVP clock driver to clk_hw interface - constify raspberrypi_clk_data in raspberrypi_clock_property - Don't mark firmware clocks as IGNORE_UNUSED - Change from reset_ms to reset_us in reset-simple, and add a bit more comments - Remove generic clk patch to test if a NULL pointer is returned - Removed misleading message in the is_prepared renaming patch commit message - Constify HDMI controller variants - Fix a bug in the allocation size of the clk data array - Added a mention in the DT binding conversion patches about the breakage - Merged a few fixes from kbuild - Fixed a few bisection and CEC build issues - Collected Acked-by and Reviewed-by - Change Dave email address to raspberrypi.com Dave Stevenson (6): drm/vc4: Add support for the BCM2711 HVS5 drm/vc4: plane: Improve LBM usage drm/vc4: hdmi: Use reg-names to retrieve the HDMI audio registers drm/vc4: hdmi: Reset audio infoframe on encoder_enable if previously streaming drm/vc4: hdmi: Set the b-frame marker to the match ALSA's default. drm/vc4: hdmi: Add audio-related callbacks Florian Fainelli (1): dt-bindings: arm: bcm: Convert BCM2835 firmware binding to YAML Maxime Ripard (84): i2c: brcmstb: Allow to compile it on BCM2835 dt-bindings: clock: Add a binding for the RPi Firmware clocks firmware: rpi: Only create clocks device if we don't have a node for it clk: bcm: rpi: Allow the driver to be probed by DT clk: bcm: rpi: Statically init clk_init_data clk: bcm: rpi: Use clk_hw_register for pllb_arm clk: bcm: rpi: Remove global pllb_arm clock pointer clk: bcm: rpi: Make sure pllb_arm is removed clk: bcm: rpi: Remove pllb_arm_lookup global pointer clk: bcm: rpi: Switch to clk_hw_register_clkdev clk: bcm: rpi: Make sure the clkdev lookup is removed clk: bcm: rpi: Create a data structure for the clocks clk: bcm: rpi: Add clock id to data clk: bcm: rpi: Pass the clocks data to the firmware function clk: bcm: rpi: Rename is_prepared function clk: bcm: rpi: Split pllb clock hooks clk: bcm: rpi: Make the PLLB registration function return a clk_hw clk: bcm: rpi: Add DT provider for the clocks clk: bcm: rpi: Discover the firmware clocks ARM: dts: bcm2711: Add firmware clocks node reset: Move reset-simple header out of drivers/reset reset: simple: Add reset callback dt-bindings: clock: Add BCM2711 DVP binding clk: bcm: Add BCM2711 DVP driver ARM: dts: bcm2711: Add HDMI DVP dt-bindings: display: Convert VC4 bindings to schemas dt-bindings: display: vc4: dpi: Add missing clock-names property dt-bindings: display: vc4: dsi: Add missing clock properties dt-bindings: display: vc4: hdmi: Add missing clock-names property dt-bindings: display: vc4: Document BCM2711 VC5 drm/vc4: drv: Add include guards drm/vc4: drv: Support BCM2711 dt-bindings: display: Add support for the BCM2711 HVS drm/vc4: hvs: Boost the core clock during modeset drm/vc4: plane: Move planes creation to its own function drm/vc4: plane: Move additional planes creation to driver drm/vc4: plane: Register all the planes at once drm/vc4: plane: Create overlays for any CRTC drm/vc4: plane: Create more planes drm/vc4: crtc: Rename SoC data structures drm/vc4: crtc: Move crtc state to common header drm/vc4: crtc: Deal with different number of pixel per clock drm/vc4: crtc: Use a shared interrupt drm/vc4: crtc: Turn static const variable into a define drm/vc4: crtc: Move the cob allocation outside of bind drm/vc4: crtc: Rename HVS channel to output drm/vc4: crtc: Use local chan variable drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable drm/vc4: crtc: Assign output to channel automatically drm/vc4: crtc: Add FIFO depth to vc4_crtc_data drm/vc4: crtc: Add function to compute FIFO level bits drm/vc4: crtc: Rename HDMI encoder type to HDMI0 drm/vc4: crtc: Add HDMI1 encoder type drm/vc4: crtc: Remove redundant call to drm_crtc_enable_color_mgmt drm/vc4: crtc: Disable color management for HVS5 dt-bindings: display: vc4: pv: Add BCM2711 pixel valves drm/vc4: crtc: Add BCM2711 pixelvalves drm/vc4: hdmi: Use debugfs private field drm/vc4: hdmi: Move structure to header drm/vc4: hdmi: rework connectors and encoders drm/vc4: hdmi: Remove DDC argument to connector_init drm/vc4: hdmi: Rename hdmi to vc4_hdmi drm/vc4: hdmi: Move accessors to vc4_hdmi drm/vc4: hdmi: Use local vc4_hdmi directly drm/vc4: hdmi: Add container_of macros for encoders and connectors drm/vc4: hdmi: Pass vc4_hdmi to CEC code drm/vc4: hdmi: Remove vc4_dev hdmi pointer drm/vc4: hdmi: Remove vc4_hdmi_connector drm/vc4: hdmi: Introduce resource init and variant drm/vc4: hdmi: Implement a register layout abstraction drm/vc4: hdmi: Add reset callback drm/vc4: hdmi: Add PHY init and disable function drm/vc4: hdmi: Add PHY RNG enable / disable function drm/vc4: hdmi: Add a CSC setup callback drm/vc4: hdmi: Store the encoder type in the variant structure drm/vc4: hdmi: Deal with multiple debugfs files drm/vc4: hdmi: Move CEC init to its own function drm/vc4: hdmi: Add CEC support flag drm/vc4: hdmi: Remove unused CEC_CLOCK_DIV define drm/vc4: hdmi: Rename drm_encoder pointer in mode_valid drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate drm/vc4: hdmi: Support the BCM2711 HDMI controllers dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings ARM: dts: bcm2711: Enable the display pipeline Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt | 14 +- Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 59 +++- Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml | 47 ++- Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 174 +-------- Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109 +++++- Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml | 72 +++- Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml | 84 ++++- Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml | 80 ++++- Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml | 53 ++- Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml | 45 ++- Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml | 37 ++- Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml | 42 ++- Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml | 35 ++- Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml | 44 ++- MAINTAINERS | 2 +- arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 51 ++- arch/arm/boot/dts/bcm2711.dtsi | 130 +++++- drivers/clk/bcm/Kconfig | 1 +- drivers/clk/bcm/Makefile | 1 +- drivers/clk/bcm/clk-bcm2711-dvp.c | 127 ++++++- drivers/clk/bcm/clk-raspberrypi.c | 280 +++++++++---- drivers/firmware/raspberrypi.c | 17 +- drivers/gpu/drm/vc4/Makefile | 1 +- drivers/gpu/drm/vc4/vc4_crtc.c | 328 +++++++++------ drivers/gpu/drm/vc4/vc4_drv.c | 5 +- drivers/gpu/drm/vc4/vc4_drv.h | 58 ++- drivers/gpu/drm/vc4/vc4_hdmi.c | 1536 ++++++++++++++++++++++++++++++++++++++++++------------------------------ drivers/gpu/drm/vc4/vc4_hdmi.h | 179 ++++++++- drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 508 ++++++++++++++++++++++++- drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 451 +++++++++++++++++++++- drivers/gpu/drm/vc4/vc4_hvs.c | 25 +- drivers/gpu/drm/vc4/vc4_kms.c | 181 +++++++- drivers/gpu/drm/vc4/vc4_plane.c | 271 +++++++++---- drivers/gpu/drm/vc4/vc4_regs.h | 173 +++----- drivers/i2c/busses/Kconfig | 4 +- drivers/reset/reset-simple.c | 27 +- drivers/reset/reset-simple.h | 41 +-- drivers/reset/reset-socfpga.c | 3 +- drivers/reset/reset-sunxi.c | 3 +- drivers/reset/reset-uniphier-glue.c | 3 +- include/linux/reset/reset-simple.h | 47 ++- include/soc/bcm2835/raspberrypi-firmware.h | 5 +- 42 files changed, 4109 insertions(+), 1244 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml delete mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml create mode 100644 drivers/clk/bcm/clk-bcm2711-dvp.c create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.h create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi_phy.c create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi_regs.h delete mode 100644 drivers/reset/reset-simple.h create mode 100644 include/linux/reset/reset-simple.h base-commit: cb3692197b5da2fb898335eec1640db14d92e52e -- git-series 0.9.1

11 141

[Bug 208179] New: [amdgpu] black screen after exiting X
by bugzilla-daemon＠bugzilla.kernel.org 03 Jul '20

03 Jul '20

https://bugzilla.kernel.org/show_bug.cgi?id=208179 Bug ID: 208179 Summary: [amdgpu] black screen after exiting X Product: Drivers Version: 2.5 Kernel Version: 5.7.2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: shlomo(a)fastmail.com CC: daniel(a)ffwll.ch, dri-devel(a)lists.freedesktop.org Regression: Yes After exiting X on a virtual terminal that isn't tty1, the screen becomes all black instead of showing the text tty. Keyboard input still goes to the text tty, but I can't see what I'm typing. After this happens, a workaround is to switch to a different virtual terminal (with Ctrl+Alt+FN) that is in text mode (not running X) and then switch back. Then the text tty is visible and works normally. Switching to a different virtual terminal that is running X and then switching back doesn't help. The problematic virtual terminal is still all black. My graphics card is Gigabyte Radeon RX VEGA 56 GAMING OC 8G. (amdgpu) The bug appeared after upgrading Arch linux 5.6.15.arch1-1 to 5.7.2.arch1-1. The first bad commit is 64914da24ea95d2b2f7017d014d74c26005d8780 (drm/fbdev-helper: don't force restores). The previous commit e81a2557e0650ee0ce37ba14476ddb709d6daf57 is good. When testing these two commits, I needed to cherry-pick the following fixes: a9a3ed1eff3601b63aea4fb462d8b3b92c7c1e7e (x86: Fix early boot crash on gcc-10, third try) e33a814e772cdc36436c8c188d8c42d019fda639 (scripts/dtc: Remove redundant YYLOC global declaration) df6d4f9db79c1a5d6f48b59db35ccd1e9ff9adfc (x86/boot/compressed: Don't declare __force_order in kaslr_64.c) These are needed when compiling with GCC 10 to fix compilation errors and a hang on boot. -- You are receiving this mail because: You are on the CC list for the bug. You are watching the assignee of the bug.

1 5

[PATCH v4 00/37] Introduce memory interconnect for NVIDIA Tegra SoCs
by Dmitry Osipenko 03 Jul '20

03 Jul '20

Hello, This series brings initial support for memory interconnect to Tegra20 and Tegra30 SoCs. For the starter only display controllers are getting interconnect API support, others could be supported later on. The display controllers have the biggest demand for interconnect API right now because dynamic memory frequency scaling can't be done safely without taking into account bandwidth requirement from the displays. Changelog: v4: - All drivers that use interconnect API now select it in the Kconfig in order to properly express the build dependency. - The IS_ENABLED(CONFIG_INTERCONNECT) is dropped now from all patches. - Added MODULE_AUTHOR() to the modularized drivers, for completeness. - Added missed TEGRA_MC Kconfig dependency for the Tegra20 EMC driver. - Added more acks from Rob Herring that I accidentally missed to add in v3. v3: - Added acks from Rob Herring that were given to some of the v2 patches. - Specified name of the TRM documentation chapter in the patch "dt-bindings: host1x: Document new interconnect properties", which was suggested by Rob Herring in the review comment to v2. - Added patches that allow EMC drivers to be compiled as a loadable kernel modules. This came up during of the v2 review when Georgi Djakov pointed out that interconnect-core could be compiled as a kernel module. Please note that the Tegra124 EMC driver is compile-tested only, I don't have Tegra124 HW. - In the review comment to [1] Stephen Boyd suggested that it will be better not to make changes to clk API, which was needed in order to avoid clashing of the interconnect driver with the devfreq in regards to memory clk-rate rounding. [1] https://patchwork.ozlabs.org/project/linux-tegra/patch/20200330231617.17079… Stephen Boyd suggested that instead we should provide OPP table via DT. I tried to investigate whether this could be done and turned out it's a bit complicated. Technically it should be doable, but: 1. For now we don't fully support voltage scaling of the CORE regulator and so OPP table in the DT isn't really needed today. We can generate table from the memory timings, which is what Tegra devfreq drivers already do. 2. The OPP table should be defined in the DT for the Memory Controller node and then its usage somehow should be shared by both interconnect and devfreq drivers. It's not obvious what's the best way to do it. So, it will be much better to postpone the DT OPP table addition until these questions are resolved. We can infer OPPs from the memory timings and we could get the memory rates from the memory driver directly, avoiding the problems induced by the clk API usage. This idea is implemented in v3, see these patches: PM / devfreq: tegra20: Use MC timings for building OPP table PM / devfreq: tegra30: Use MC timings for building OPP table v2: - Instead of a single dma-mem interconnect path, the paths are now defined per memory client. - The EMC provider now uses #interconnect-cells=<0>. - Dropped Tegra124 because there is no enough information about how to properly calculate required EMC clock rate for it and I don't have hardware for testing. Somebody else will have to work on it. - Moved interconnect providers code into drivers/memory/tegra/*. - Added "Create tegra20-devfreq device" patch because interconnect is not very usable without the devfreq memory auto-scaling since memory freq will be fixed to the display's requirement. Artur Świgoń (1): interconnect: Relax requirement in of_icc_get_from_provider() Dmitry Osipenko (36): clk: Export clk_hw_reparent() clk: tegra: Remove Memory Controller lock clk: tegra: Export Tegra20 EMC kernel symbols memory: tegra20-emc: Make driver modular memory: tegra30-emc: Make driver modular memory: tegra124-emc: Make driver modular memory: tegra124-emc: Use devm_platform_ioremap_resource soc/tegra: fuse: Export tegra_read_ram_code() memory: tegra20-emc: Initialize MC timings PM / devfreq: tegra20: Silence deferred probe error PM / devfreq: tegra30: Silence deferred probe error PM / devfreq: tegra20: Use MC timings for building OPP table PM / devfreq: tegra30: Use MC timings for building OPP table PM / devfreq: tegra20: Add error messages to tegra_devfreq_target() PM / devfreq: tegra30: Add error messages to tegra_devfreq_target() PM / devfreq: tegra20: Adjust clocks conversion ratio and polling interval PM / devfreq: tegra20: Relax Kconfig dependency dt-bindings: memory: tegra20: mc: Document new interconnect property dt-bindings: memory: tegra20: emc: Document new interconnect property dt-bindings: memory: tegra30: mc: Document new interconnect property dt-bindings: memory: tegra30: emc: Document new interconnect property dt-bindings: host1x: Document new interconnect properties dt-bindings: memory: tegra20: Add memory client IDs dt-bindings: memory: tegra30: Add memory client IDs ARM: tegra: Add interconnect properties to Tegra20 device-tree ARM: tegra: Add interconnect properties to Tegra30 device-tree memory: tegra: Register as interconnect provider memory: tegra20-emc: Use devm_platform_ioremap_resource memory: tegra20-emc: Continue probing if timings are missing in device-tree memory: tegra20-emc: Register as interconnect provider memory: tegra20-emc: Create tegra20-devfreq device memory: tegra30-emc: Continue probing if timings are missing in device-tree memory: tegra30-emc: Register as interconnect provider drm/tegra: dc: Support memory bandwidth management drm/tegra: dc: Tune up high priority request controls for Tegra20 drm/tegra: dc: Extend debug stats with total number of events .../display/tegra/nvidia,tegra20-host1x.txt | 68 +++++ .../memory-controllers/nvidia,tegra20-emc.txt | 2 + .../memory-controllers/nvidia,tegra20-mc.txt | 3 + .../nvidia,tegra30-emc.yaml | 6 + .../memory-controllers/nvidia,tegra30-mc.yaml | 5 + arch/arm/boot/dts/tegra20.dtsi | 22 +- arch/arm/boot/dts/tegra30.dtsi | 23 +- drivers/clk/clk.c | 1 + drivers/clk/tegra/clk-divider.c | 4 +- drivers/clk/tegra/clk-tegra114.c | 6 +- drivers/clk/tegra/clk-tegra124-emc.c | 63 ++-- drivers/clk/tegra/clk-tegra124.c | 8 +- drivers/clk/tegra/clk-tegra20-emc.c | 3 + drivers/clk/tegra/clk-tegra20.c | 3 +- drivers/clk/tegra/clk-tegra30.c | 3 +- drivers/clk/tegra/clk.h | 14 +- drivers/devfreq/Kconfig | 2 +- drivers/devfreq/tegra20-devfreq.c | 52 ++-- drivers/devfreq/tegra30-devfreq.c | 115 +++++-- drivers/gpu/drm/tegra/Kconfig | 1 + drivers/gpu/drm/tegra/dc.c | 289 +++++++++++++++++- drivers/gpu/drm/tegra/dc.h | 13 + drivers/gpu/drm/tegra/drm.c | 19 ++ drivers/gpu/drm/tegra/plane.c | 1 + drivers/gpu/drm/tegra/plane.h | 4 +- drivers/interconnect/core.c | 11 +- drivers/memory/tegra/Kconfig | 9 +- drivers/memory/tegra/mc.c | 117 +++++++ drivers/memory/tegra/mc.h | 8 + drivers/memory/tegra/tegra124-emc.c | 36 ++- drivers/memory/tegra/tegra20-emc.c | 215 +++++++++++-- drivers/memory/tegra/tegra30-emc.c | 156 ++++++++-- drivers/soc/tegra/fuse/tegra-apbmisc.c | 2 + include/dt-bindings/memory/tegra20-mc.h | 53 ++++ include/dt-bindings/memory/tegra30-mc.h | 67 ++++ include/linux/clk/tegra.h | 11 + include/soc/tegra/emc.h | 16 - include/soc/tegra/mc.h | 3 + 38 files changed, 1235 insertions(+), 199 deletions(-) delete mode 100644 include/soc/tegra/emc.h -- 2.26.0

4 61

← Newer
1
...
17
18
19
20
21
22
23
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2020