[PATCH] [RFC] drm/i915: make object creation avoid regions layering.
From: Dave Airlie
This looked like indirect ptr for not much reason in the create
object path, I just wonder why it couldn't be simpler like this,
The tests aren't cleaned up but this was more of is this a good idea
test patch.
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 16 ---
drivers/gpu/drm/i915/gem/i915_gem_region.c | 33 +-
drivers/gpu/drm/i915/gem/i915_gem_region.h | 6 ++--
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 22 ++-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 24 ++--
drivers/gpu/drm/i915/i915_gem.c| 29 ---
drivers/gpu/drm/i915/intel_memory_region.h | 5
drivers/gpu/drm/i915/intel_region_lmem.c | 1 -
8 files changed, 50 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 932ee21e6609..710fb1158904 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -27,18 +27,14 @@ i915_gem_object_create_lmem(struct drm_i915_private *i915,
resource_size_t size,
unsigned int flags)
{
- return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM],
-size, flags);
-}
-
-struct drm_i915_gem_object *
-__i915_gem_lmem_object_create(struct intel_memory_region *mem,
- resource_size_t size,
- unsigned int flags)
-{
+ struct intel_memory_region *mem = i915->mm.regions[INTEL_REGION_LMEM];
static struct lock_class_key lock_class;
- struct drm_i915_private *i915 = mem->i915;
struct drm_i915_gem_object *obj;
+ int ret;
+
+ ret = i915_gem_object_pre_check(mem, , flags);
+ if (ret)
+ return ERR_PTR(ret);
obj = i915_gem_object_alloc();
if (!obj)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index 1515384d7e0e..0902b3790e70 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -133,13 +133,12 @@ void i915_gem_object_release_memory_region(struct
drm_i915_gem_object *obj)
intel_memory_region_put(mem);
}
-struct drm_i915_gem_object *
-i915_gem_object_create_region(struct intel_memory_region *mem,
- resource_size_t size,
+int i915_gem_object_pre_check(struct intel_memory_region *mem,
+ resource_size_t *size,
unsigned int flags)
{
- struct drm_i915_gem_object *obj;
+ GEM_BUG_ON(!is_power_of_2(mem->min_page_size));
/*
* NB: Our use of resource_size_t for the size stems from using struct
* resource for the mem->region. We might need to revisit this in the
@@ -148,13 +147,13 @@ i915_gem_object_create_region(struct intel_memory_region
*mem,
GEM_BUG_ON(flags & ~I915_BO_ALLOC_FLAGS);
- if (!mem)
- return ERR_PTR(-ENODEV);
+ *size = round_up(*size, mem->min_page_size);
+ if (*size == 0)
+ return -EINVAL;
- size = round_up(size, mem->min_page_size);
-
- GEM_BUG_ON(!size);
- GEM_BUG_ON(!IS_ALIGNED(size, I915_GTT_MIN_ALIGNMENT));
+ /* For most of the ABI (e.g. mmap) we think in system pages */
+ GEM_BUG_ON(!IS_ALIGNED(*size, PAGE_SIZE));
+ GEM_BUG_ON(!IS_ALIGNED(*size, I915_GTT_MIN_ALIGNMENT));
/*
* XXX: There is a prevalence of the assumption that we fit the
@@ -163,15 +162,11 @@ i915_gem_object_create_region(struct intel_memory_region
*mem,
* spot such a local variable, please consider fixing!
*/
- if (size >> PAGE_SHIFT > INT_MAX)
- return ERR_PTR(-E2BIG);
-
- if (overflows_type(size, obj->base.size))
- return ERR_PTR(-E2BIG);
+ if (*size >> PAGE_SHIFT > INT_MAX)
+ return -E2BIG;
- obj = mem->ops->create_object(mem, size, flags);
- if (!IS_ERR(obj))
- trace_i915_gem_object_create(obj);
+ if (overflows_type(*size, size_t))
+ return -E2BIG;
- return obj;
+ return 0;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.h
b/drivers/gpu/drm/i915/gem/i915_gem_region.h
index f2ff6f8bff74..584f3e91060c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.h
@@ -21,9 +21,7 @@ void i915_gem_object_init_memory_region(struct
drm_i915_gem_object *obj,
unsigned long flags);
void i915_gem_object_release_memory_region(struct drm_i915_gem_object *obj);
-struct drm_i915_gem_object *
-i915_gem_object_create_region(struct intel_memory_region *mem,
- resource_size_t size,
+int i915_gem_object_pre_check(struct intel_memory_region *mem,
+
[PATCH v2 1/4] clk: bcm: rpi: Add register to control pixel bvb clk
To use QHD or higher, we need to modify the pixel_bvb_clk value. So add register to control this clock. Signed-off-by: Hoegeun Kwon --- drivers/clk/bcm/clk-raspberrypi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c index 5cc82954e1ce..f89b9cfc4309 100644 --- a/drivers/clk/bcm/clk-raspberrypi.c +++ b/drivers/clk/bcm/clk-raspberrypi.c @@ -271,6 +271,7 @@ static int raspberrypi_discover_clocks(struct raspberrypi_clk *rpi, case RPI_FIRMWARE_CORE_CLK_ID: case RPI_FIRMWARE_M2MC_CLK_ID: case RPI_FIRMWARE_V3D_CLK_ID: + case RPI_FIRMWARE_PIXEL_BVB_CLK_ID: hw = raspberrypi_clk_register(rpi, clks->parent, clks->id); if (IS_ERR(hw)) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] ARM: dts: bcm2711: Add bvb clock for hdmi-pixel
It is necessary to control the hdmi pixel bvb clock. Add bvb clock.
Signed-off-by: Hoegeun Kwon
---
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index b93eb30e1ddb..90dee4cb38bc 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -172,12 +172,14 @@
};
{
- clocks = <_clocks 13>, < 0>;
+ clocks = <_clocks 13>, < 0>, <_clocks 14>;
+ clock-names = "hdmi", "clk-108M", "bvb";
status = "okay";
};
{
- clocks = <_clocks 13>, < 1>;
+ clocks = <_clocks 13>, < 1>, <_clocks 14>;
+ clock-names = "hdmi", "clk-108M", "bvb";
status = "okay";
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] dt-bindings: display: vc4: hdmi: Add bvb clock-names property
When using a resolution exceeding FHD, bvb clock is required. Add bvb clock-names property. Signed-off-by: Hoegeun Kwon --- .../bindings/display/brcm,bcm2711-hdmi.yaml | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml index 6091fe3d315b..08cdcc579cf5 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml @@ -40,10 +40,14 @@ properties: - const: hd clocks: -description: The HDMI state machine clock +items: + - description: The HDMI state machine clock + - description: The bvb clock clock-names: -const: hdmi +items: + - const: hdmi + - const: bvb ddc: allOf: @@ -100,8 +104,8 @@ examples: "csc", "cec", "hd"; -clocks = <_clocks 13>; -clock-names = "hdmi"; +clocks = <_clocks 13>, <_clocks 14>; +clock-names = "hdmi", "bvb"; resets = < 0>; ddc = <>; }; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] drm/vc4: Support HDMI QHD or higher output
Hi everyone, There is a problem that the output does not work at a resolution exceeding FHD. To solve this, we need to adjust the bvb clock at a resolution exceeding FHD. Rebased on top of next-20200708 and [1]. [1] : [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline (Maxime's patchset) Changes from v1: - Added dt-bindings documents - Change patch order, first fix driver and then device tree Hoegeun Kwon (4): clk: bcm: rpi: Add register to control pixel bvb clk drm/vc4: hdmi: Add pixel bvb clock control dt-bindings: display: vc4: hdmi: Add bvb clock-names property ARM: dts: bcm2711: Add bvb clock for hdmi-pixel .../bindings/display/brcm,bcm2711-hdmi.yaml | 12 ++--- arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 +++-- drivers/clk/bcm/clk-raspberrypi.c | 1 + drivers/gpu/drm/vc4/vc4_hdmi.c| 25 +++ drivers/gpu/drm/vc4/vc4_hdmi.h| 1 + 5 files changed, 39 insertions(+), 6 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/vc4: hdmi: Add pixel bvb clock control
There is a problem that the output does not work at a resolution
exceeding FHD. To solve this, we need to adjust the bvb clock at a
resolution exceeding FHD.
Signed-off-by: Hoegeun Kwon
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 95ec5eedea39..eb3192d1fd86 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -80,6 +80,7 @@
# define VC4_HD_M_ENABLE BIT(0)
#define CEC_CLOCK_FREQ 4
+#define VC4_HSM_MID_CLOCK 149985000
static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
{
@@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct
drm_encoder *encoder)
HDMI_WRITE(HDMI_VID_CTL,
HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
+ clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
clk_disable_unprepare(vc4_hdmi->hsm_clock);
clk_disable_unprepare(vc4_hdmi->pixel_clock);
@@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder)
return;
}
+ ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
+ (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
+ if (ret) {
+ DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
+ clk_disable_unprepare(vc4_hdmi->hsm_clock);
+ clk_disable_unprepare(vc4_hdmi->pixel_clock);
+ return;
+ }
+
+ ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
+ if (ret) {
+ DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
+ clk_disable_unprepare(vc4_hdmi->hsm_clock);
+ clk_disable_unprepare(vc4_hdmi->pixel_clock);
+ return;
+ }
+
if (vc4_hdmi->variant->reset)
vc4_hdmi->variant->reset(vc4_hdmi);
@@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
*vc4_hdmi)
return PTR_ERR(vc4_hdmi->audio_clock);
}
+ vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
+ if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
+ DRM_ERROR("Failed to get pixel bvb clock\n");
+ return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
+ }
+
vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
if (IS_ERR(vc4_hdmi->reset)) {
DRM_ERROR("Failed to get HDMI reset line\n");
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 0806c6d9f24e..63c6f8bddf1d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -147,6 +147,7 @@ struct vc4_hdmi {
struct clk *pixel_clock;
struct clk *hsm_clock;
struct clk *audio_clock;
+ struct clk *pixel_bvb_clock;
struct reset_control *reset;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208373] drm:drm_atomic_helper_wait_for_dependencies - drm_kms_helper - flip_done timed out
https://bugzilla.kernel.org/show_bug.cgi?id=208373 --- Comment #3 from Lucas (l.sym...@live.com) --- (In reply to Alex Deucher from comment #1) > If this is a regression between 5.7.2 and 5.7.0, can you bisect? How do you Bisect? I can try doing that if it helps. Also, kernel 8.5.3-2 seemed to solve the issue for me but it will still happen if I leave the screens off for over 24 hours then power them back on. That's better than just powering them off overnight and having it happen. -- 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 v9 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge
Hi Swapnil,
Thank you for the patch.
On Mon, Aug 31, 2020 at 10:23:34AM +0200, Swapnil Jakhade wrote:
> Add a new DRM bridge driver for Cadence MHDP8546 DPTX IP used in TI J721E
> SoC. MHDP DPTX IP is the component that complies with VESA DisplayPort (DP)
> and embedded Display Port (eDP) standards. It integrates uCPU running the
> embedded Firmware (FW) interfaced over APB interface.
>
> Basically, it takes a DPI stream as input and outputs it encoded in DP
> format. Currently, it supports only SST mode.
>
> Co-developed-by: Tomi Valkeinen
> Signed-off-by: Tomi Valkeinen
> Co-developed-by: Jyri Sarha
> Signed-off-by: Jyri Sarha
> Signed-off-by: Quentin Schulz
> Signed-off-by: Yuti Amonkar
> Signed-off-by: Swapnil Jakhade
> ---
> drivers/gpu/drm/bridge/Kconfig|2 +
> drivers/gpu/drm/bridge/Makefile |1 +
> drivers/gpu/drm/bridge/cadence/Kconfig| 11 +
> drivers/gpu/drm/bridge/cadence/Makefile |3 +
> .../drm/bridge/cadence/cdns-mhdp8546-core.c | 2548 +
> .../drm/bridge/cadence/cdns-mhdp8546-core.h | 402 +++
> 6 files changed, 2967 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/cadence/Kconfig
> create mode 100644 drivers/gpu/drm/bridge/cadence/Makefile
> create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3e11af4e9f63..ef91646441b1 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -241,6 +241,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
> source "drivers/gpu/drm/bridge/adv7511/Kconfig"
>
> +source "drivers/gpu/drm/bridge/cadence/Kconfig"
> +
> source "drivers/gpu/drm/bridge/synopsys/Kconfig"
>
> endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index c589a6a7cbe1..2b3aff104e46 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -25,4 +25,5 @@ obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
> obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
>
> obj-y += analogix/
> +obj-y += cadence/
> obj-y += synopsys/
> diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
> b/drivers/gpu/drm/bridge/cadence/Kconfig
> new file mode 100644
> index ..f49d77eb7814
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cadence/Kconfig
> @@ -0,0 +1,11 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config DRM_CDNS_MHDP8546
> + tristate "Cadence DPI/DP bridge"
> + select DRM_KMS_HELPER
> + select DRM_PANEL_BRIDGE
> + depends on OF
> + help
> + Support Cadence DPI to DP bridge. This is an internal
> + bridge and is meant to be directly embedded in a SoC.
> + It takes a DPI stream as input and outputs it encoded
> + in DP format.
> diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
> b/drivers/gpu/drm/bridge/cadence/Makefile
> new file mode 100644
> index ..676739cdf5e6
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cadence/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
> +cdns-mhdp8546-y := cdns-mhdp8546-core.o
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> new file mode 100644
> index ..14be6f370d6e
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -0,0 +1,2548 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Cadence MHDP8546 DP bridge driver.
> + *
> + * Copyright (C) 2020 Cadence Design Systems, Inc.
> + *
> + * Authors: Quentin Schulz
> + * Swapnil Jakhade
> + * Yuti Amonkar
> + * Tomi Valkeinen
> + * Jyri Sarha
> + *
> + * TODO:
> + * - Implement optimized mailbox communication using mailbox interrupts
> + * - Add support for power management
> + * - Add support for features like audio, MST and fast link training
> + * - Implement request_fw_cancel to handle HW_STATE
> + * - Fix asynchronous loading of firmware implementation
> + * - Add DRM helper function for cdns_mhdp_lower_link_rate
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "cdns-mhdp8546-core.h"
> +
> +static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
> +{
> + int ret, empty;
> +
> + WARN_ON(!mutex_is_locked(>mbox_mutex));
> +
> + ret = readx_poll_timeout(readl, mhdp->regs + CDNS_MAILBOX_EMPTY,
> + empty, !empty, MAILBOX_RETRY_US,
> +
[PATCH v7 3/4] drm/kmb: Mipi DSI part of the display driver
Initializes Mipi DSI and sets up connects to ADV bridge
v2: removed license text
upclassed dev_private, removed HAVE_IRQ. (Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
v5: corrected spellings
v6: corrected checkpatch warnings
v7: review changes Sam Ravnborg and Thomas Zimmerman
removed unnecessary logs and defines and ifdef codes (Sam)
split dphy_init_sequence smaller (Sam)
removed redundant checks in kmb_dsi (Sam)
changed kmb_dsi_init to drm_bridge_connector_init and
drm_connector_attach_encoder to bridge's connector (Sam)
Cc: Sam Ravnborg
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Bob Paauwe
---
drivers/gpu/drm/kmb/kmb_dsi.c | 1523 +
drivers/gpu/drm/kmb/kmb_dsi.h | 350 ++
2 files changed, 1873 insertions(+)
create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.c
create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.h
diff --git a/drivers/gpu/drm/kmb/kmb_dsi.c b/drivers/gpu/drm/kmb/kmb_dsi.c
new file mode 100644
index 000..a0dbfa7
--- /dev/null
+++ b/drivers/gpu/drm/kmb/kmb_dsi.c
@@ -0,0 +1,1523 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © 2019-2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "kmb_drv.h"
+#include "kmb_dsi.h"
+#include "kmb_regs.h"
+
+static struct mipi_dsi_host *dsi_host;
+static struct mipi_dsi_device *dsi_device;
+
+/* Default setting is 1080p, 4 lanes */
+#define IMG_HEIGHT_LINES 1080
+#define IMG_WIDTH_PX 1920
+#define MIPI_TX_ACTIVE_LANES 4
+
+struct mipi_tx_frame_section_cfg mipi_tx_frame0_sect_cfg = {
+ .width_pixels = IMG_WIDTH_PX,
+ .height_lines = IMG_HEIGHT_LINES,
+ .data_type = DSI_LP_DT_PPS_RGB888_24B,
+ .data_mode = MIPI_DATA_MODE1,
+ .dma_packed = 0
+};
+
+struct mipi_tx_frame_cfg mipitx_frame0_cfg = {
+ .sections[0] = _tx_frame0_sect_cfg,
+ .sections[1] = NULL,
+ .sections[2] = NULL,
+ .sections[3] = NULL,
+ .vsync_width = 5,
+ .v_backporch = 36,
+ .v_frontporch = 4,
+ .hsync_width = 44,
+ .h_backporch = 148,
+ .h_frontporch = 88
+};
+
+struct mipi_tx_dsi_cfg mipitx_dsi_cfg = {
+ .hfp_blank_en = 0,
+ .eotp_en = 0,
+ .lpm_last_vfp_line = 0,
+ .lpm_first_vsa_line = 0,
+ .sync_pulse_eventn = DSI_VIDEO_MODE_NO_BURST_EVENT,
+ .hfp_blanking = SEND_BLANK_PACKET,
+ .hbp_blanking = SEND_BLANK_PACKET,
+ .hsa_blanking = SEND_BLANK_PACKET,
+ .v_blanking = SEND_BLANK_PACKET,
+};
+
+struct mipi_ctrl_cfg mipi_tx_init_cfg = {
+ .active_lanes = MIPI_TX_ACTIVE_LANES,
+ .lane_rate_mbps = MIPI_TX_LANE_DATA_RATE_MBPS,
+ .ref_clk_khz = MIPI_TX_REF_CLK_KHZ,
+ .cfg_clk_khz = MIPI_TX_CFG_CLK_KHZ,
+ .tx_ctrl_cfg = {
+ .frames[0] = _frame0_cfg,
+ .frames[1] = NULL,
+ .frames[2] = NULL,
+ .frames[3] = NULL,
+ .tx_dsi_cfg = _dsi_cfg,
+ .line_sync_pkt_en = 0,
+ .line_counter_active = 0,
+ .frame_counter_active = 0,
+ .tx_always_use_hact = 1,
+ .tx_hact_wait_stop = 1,
+ }
+};
+
+struct mipi_hs_freq_range_cfg {
+ u16 default_bit_rate_mbps;
+ u8 hsfreqrange_code;
+};
+
+struct vco_params {
+ u32 freq;
+ u32 range;
+ u32 divider;
+};
+
+static struct vco_params vco_table[] = {
+ {52, 0x3f, 8},
+ {80, 0x39, 8},
+ {105, 0x2f, 4},
+ {160, 0x29, 4},
+ {210, 0x1f, 2},
+ {320, 0x19, 2},
+ {420, 0x0f, 1},
+ {630, 0x09, 1},
+ {1100, 0x03, 1},
+ {0x, 0x01, 1},
+};
+
+static struct mipi_hs_freq_range_cfg
+mipi_hs_freq_range[MIPI_DPHY_DEFAULT_BIT_RATES] = {
+ {.default_bit_rate_mbps = 80, .hsfreqrange_code = 0x00},
+ {.default_bit_rate_mbps = 90, .hsfreqrange_code = 0x10},
+ {.default_bit_rate_mbps = 100, .hsfreqrange_code = 0x20},
+ {.default_bit_rate_mbps = 110, .hsfreqrange_code = 0x30},
+ {.default_bit_rate_mbps = 120, .hsfreqrange_code = 0x01},
+ {.default_bit_rate_mbps = 130, .hsfreqrange_code = 0x11},
+ {.default_bit_rate_mbps = 140, .hsfreqrange_code = 0x21},
+ {.default_bit_rate_mbps = 150, .hsfreqrange_code = 0x31},
+ {.default_bit_rate_mbps = 160, .hsfreqrange_code = 0x02},
+ {.default_bit_rate_mbps = 170, .hsfreqrange_code = 0x12},
+ {.default_bit_rate_mbps = 180, .hsfreqrange_code = 0x22},
+ {.default_bit_rate_mbps = 190, .hsfreqrange_code = 0x32},
+ {.default_bit_rate_mbps = 205, .hsfreqrange_code = 0x03},
+ {.default_bit_rate_mbps = 220, .hsfreqrange_code = 0x13},
+
[PATCH v7 0/4] Add support for KeemBay DRM driver
This is a new DRM driver for Intel's KeemBay SOC. The SoC couples an ARM Cortex A53 CPU with an Intel Movidius VPU. This driver is tested with the KMB EVM board which is the refernce baord for Keem Bay SOC. The SOC's display pipeline is as follows +--++-++---+ |LCD controller| -> |Mipi DSI | -> |Mipi to HDMI Converter | +--++-++---+ LCD controller and Mipi DSI transmitter are part of the SOC and mipi to HDMI converter is ADV7535 for KMB EVM board. The DRM driver is a basic KMS atomic modesetting display driver and has no 2D or 3D graphics.It calls into the ADV bridge driver at the connector level. Only 1080p resolution and single plane is supported at this time. The usecase is for debugging video and camera outputs. Device tree patches are under review here https://lore.kernel.org/linux-arm-kernel/20200708175020.194436-1-daniele.alessandre...@linux.intel.com/T/ Changes since v1: - Removed redundant license text, updated license - Rearranged include blocks - renamed global vars and removed extern in c - Used upclassing for dev_private - Used drm_dev_init in drm device create - minor cleanups Changes since v2: - squashed all commits to a single commit - logging changed to drm_info, drm_dbg etc. - used devm_drm_dev_alloc() - removed commented out sections and general cleanup Changes since v3: - renamed dev_p to kmb - moved clocks under kmb_clock, consolidated clk initializations - use drmm functions - use DRM_GEM_CMA_DRIVER_OPS_VMAP - more cleanups Changes since v4: - corrected spellings Changes since v5: - corrected checkpatch warnings/checks -Please ignore checkpatch checks on Camelcase - this is how it is named in the databook - Please ignore checkpatch warnings on misspelled for hsa, dout, widthn etc. - they are spelled as in the databook - Please ignore checkpatch checks on macro arguments reuse - its confirmed ok Changes since v6: - review changes Sam Ravnborg and Thomas Zimmerman split patch into 4 parts, part1 register definitions, part2 display driver files, part3 mipi dsi, part4 build files (Sam) removed kmb_crtc.h kmb_crtc_cleanup (Thomas) renamed mode_set, kmb_load, inlined unload (Thomas) moved remaining logging to drm_*(Thomas) re-orged driver initialization (Thomas) moved plane_status to drm_private (Sam) removed unnecessary logs and defines and ifdef codes (Sam) split dphy_init_sequence smaller (Sam) removed redundant checks in kmb_dsi (Sam) changed kmb_dsi_init to drm_bridge_connector_init and drm_connector_attach_encoder to bridge's connector (Sam) call helper_check in plane_atomic_check (Sam) renamed set to get for bpp and format functions(Sam) use drm helper functions for reset, duplicate/destroy state instead of kmb functions (Sam) removed kmb_priv from kmb_plane and removed kmb_plane_state (Sam) Anitha Chrisanthus (4): drm/kmb: Keem Bay driver register definition drm/kmb: Add support for KeemBay Display drm/kmb: Mipi DSI part of the display driver drm/kmb: Build files for KeemBay Display driver drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile|1 + drivers/gpu/drm/kmb/Kconfig | 13 + drivers/gpu/drm/kmb/Makefile|2 + drivers/gpu/drm/kmb/kmb_crtc.c | 224 ++ drivers/gpu/drm/kmb/kmb_drv.c | 676 + drivers/gpu/drm/kmb/kmb_drv.h | 170 + drivers/gpu/drm/kmb/kmb_dsi.c | 1523 +++ drivers/gpu/drm/kmb/kmb_dsi.h | 350 + drivers/gpu/drm/kmb/kmb_plane.c | 480 drivers/gpu/drm/kmb/kmb_plane.h | 110 +++ drivers/gpu/drm/kmb/kmb_regs.h | 748 +++ 12 files changed, 4299 insertions(+) create mode 100644 drivers/gpu/drm/kmb/Kconfig create mode 100644 drivers/gpu/drm/kmb/Makefile create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.c create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.h create mode 100644 drivers/gpu/drm/kmb/kmb_plane.c create mode 100644 drivers/gpu/drm/kmb/kmb_plane.h create mode 100644 drivers/gpu/drm/kmb/kmb_regs.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 4/4] drm/kmb: Build files for KeemBay Display driver
Cc: Sam Ravnborg Signed-off-by: Anitha Chrisanthus Reviewed-by: Bob Paauwe --- drivers/gpu/drm/Kconfig | 2 ++ drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/kmb/Kconfig | 13 + drivers/gpu/drm/kmb/Makefile | 2 ++ 4 files changed, 18 insertions(+) create mode 100644 drivers/gpu/drm/kmb/Kconfig create mode 100644 drivers/gpu/drm/kmb/Makefile diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 147d61b..97a1631b 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -275,6 +275,8 @@ source "drivers/gpu/drm/nouveau/Kconfig" source "drivers/gpu/drm/i915/Kconfig" +source "drivers/gpu/drm/kmb/Kconfig" + config DRM_VGEM tristate "Virtual GEM provider" depends on DRM diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2f31579..2146ff8 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/ obj-$(CONFIG_DRM_MGA) += mga/ obj-$(CONFIG_DRM_I810) += i810/ obj-$(CONFIG_DRM_I915) += i915/ +obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ obj-$(CONFIG_DRM_V3D) += v3d/ obj-$(CONFIG_DRM_VC4) += vc4/ diff --git a/drivers/gpu/drm/kmb/Kconfig b/drivers/gpu/drm/kmb/Kconfig new file mode 100644 index 000..e18b74c --- /dev/null +++ b/drivers/gpu/drm/kmb/Kconfig @@ -0,0 +1,13 @@ +config DRM_KMB_DISPLAY + tristate "INTEL KEEMBAY DISPLAY" + depends on DRM && OF && (ARM || ARM64) + depends on COMMON_CLK + select DRM_KMS_HELPER + select DRM_KMS_CMA_HELPER + select DRM_GEM_CMA_HELPER + select VIDEOMODE_HELPERS + help + Choose this option if you have Intel's KeemBay SOC which integrates + an ARM Cortex A53 CPU with an Intel Movidius VPU. + + If M is selected the module will be called kmb-drm. diff --git a/drivers/gpu/drm/kmb/Makefile b/drivers/gpu/drm/kmb/Makefile new file mode 100644 index 000..527d737 --- /dev/null +++ b/drivers/gpu/drm/kmb/Makefile @@ -0,0 +1,2 @@ +kmb-drm-y := kmb_crtc.o kmb_drv.o kmb_plane.o kmb_dsi.o +obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb-drm.o -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/sun4i: tcon: Refactor the LVDS and panel probing
Hi Maxime,
Thank you for the patch.
On Thu, Jul 30, 2020 at 11:35:02AM +0200, Maxime Ripard wrote:
> The current code to parse the DT, deal with the older device trees, and
> register either the RGB or LVDS output has so far grown organically into
> the bind function and has become quite hard to extend properly.
>
> Let's move it into a single function that grabs all the resources it needs
> and registers the proper panel output.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 139 +++---
> 1 file changed, 70 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 2a5a9903c4c6..d03ad75f9900 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -875,6 +875,75 @@ static int sun4i_tcon_init_regmap(struct device *dev,
> return 0;
> }
>
> +static int sun4i_tcon_register_panel(struct drm_device *drm,
> + struct sun4i_tcon *tcon)
> +{
> + struct device_node *companion;
> + struct device_node *remote;
> + struct device *dev = tcon->dev;
> + bool has_lvds_alt;
> + bool has_lvds_rst;
> + int ret;
> +
> + /*
> + * If we have an LVDS panel connected to the TCON, we should
> + * just probe the LVDS connector. Otherwise, let's just register
> + * an RGB panel.
> + */
> + remote = of_graph_get_remote_node(dev->of_node, 1, 0);
> + if (!tcon->quirks->supports_lvds ||
> + !of_device_is_compatible(remote, "panel-lvds"))
This isn't very nice :-S Not a candidate for a fix in this patch, but
something that should be addressed in the future. As Chen-Yu mentioned,
there are LVDS panels supported by the panel-simple driver.
> + return sun4i_rgb_init(drm, tcon);
> +
> + /*
> + * This can only be made optional since we've had DT
> + * nodes without the LVDS reset properties.
> + *
> + * If the property is missing, just disable LVDS, and
> + * print a warning.
> + */
> + tcon->lvds_rst = devm_reset_control_get_optional(dev, "lvds");
> + if (IS_ERR(tcon->lvds_rst)) {
> + dev_err(dev, "Couldn't get our reset line\n");
> + return PTR_ERR(tcon->lvds_rst);
> + } else if (tcon->lvds_rst) {
> + has_lvds_rst = true;
> + reset_control_reset(tcon->lvds_rst);
> + } else {
> + has_lvds_rst = false;
> + }
> +
> + /*
> + * This can only be made optional since we've had DT
> + * nodes without the LVDS reset properties.
Shouldn't this mention clock, not reset ?
> + *
> + * If the property is missing, just disable LVDS, and
> + * print a warning.
> + */
> + if (tcon->quirks->has_lvds_alt) {
> + tcon->lvds_pll = devm_clk_get(dev, "lvds-alt");
> + if (IS_ERR(tcon->lvds_pll)) {
> + if (PTR_ERR(tcon->lvds_pll) == -ENOENT) {
> + has_lvds_alt = false;
> + } else {
> + dev_err(dev, "Couldn't get the LVDS PLL\n");
> + return PTR_ERR(tcon->lvds_pll);
> + }
> + } else {
> + has_lvds_alt = true;
> + }
> + }
> +
> + if (!has_lvds_rst ||
> + (tcon->quirks->has_lvds_alt && !has_lvds_alt)) {
> + dev_warn(dev, "Missing LVDS properties, Please upgrade your
> DT\n");
> + dev_warn(dev, "LVDS output disabled\n");
Would it make sense to move this to the has_lvds_rst = false and
has_lvds_alt = false code sections about ? You could then print which
property is missing.
Reviewed-by: Laurent Pinchart
> + return -ENODEV;
> + }
> +
> + return sun4i_lvds_init(drm, tcon);
> +}
> +
> /*
> * On SoCs with the old display pipeline design (Display Engine 1.0),
> * the TCON is always tied to just one backend. Hence we can traverse
> @@ -1122,10 +1191,8 @@ static int sun4i_tcon_bind(struct device *dev, struct
> device *master,
> struct drm_device *drm = data;
> struct sun4i_drv *drv = drm->dev_private;
> struct sunxi_engine *engine;
> - struct device_node *remote;
> struct sun4i_tcon *tcon;
> struct reset_control *edp_rstc;
> - bool has_lvds_rst, has_lvds_alt, can_lvds;
> int ret;
>
> engine = sun4i_tcon_find_engine(drv, dev->of_node);
> @@ -1170,58 +1237,6 @@ static int sun4i_tcon_bind(struct device *dev, struct
> device *master,
> return ret;
> }
>
> - if (tcon->quirks->supports_lvds) {
> - /*
> - * This can only be made optional since we've had DT
> - * nodes without the LVDS reset properties.
> - *
> - * If the property is missing, just disable LVDS, and
> - * print a warning.
> - */
> -
Re: [PATCH 2/2] drm/radeon: Add vddc hwmon sensor
On Sun, Aug 30, 2020 at 3:26 AM Sandeep Raghuraman wrote:
>
Please add a commit message. Also, split this into 2-3 patches:
1. add the new dpm callback
2. add the sumo implementation of the new callback (could be combined with 1)
3. expose the voltage via hwmon
For the last patch, you probably also want to adjust
hwmon_attributes_visible() to hide the voltage on asics which don't
have the callback.
Thanks!
Alex
> Signed-off-by: Sandeep Raghuraman
> ---
> drivers/gpu/drm/radeon/radeon.h | 1 +
> drivers/gpu/drm/radeon/radeon_asic.c | 1 +
> drivers/gpu/drm/radeon/radeon_asic.h | 1 +
> drivers/gpu/drm/radeon/radeon_pm.c | 21 +
> drivers/gpu/drm/radeon/sumo_dpm.c| 20
> 5 files changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 30e32adc1fc6..ec82f22e503a 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1992,6 +1992,7 @@ struct radeon_asic {
> int (*get_fan_speed_percent)(struct radeon_device *rdev, u32
> *speed);
> u32 (*get_current_sclk)(struct radeon_device *rdev);
> u32 (*get_current_mclk)(struct radeon_device *rdev);
> + u16 (*get_current_vddc)(struct radeon_device *rdev);
> } dpm;
> /* pageflipping */
> struct {
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index 495700d16fc9..8becbe09af2f 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -1513,6 +1513,7 @@ static struct radeon_asic sumo_asic = {
> .force_performance_level = _dpm_force_performance_level,
> .get_current_sclk = _dpm_get_current_sclk,
> .get_current_mclk = _dpm_get_current_mclk,
> + .get_current_vddc = _dpm_get_current_vddc,
> },
> .pflip = {
> .page_flip = _page_flip,
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
> b/drivers/gpu/drm/radeon/radeon_asic.h
> index a74fa18cd27b..24644daead53 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.h
> +++ b/drivers/gpu/drm/radeon/radeon_asic.h
> @@ -596,6 +596,7 @@ int sumo_dpm_force_performance_level(struct radeon_device
> *rdev,
> enum radeon_dpm_forced_level level);
> u32 sumo_dpm_get_current_sclk(struct radeon_device *rdev);
> u32 sumo_dpm_get_current_mclk(struct radeon_device *rdev);
> +u16 sumo_dpm_get_current_vddc(struct radeon_device *rdev);
>
> /*
> * cayman
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 05c4196a8212..f02386a0d988 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -737,6 +737,26 @@ static ssize_t radeon_hwmon_show_sclk(struct device *dev,
> static SENSOR_DEVICE_ATTR(freq1_input, S_IRUGO, radeon_hwmon_show_sclk, NULL,
> 0);
>
> +static ssize_t radeon_hwmon_show_vddc(struct device *dev,
> + struct device_attribute *attr, char
> *buf)
> +{
> + struct radeon_device *rdev = dev_get_drvdata(dev);
> + struct drm_device *ddev = rdev->ddev;
> + u16 vddc = 0;
> +
> + /* Can't get vddc when the card is off */
> + if ((rdev->flags & RADEON_IS_PX) &&
> + (ddev->switch_power_state != DRM_SWITCH_POWER_ON))
> + return -EINVAL;
> +
> + if (rdev->asic->dpm.get_current_vddc)
> + vddc = rdev->asic->dpm.get_current_vddc(rdev);
> +
> + return snprintf(buf, PAGE_SIZE, "%u\n", vddc);
> +}
> +
> +static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, radeon_hwmon_show_vddc, NULL,
> + 0);
>
> static struct attribute *hwmon_attributes[] = {
> _dev_attr_temp1_input.dev_attr.attr,
> @@ -747,6 +767,7 @@ static struct attribute *hwmon_attributes[] = {
> _dev_attr_pwm1_min.dev_attr.attr,
> _dev_attr_pwm1_max.dev_attr.attr,
> _dev_attr_freq1_input.dev_attr.attr,
> + _dev_attr_in0_input.dev_attr.attr,
> NULL
> };
>
> diff --git a/drivers/gpu/drm/radeon/sumo_dpm.c
> b/drivers/gpu/drm/radeon/sumo_dpm.c
> index b95d5d390caf..f74f381af05f 100644
> --- a/drivers/gpu/drm/radeon/sumo_dpm.c
> +++ b/drivers/gpu/drm/radeon/sumo_dpm.c
> @@ -1865,6 +1865,26 @@ u32 sumo_dpm_get_current_mclk(struct radeon_device
> *rdev)
> return pi->sys_info.bootup_uma_clk;
> }
>
> +u16 sumo_dpm_get_current_vddc(struct radeon_device *rdev)
> +{
> + struct sumo_power_info *pi = sumo_get_pi(rdev);
> + struct radeon_ps *rps = >current_rps;
> + struct sumo_ps *ps = sumo_get_ps(rps);
> + struct sumo_pl *pl;
> + u32 current_index =
> + (RREG32(TARGET_AND_CURRENT_PROFILE_INDEX) & CURR_INDEX_MASK)
> >>
> + CURR_INDEX_SHIFT;
> +
> + if (current_index ==
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Thank you reviews by Dave, Maxime and Stefan.
On 8/29/20 12:37 AM, Dave Stevenson wrote:
> Hi Maxime, Stefan, and Hoegeun
>
> On Fri, 28 Aug 2020 at 16:25, Maxime Ripard wrote:
>> Hi,
>>
>> On Fri, Aug 28, 2020 at 02:45:49PM +0200, Stefan Wahren wrote:
>>> Am 28.08.20 um 08:30 schrieb Hoegeun Kwon:
On 8/27/20 6:49 PM, Stefan Wahren wrote:
> Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
>> Hi Stefan,
>>
>> Thank you for your review.
>>
>>
>> On 8/26/20 7:04 PM, Stefan Wahren wrote:
>>> Hi Hoeguen,
>>>
>>> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
There is a problem that the output does not work at a resolution
exceeding FHD. To solve this, we need to adjust the bvb clock at a
resolution exceeding FHD.
>>> this patch introduces a mandatory clock, please update
>>> brcm,bcm2835-hdmi.yaml first.
>>>
>>> Is this clock physically available on BCM283x or only on BCM2711?
>> As far as I know, BCM2711 raspberry pi 4 supports 4k,
>>
>> don't supported on pi 3 and pi 3+.
>>
>> Since 4k is not supported in versions prior to Raspberry Pi 4,
>>
>> I don't think we need to modify the bvb clock.
>>
>>
>> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
>>
>> instead of 'brcm,bcm2835-hdmi.yaml'.
> You are correct please update only brcm,bcm2711-hdmi.yaml.
>
> My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
> is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
> DTB. So making the BVB clock optional might be better?
You are right, if use old dtb, we have a problem with the hdmi driver.
So how about modifying it like this?
@@ -1614,8 +1614,8 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
*vc4_hdmi)
vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
- DRM_ERROR("Failed to get pixel bvb clock\n");
- return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
+ DRM_WARN("Failed to get pixel bvb clock\n");
+ vc4_hdmi->pixel_bvb_clock = NULL;
}
>>> i think the better solution would be devm_clk_get_optional(), which
>>> return NULL in case the clock doesn't exist.
>> It's not really optional though. BCM2711 will require it in order to run
>> properly (as Hoegeun experienced), and the previous SoCs won't.
>>
>> If we use clk_get_optional and that the DT is missing the clock on the
>> BCM2711, we will silently ignore it which doesn't sound great.
> Am I missing something here? (I know I missed this earlier)
> We're in vc5_hdmi_init_resources, which is inherently bcm2711 only.
> bcm283x will go through vc4_hdmi_init_resources.
>
> As long as vc4_hdmi_init_resources has left vc4_hdmi->pixel_bvb_clock
> at NULL, then the clock framework will be happy to do a nop.
>
> For BCM2711 an old DT would have issues, but, as Maxime has stated, no
> binding or upstream DTB has been merged yet, so it can be made
> mandatory.
If so, it seems good to set bvb_clock to mandatory without taking into
account the BCM2711 an old DTB as it hasn't been merged yet.
I will send version 2 patches.
> Making it optional drops you back on whatever the firmware might have
> set it to, which may be sufficient for some resolutions but not
> others.
As a result of checking by adding bvb_clock when I operated it with
the firmware, it was confirmed that the firmware increased the bvb_clock
from 7500 to 15000 when the FHD was exceeded.
Best regards
Hoegeun
>
>Dave
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm/of: Change the prototype of drm_of_lvds_get_dual_link_pixel_order
Hi Maxime,
Thank you for the patch.
On Thu, Jul 30, 2020 at 11:35:01AM +0200, Maxime Ripard wrote:
> The drm_of_lvds_get_dual_link_pixel_order() function took so far the
> device_node of the two ports used together to make up a dual-link LVDS
> output.
>
> This assumes that a binding would use an entire port for the LVDS output.
> However, some bindings have used endpoints instead and thus we need to
> operate at the endpoint level. Change slightly the arguments to allow that.
Is this still needed ? Unless I'm mistaken, the Allwinner platform now
uses two TCON instances for the two links, so there are two ports.
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/drm_of.c| 98 +++---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 8 +--
> include/drm/drm_of.h| 16 +++--
> 3 files changed, 63 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index b50b44e76279..2dcb49b0401b 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -291,50 +291,34 @@ static int drm_of_lvds_get_port_pixels_type(struct
> device_node *port_node)
> (odd_pixels ? DRM_OF_LVDS_ODD : 0);
> }
>
> -static int drm_of_lvds_get_remote_pixels_type(
> - const struct device_node *port_node)
> +static int drm_of_lvds_get_remote_pixels_type(const struct device_node
> *endpoint)
> {
> - struct device_node *endpoint = NULL;
> - int pixels_type = -EPIPE;
> + struct device_node *remote_port;
> + int pixels_type;
>
> - for_each_child_of_node(port_node, endpoint) {
> - struct device_node *remote_port;
> - int current_pt;
> -
> - if (!of_node_name_eq(endpoint, "endpoint"))
> - continue;
> -
> - remote_port = of_graph_get_remote_port(endpoint);
> - if (!remote_port) {
> - of_node_put(remote_port);
> - return -EPIPE;
> - }
> -
> - current_pt = drm_of_lvds_get_port_pixels_type(remote_port);
> + remote_port = of_graph_get_remote_port(endpoint);
> + if (!remote_port) {
> of_node_put(remote_port);
> - if (pixels_type < 0)
> - pixels_type = current_pt;
> -
> - /*
> - * Sanity check, ensure that all remote endpoints have the same
> - * pixel type. We may lift this restriction later if we need to
> - * support multiple sinks with different dual-link
> - * configurations by passing the endpoints explicitly to
> - * drm_of_lvds_get_dual_link_pixel_order().
> - */
> - if (!current_pt || pixels_type != current_pt) {
> - of_node_put(remote_port);
> - return -EINVAL;
> - }
> + return -EPIPE;
> }
>
> + pixels_type = drm_of_lvds_get_port_pixels_type(remote_port);
> + of_node_put(remote_port);
> +
> + if (pixels_type < 0)
> + pixels_type = -EPIPE;
> +
> return pixels_type;
> }
>
> /**
> * drm_of_lvds_get_dual_link_pixel_order - Get LVDS dual-link pixel order
> - * @port1: First DT port node of the Dual-link LVDS source
> - * @port2: Second DT port node of the Dual-link LVDS source
> + * @dev1: First DT device node of the Dual-Link LVDS source
> + * @port1_id: ID of the first DT port node of the Dual-Link LVDS source
> + * @endpoint1_id: ID of the first DT port node of the Dual-Link LVDS source
> + * @dev2: First DT device node of the Dual-Link LVDS source
> + * @port2_id: ID of the first DT port node of the Dual-Link LVDS source
> + * @endpoint2_id: ID of the first DT port node of the Dual-Link LVDS source
> *
> * An LVDS dual-link connection is made of two links, with even pixels
> * transitting on one link, and odd pixels on the other link. This function
> @@ -348,32 +332,48 @@ static int drm_of_lvds_get_remote_pixels_type(
> *
> * If either port is not connected, this function returns -EPIPE.
> *
> - * @port1 and @port2 are typically DT sibling nodes, but may have different
> - * parents when, for instance, two separate LVDS encoders carry the even and
> odd
> - * pixels.
> + * @port1_id and @port2_id are typically DT sibling nodes, but may have
> + * different parents when, for instance, two separate LVDS encoders carry the
> + * even and odd pixels.
> + *
> + * If @port1_id, @port2_id, @endpoint1_id or @endpoint2_id are set to -1,
> their
> + * value is going to be ignored.
> *
> * Return:
> - * * DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS - @port1 carries even pixels and
> @port2
> - * carries odd pixels
> - * * DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS - @port1 carries odd pixels and
> @port2
> - * carries even pixels
> - * * -EINVAL - @port1 and @port2 are not connected to a dual-link LVDS sink,
> or
> - * the sink configuration is invalid
> - * * -EPIPE -
Re: [PATCH 01/19] drm/msm: remove dangling submitqueue references
On Mon, Aug 31, 2020 at 7:35 PM Bjorn Andersson
wrote:
>
> On Fri 14 Aug 02:40 UTC 2020, Rob Clark wrote:
>
> > From: Rob Clark
> >
> > Currently it doesn't matter, since we free the ctx immediately. But
> > when we start refcnt'ing the ctx, we don't want old dangling list
> > entries to hang around.
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
> > b/drivers/gpu/drm/msm/msm_submitqueue.c
> > index a1d94be7883a..90c9d84e6155 100644
> > --- a/drivers/gpu/drm/msm/msm_submitqueue.c
> > +++ b/drivers/gpu/drm/msm/msm_submitqueue.c
> > @@ -49,8 +49,10 @@ void msm_submitqueue_close(struct msm_file_private *ctx)
> >* No lock needed in close and there won't
> >* be any more user ioctls coming our way
> >*/
> > - list_for_each_entry_safe(entry, tmp, >submitqueues, node)
> > + list_for_each_entry_safe(entry, tmp, >submitqueues, node) {
> > + list_del(>node);
>
> If you refcount ctx, what does that do for the entries in the submit
> queue?
>
> "entry" here is kref'ed, but you're popping it off the list regardless
> of the put ends up freeing the object or not - which afaict would mean
> leaking the object.
>
What ends up happening is the submit has reference to submit-queue,
which has reference to the ctx.. the submitqueue could be alive still
pending in-flight submits (in a later patch), but dead from the PoV of
userspace interface.
We aren't relying (or at least aren't in the end, and I *think* I
didn't miss anything in the middle) relying on ctx->submitqueues list
to clean anything up in the end, just track what is still a valid
submitqueue from userspace PoV
BR,
-R
>
> On the other hand, with the current implementation an object with higher
> refcount with adjacent objects of single refcount would end up with
> dangling pointers after the put. So in itself this change seems like a
> net gain, but I'm wondering about the plan described in the commit
> message.
>
> Regards,
> Bjorn
>
> > msm_submitqueue_put(entry);
> > + }
> > }
> >
> > int msm_submitqueue_create(struct drm_device *drm, struct msm_file_private
> > *ctx,
> > --
> > 2.26.2
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/4] drm/kmb: Add support for KeemBay Display
This is a basic KMS atomic modesetting display driver for KeemBay family of
SOCs. Driver has no 2D or 3D graphics.It calls into the ADV bridge
driver at the connector level.
Single CRTC with LCD controller->mipi DSI-> ADV bridge
Only 1080p resolution and single plane is supported at this time.
v2: moved extern to .h, removed license text
use drm_dev_init, upclassed dev_private, removed HAVE_IRQ.(Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
moved clocks under kmb_clock, consolidated clk initializations
use drmm functions
use DRM_GEM_CMA_DRIVER_OPS_VMAP
v5: corrected spellings
v6: corrected checkpatch warnings
v7: review changes Sam Ravnborg and Thomas Zimmerman
removed kmb_crtc.h kmb_crtc_cleanup (Thomas)
renamed mode_set, kmb_load, inlined unload (Thomas)
moved remaining logging to drm_*(Thomas)
re-orged driver initialization (Thomas)
moved plane_status to drm_private (Sam)
removed unnecessary logs and defines and ifdef codes (Sam)
call helper_check in plane_atomic_check (Sam)
renamed set to get for bpp and format functions(Sam)
use drm helper functions for reset, duplicate/destroy state instead
of kmb functions (Sam)
removed kmb_priv from kmb_plane and removed kmb_plane_state (Sam)
Cc: Sam Ravnborg
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Bob Paauwe
---
drivers/gpu/drm/kmb/kmb_crtc.c | 224 +
drivers/gpu/drm/kmb/kmb_drv.c | 676
drivers/gpu/drm/kmb/kmb_drv.h | 170 ++
drivers/gpu/drm/kmb/kmb_plane.c | 480
drivers/gpu/drm/kmb/kmb_plane.h | 110 +++
5 files changed, 1660 insertions(+)
create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c
create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c
create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h
create mode 100644 drivers/gpu/drm/kmb/kmb_plane.c
create mode 100644 drivers/gpu/drm/kmb/kmb_plane.h
diff --git a/drivers/gpu/drm/kmb/kmb_crtc.c b/drivers/gpu/drm/kmb/kmb_crtc.c
new file mode 100644
index 000..a684331
--- /dev/null
+++ b/drivers/gpu/drm/kmb/kmb_crtc.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © 2018-2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "kmb_drv.h"
+#include "kmb_dsi.h"
+#include "kmb_plane.h"
+#include "kmb_regs.h"
+
+struct kmb_crtc_timing {
+ u32 vfront_porch;
+ u32 vback_porch;
+ u32 vsync_len;
+ u32 hfront_porch;
+ u32 hback_porch;
+ u32 hsync_len;
+};
+
+static int kmb_crtc_enable_vblank(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct kmb_drm_private *kmb = to_kmb(dev);
+
+ /* Clear interrupt */
+ kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_VERT_COMP);
+ /* Set which interval to generate vertical interrupt */
+ kmb_write_lcd(kmb, LCD_VSTATUS_COMPARE,
+ LCD_VSTATUS_COMPARE_VSYNC);
+ /* Enable vertical interrupt */
+ kmb_set_bitmask_lcd(kmb, LCD_INT_ENABLE,
+ LCD_INT_VERT_COMP);
+ return 0;
+}
+
+static void kmb_crtc_disable_vblank(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct kmb_drm_private *kmb = to_kmb(dev);
+
+ /* Clear interrupt */
+ kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_VERT_COMP);
+ /* Disable vertical interrupt */
+ kmb_clr_bitmask_lcd(kmb, LCD_INT_ENABLE,
+ LCD_INT_VERT_COMP);
+}
+
+static const struct drm_crtc_funcs kmb_crtc_funcs = {
+ .destroy = drm_crtc_cleanup,
+ .set_config = drm_atomic_helper_set_config,
+ .page_flip = drm_atomic_helper_page_flip,
+ .reset = drm_atomic_helper_crtc_reset,
+ .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+ .enable_vblank = kmb_crtc_enable_vblank,
+ .disable_vblank = kmb_crtc_disable_vblank,
+};
+
+static void kmb_crtc_set_mode(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_display_mode *m = >state->adjusted_mode;
+ struct kmb_crtc_timing vm;
+ int vsync_start_offset;
+ int vsync_end_offset;
+ struct kmb_drm_private *kmb = to_kmb(dev);
+ unsigned int val = 0;
+
+ /* Initialize mipi */
+ kmb_dsi_hw_init(dev, m);
+ drm_info(dev,
+"vfp= %d vbp= %d vsyc_len=%d hfp=%d hbp=%d hsync_len=%d\n",
+m->crtc_vsync_start - m->crtc_vdisplay,
+m->crtc_vtotal - m->crtc_vsync_end,
+m->crtc_vsync_end - m->crtc_vsync_start,
+m->crtc_hsync_start - m->crtc_hdisplay,
[PATCH v7 1/4] drm/kmb: Keem Bay driver register definition
Register definitions for Keem Bay display driver v2: removed license text (Sam) v3: Squashed all 59 commits to one v4: review changes from Sam Ravnborg renamed dev_p to kmb v5: corrected spellings v6: corrected checkpatch warnings Cc: Sam Ravnborg Signed-off-by: Anitha Chrisanthus Reviewed-by: Bob Paauwe --- drivers/gpu/drm/kmb/kmb_regs.h | 748 + 1 file changed, 748 insertions(+) create mode 100644 drivers/gpu/drm/kmb/kmb_regs.h diff --git a/drivers/gpu/drm/kmb/kmb_regs.h b/drivers/gpu/drm/kmb/kmb_regs.h new file mode 100644 index 000..f794ac3 --- /dev/null +++ b/drivers/gpu/drm/kmb/kmb_regs.h @@ -0,0 +1,748 @@ +/* SPDX-License-Identifier: GPL-2.0-only + * + * Copyright © 2018-2020 Intel Corporation + */ + +#ifndef __KMB_REGS_H__ +#define __KMB_REGS_H__ + +#define ENABLE 1 +#define DISABLE 0 +/*from Data Book section 12.5.8.1 page 4322 */ +#define CPR_BASE_ADDR (0x2081) +#define MIPI_BASE_ADDR (0x2090) +/*from Data Book section 12.11.6.1 page 4972 */ +#define LCD_BASE_ADDR (0x2093) +#define MSS_CAM_BASE_ADDR (MIPI_BASE_ADDR + 0x1) +#define LCD_MMIO_SIZE (0x3000) +#define MIPI_MMIO_SIZE (0x4000) +#define MSS_CAM_MMIO_SIZE (0x30) + +/*** + *LCD controller control register defines + ***/ +#define LCD_CONTROL(0x4 * 0x000) +#define LCD_CTRL_PROGRESSIVE (0 << 0) +#define LCD_CTRL_INTERLACED BIT(0) +#define LCD_CTRL_ENABLE BIT(1) +#define LCD_CTRL_VL1_ENABLE BIT(2) +#define LCD_CTRL_VL2_ENABLE BIT(3) +#define LCD_CTRL_GL1_ENABLE BIT(4) +#define LCD_CTRL_GL2_ENABLE BIT(5) +#define LCD_CTRL_ALPHA_BLEND_VL1 (0 << 6) +#define LCD_CTRL_ALPHA_BLEND_VL2 BIT(6) +#define LCD_CTRL_ALPHA_BLEND_GL1 (2 << 6) +#define LCD_CTRL_ALPHA_BLEND_GL2 (3 << 6) +#define LCD_CTRL_ALPHA_TOP_VL1 (0 << 8) +#define LCD_CTRL_ALPHA_TOP_VL2 BIT(8) +#define LCD_CTRL_ALPHA_TOP_GL1 (2 << 8) +#define LCD_CTRL_ALPHA_TOP_GL2 (3 << 8) +#define LCD_CTRL_ALPHA_MIDDLE_VL1(0 << 10) +#define LCD_CTRL_ALPHA_MIDDLE_VL2BIT(10) +#define LCD_CTRL_ALPHA_MIDDLE_GL1(2 << 10) +#define LCD_CTRL_ALPHA_MIDDLE_GL2(3 << 10) +#define LCD_CTRL_ALPHA_BOTTOM_VL1(0 << 12) +#define LCD_CTRL_ALPHA_BOTTOM_VL2BIT(12) +#define LCD_CTRL_ALPHA_BOTTOM_GL1(2 << 12) +#define LCD_CTRL_ALPHA_BOTTOM_GL2(3 << 12) +#define LCD_CTRL_TIM_GEN_ENABLE BIT(14) +#define LCD_CTRL_CONTINUOUS (0 << 15) +#define LCD_CTRL_ONE_SHOTBIT(15) +#define LCD_CTRL_PWM0_EN BIT(16) +#define LCD_CTRL_PWM1_EN BIT(17) +#define LCD_CTRL_PWM2_EN BIT(18) +#define LCD_CTRL_OUTPUT_DISABLED (0 << 19) +#define LCD_CTRL_OUTPUT_ENABLED BIT(19) +#define LCD_CTRL_BPORCH_ENABLE BIT(21) +#define LCD_CTRL_FPORCH_ENABLE BIT(22) +#define LCD_CTRL_PIPELINE_DMABIT(28) +#define LCD_CTRL_VHSYNC_IDLE_LVL BIT(31) + +/*interrupts */ +#define LCD_INT_STATUS (0x4 * 0x001) +#define LCD_INT_EOF BIT(0) +#define LCD_INT_LINE_CMP BIT(1) +#define LCD_INT_VERT_COMPBIT(2) +#define LAYER0_DMA_DONE BIT(3) +#define LAYER0_DMA_IDLE BIT(4) +#define LAYER0_DMA_FIFO_OVERFLOW BIT(5) +#define LAYER0_DMA_FIFO_UNDERFLOWBIT(6) +#define LAYER0_DMA_CB_FIFO_OVERFLOW BIT(7) +#define LAYER0_DMA_CB_FIFO_UNDERFLOW BIT(8) +#define LAYER0_DMA_CR_FIFO_OVERFLOW BIT(9) +#define LAYER0_DMA_CR_FIFO_UNDERFLOW BIT(10) +#define LAYER1_DMA_DONE BIT(11) +#define LAYER1_DMA_IDLE BIT(12) +#define LAYER1_DMA_FIFO_OVERFLOW BIT(13) +#define LAYER1_DMA_FIFO_UNDERFLOWBIT(14) +#define LAYER1_DMA_CB_FIFO_OVERFLOW BIT(15) +#define LAYER1_DMA_CB_FIFO_UNDERFLOW BIT(16) +#define LAYER1_DMA_CR_FIFO_OVERFLOW BIT(17) +#define LAYER1_DMA_CR_FIFO_UNDERFLOW
Re: [PATCH] drm: Parse Colorimetry data block from EDID
On Fri, Aug 28, 2020 at 09:07:13AM +0800, crj wrote:
> Hi Ville Syrjälä,
>
> 在 2020/8/27 18:57, Ville Syrjälä 写道:
> > On Wed, Aug 26, 2020 at 10:23:28PM +0800, Algea Cao wrote:
> >> CEA 861.3 spec adds colorimetry data block for HDMI.
> >> Parsing the block to get the colorimetry data from
> >> panel.
> > And what exactly do you want to do with that data?
>
>
> We can get colorimetry data block from edid then support
>
> HDMI colorimetry such as BT2020.
But what do you want to do with it? The patch does nothing
functional.
>
> >> Signed-off-by: Algea Cao
> >> ---
> >>
> >> drivers/gpu/drm/drm_edid.c | 45 +
> >> include/drm/drm_connector.h | 3 +++
> >> include/drm/drm_edid.h | 14
> >> 3 files changed, 62 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 31496b6cfc56..67e607c04492 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -3223,6 +3223,7 @@ add_detailed_modes(struct drm_connector *connector,
> >> struct edid *edid,
> >> #define VIDEO_BLOCK 0x02
> >> #define VENDOR_BLOCK0x03
> >> #define SPEAKER_BLOCK0x04
> >> +#define COLORIMETRY_DATA_BLOCK0x5
> >> #define HDR_STATIC_METADATA_BLOCK0x6
> >> #define USE_EXTENDED_TAG 0x07
> >> #define EXT_VIDEO_CAPABILITY_BLOCK 0x00
> >> @@ -4309,6 +4310,48 @@ static void fixup_detailed_cea_mode_clock(struct
> >> drm_display_mode *mode)
> >>mode->clock = clock;
> >> }
> >>
> >> +static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
> >> +{
> >> + if (cea_db_tag(db) != USE_EXTENDED_TAG)
> >> + return false;
> >> +
> >> + if (db[1] != COLORIMETRY_DATA_BLOCK)
> >> + return false;
> >> +
> >> + if (cea_db_payload_len(db) < 2)
> >> + return false;
> >> +
> >> + return true;
> >> +}
> >> +
> >> +static void
> >> +drm_parse_colorimetry_data_block(struct drm_connector *connector, const
> >> u8 *db)
> >> +{
> >> + struct drm_hdmi_info *info = >display_info.hdmi;
> >> +
> >> + if (db[2] & DRM_EDID_CLRMETRY_xvYCC_601)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_601;
> >> + if (db[2] & DRM_EDID_CLRMETRY_xvYCC_709)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_709;
> >> + if (db[2] & DRM_EDID_CLRMETRY_sYCC_601)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_sYCC_601;
> >> + if (db[2] & DRM_EDID_CLRMETRY_ADBYCC_601)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_ADBYCC_601;
> >> + if (db[2] & DRM_EDID_CLRMETRY_ADB_RGB)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_ADB_RGB;
> >> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_CYCC)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_CYCC;
> >> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_YCC)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_YCC;
> >> + if (db[2] & DRM_EDID_CLRMETRY_BT2020_RGB)
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_RGB;
> >> + /* Byte 4 Bit 7: DCI-P3 */
> >> + if (db[3] & BIT(7))
> >> + info->colorimetry |= DRM_EDID_CLRMETRY_DCI_P3;
> >> +
> >> + DRM_DEBUG_KMS("Supported Colorimetry 0x%x\n", info->colorimetry);
> >> +}
> >> +
> >> static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
> >> {
> >>if (cea_db_tag(db) != USE_EXTENDED_TAG)
> >> @@ -4994,6 +5037,8 @@ static void drm_parse_cea_ext(struct drm_connector
> >> *connector,
> >>drm_parse_vcdb(connector, db);
> >>if (cea_db_is_hdmi_hdr_metadata_block(db))
> >>drm_parse_hdr_metadata_block(connector, db);
> >> + if (cea_db_is_hdmi_colorimetry_data_block(db))
> >> + drm_parse_colorimetry_data_block(connector, db);
> >>}
> >> }
> >>
> >> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> >> index af145608b5ed..d599c3b9e881 100644
> >> --- a/include/drm/drm_connector.h
> >> +++ b/include/drm/drm_connector.h
> >> @@ -207,6 +207,9 @@ struct drm_hdmi_info {
> >>
> >>/** @y420_dc_modes: bitmap of deep color support index */
> >>u8 y420_dc_modes;
> >> +
> >> + /* @colorimetry: bitmap of supported colorimetry modes */
> >> + u16 colorimetry;
> >> };
> >>
> >> /**
> >> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> >> index cfa4f5af49af..98fa78c2f82d 100644
> >> --- a/include/drm/drm_edid.h
> >> +++ b/include/drm/drm_edid.h
> >> @@ -229,6 +229,20 @@ struct detailed_timing {
> >>DRM_EDID_YCBCR420_DC_36 | \
> >>DRM_EDID_YCBCR420_DC_30)
> >>
> >> +/*
> >> + * Supported Colorimetry from colorimetry data block
> >> + * as per CEA 861-G spec
> >> + */
> >> +#define DRM_EDID_CLRMETRY_xvYCC_601 (1 << 0)
> >> +#define DRM_EDID_CLRMETRY_xvYCC_709 (1 << 1)
> >> +#define DRM_EDID_CLRMETRY_sYCC_601(1 << 2)
> >> +#define DRM_EDID_CLRMETRY_ADBYCC_601 (1 << 3)
> >> +#define
RE: [PATCH v6] drm/kmb: Add support for KeemBay Display
Hi Sam,
Thanks a lot for the review. I will address your comments in v7.
For those that are not addressed, please see my reply inline.
Regards,
Anitha
> -Original Message-
> From: Sam Ravnborg
> Sent: Thursday, August 20, 2020 1:10 PM
> To: Chrisanthus, Anitha
> Cc: dri-devel@lists.freedesktop.org; Paauwe, Bob J
> ; Dea, Edmund J ;
> Vetter, Daniel ; intel-...@lists.freedesktop.org
> Subject: Re: [PATCH v6] drm/kmb: Add support for KeemBay Display
>
> Hi Anitha.
>
> Feedback on kmb_dsi.
>
> The main feedback can be found after the kmb_dsi_init function.
> The highligt of the feedback is that, in my opinion, the
> best would be to use the drm_bridge abstraction for the kmb_dsi.
> Maybe because I am biased - and this is just overhead.
> But it just looks simpler to me.
Mipi dsi is very time sensitive and any delay can cause problems.
As soon as it's initialized it expects LCD controller to be up and running
especially the LCD_TIMING_GEN_TRIG, a slight delay and lots of issues.
It is tightly coupled in the hardware with LCD and let's keep it that
way in the software too.
> There are several chunks of code surrounded by #ifdef.
> It would be good if they could all be handled so no more #ifdef are
> required.
>
> There is also a lot of debug prints. Maybe this can be trimmed now that
> the driver works?
>
> There is a lot of variables that should all be included in a struct
> kmb_dsi that should be allocated in the probe function (if this becomes
> a bridge driver).
>
> I hope this does not scare you away! If I am right about the ocnversion
> to a drm_bridge, then I hope it is semi trivial to do.
> All the hard HW init stuff is done.
>
> Sam
>
> > diff --git a/drivers/gpu/drm/kmb/kmb_dsi.c
> b/drivers/gpu/drm/kmb/kmb_dsi.c
> > new file mode 100644
> > index 000..21745ae
> > --- /dev/null
> > +++ b/drivers/gpu/drm/kmb/kmb_dsi.c
> > @@ -0,0 +1,1828 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (c) 2019-2020 Intel Corporation
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "kmb_drv.h"
> > +#include "kmb_dsi.h"
> > +#include "kmb_regs.h"
> > +
> > +static int hw_initialized;
> > +/* #define MIPI_TX_TEST_PATTERN_GENERATION */
> > +/* #define DPHY_GET_FSM */
> > +/* #define DPHY_READ_TESTCODE */
> > +
> > +static struct mipi_dsi_host *dsi_host;
> > +static struct mipi_dsi_device *dsi_device;
> > +
> > +/* Default setting is 1080p, 4 lanes */
> > +#define IMG_HEIGHT_LINES 1080
> > +#define IMG_WIDTH_PX 1920
> > +#define MIPI_TX_ACTIVE_LANES 4
> > +
> > +struct mipi_tx_frame_section_cfg mipi_tx_frame0_sect_cfg = {
> > + .width_pixels = IMG_WIDTH_PX,
> > + .height_lines = IMG_HEIGHT_LINES,
> > + .data_type = DSI_LP_DT_PPS_RGB888_24B,
> > + .data_mode = MIPI_DATA_MODE1,
> > + .dma_packed = 0
> > +};
> > +
> > +struct mipi_tx_frame_cfg mipitx_frame0_cfg = {
> > + .sections[0] = _tx_frame0_sect_cfg,
> > + .sections[1] = NULL,
> > + .sections[2] = NULL,
> > + .sections[3] = NULL,
> > + .vsync_width = 5,
> > + .v_backporch = 36,
> > + .v_frontporch = 4,
> > + .hsync_width = 44,
> > + .h_backporch = 148,
> > + .h_frontporch = 88
> > +};
> > +
> > +struct mipi_tx_dsi_cfg mipitx_dsi_cfg = {
> > + .hfp_blank_en = 0,
> > + .eotp_en = 0,
> > + .lpm_last_vfp_line = 0,
> > + .lpm_first_vsa_line = 0,
> > + .sync_pulse_eventn = DSI_VIDEO_MODE_NO_BURST_EVENT,
> > + .hfp_blanking = SEND_BLANK_PACKET,
> > + .hbp_blanking = SEND_BLANK_PACKET,
> > + .hsa_blanking = SEND_BLANK_PACKET,
> > + .v_blanking = SEND_BLANK_PACKET,
> > +};
> > +
> > +struct mipi_ctrl_cfg mipi_tx_init_cfg = {
> > + .index = MIPI_CTRL6,
> > + .type = MIPI_DSI,
> > + .dir = MIPI_TX,
> > + .active_lanes = MIPI_TX_ACTIVE_LANES,
> > + .lane_rate_mbps = MIPI_TX_LANE_DATA_RATE_MBPS,
> > + .ref_clk_khz = MIPI_TX_REF_CLK_KHZ,
> > + .cfg_clk_khz = MIPI_TX_CFG_CLK_KHZ,
> > + .data_if = MIPI_IF_PARALLEL,
> > + .tx_ctrl_cfg = {
> > + .frames[0] = _frame0_cfg,
> > + .frames[1] = NULL,
> > + .frames[2] = NULL,
> > + .frames[3] = NULL,
> > + .tx_dsi_cfg = _dsi_cfg,
> > + .line_sync_pkt_en = 0,
> > + .line_counter_active = 0,
> > + .frame_counter_active = 0,
> > + .tx_always_use_hact = 1,
> > + .tx_hact_wait_stop = 1,
> > + }
> > +};
> > +
> > +struct mipi_hs_freq_range_cfg {
> > + u16 default_bit_rate_mbps;
> > + u8 hsfreqrange_code;
> > +};
> > +
> > +struct vco_params {
> > + u32 freq;
> > + u32 range;
> > + u32 divider;
> > +};
> > +
> > +static struct vco_params vco_table[] = {
> > + {52, 0x3f, 8},
> > + {80, 0x39, 8},
> > + {105, 0x2f, 4},
> > +
Re: [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
On Thu, Aug 27, 2020 at 01:04:54PM +0800, Kai Heng Feng wrote:
> Hi Ville,
>
> > On Aug 27, 2020, at 12:24 AM, Ville Syrjälä
> > wrote:
> >
> > On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
> >> LSPCON only supports 8 bpc for RGB/YCbCr444.
> >>
> >> Set the correct bpp otherwise it renders blank screen.
> >
> > Hmm. Does
> > git://github.com/vsyrjala/linux.git dp_downstream_ports_5
> > work?
> >
> > Actually better make that dp_downstream_ports_5^^^ aka.
> > 54d846ce62a2 ("drm/i915: Do YCbCr 444->420 conversion via DP protocol
> > converters") to avoid the experiments and hacks I have sitting on top.
>
> Can you please rebase it to mainline master or drm-tip?
git://github.com/vsyrjala/linux.git dp_downstream_ports_6
I threw out the hacks/experimental stuff.
>
> I am getting errors on the branch:
>
> DESCEND objtool
> CALLscripts/atomic/check-atomics.sh
> CALLscripts/checksyscalls.sh
> CHK include/generated/compile.h
> Building modules, stage 2.
> MODPOST 166 modules
> LD arch/x86/boot/compressed/vmlinux
> ld: arch/x86/boot/compressed/pgtable_64.o:(.bss+0x0): multiple definition of
> `__force_order'; arch/x86/boot/compressed/kaslr_64.o:(.bss+0x0): first
> defined here
> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only
> section `.head.text'
> ld: warning: creating DT_TEXTREL in a PIE
> make[2]: *** [arch/x86/boot/compressed/Makefile:119:
> arch/x86/boot/compressed/vmlinux] Error 1
> make[1]: *** [arch/x86/boot/Makefile:113: arch/x86/boot/compressed/vmlinux]
> Error 2
> make: *** [arch/x86/Makefile:284: bzImage] Error 2
> make: *** Waiting for unfinished jobs
>
> Kai-Heng
>
> >
> >>
> >> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
> >> Signed-off-by: Kai-Heng Feng
> >> ---
> >> drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> >> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> >> index b781bf469644..c7a44fcaade8 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> >> @@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector
> >> *connector,
> >>crtc_state->port_clock /= 2;
> >>crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
> >>crtc_state->lspcon_downsampling = true;
> >> - }
> >> + } else
> >> + crtc_state->pipe_bpp = 24;
> >> }
> >>
> >> static bool lspcon_probe(struct intel_lspcon *lspcon)
> >> --
> >> 2.17.1
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: Add sclk frequency as hwmon sensor
On Sun, Aug 30, 2020 at 3:25 AM Sandeep Raghuraman wrote:
>
> This patch series adds support for reporting sclk and vddc values for Radeon
> GPUs, where supported.
This commit message should be specific to this particular patch rather
than the series. You could probably expose mclk as well.
Alex
>
> Signed-off-by: Sandeep Raghuraman
> ---
> drivers/gpu/drm/radeon/radeon_pm.c | 29 -
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 8c5d6fda0d75..05c4196a8212 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -712,6 +712,31 @@ static SENSOR_DEVICE_ATTR(pwm1_enable, S_IRUGO |
> S_IWUSR, radeon_hwmon_get_pwm1_
> static SENSOR_DEVICE_ATTR(pwm1_min, S_IRUGO, radeon_hwmon_get_pwm1_min,
> NULL, 0);
> static SENSOR_DEVICE_ATTR(pwm1_max, S_IRUGO, radeon_hwmon_get_pwm1_max,
> NULL, 0);
>
> +static ssize_t radeon_hwmon_show_sclk(struct device *dev,
> + struct device_attribute *attr, char
> *buf)
> +{
> + struct radeon_device *rdev = dev_get_drvdata(dev);
> + struct drm_device *ddev = rdev->ddev;
> + u32 sclk = 0;
> +
> + /* Can't get clock frequency when the card is off */
> + if ((rdev->flags & RADEON_IS_PX) &&
> + (ddev->switch_power_state != DRM_SWITCH_POWER_ON))
> + return -EINVAL;
> +
> + if (rdev->asic->dpm.get_current_sclk)
> + sclk = radeon_dpm_get_current_sclk(rdev);
> +
> + /* Value returned by dpm is in 10 KHz units, need to convert it into
> Hz
> + for hwmon */
> + sclk *= 1;
> +
> + return snprintf(buf, PAGE_SIZE, "%u\n", sclk);
> +}
> +
> +static SENSOR_DEVICE_ATTR(freq1_input, S_IRUGO, radeon_hwmon_show_sclk, NULL,
> + 0);
> +
>
> static struct attribute *hwmon_attributes[] = {
> _dev_attr_temp1_input.dev_attr.attr,
> @@ -721,6 +746,7 @@ static struct attribute *hwmon_attributes[] = {
> _dev_attr_pwm1_enable.dev_attr.attr,
> _dev_attr_pwm1_min.dev_attr.attr,
> _dev_attr_pwm1_max.dev_attr.attr,
> + _dev_attr_freq1_input.dev_attr.attr,
> NULL
> };
>
> @@ -738,7 +764,8 @@ static umode_t hwmon_attributes_visible(struct kobject
> *kobj,
> attr == _dev_attr_pwm1.dev_attr.attr ||
> attr == _dev_attr_pwm1_enable.dev_attr.attr ||
> attr == _dev_attr_pwm1_max.dev_attr.attr ||
> -attr == _dev_attr_pwm1_min.dev_attr.attr))
> +attr == _dev_attr_pwm1_min.dev_attr.attr ||
> +attr == _dev_attr_freq1_input.dev_attr.attr))
> return 0;
>
> /* Skip fan attributes if fan is not present */
> --
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/sun4i: tcon: Support the LVDS Dual-Link on the A20
Hi Maxime,
Thank you for the patch.
On Thu, Jul 30, 2020 at 11:35:03AM +0200, Maxime Ripard wrote:
> The A20 can use its second TCON as the secondary LVDS link in a dual-link
> setup, with the TCON0 being the main link. Extend a bit the parsing code to
> leverage the DRM dual-link code, register only the LVDS output on the
> primary TCON, and add the needed bits to setup the TCON properly.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 36 +++-
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 +++-
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index d03ad75f9900..ed2abf6eb18b 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -487,6 +487,9 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon
> *tcon,
> else
> reg |= SUN4I_TCON0_LVDS_IF_DATA_POL_NORMAL;
>
> + if (tcon->lvds_dual_link)
> + reg |= SUN4I_TCON0_LVDS_IF_DUAL_LINK;
> +
> if (sun4i_tcon_get_pixel_depth(encoder) == 24)
> reg |= SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS;
> else
> @@ -896,6 +899,16 @@ static int sun4i_tcon_register_panel(struct drm_device
> *drm,
> return sun4i_rgb_init(drm, tcon);
>
> /*
> + * Only the TCON0 will be relevant for the LVDS output, so if
> + * our ID is something else, let's prevent our TCON from
> + * registering its own LVDS output
> + */
> + if (tcon->id) {
> + dev_info(dev, "Secondary TCON, disabling panel output");
This may worry the user unnecessarily. I'd make it a debug message, or
drop it completely, and like reword it a bit as pointed out by Chen-Yu.
> + return 0;
> + }
> +
> + /*
>* This can only be made optional since we've had DT
>* nodes without the LVDS reset properties.
>*
> @@ -941,6 +954,28 @@ static int sun4i_tcon_register_panel(struct drm_device
> *drm,
> return -ENODEV;
> }
>
> + /*
> + * If we don't have a second TCON, we will never be able to do
> + * dual-link LVDS, so we don't have much more to do.
> + */
> + companion = of_parse_phandle(dev->of_node, "allwinner,lvds-companion",
> 0);
Should there be a patch to add this property to the DT bindings ?
> + if (!companion)
> + return 0;
> +
> + /*
> + * Let's do a sanity check on the dual-link setup to make sure
> + * everything is properly described.
> + */
> + ret = drm_of_lvds_get_dual_link_pixel_order(dev->of_node, 1, 0,
> + companion, 1, 0);
> + if (ret < 0) {
> + dev_err(dev, "Invalid Dual-Link Configuration.\n");
> + return ret;
> + }
> +
> + dev_info(dev, "Primary TCON, enabling LVDS Dual-Link");
> + tcon->lvds_dual_link = true;
> +
> return sun4i_lvds_init(drm, tcon);
> }
>
> @@ -1500,6 +1535,7 @@ static const struct sun4i_tcon_quirks
> sun7i_a20_tcon0_quirks = {
> };
>
> static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
> + .supports_lvds = true,
Should this be split to a separate patch, or at least mentioned in the
commit message ?
> .has_channel_0 = true,
> .has_channel_1 = true,
> .dclk_min_div = 4,
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index cfbf4e6c1679..51c4e09cdd13 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -98,6 +98,7 @@
>
> #define SUN4I_TCON0_LVDS_IF_REG 0x84
> #define SUN4I_TCON0_LVDS_IF_EN BIT(31)
> +#define SUN4I_TCON0_LVDS_IF_DUAL_LINKBIT(30)
> #define SUN4I_TCON0_LVDS_IF_BITWIDTH_MASKBIT(26)
> #define SUN4I_TCON0_LVDS_IF_BITWIDTH_18BITS (1 << 26)
> #define SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS (0 << 26)
> @@ -274,6 +275,9 @@ struct sun4i_tcon {
> /* Associated crtc */
> struct sun4i_crtc *crtc;
>
> + /* Is the LVDS link a dual-channel link? */
> + boollvds_dual_link;
> +
> int id;
>
> /* TCON list management */
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] topic/nouveau-i915-dp-helpers-and-cleanup
topic/nouveau-i915-dp-helpers-and-cleanup-2020-08-31-1: UAPI Changes: None Cross-subsystem Changes: * Moves a bunch of miscellaneous DP code from the i915 driver into a set of shared DRM DP helpers Core Changes: * New DRM DP helpers (see above) Driver Changes: * Implements usage of the aforementioned DP helpers in the nouveau driver, along with some other various HPD related cleanup for nouveau The following changes since commit bfacb84993eb173c0ab53ca4dd6180f76f4dc176: drm: virtio: fix kconfig dependency warning (2020-08-31 08:55:02 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/topic/nouveau-i915-dp-helpers-and-cleanup-2020-08-31-1 for you to fetch changes up to 79416e97dda0118b137302575a70a14259a27d7d: drm/nouveau/kms: Start using drm_dp_read_dpcd_caps() (2020-08-31 19:10:09 -0400) UAPI Changes: None Cross-subsystem Changes: * Moves a bunch of miscellaneous DP code from the i915 driver into a set of shared DRM DP helpers Core Changes: * New DRM DP helpers (see above) Driver Changes: * Implements usage of the aforementioned DP helpers in the nouveau driver, along with some other various HPD related cleanup for nouveau Lyude Paul (20): drm/nouveau/kms: Fix some indenting in nouveau_dp_detect() drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc() drm/nouveau/kms/nv50-: Just use drm_dp_dpcd_read() in nouveau_dp.c drm/nouveau/kms/nv50-: Use macros for DP registers in nouveau_dp.c drm/nouveau/kms: Don't clear DP_MST_CTRL DPCD in nv50_mstm_new() drm/nouveau/kms: Search for encoders' connectors properly drm/nouveau/kms/nv50-: Use drm_dp_dpcd_(readb|writeb)() in nv50_sor_disable() drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handling drm/i915/dp: Extract drm_dp_read_mst_cap() drm/nouveau/kms: Use new drm_dp_read_mst_cap() helper for checking MST caps drm/nouveau/kms: Move drm_dp_cec_unset_edid() into nouveau_connector_detect() drm/nouveau/kms: Only use hpd_work for reprobing in HPD paths drm/i915/dp: Extract drm_dp_read_downstream_info() drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation drm/i915/dp: Extract drm_dp_read_sink_count_cap() drm/i915/dp: Extract drm_dp_read_sink_count() drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT drm/nouveau/kms: Don't change EDID when it hasn't actually changed drm/i915/dp: Extract drm_dp_read_dpcd_caps() drm/nouveau/kms: Start using drm_dp_read_dpcd_caps() drivers/gpu/drm/drm_dp_helper.c | 187 - drivers/gpu/drm/drm_dp_mst_topology.c | 22 ++ drivers/gpu/drm/i915/display/intel_dp.c | 124 +++ drivers/gpu/drm/i915/display/intel_dp.h | 1 - drivers/gpu/drm/i915/display/intel_lspcon.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/dac.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/dfp.c | 7 +- drivers/gpu/drm/nouveau/dispnv04/disp.c | 24 ++- drivers/gpu/drm/nouveau/dispnv04/disp.h | 4 + drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 305 drivers/gpu/drm/nouveau/nouveau_connector.c | 132 +--- drivers/gpu/drm/nouveau/nouveau_connector.h | 1 + drivers/gpu/drm/nouveau/nouveau_display.c | 72 ++- drivers/gpu/drm/nouveau/nouveau_display.h | 3 +- drivers/gpu/drm/nouveau/nouveau_dp.c| 210 +++ drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +- drivers/gpu/drm/nouveau/nouveau_drv.h | 2 + drivers/gpu/drm/nouveau/nouveau_encoder.h | 48 - include/drm/drm_dp_helper.h | 15 +- include/drm/drm_dp_mst_helper.h | 3 +- 22 files changed, 779 insertions(+), 393 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208893] Navi (RX 5700 XT) system appears to hang with more than one display connected
https://bugzilla.kernel.org/show_bug.cgi?id=208893 --- Comment #15 from Alex Deucher (alexdeuc...@gmail.com) --- Does setting amdgpu.dpm=0 on the kernel command line in grub fix the issue? If so, remove that and try setting amdgpu.ppfeaturemask=0xbffd on the kernel command line in grub. Does that help? -- 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: [RFT 3/4] ARM: dts: exynos: Move CMU assigned ISP clocks to buses in Exynos3250
Hi Krzysztof,
On 29.08.2020 19:25, Krzysztof Kozlowski wrote:
> Commit 52005dece527 ("ARM: dts: Add assigned clock parents to CMU node
> for exynos3250") added assigned clocks under Clock Management Unit to
> fix hangs when accessing ISP registers.
>
> This is not the place for it as CMU does not have a required "clocks"
> property:
>
>arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml:
> clock-controller@1003: 'clocks' is a dependency of 'assigned-clocks'
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Not tested and I wonder whether actually correct. For example, what will
> happen if devfreq (exynos-bus) is not built in?
>
> Could someone verify it?
Sorry, but this patch is not correct. Those clocks has noting with
bus-freq. The assigned clocks property should stay where it is. Maybe
one need to fix the schemas for dts verification. Those clocks has to be
set (and so generic clock framework does) according to the assigned
clocks properties once the clock controller is instantiated.
The only alternative would be to add exynos-subcmu variant to properly
link CMU with the ISP power domain, but assuming that there is no Exynos
3250 ISP driver in mainline (and probably never will be), it is safe to
keep those clocks sourced from 24MHz crystal.
> ---
> arch/arm/boot/dts/exynos3250.dtsi | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> index c67c70e46794..6d467022d929 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -214,10 +214,6 @@
> compatible = "samsung,exynos3250-cmu";
> reg = <0x1003 0x2>;
> #clock-cells = <1>;
> - assigned-clocks = < CLK_MOUT_ACLK_400_MCUISP_SUB>,
> - < CLK_MOUT_ACLK_266_SUB>;
> - assigned-clock-parents = < CLK_FIN_PLL>,
> - < CLK_FIN_PLL>;
> };
>
> cmu_dmc: clock-controller@105c {
> @@ -835,6 +831,8 @@
> compatible = "samsung,exynos-bus";
> clocks = < CLK_DIV_ACLK_400_MCUISP>;
> clock-names = "bus";
> + assigned-clocks = < CLK_MOUT_ACLK_400_MCUISP_SUB>;
> + assigned-clock-parents = < CLK_FIN_PLL>;
> operating-points-v2 = <_mcuisp_opp_table>;
> status = "disabled";
> };
> @@ -843,6 +841,8 @@
> compatible = "samsung,exynos-bus";
> clocks = < CLK_DIV_ACLK_266>;
> clock-names = "bus";
> + assigned-clocks = < CLK_MOUT_ACLK_266_SUB>;
> + assigned-clock-parents = < CLK_FIN_PLL>;
> operating-points-v2 = <_isp_opp_table>;
> status = "disabled";
> };
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 v5 3/4] phy: mediatek: Move mtk_hdmi_phy driver into drivers/phy/mediatek folder
On Mon, 2020-08-31 at 07:03 +0800, Chun-Kuang Hu wrote:
> Hi, Chunfeng & Kishon:
>
> How do you feel about this patch?
It's fine to me,
Reviewed-by: Chunfeng Yun
Thanks a lot
>
> Regards,
> Chun-Kuang.
>
> Chun-Kuang Hu 於 2020年8月23日 週日 上午9:48寫道：
> >
> > 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 | 5 +
> > .../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, 15 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 6363f2c1cdbc..65cd03a4be29 100644
> > --- a/drivers/gpu/drm/mediatek/Kconfig
> > +++ b/drivers/gpu/drm/mediatek/Kconfig
> > @@ -27,10 +27,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
> > - Support HDMI PHY for Mediatek SoCs.
> > 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..50c5e9306e19 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
> > + Support HDMI PHY for Mediatek SoCs.
> > diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> > index 08a8e6a97b1e..6325e38709ed 100644
> > --- a/drivers/phy/mediatek/Makefile
> > +++ b/drivers/phy/mediatek/Makefile
> > @@ -6,3 +6,8 @@
> > 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-y := phy-mtk-hdmi.o
> > +phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt2701.o
> > +phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt8173.o
> > +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
Re: [PATCH 16/18] staging/media/tegra-vde: Clean up IOMMU workaround
27.08.2020 18:54, Thierry Reding пишет: ... >> The Tegra DRM has a very special quirk for ARM32 that was added in this >> commit [2] and driver relies on checking of whether explicit or implicit >> IOMMU is used in order to activate the quirk. >> >> [2] >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=273da5a046965ccf0ec79eb63f2d5173467e20fa >> >> Once the implicit IOMMU is used for the DRM driver, the quirk no longer >> works (if I'm not missing something). This problem needs to be resolved >> before implicit IOMMU could be used by the Tegra DRM on ARM32. ... > I do have a patch lying around somewhere that implements the mapping > cache that was referenced in the above commit. Let me know if I should > dig that up and send it out. Hello, Thierry! It certainly will be interesting to take a look at yours patch! I think that the caching shouldn't be strictly necessary for keeping the current workaround working and it should be possible to keep the code as-is by replacing the domain-type checking with the SoC-generation check in the Tegra DRM driver. In general, IMO it should be better to stash the complex changes until we'll get closer to adopting the new UAPI as it will certainly touch the aspect of the per-device mappings. But if yours patch is less than 100 LOC, then maybe we could consider applying it right now! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: innolux p097pfg dpms off/on fails (on gru-scarlet) with dw-mipi-dsi
Hi Samuel, Am Montag, 31. August 2020, 02:47:56 CEST schrieb Samuel Dionne-Riel: > I have an Asus Chromebook Tablet CT100PA, which I will refer to as > "dumo" from this point on, which is a specific variant of gru-scarlet. > As far as I am aware, all gru-scarlet are the same, except for the > display, and in turn the different scarlets with the innolux panel > are the same. > > I do not have the hardware to verify the kingdisplay variant's > behaviour, though I don't really expect it to fail the same way, but it > is still a possibility that there is a root cause that could cause a > similar failure. as I said in that chat yesterday, this really looks like an issue with how the dw-mipi-dsi handles powering on and off via the "hack" in mode_set, which doesn't get called again in non-atomic contexts. --- Reproducing the text from the paste from yesterday DRM component enablement is complex and runs in 3 stages: - mode_set goes outwards from crtc -> bridges -> panel - pre_enable goes inwards panel -> bridges -> crtc - enables again goes outwards crtc -> bridges -> panel The pre_enable callback for panels is meant to do its powerup which includes sending its init-sequence - see struct drm_panel documentation. But this in turn generally requires the dsi controller to be up and running. With pre_enable only running inwards the dsi-controller pre_enable only runs _after_ the panel's pre_enable, making panels unable to receive their init sequences. dw_mipi_dsi solved this "creatively" by putting the relevant commands into the mode_set (including clocks and phy setup) and in all-atomic environments this seems to work "ok", as mode_set gets call on every unblank of the display. But this solution stops working once applications use non-atomic modesetting, like X11 with the patch applied to v5.4 to block it from using atomic modesetting or an old qt (v5.9) in this case. Here only the pre_enable and enable callbacks gets called without invoking mode_set before, resulting in display output breaking after the first time the display gets disabled (like blanked due inactivity). For the short term fix this by simply not disabling the dw-dsi parts. --- And while I wanted to tackle that problem at some point, so far I haven't found the time to do so. I've added Yannick and Angelo who also worked on the driver, maybe they have more ideas. Heiko > The display will apparently suspend (right wording?) fine with DPMS, > but will not resume (wording?) fine. This has been an issue since the > introduction of the driver and the introduction of the device (scarlet) > to the kernel, and is still on 5.9-rc2. > > Doing the following: > > $ xset dpms force off # standby, or suspend > $ xset dpms force on > > Pretty much instantly the following messages are logged: > > [ 53.731851] dw-mipi-dsi-rockchip ff96.mipi: failed to write command > FIFO > [ 53.739815] panel-innolux-p079zca ff96.mipi.0: failed to write command > 0 > > Then 120 seconds later, this pair of WARN: > > [ 173.754168] [ cut here ] > [ 173.759343] pclk_mipi_dsi1 already disabled > [ 173.764076] WARNING: CPU: 2 PID: 5182 at drivers/clk/clk.c:952 > clk_core_disable+0x2c/0x94 > [ 173.773216] Modules linked in: > [ 173.776639] CPU: 2 PID: 5182 Comm: X Not tainted 5.9.0-rc2 #1-mobile-nixos > [ 173.784323] Hardware name: Google Scarlet (DT) > [ 173.789292] pstate: 4085 (nZcv daIf -PAN -UAO BTYPE=--) > [ 173.795522] pc : clk_core_disable+0x2c/0x94 > [ 173.800199] lr : clk_core_disable+0x2c/0x94 > [ 173.804871] sp : 800011d3ba20 > [ 173.808573] x29: 800011d3ba20 x28: 0028 > [ 173.814514] x27: c32bdf00 x26: 0038 > [ 173.820455] x25: 800010d2e2eb x24: edece000 > [ 173.826395] x23: f0bea680 x22: 0001 > [ 173.832326] x21: ef82e0e0 x20: f0986500 > [ 173.838266] x19: f0986500 x18: > [ 173.844198] x17: x16: > [ 173.850137] x15: 000a x14: 000b962f > [ 173.856077] x13: 800091d3b76f x12: 0006 > [ 173.862008] x11: x10: 0030 > [ 173.867939] x9 : 800011d3b77d x8 : > [ 173.873869] x7 : 0008 x6 : 80001118811e > [ 173.879809] x5 : f5589e48 x4 : > [ 173.885741] x3 : 0027 x2 : 0027 > [ 173.891680] x1 : e5c3ee40 x0 : 001f > [ 173.897612] Call trace: > [ 173.900349] clk_core_disable+0x2c/0x94 > [ 173.904637] clk_core_disable_lock+0x20/0x34 > [ 173.909413] clk_disable+0x1c/0x28 > [ 173.913220] dw_mipi_dsi_bridge_post_disable+0x80/0x120 > [ 173.919065] drm_atomic_bridge_chain_post_disable+0x74/0x98
Re: [PATCH v8 12/17] pwm: crc: Implement apply() method to support the new atomic PWM API
On Sun, Aug 30, 2020 at 02:57:48PM +0200, Hans de Goede wrote: > Replace the enable, disable and config pwm_ops with an apply op, > to support the new atomic PWM API. > > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > Changes in v6: > - Rebase on 5.9-rc1 > - Use do_div when calculating level because pwm_state.period and .duty_cycle > are now u64 > > Changes in v3: > - Keep crc_pwm_calc_clk_div() helper to avoid needless churn > --- > drivers/pwm/pwm-crc.c | 89 ++- > 1 file changed, 54 insertions(+), 35 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 13/17] pwm: crc: Implement get_state() method
On Sun, Aug 30, 2020 at 02:57:49PM +0200, Hans de Goede wrote: > Implement the pwm_ops.get_state() method to complete the support for the > new atomic PWM API. > > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > Changes in v6: > - Rebase on 5.9-rc1 > - Use DIV_ROUND_UP_ULL because pwm_state.period and .duty_cycle are now u64 > > Changes in v5: > - Fix an indentation issue > > Changes in v4: > - Use DIV_ROUND_UP when calculating the period and duty_cycle from the > controller's register values > > Changes in v3: > - Add Andy's Reviewed-by tag > - Remove extra whitespace to align some code after assignments (requested by > Uwe Kleine-König) > --- > drivers/pwm/pwm-crc.c | 31 +++ > 1 file changed, 31 insertions(+) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm/modeset-lock: Take the modeset BKL for legacy drivers" has been added to the 5.8-stable tree
This is a note to let you know that I've just added the patch titled
drm/modeset-lock: Take the modeset BKL for legacy drivers
to the 5.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-modeset-lock-take-the-modeset-bkl-for-legacy-drivers.patch
and it can be found in the queue-5.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 77ef38574beb3e0b414db48e9c0f04633df68ba6 Mon Sep 17 00:00:00 2001
From: Daniel Vetter
Date: Fri, 14 Aug 2020 11:38:42 +0200
Subject: drm/modeset-lock: Take the modeset BKL for legacy drivers
From: Daniel Vetter
commit 77ef38574beb3e0b414db48e9c0f04633df68ba6 upstream.
This fell off in the conversion in
commit 9bcaa3fe58ab7559e71df798bcff6e0795158695
Author: Michal Orzel
Date: Tue Apr 28 19:10:04 2020 +0200
drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers
but it's caught by the drm_warn_on_modeset_not_all_locked() that the
legacy modeset code uses. Since this is the bkl and it's unclear
what's all protected, play it safe and grab it again for legacy
drivers.
Unfortunately this means we need to sprinkle a few more #includes
around.
Also we need to add the drm_device as a parameter to the _END macro.
Finally remove the mute_lock() from setcrtc, since that's now done by
the macro.
Cc: Alex Deucher
References: https://gitlab.freedesktop.org/drm/amd/-/issues/1224
Fixes: 9bcaa3fe58ab ("drm: Replace drm_modeset_lock/unlock_all with
DRM_MODESET_LOCK_ALL_* helpers")
Cc: Michal Orzel
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.8+
Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20200814093842.3048472-1-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_atomic_helper.c |7 ---
drivers/gpu/drm/drm_color_mgmt.c|2 +-
drivers/gpu/drm/drm_crtc.c |4 +---
drivers/gpu/drm/drm_mode_object.c |4 ++--
drivers/gpu/drm/drm_plane.c |2 +-
include/drm/drm_modeset_lock.h |9 +++--
6 files changed, 16 insertions(+), 12 deletions(-)
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -3105,7 +3106,7 @@ void drm_atomic_helper_shutdown(struct d
if (ret)
DRM_ERROR("Disabling all crtc's during unload failed with
%i\n", ret);
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
}
EXPORT_SYMBOL(drm_atomic_helper_shutdown);
@@ -3245,7 +3246,7 @@ struct drm_atomic_state *drm_atomic_help
}
unlock:
- DRM_MODESET_LOCK_ALL_END(ctx, err);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, err);
if (err)
return ERR_PTR(err);
@@ -3326,7 +3327,7 @@ int drm_atomic_helper_resume(struct drm_
err = drm_atomic_helper_commit_duplicated_state(state, );
- DRM_MODESET_LOCK_ALL_END(ctx, err);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, err);
drm_atomic_state_put(state);
return err;
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -294,7 +294,7 @@ int drm_mode_gamma_set_ioctl(struct drm_
crtc->gamma_size, );
out:
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
return ret;
}
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -561,7 +561,6 @@ int drm_mode_setcrtc(struct drm_device *
if (crtc_req->mode_valid && !drm_lease_held(file_priv, plane->base.id))
return -EACCES;
- mutex_lock(>dev->mode_config.mutex);
DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx,
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
@@ -728,8 +727,7 @@ out:
fb = NULL;
mode = NULL;
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
- mutex_unlock(>dev->mode_config.mutex);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
return ret;
}
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -428,7 +428,7 @@ int drm_mode_obj_get_properties_ioctl(st
out_unref:
drm_mode_object_put(obj);
out:
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
return ret;
}
@@ -470,7 +470,7 @@ static int set_property_legacy(struct dr
break;
}
drm_property_change_valid_put(prop, ref);
- DRM_MODESET_LOCK_ALL_END(ctx, ret);
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
return ret;
}
--- a/drivers/gpu/drm/drm_plane.c
+++
Re: [RFT 3/4] ARM: dts: exynos: Move CMU assigned ISP clocks to buses in Exynos3250
On Mon, Aug 31, 2020 at 10:19:06AM +0200, Krzysztof Kozlowski wrote:
> On Mon, Aug 31, 2020 at 10:11:02AM +0200, Marek Szyprowski wrote:
> > Hi Krzysztof,
> >
> > On 29.08.2020 19:25, Krzysztof Kozlowski wrote:
> > > Commit 52005dece527 ("ARM: dts: Add assigned clock parents to CMU node
> > > for exynos3250") added assigned clocks under Clock Management Unit to
> > > fix hangs when accessing ISP registers.
> > >
> > > This is not the place for it as CMU does not have a required "clocks"
> > > property:
> > >
> > >arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml:
> > > clock-controller@1003: 'clocks' is a dependency of 'assigned-clocks'
> > >
> > > Signed-off-by: Krzysztof Kozlowski
> > >
> > > ---
> > >
> > > Not tested and I wonder whether actually correct. For example, what will
> > > happen if devfreq (exynos-bus) is not built in?
> > >
> > > Could someone verify it?
> >
> > Sorry, but this patch is not correct. Those clocks has noting with
> > bus-freq. The assigned clocks property should stay where it is. Maybe
> > one need to fix the schemas for dts verification. Those clocks has to be
> > set (and so generic clock framework does) according to the assigned
> > clocks properties once the clock controller is instantiated.
> >
> > The only alternative would be to add exynos-subcmu variant to properly
> > link CMU with the ISP power domain, but assuming that there is no Exynos
> > 3250 ISP driver in mainline (and probably never will be), it is safe to
> > keep those clocks sourced from 24MHz crystal.
>
> Thanks for the clarification. Another solution to silence the warning
> could be to add a "clocks" property for FIN_PLL, although the driver
> actually does not take it.
>
> This is the only remaining dtschema check warning on Exynos3250 so it
> would be nice to at least silence it. My goal is to have all them
> schema-correct, or as close as possible (for Exynos4 the camera node is
> a trouble).
BTW, if you have some time, it would be awesome if you could test all
the series (on Exynos3250 obviously with this patch reverted):
https://github.com/krzk/linux/tree/for-next/dts-exynos-schema-cleanups
The Exynos5 cleanup is ongoing, so there will be more patches. But
Exynos3 and Exynos4 I finished.
Best regards,
Krzysztof
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/plane: add drmm_universal_plane_alloc()
Hi Philipp,
url:
https://github.com/0day-ci/linux/commits/Philipp-Zabel/drm-add-drmm_encoder_alloc/20200826-203629
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-m001-20200826 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
New smatch warnings:
drivers/gpu/drm/drm_plane.c:302 drm_universal_plane_init() error: uninitialized
symbol 'ap'.
drivers/gpu/drm/drm_plane.c:345 __drmm_universal_plane_alloc() error:
uninitialized symbol 'ap'.
Old smatch warnings:
drivers/gpu/drm/drm_plane.c:117 create_in_format_blob() error: potential null
dereference 'blob'. (drm_property_create_blob returns null)
#
https://github.com/0day-ci/linux/commit/d809a51da3d2939a84ecf6b4ada8f5be6c3ecb35
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Philipp-Zabel/drm-add-drmm_encoder_alloc/20200826-203629
git checkout d809a51da3d2939a84ecf6b4ada8f5be6c3ecb35
vim +/ap +302 drivers/gpu/drm/drm_plane.c
d809a51da3d293 Philipp Zabel 2020-08-26 287 int
drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
d809a51da3d293 Philipp Zabel 2020-08-26 288 uint32_t
possible_crtcs,
d809a51da3d293 Philipp Zabel 2020-08-26 289 const
struct drm_plane_funcs *funcs,
d809a51da3d293 Philipp Zabel 2020-08-26 290 const
uint32_t *formats, unsigned int format_count,
d809a51da3d293 Philipp Zabel 2020-08-26 291 const
uint64_t *format_modifiers,
d809a51da3d293 Philipp Zabel 2020-08-26 292 enum
drm_plane_type type,
d809a51da3d293 Philipp Zabel 2020-08-26 293 const char
*name, ...)
d809a51da3d293 Philipp Zabel 2020-08-26 294 {
d809a51da3d293 Philipp Zabel 2020-08-26 295va_list ap;
^^
d809a51da3d293 Philipp Zabel 2020-08-26 296int ret;
d809a51da3d293 Philipp Zabel 2020-08-26 297
d809a51da3d293 Philipp Zabel 2020-08-26 298if (name)
d809a51da3d293 Philipp Zabel 2020-08-26 299va_start(ap, name);
^^
d809a51da3d293 Philipp Zabel 2020-08-26 300ret =
__drm_universal_plane_init(dev, plane, possible_crtcs, funcs,
d809a51da3d293 Philipp Zabel 2020-08-26 301
formats, format_count, format_modifiers,
d809a51da3d293 Philipp Zabel 2020-08-26 @302
type, name, ap);
^^
This isn't always initialized. Presumably it's not a problem but
runtime tools like KASan (syzbot) will detect the load and complain as
well so it's probably better to silence it.
d809a51da3d293 Philipp Zabel 2020-08-26 303if (name)
d809a51da3d293 Philipp Zabel 2020-08-26 304va_end(ap);
d809a51da3d293 Philipp Zabel 2020-08-26 305return ret;
d809a51da3d293 Philipp Zabel 2020-08-26 306 }
43968d7b806d7a Daniel Vetter 2016-09-21 307
EXPORT_SYMBOL(drm_universal_plane_init);
43968d7b806d7a Daniel Vetter 2016-09-21 308
d809a51da3d293 Philipp Zabel 2020-08-26 309 static void
drmm_universal_plane_alloc_release(struct drm_device *dev, void *ptr)
d809a51da3d293 Philipp Zabel 2020-08-26 310 {
d809a51da3d293 Philipp Zabel 2020-08-26 311struct drm_plane *plane = ptr;
d809a51da3d293 Philipp Zabel 2020-08-26 312
d809a51da3d293 Philipp Zabel 2020-08-26 313if (WARN_ON(!plane->dev))
d809a51da3d293 Philipp Zabel 2020-08-26 314return;
d809a51da3d293 Philipp Zabel 2020-08-26 315
d809a51da3d293 Philipp Zabel 2020-08-26 316drm_plane_cleanup(plane);
d809a51da3d293 Philipp Zabel 2020-08-26 317 }
d809a51da3d293 Philipp Zabel 2020-08-26 318
d809a51da3d293 Philipp Zabel 2020-08-26 319 void
*__drmm_universal_plane_alloc(struct drm_device *dev, size_t size,
d809a51da3d293 Philipp Zabel 2020-08-26 320
size_t offset, uint32_t possible_crtcs,
d809a51da3d293 Philipp Zabel 2020-08-26 321
const struct drm_plane_funcs *funcs,
d809a51da3d293 Philipp Zabel 2020-08-26 322
const uint32_t *formats, unsigned int format_count,
d809a51da3d293 Philipp Zabel 2020-08-26 323
const uint64_t *format_modifiers,
d809a51da3d293 Philipp Zabel 2020-08-26 324 enum
drm_plane_type type,
d809a51da3d293 Philipp Zabel 2020-08-26 325
const char *name, ...)
d809a51da3d293 Philipp Zabel 2020-08-26 326 {
d809a51da3d293 Philipp Zabel 2020-08-26 327void *container;
d809a51da3d293 Philipp Zabel 2020-08-26 328struct drm_plane *plane;
d809a51da3d293 Philipp Zabel 2020-08-26 329
Re: [PATCH] dma-buf: fix kernel-doc warning in
Am 31.08.20 um 06:16 schrieb Randy Dunlap:
Fix kernel-doc warning in :
../include/linux/dma-buf.h:330: warning: Function parameter or member
'name_lock' not described in 'dma_buf'
Signed-off-by: Randy Dunlap
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Christian König
---
include/linux/dma-buf.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- lnx-59-rc3.orig/include/linux/dma-buf.h
+++ lnx-59-rc3/include/linux/dma-buf.h
@@ -283,6 +283,7 @@ struct dma_buf_ops {
* @exp_name: name of the exporter; useful for debugging.
* @name: userspace-provided name; useful for accounting and debugging,
*protected by @resv.
+ * @name_lock: spinlock to protect name access
* @owner: pointer to exporter module; used for refcounting when exporter is a
* kernel module.
* @list_node: node for dma_buf accounting and debugging.
@@ -311,7 +312,7 @@ struct dma_buf {
void *vmap_ptr;
const char *exp_name;
const char *name;
- spinlock_t name_lock; /* spinlock to protect name access */
+ spinlock_t name_lock;
struct module *owner;
struct list_head list_node;
void *priv;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203905] amdgpu:actual_brightness has unreal/wrong value
https://bugzilla.kernel.org/show_bug.cgi?id=203905 shanmukhat...@gmail.com (shanmukhat...@gmail.com) changed: What|Removed |Added CC||shanmukhat...@gmail.com --- Comment #13 from shanmukhat...@gmail.com (shanmukhat...@gmail.com) --- I have built a workaround for this issue by forking systemd-backlight for the time-being. It has been tested on my ASUS TUF FX505DT with Ryzen 3550H. https://github.com/shanmukhateja/systemd/tree/fix-amdgpu-backlight -- 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 v8 06/17] pwm: lpss: Use pwm_lpss_restore() when restoring state on resume
On Sun, Aug 30, 2020 at 02:57:42PM +0200, Hans de Goede wrote: > Before this commit a suspend + resume of the LPSS PWM controller > would result in the controller being reset to its defaults of > output-freq = clock/256, duty-cycle=100%, until someone changes > to the output-freq and/or duty-cycle are made. > > This problem has been masked so far because the main consumer > (the i915 driver) was always making duty-cycle changes on resume. > With the conversion of the i915 driver to the atomic PWM API the > driver now only disables/enables the PWM on suspend/resume leaving > the output-freq and duty as is, triggering this problem. Doesn't this imply that there's another bug at play here? At the PWM API level you're applying a state and it's up to the driver to ensure that the hardware state after ->apply() is what the software has requested. If you only switch the enable state and that doesn't cause period and duty cycle to be updated it means that your driver isn't writing those registers when it should be. > The LPSS PWM controller has a mechanism where the ctrl register value > and the actual base-unit and on-time-div values used are latched. When > software sets the SW_UPDATE bit then at the end of the current PWM cycle, > the new values from the ctrl-register will be latched into the actual > registers, and the SW_UPDATE bit will be cleared. > > The problem is that before this commit our suspend/resume handling > consisted of simply saving the PWM ctrl register on suspend and > restoring it on resume, without setting the PWM_SW_UPDATE bit. > When the controller has lost its state over a suspend/resume and thus > has been reset to the defaults, just restoring the register is not > enough. We must also set the SW_UPDATE bit to tell the controller to > latch the restored values into the actual registers. > > Fixing this problem is not as simple as just or-ing in the value which > is being restored with SW_UPDATE. If the PWM was enabled before we must > write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE. > We must also wait for PWM_SW_UPDATE to become 0 again and depending on the > model we must do this either before or after the setting of PWM_ENABLE. > > All the necessary logic for doing this is already present inside > pwm_lpss_apply(), so instead of duplicating this inside the resume > handler, this commit adds a new pwm_lpss_restore() helper which mirrors > pwm_lpss_apply() minus the runtime-pm reference handling (which we should > not change on resume). If this is all already implemented in pwm_lpss_apply(), why isn't it working for the suspend/resume case? It shouldn't matter that the consumer only changes the enable/disable state. After ->apply() successfully returns your hardware should be programmed with exactly the state that the consumer requested. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/10] dt-bindings: sound: samsung-i2s: Use unevaluatedProperties
On 29.08.2020 16:24, Krzysztof Kozlowski wrote:
> Additional properties actually might appear (e.g. power-domains) so use
> unevaluatedProperties to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: i2s@1144:
> Additional properties are not allowed ('power-domains', '#address-cells',
> 'interrupts', '#size-cells' were unexpected)
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Sylwester Nawrocki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge
Add a new DRM bridge driver for Cadence MHDP8546 DPTX IP used in TI J721E
SoC. MHDP DPTX IP is the component that complies with VESA DisplayPort (DP)
and embedded Display Port (eDP) standards. It integrates uCPU running the
embedded Firmware (FW) interfaced over APB interface.
Basically, it takes a DPI stream as input and outputs it encoded in DP
format. Currently, it supports only SST mode.
Co-developed-by: Tomi Valkeinen
Signed-off-by: Tomi Valkeinen
Co-developed-by: Jyri Sarha
Signed-off-by: Jyri Sarha
Signed-off-by: Quentin Schulz
Signed-off-by: Yuti Amonkar
Signed-off-by: Swapnil Jakhade
---
drivers/gpu/drm/bridge/Kconfig|2 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/cadence/Kconfig| 11 +
drivers/gpu/drm/bridge/cadence/Makefile |3 +
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 2548 +
.../drm/bridge/cadence/cdns-mhdp8546-core.h | 402 +++
6 files changed, 2967 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/cadence/Kconfig
create mode 100644 drivers/gpu/drm/bridge/cadence/Makefile
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3e11af4e9f63..ef91646441b1 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -241,6 +241,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
source "drivers/gpu/drm/bridge/adv7511/Kconfig"
+source "drivers/gpu/drm/bridge/cadence/Kconfig"
+
source "drivers/gpu/drm/bridge/synopsys/Kconfig"
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index c589a6a7cbe1..2b3aff104e46 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -25,4 +25,5 @@ obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
obj-y += analogix/
+obj-y += cadence/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
new file mode 100644
index ..f49d77eb7814
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config DRM_CDNS_MHDP8546
+ tristate "Cadence DPI/DP bridge"
+ select DRM_KMS_HELPER
+ select DRM_PANEL_BRIDGE
+ depends on OF
+ help
+ Support Cadence DPI to DP bridge. This is an internal
+ bridge and is meant to be directly embedded in a SoC.
+ It takes a DPI stream as input and outputs it encoded
+ in DP format.
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
new file mode 100644
index ..676739cdf5e6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
+cdns-mhdp8546-y := cdns-mhdp8546-core.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
new file mode 100644
index ..14be6f370d6e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -0,0 +1,2548 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cadence MHDP8546 DP bridge driver.
+ *
+ * Copyright (C) 2020 Cadence Design Systems, Inc.
+ *
+ * Authors: Quentin Schulz
+ * Swapnil Jakhade
+ * Yuti Amonkar
+ * Tomi Valkeinen
+ * Jyri Sarha
+ *
+ * TODO:
+ * - Implement optimized mailbox communication using mailbox interrupts
+ * - Add support for power management
+ * - Add support for features like audio, MST and fast link training
+ * - Implement request_fw_cancel to handle HW_STATE
+ * - Fix asynchronous loading of firmware implementation
+ * - Add DRM helper function for cdns_mhdp_lower_link_rate
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "cdns-mhdp8546-core.h"
+
+static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
+{
+ int ret, empty;
+
+ WARN_ON(!mutex_is_locked(>mbox_mutex));
+
+ ret = readx_poll_timeout(readl, mhdp->regs + CDNS_MAILBOX_EMPTY,
+empty, !empty, MAILBOX_RETRY_US,
+MAILBOX_TIMEOUT_US);
+ if (ret < 0)
+ return ret;
+
+ return readl(mhdp->regs + CDNS_MAILBOX_RX_DATA) & 0xff;
+}
+
+static int cdns_mhdp_mailbox_write(struct cdns_mhdp_device *mhdp, u8 val)
+{
+ int ret, full;
+
+ WARN_ON(!mutex_is_locked(>mbox_mutex));
+
+ ret = readx_poll_timeout(readl, mhdp->regs
Re: nouveau PUSHBUFFER_ERR on 5.9.0-rc2-next-20200824
On Mon, Aug 31, 2020 at 7:30 AM Ben Skeggs wrote:
>
> On Tue, 25 Aug 2020 at 17:21, Alexander Kapshuk
> wrote:
> >
> > Since upgrading to linux-next based on 5.9.0-rc1 and 5.9.0-rc2 I have
> > had my mouse pointer disappear soon after logging in, and I have
> > observed the system freezing temporarily when clicking on objects and
> > when typing text.
> > I have also found records of push buffer errors in dmesg output:
> > [ 6625.450394] nouveau :01:00.0: disp: ERROR 1 [PUSHBUFFER_ERR] 02
> > [] chid 0 mthd data 0400
> Hey,
>
> Yeah, I'm aware of this. Lyude and I have both seen it, but it's been
> very painful to track down to what's actually causing it so far. It
> likely is the commit you mentioned that's at fault, and I'm still
> working to find a proper solution before I revert it.
>
> Ben.
>
> >
> > I tried setting CONFIG_NOUVEAU_DEBUG=5 (tracing) to try and collect
> > further debug info, but nothing caught the eye.
> >
> > The error message in question comes from nv50_disp_intr_error in
> > drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c:613,645.
> > And nv50_disp_intr_error is called from nv50_disp_intr in the
> > following while block:
> > drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c:647,658
> > void
> > nv50_disp_intr(struct nv50_disp *disp)
> > {
> > struct nvkm_device *device = disp->base.engine.subdev.device;
> > u32 intr0 = nvkm_rd32(device, 0x610020);
> > u32 intr1 = nvkm_rd32(device, 0x610024);
> >
> > while (intr0 & 0x001f) {
> > u32 chid = __ffs(intr0 & 0x001f) - 16;
> > nv50_disp_intr_error(disp, chid);
> > intr0 &= ~(0x0001 << chid);
> > }
> > ...
> > }
> >
> > Could this be in any way related to this series of commits?
> > commit 0a96099691c8cd1ac0744ef30b6846869dc2b566
> > Author: Ben Skeggs
> > Date: Tue Jul 21 11:34:07 2020 +1000
> >
> > drm/nouveau/kms/nv50-: implement proper push buffer control logic
> >
> > We had a, what was supposed to be temporary, hack in the KMS code where
> > we'd
> > completely drain an EVO/NVD channel's push buffer when wrapping to the
> > start
> > again, instead of treating it as a ring buffer.
> >
> > Let's fix that, finally.
> >
> > Signed-off-by: Ben Skeggs
> >
> > Here are my GPU details:
> > 01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [GeForce
> > 210] (rev a1)
> > Subsystem: Micro-Star International Co., Ltd. [MSI] Device 8a93
> > Kernel driver in use: nouveau
> >
> > The last linux-next kernel I built where the problem reported does not
> > manifest itself is 5.8.0-rc6-next-20200720.
> >
> > I would appreciate being given any pointers on how to further debug this.
> > Or is git bisect the only way to proceed with this?
> >
> > Thanks.
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Thanks a lot for getting back to me about this.
Please let me know if there's anything else I can do to help track this down.
Alexander.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 答复: [PATCH v2 6/6] drm/panel: Add Ilitek ILI9341 DBI panel driver
Hi Leon,
Le dim. 30 août 2020 à 16:36, 何小龙 (Leon He)
a écrit :
+struct ili9341 {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi;
+ const struct ili9341_pdata *pdata;
+
+ struct gpio_desc*reset_gpiod;
+ u32 rotation;
+};
+
Hi Paul, you put the mipi_dsi_device inside the struct. I think it
maybe not
a good idea. That means the panel has a MIPI-DSI interface but it
doesn't
have actually.
+static int ili9341_probe(struct mipi_dsi_device *dsi)
+{
+ struct device *dev = >dev;
+ struct ili9341 *priv;
+ int ret;
+
+ /* See comment for mipi_dbi_spi_init() */
+ if (!dev->coherent_dma_mask) {
+ ret = dma_coerce_mask_and_coherent(dev,
DMA_BIT_MASK(32));
+ if (ret) {
+ dev_warn(dev, "Failed to set dma mask
%d\n", ret);
+ return ret;
+ }
+ }
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ mipi_dsi_set_drvdata(dsi, priv);
+ priv->dsi = dsi;
+
+ device_property_read_u32(dev, "rotation", >rotation);
+
+ priv->pdata = device_get_match_data(dev);
+ if (!priv->pdata)
+ return -EINVAL;
+
+ drm_panel_init(>panel, dev, _funcs,
+ DRM_MODE_CONNECTOR_DPI);
+
+ priv->reset_gpiod = devm_gpiod_get(dev, "reset",
GPIOD_OUT_HIGH);
+ if (IS_ERR(priv->reset_gpiod)) {
+ dev_err(dev, "Couldn't get our reset GPIO\n");
+ return PTR_ERR(priv->reset_gpiod);
+ }
+
+ ret = drm_panel_of_backlight(>panel);
+ if (ret < 0) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get backlight
handle\n");
+ return ret;
+ }
+
+ drm_panel_add(>panel);
+
+ dsi->bus_type = priv->pdata->bus_type;
+ dsi->lanes = priv->pdata->lanes;
+ dsi->format = MIPI_DSI_FMT_RGB565;
+
+ ret = mipi_dsi_attach(dsi);
+ if (ret) {
+ dev_err(dev, "Failed to attach DSI panel\n");
+ goto err_panel_remove;
+ }
+
+ ret = mipi_dsi_maybe_register_tiny_driver(dsi);
+ if (ret) {
+ dev_err(dev, "Failed to init TinyDRM driver\n");
+ goto err_mipi_dsi_detach;
+ }
+
+ return 0;
+
+err_mipi_dsi_detach:
+ mipi_dsi_detach(dsi);
+err_panel_remove:
+ drm_panel_remove(>panel);
+ return ret;
+}
+
+static int ili9341_remove(struct mipi_dsi_device *dsi)
+{
+ struct ili9341 *priv = mipi_dsi_get_drvdata(dsi);
+
+ mipi_dsi_detach(dsi);
+ drm_panel_remove(>panel);
+
+ drm_panel_disable(>panel);
+ drm_panel_unprepare(>panel);
+
+ return 0;
+}
+
+static const struct ili9341_pdata yx240qv29_pdata = {
+ .mode = { DRM_SIMPLE_MODE(240, 320, 37, 49) },
+ .width_mm = 0, // TODO
+ .height_mm = 0, // TODO
+ .bus_type = MIPI_DCS_BUS_TYPE_DBI_SPI_C3,
+ .lanes = 1,
+};
+
+static const struct of_device_id ili9341_of_match[] = {
+ { .compatible = "adafruit,yx240qv29", .data =
_pdata },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ili9341_of_match);
+
+static struct mipi_dsi_driver ili9341_dsi_driver = {
+ .probe = ili9341_probe,
+ .remove = ili9341_remove,
+ .driver = {
+ .name = "ili9341-dsi",
+ .of_match_table = ili9341_of_match,
+ },
+};
+module_mipi_dsi_driver(ili9341_dsi_driver);
Again, you treat this driver as a mipi dsi driver but for a MIPI-DBI
(I8080/SPI)
panel device. That will make developers confused.
Is it possible to just add a mipi_dbi_driver for I8080/SPI interface
panel?
Thanks!
Please read the cover letter, it explains why it's done this way. The
whole point of this patchset is to merge DSI and DBI frameworks in a
way that can be maintained.
Cheers,
-Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v6 4/6] drm/sprd: add Unisoc's drm display controller driver
Daniel Vetter 于2020年7月29日周三 上午5:51写道： > > On Tue, Jul 28, 2020 at 12:08 PM Kevin Tang wrote: > > > > From: Kevin Tang > > > > Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem. > > It's support multi planes, scaler, rotation, PQ(Picture Quality) and more. > > > > RFC v6: > > - Access registers via readl/writel > > - Checking for unsupported KMS properties (format, rotation, blend_mode, > > etc) on plane_check ops > > - Remove always true checks for dpu core ops > > > > Cc: Orson Zhai > > Cc: Chunyan Zhang > > Signed-off-by: Kevin Tang > > Quickly scrolled through this, and the entire thing very much leaves a > midlayer heavy aftertaste. Do we really need stuff like struct dpu_layer > and struct dpu_core_ops? They only seem to complicate the code base, and > seem to have no real reason. The indirection with first computing register > values into a sprd_plane/crtc structure, and then writing it into hardware > is also a bit much - I recommend to only do that if you have to compute > values in _check to validate them, so that the computation doesn't have to > be repeated in the commit phase functions. Hi daniel, Maybe some DPU's IP verison, there will be some differences in the DPU on each Soc. Not only control registers, there will be some differences in control logic and functions If access H/W registers all put into crtc or plane driver, how did others deal with it? Add Soc's macro? When there are too many H/W IPs, split into different files(dpu_core_ops) according to different IP, I think the code project will be more convenient to keeping. For multiple H/W IP, the popular design method is? > > Also, the layer and pending_flips stuff in sprd_dpu don't work with > atomic, that races. You have to put all that stuff into state objects, or > if it's some data shared with interrupt handlers (doesn't seem to be the > case here), it needs its own locking, and any data you need in the > interrupt handler must be copied over. the layer and pending_flips, we put into atomic_flush, We do have some features related to interrupt handlers, but it has not been submitted yet. So pending_flips lock have not been added. > > Also no devm_kzalloc for anything containined a drm_* structure, that's > the wrong lifetime. > > So yeah high level review is that I think this driver would benefit a lot > from a pile of demidlayer. > > Cheers, Daniel > > > --- > > drivers/gpu/drm/sprd/Makefile | 5 +- > > drivers/gpu/drm/sprd/dpu/Makefile | 3 + > > drivers/gpu/drm/sprd/dpu/dpu_r2p0.c | 503 > > drivers/gpu/drm/sprd/sprd_dpu.c | 646 > > > > drivers/gpu/drm/sprd/sprd_dpu.h | 187 +++ > > drivers/gpu/drm/sprd/sprd_drm.c | 1 + > > drivers/gpu/drm/sprd/sprd_drm.h | 2 + > > 7 files changed, 1346 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/sprd/dpu/Makefile > > create mode 100644 drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h > > > > diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile > > index 86d95d9..88ab32a 100644 > > --- a/drivers/gpu/drm/sprd/Makefile > > +++ b/drivers/gpu/drm/sprd/Makefile > > @@ -2,4 +2,7 @@ > > > > subdir-ccflags-y += -I$(srctree)/$(src) > > > > -obj-y := sprd_drm.o > > +obj-y := sprd_drm.o \ > > + sprd_dpu.o > > + > > +obj-y += dpu/ > > diff --git a/drivers/gpu/drm/sprd/dpu/Makefile > > b/drivers/gpu/drm/sprd/dpu/Makefile > > new file mode 100644 > > index 000..40278b6 > > --- /dev/null > > +++ b/drivers/gpu/drm/sprd/dpu/Makefile > > @@ -0,0 +1,3 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > + > > +obj-y += dpu_r2p0.o > > diff --git a/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > > b/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > > new file mode 100644 > > index 000..4b9521d > > --- /dev/null > > +++ b/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > > @@ -0,0 +1,503 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2020 Unisoc Inc. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > + > > +#include "sprd_dpu.h" > > + > > +/* DPU registers size, 4 Bytes(32 Bits) */ > > +#define DPU_REG_SIZE 0x04 > > + > > +/* Layer registers offset */ > > +#define DPU_LAY_REG_OFFSET 0x0C > > + > > +#define DPU_LAY_REG(reg, index) \ > > + (reg + index * DPU_LAY_REG_OFFSET * DPU_REG_SIZE) > > + > > +#define DPU_REG_RD(reg) readl_relaxed(reg) > > + > > +#define DPU_REG_WR(reg, mask) writel_relaxed(mask, reg) > > + > > +#define DPU_REG_SET(reg, mask) \ > > + writel_relaxed(readl_relaxed(reg) | mask, reg) > > + > > +#define DPU_REG_CLR(reg, mask) \ > > + writel_relaxed(readl_relaxed(reg) & ~mask, reg) > > + > > +/* Global control registers */ > > +#define REG_DPU_CTRL 0x04 > > +#define REG_DPU_CFG0 0x08 > > +#define REG_DPU_CFG1 0x0C > > +#define REG_DPU_CFG2 0x10 >
[PATCH] drm/gma500: Constify static structs
The only usage of these is to assign their address to the fbops field in
the fb_info struct, which is a const pointer. Make them const to allow
the compiler to put them in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/gma500/framebuffer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index da02d7e8a8f5..54d9876b5305 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -164,7 +164,7 @@ static int psbfb_mmap(struct fb_info *info, struct
vm_area_struct *vma)
return 0;
}
-static struct fb_ops psbfb_ops = {
+static const struct fb_ops psbfb_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
.fb_setcolreg = psbfb_setcolreg,
@@ -175,7 +175,7 @@ static struct fb_ops psbfb_ops = {
.fb_sync = psbfb_sync,
};
-static struct fb_ops psbfb_roll_ops = {
+static const struct fb_ops psbfb_roll_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
.fb_setcolreg = psbfb_setcolreg,
@@ -186,7 +186,7 @@ static struct fb_ops psbfb_roll_ops = {
.fb_mmap = psbfb_mmap,
};
-static struct fb_ops psbfb_unaccel_ops = {
+static const struct fb_ops psbfb_unaccel_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
.fb_setcolreg = psbfb_setcolreg,
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 3/3] drm: bridge: cdns-mhdp8546: Add TI J721E wrapper
Add J721E wrapper for mhdp, which sets up the clock and data muxes.
Signed-off-by: Jyri Sarha
Signed-off-by: Yuti Amonkar
Signed-off-by: Swapnil Jakhade
Reviewed-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/cadence/Kconfig| 13
drivers/gpu/drm/bridge/cadence/Makefile | 1 +
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 10 +++
.../drm/bridge/cadence/cdns-mhdp8546-core.h | 1 +
.../drm/bridge/cadence/cdns-mhdp8546-j721e.c | 78 +++
.../drm/bridge/cadence/cdns-mhdp8546-j721e.h | 19 +
6 files changed, 122 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.h
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index f49d77eb7814..511d67b16d14 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -9,3 +9,16 @@ config DRM_CDNS_MHDP8546
bridge and is meant to be directly embedded in a SoC.
It takes a DPI stream as input and outputs it encoded
in DP format.
+
+if DRM_CDNS_MHDP8546
+
+config DRM_CDNS_MHDP8546_J721E
+ depends on ARCH_K3_J721E_SOC || COMPILE_TEST
+ bool "J721E Cadence DPI/DP wrapper support"
+ default y
+ help
+ Support J721E Cadence DPI/DP wrapper. This is a wrapper
+ which adds support for J721E related platform ops. It
+ initializes the J721E Display Port and sets up the
+ clock and data muxes.
+endif
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index 676739cdf5e6..8f647991b374 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
cdns-mhdp8546-y := cdns-mhdp8546-core.o
+cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 14be6f370d6e..5dc83b2e3603 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -50,6 +50,8 @@
#include "cdns-mhdp8546-core.h"
+#include "cdns-mhdp8546-j721e.h"
+
static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
{
int ret, empty;
@@ -2522,6 +2524,14 @@ static int cdns_mhdp_remove(struct platform_device *pdev)
static const struct of_device_id mhdp_ids[] = {
{ .compatible = "cdns,mhdp8546", },
+#ifdef CONFIG_DRM_CDNS_MHDP8546_J721E
+ { .compatible = "ti,j721e-mhdp8546",
+ .data = &(const struct cdns_mhdp_platform_info) {
+ .timings = _ti_j721e_bridge_timings,
+ .ops = _ti_j721e_ops,
+ },
+ },
+#endif
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mhdp_ids);
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
index 14ba7431fab8..d2183f3f3263 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.h
@@ -344,6 +344,7 @@ struct cdns_mhdp_platform_info {
struct cdns_mhdp_device {
void __iomem *regs;
+ void __iomem *j721e_regs;
struct device *dev;
struct clk *clk;
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
new file mode 100644
index ..dfe1b59514f7
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-j721e.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI j721e Cadence MHDP8546 DP wrapper
+ *
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: Jyri Sarha
+ */
+
+#include
+#include
+
+#include "cdns-mhdp8546-j721e.h"
+
+#defineREVISION0x00
+#defineDPTX_IPCFG 0x04
+#defineECC_MEM_CFG 0x08
+#defineDPTX_DSC_CFG0x0c
+#defineDPTX_SRC_CFG0x10
+#defineDPTX_VIF_SECURE_MODE_CFG0x14
+#defineDPTX_VIF_CONN_STATUS0x18
+#definePHY_CLK_STATUS 0x1c
+
+#define DPTX_SRC_AIF_ENBIT(16)
+#define DPTX_SRC_VIF_3_IN30B BIT(11)
+#define DPTX_SRC_VIF_2_IN30B BIT(10)
+#define DPTX_SRC_VIF_1_IN30B BIT(9)
+#define DPTX_SRC_VIF_0_IN30B BIT(8)
+#define DPTX_SRC_VIF_3_SEL_DPI5BIT(7)
+#define DPTX_SRC_VIF_3_SEL_DPI30
+#define DPTX_SRC_VIF_2_SEL_DPI4BIT(6)
+#define DPTX_SRC_VIF_2_SEL_DPI20
+#define DPTX_SRC_VIF_1_SEL_DPI3BIT(5)
+#define DPTX_SRC_VIF_1_SEL_DPI1
innolux p097pfg dpms off/on fails (on gru-scarlet)
Hi, I have an Asus Chromebook Tablet CT100PA, which I will refer to as "dumo" from this point on, which is a specific variant of gru-scarlet. As far as I am aware, all gru-scarlet are the same, except for the display, and in turn the different scarlets with the innolux panel are the same. I do not have the hardware to verify the kingdisplay variant's behaviour, though I don't really expect it to fail the same way, but it is still a possibility that there is a root cause that could cause a similar failure. The display will apparently suspend (right wording?) fine with DPMS, but will not resume (wording?) fine. This has been an issue since the introduction of the driver and the introduction of the device (scarlet) to the kernel, and is still on 5.9-rc2. Doing the following: $ xset dpms force off # standby, or suspend $ xset dpms force on Pretty much instantly the following messages are logged: [ 53.731851] dw-mipi-dsi-rockchip ff96.mipi: failed to write command FIFO [ 53.739815] panel-innolux-p079zca ff96.mipi.0: failed to write command 0 Then 120 seconds later, this pair of WARN: [ 173.754168] [ cut here ] [ 173.759343] pclk_mipi_dsi1 already disabled [ 173.764076] WARNING: CPU: 2 PID: 5182 at drivers/clk/clk.c:952 clk_core_disable+0x2c/0x94 [ 173.773216] Modules linked in: [ 173.776639] CPU: 2 PID: 5182 Comm: X Not tainted 5.9.0-rc2 #1-mobile-nixos [ 173.784323] Hardware name: Google Scarlet (DT) [ 173.789292] pstate: 4085 (nZcv daIf -PAN -UAO BTYPE=--) [ 173.795522] pc : clk_core_disable+0x2c/0x94 [ 173.800199] lr : clk_core_disable+0x2c/0x94 [ 173.804871] sp : 800011d3ba20 [ 173.808573] x29: 800011d3ba20 x28: 0028 [ 173.814514] x27: c32bdf00 x26: 0038 [ 173.820455] x25: 800010d2e2eb x24: edece000 [ 173.826395] x23: f0bea680 x22: 0001 [ 173.832326] x21: ef82e0e0 x20: f0986500 [ 173.838266] x19: f0986500 x18: [ 173.844198] x17: x16: [ 173.850137] x15: 000a x14: 000b962f [ 173.856077] x13: 800091d3b76f x12: 0006 [ 173.862008] x11: x10: 0030 [ 173.867939] x9 : 800011d3b77d x8 : [ 173.873869] x7 : 0008 x6 : 80001118811e [ 173.879809] x5 : f5589e48 x4 : [ 173.885741] x3 : 0027 x2 : 0027 [ 173.891680] x1 : e5c3ee40 x0 : 001f [ 173.897612] Call trace: [ 173.900349] clk_core_disable+0x2c/0x94 [ 173.904637] clk_core_disable_lock+0x20/0x34 [ 173.909413] clk_disable+0x1c/0x28 [ 173.913220] dw_mipi_dsi_bridge_post_disable+0x80/0x120 [ 173.919065] drm_atomic_bridge_chain_post_disable+0x74/0x98 [ 173.925297] drm_atomic_helper_commit_modeset_disables+0x3d8/0x3dc [ 173.932208] drm_atomic_helper_commit_tail_rpm+0x20/0xa0 [ 173.938138] commit_tail+0x74/0xf8 [ 173.941941] drm_atomic_helper_commit+0x104/0x108 [ 173.947203] drm_atomic_commit+0x48/0x54 [ 173.951590] drm_atomic_connector_commit_dpms+0xa0/0x100 [ 173.957531] drm_mode_obj_set_property_ioctl+0xd4/0x2c8 [ 173.963378] drm_connector_property_set_ioctl+0x20/0x28 [ 173.969220] drm_ioctl_kernel+0xa0/0xdc [ 173.973507] drm_ioctl+0x2c4/0x2ec [ 173.977312] vfs_ioctl+0x24/0x40 [ 173.980921] __arm64_sys_ioctl+0x74/0xa4 [ 173.985299] el0_svc_common.constprop.0+0xe0/0x160 [ 173.990655] do_el0_svc+0x44/0x70 [ 173.994362] el0_sync_handler+0xc8/0x184 [ 173.998747] el0_sync+0x140/0x180 [ 174.002450] ---[ end trace 6c6d0de3ca79ec7d ]--- [ 174.007763] [ cut here ] [ 174.012925] pclk_mipi_dsi0 already disabled [ 174.017633] WARNING: CPU: 5 PID: 5182 at drivers/clk/clk.c:952 clk_core_disable+0x2c/0x94 [ 174.026770] Modules linked in: [ 174.030184] CPU: 5 PID: 5182 Comm: X Tainted: GW 5.9.0-rc2 #1-mobile-nixos [ 174.039419] Hardware name: Google Scarlet (DT) [ 174.044382] pstate: 4085 (nZcv daIf -PAN -UAO BTYPE=--) [ 174.050608] pc : clk_core_disable+0x2c/0x94 [ 174.055278] lr : clk_core_disable+0x2c/0x94 [ 174.059948] sp : 800011d3ba20 [ 174.063646] x29: 800011d3ba20 x28: 0028 [ 174.069582] x27: c32bdf00 x26: 0038 [ 174.075517] x25: 800010d2e2eb x24: edece000 [ 174.081451] x23: f0bea680 x22: 0001 [ 174.087385] x21: ef82e0e0 x20: f0986400 [ 174.093319] x19: f0986400 x18: [ 174.099254] x17: x16: [ 174.105187] x15: 000a x14: 327d [ 174.21] x13: 800091d3b76f x12: 0006 [ 174.117055] x11: x10: 0030 [ 174.122989] x9 : 800011d3b77d x8 : [ 174.128923] x7 : 0008 x6 : 80001118811e [ 174.134856] x5 : f55cbe48 x4 : [
Re: [PATCH v5 4/4] MAINTAINERS: add files for Mediatek DRM drivers
On Sun, 2020-08-23 at 09:48 +0800, Chun-Kuang Hu wrote: > 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 > Reviewed-by: Matthias Brugger > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index deaafb617361..191bacf02209 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5793,6 +5793,7 @@ L: dri-devel@lists.freedesktop.org > S: Supported > F: Documentation/devicetree/bindings/display/mediatek/ > F: drivers/gpu/drm/mediatek/ > +F: drivers/phy/mediatek/phy-mtk-hdmi* > > DRM DRIVERS FOR NVIDIA TEGRA > M: Thierry Reding Reviewed-by: Chunfeng Yun Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: fix kernel-doc warning in
Fix kernel-doc warning in :
../include/linux/dma-buf.h:330: warning: Function parameter or member
'name_lock' not described in 'dma_buf'
Signed-off-by: Randy Dunlap
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
include/linux/dma-buf.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- lnx-59-rc3.orig/include/linux/dma-buf.h
+++ lnx-59-rc3/include/linux/dma-buf.h
@@ -283,6 +283,7 @@ struct dma_buf_ops {
* @exp_name: name of the exporter; useful for debugging.
* @name: userspace-provided name; useful for accounting and debugging,
*protected by @resv.
+ * @name_lock: spinlock to protect name access
* @owner: pointer to exporter module; used for refcounting when exporter is a
* kernel module.
* @list_node: node for dma_buf accounting and debugging.
@@ -311,7 +312,7 @@ struct dma_buf {
void *vmap_ptr;
const char *exp_name;
const char *name;
- spinlock_t name_lock; /* spinlock to protect name access */
+ spinlock_t name_lock;
struct module *owner;
struct list_head list_node;
void *priv;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: fix kernel-doc warning in dma-fence.c
Add @cookie to dma_fence_end_signalling() to prevent kernel-doc warning in drivers/dma-buf/dma-fence.c: ../drivers/dma-buf/dma-fence.c:291: warning: Function parameter or member 'cookie' not described in 'dma_fence_end_signalling' Signed-off-by: Randy Dunlap Cc: Sumit Semwal Cc: Gustavo Padovan Cc: Christian König Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org --- drivers/dma-buf/dma-fence.c |1 + 1 file changed, 1 insertion(+) --- lnx-59-rc3.orig/drivers/dma-buf/dma-fence.c +++ lnx-59-rc3/drivers/dma-buf/dma-fence.c @@ -283,6 +283,7 @@ EXPORT_SYMBOL(dma_fence_begin_signalling /** * dma_fence_end_signalling - end a critical DMA fence signalling section + * @cookie: opaque cookie from dma_fence_begin_signalling() * * Closes a critical section annotation opened by dma_fence_begin_signalling(). */ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/ingenic: Fix leak of device_node pointer
Hi Sam,
Le sam. 29 août 2020 à 23:07, Sam Ravnborg a
écrit :
On Thu, Aug 27, 2020 at 01:44:03PM +0200, Paul Cercueil wrote:
of_graph_get_remote_node() requires of_node_put() to be called on
the
device_node pointer when it's no more in use.
Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
Signed-off-by: Paul Cercueil
Reviewed-by: Sam Ravnborg
Thanks. Both patches pushed to drm-misc-fixes.
Cheers,
-Paul
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index ada990a7f911..c1bcb93aed2d 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -978,6 +978,7 @@ static int ingenic_drm_probe(struct
platform_device *pdev)
}
drm_of_component_match_add(dev, , compare_of, np);
+ of_node_put(np);
return component_master_add_with_match(dev, _master_ops,
match);
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: gpu: arm, mali-utgard: Correct Maxime's email
On Sun, Aug 30, 2020 at 10:51:22AM +0200, Krzysztof Kozlowski wrote: > Update the address of Maxime Ripard as one in @free-electrons.com does > not work. > > Cc: Maxime Ripard > Signed-off-by: Krzysztof Kozlowski Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/ingenic: Fix driver not probing when IPU port is missing
Le dim. 30 août 2020 à 21:21, Ezequiel Garcia
a écrit :
Hi Paul,
On Thu, 27 Aug 2020 at 09:04, Paul Cercueil
wrote:
Even if support for the IPU was compiled in, we may run on a device
(e.g. the Qi LB60) where the IPU is not available, or simply with
an old
devicetree without the IPU node. In that case the ingenic-drm
refused to
probe.
Fix the driver so that it will probe even if the IPU node is not
present
in devicetree (but then IPU support is disabled of course).
v2: Take a different approach
Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index c1bcb93aed2d..b7074161ccf0 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -673,7 +673,7 @@ static void ingenic_drm_unbind_all(void *d)
component_unbind_all(priv->dev, >drm);
}
-static int ingenic_drm_bind(struct device *dev)
+static int ingenic_drm_bind(struct device *dev, bool
has_components)
{
struct platform_device *pdev = to_platform_device(dev);
const struct jz_soc_info *soc_info;
@@ -808,7 +808,7 @@ static int ingenic_drm_bind(struct device *dev)
return ret;
}
- if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU)) {
+ if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU) &&
has_components) {
ret = component_bind_all(dev, drm);
if (ret) {
if (ret != -EPROBE_DEFER)
@@ -939,6 +939,11 @@ static int ingenic_drm_bind(struct device *dev)
return ret;
}
+static int ingenic_drm_bind_with_components(struct device *dev)
+{
+ return ingenic_drm_bind(dev, true);
+}
+
static int compare_of(struct device *dev, void *data)
{
return dev->of_node == data;
@@ -957,7 +962,7 @@ static void ingenic_drm_unbind(struct device
*dev)
}
static const struct component_master_ops ingenic_master_ops = {
- .bind = ingenic_drm_bind,
+ .bind = ingenic_drm_bind_with_components,
.unbind = ingenic_drm_unbind,
};
@@ -968,14 +973,12 @@ static int ingenic_drm_probe(struct
platform_device *pdev)
struct device_node *np;
if (!IS_ENABLED(CONFIG_DRM_INGENIC_IPU))
- return ingenic_drm_bind(dev);
+ return ingenic_drm_bind(dev, false);
/* IPU is at port address 8 */
np = of_graph_get_remote_node(dev->of_node, 8, 0);
How about we get rid of this (seems a bit odd to rely on port
address) ?
Rockchip-drm driver has a nice approach, and I think we might need
something like that going forward, to support dw-hdmi.
The rockchip-drm approach works because all the sub-drivers must probe.
In the case of ingenic-drm, even if the ingenic-drm driver was compiled
with the ipu and dw-hdmi sub-drivers, you can't rely on these probing,
as they are not present on e.g. the JZ4740.
Cheers,
-Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 1/3] dt-bindings: drm/bridge: Document Cadence MHDP8546 bridge bindings
From: Yuti Amonkar
Document the bindings used for the Cadence MHDP8546 DPI/DP bridge in
yaml format.
Signed-off-by: Yuti Amonkar
Signed-off-by: Swapnil Jakhade
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
---
.../display/bridge/cdns,mhdp8546.yaml | 154 ++
1 file changed, 154 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
new file mode 100644
index ..a21a4bfe15cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
@@ -0,0 +1,154 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/cdns,mhdp8546.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Cadence MHDP8546 bridge
+
+maintainers:
+ - Swapnil Jakhade
+ - Yuti Amonkar
+
+properties:
+ compatible:
+enum:
+ - cdns,mhdp8546
+ - ti,j721e-mhdp8546
+
+ reg:
+minItems: 1
+maxItems: 2
+items:
+ - description:
+ Register block of mhdptx apb registers up to PHY mapped area
(AUX_CONFIG_P).
+ The AUX and PMA registers are not part of this range, they are
instead
+ included in the associated PHY.
+ - description:
+ Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7
SoCs.
+
+ reg-names:
+minItems: 1
+maxItems: 2
+items:
+ - const: mhdptx
+ - const: j721e-intg
+
+ clocks:
+maxItems: 1
+description:
+ DP bridge clock, used by the IP to know how to translate a number of
+ clock cycles into a time (which is used to comply with DP standard
timings
+ and delays).
+
+ phys:
+maxItems: 1
+description:
+ phandle to the DisplayPort PHY.
+
+ ports:
+type: object
+description:
+ Ports as described in Documentation/devicetree/bindings/graph.txt.
+
+properties:
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+ port@0:
+type: object
+description:
+ First input port representing the DP bridge input.
+
+ port@1:
+type: object
+description:
+ Second input port representing the DP bridge input.
+
+ port@2:
+type: object
+description:
+ Third input port representing the DP bridge input.
+
+ port@3:
+type: object
+description:
+ Fourth input port representing the DP bridge input.
+
+ port@4:
+type: object
+description:
+ Output port representing the DP bridge output.
+
+required:
+ - port@0
+ - port@4
+ - '#address-cells'
+ - '#size-cells'
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: ti,j721e-mhdp8546
+then:
+ properties:
+reg:
+ minItems: 2
+reg-names:
+ minItems: 2
+else:
+ properties:
+reg:
+ maxItems: 1
+reg-names:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - reg
+ - reg-names
+ - phys
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+bus {
+#address-cells = <2>;
+#size-cells = <2>;
+
+mhdp: dp-bridge@f0fb00 {
+compatible = "cdns,mhdp8546";
+reg = <0xf0 0xfb00 0x0 0x100>;
+reg-names = "mhdptx";
+clocks = <_clock>;
+phys = <_phy>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dp_bridge_input: endpoint {
+remote-endpoint = <_dpi_output>;
+};
+};
+
+port@4 {
+reg = <4>;
+dp_bridge_output: endpoint {
+remote-endpoint = <_dp_connector_input>;
+};
+};
+};
+};
+};
+...
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 07/17] pwm: lpss: Always update state and set update bit
On Sun, Aug 30, 2020 at 02:57:43PM +0200, Hans de Goede wrote:
> This commit removes a check where we would skip writing the ctrl register
> and then setting the update bit in case the ctrl register already contains
> the correct values.
>
> In a perfect world skipping the update should be fine in these cases, but
> on Cherry Trail devices the AML code in the GFX0 devices' PS0 and PS3
> methods messes with the PWM controller.
>
> The "ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase" patch
> earlier in this series stops the GFX0._PS0 method from messing with the PWM
> controller and on the DSDT-s inspected sofar the _PS3 method only reads
> from the PWM controller (and turns it off before we get a change to do so):
>
> {
> PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> PSAT |= 0x03
> Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> }
>
> The PWM controller getting turning off before we do this ourselves is
> a bit annoying but not really an issue.
>
> The problem this patch fixes comes from a new variant of the GFX0._PS3 code
> messing with the PWM controller found on the Acer One 10 S1003 (1):
>
> {
> PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> PWMT &= 0xFFFF
> PWMT |= 0xC000
> PWMC = PWMT /* \_SB_.PCI0.GFX0.PWMT */
> PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> Sleep (0x64)
> PWMB &= 0x3FFF
> PWMC = PWMB /* \_SB_.PCI0.GFX0.PWMB */
> PSAT |= 0x03
> Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> }
>
> This "beautiful" piece of code clears the base-unit part of the ctrl-reg,
> which effectively disables the controller, and it sets the update flag
> to apply this change. Then after this it restores the original ctrl-reg
> value, so we do not see it has mucked with the controller.
>
> *But* it does not set the update flag when restoring the original value.
> So the check to see if we can skip writing the ctrl register succeeds
> but since the update flag was not set, the old base-unit value of 0 is
> still in use and the PWM controller is effectively disabled.
>
> IOW this PWM controller poking means that we cannot trust the base-unit /
> on-time-div value we read back from the PWM controller since it may not
> have been applied/committed. Thus we must always update the ctrl-register
> and set the update bit.
>
> 1) And once I knew what to look for also in a bunch of other devices
> including the popular Lenovo Ideapad Miix 310 and 320 models and
> various Medion models.
Despite the above mentioned issue I'm always in favour of not micro-optimizing
I/O.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Hans de Goede
> ---
> Changes in v8:
> - New patch in v8 of this patch-set
> ---
> drivers/pwm/pwm-lpss.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
> index 9a7400c6fb6e..20f6b6d6f874 100644
> --- a/drivers/pwm/pwm-lpss.c
> +++ b/drivers/pwm/pwm-lpss.c
> @@ -85,7 +85,7 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm,
> struct pwm_device *pwm,
> unsigned long long on_time_div;
> unsigned long c = lpwm->info->clk_rate, base_unit_range;
> unsigned long long base_unit, freq = NSEC_PER_SEC;
> - u32 orig_ctrl, ctrl;
> + u32 ctrl;
>
> do_div(freq, period_ns);
>
> @@ -104,16 +104,14 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip
> *lpwm, struct pwm_device *pwm,
> do_div(on_time_div, period_ns);
> on_time_div = 255ULL - on_time_div;
>
> - orig_ctrl = ctrl = pwm_lpss_read(pwm);
> + ctrl = pwm_lpss_read(pwm);
> ctrl &= ~PWM_ON_TIME_DIV_MASK;
> ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
> ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
> ctrl |= on_time_div;
>
> - if (orig_ctrl != ctrl) {
> - pwm_lpss_write(pwm, ctrl);
> - pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
> - }
> + pwm_lpss_write(pwm, ctrl);
> + pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
> }
>
> static inline void pwm_lpss_cond_enable(struct pwm_device *pwm, bool cond)
> --
> 2.28.0
>
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
DMA-BUF Heaps BoF notes (Re: [RFC] Experimental DMA-BUF Device Heaps)
Dear all, Here are the notes we took during the BoF. I believe the meeting was super interesting. Although it felt a bit short for the topic, we left with a few interesting ideas. Thanks everyone! Ezequiel --- LPC 2020 BoF: Negotiating DMA-BUF Heaps Attendees: * Brian Starkey * Daniel Stone * Ezequiel Garcia * James Jones * John Reitan * Laura Abbott * Laurent Pinchart * Sumit Semwal * Robert Beckett # Replacing subsystem memory allocators with dma-buf heaps * Laurent: we should not have subsystem implement their own allocator. Using heaps could be a good idea. * Laura: Wary to add too much support to heaps, from the ION experience. * Laurent: V4L2: most drivers use videobuf2, which is a fairly complex piece of code. Three constraints, sg, contig, and vmalloc: these are fairly generic and not video-specific, why can't these just use heaps? * Brian: In-kernel API will most likely just care of dma-buf not necessarily FDs. This was discussed recently, see "Role of DMA Heaps vs GEM in allocation",https://www.spinics.net/lists/dri-devel/msg268103.html * Do we expect to get a non-file descriptor identifier for a dma-buf? No. * Laurent proposes a two steps API (similar to existing GEM API), where we have one interface to allocate a buffer, with an identifier local to a process, and then another interface to wrap the buffer on a dma-buf (fd). * If devices are not meant to be shared, then we might want to avoid the DMA-BUF design entirely. As Sumit mentioned, the fundamental idea behind DMA-BUF is that they are expected to be shared. OTOH, it was mentioned that sometimes we don't know if a buffer will be shared or not, so that's why the ability to wrap a buffer over dma-buf is useful. * New subsytems would possibly want to avoid implementing its own allocator interface. But unfortunately, we don't want to produce a fd per buffer, so that will mean a new subsystem will eventually require its own API (GEM-like). If a subsystem doesn't need many buffers, and the FD semantic is fine, then it would be acceptable to avoid a subsystem-specific API. * It would be interesting to experiment replacing videobuf2-dma-contig with just dma-buf heap usage, and see what kind of code save we'd save. * John Stultz has ideas around providing in-kernel accessors for the heaps - the idea is for drivers to not have to implement full exporter functionality for an already existing dma-buf heap type. * Drawback to this idea of reusing dma-buf heaps to allocate buffers, is that it means marking every buffer that gets exported as shareable. * The benefits in having a centralized implementation would be in unifying the semantics, reusable concepts that can be used to build future APIs around, rather than trying to created unified APIs around disparate kernel allocation APIs at only the userspace level. * Robert: Is there an in-kernel user for the in-kernel dma-buf request? A possible answer would be for scratch buffers. The idea would be to avoid getting details wrong. However, doing this would allow every buffer to be exportable. Also, it sounds like this means re-implementing DMA-API? * DMA-BUF are designed to be shared, not necessarily an allocator. * Want something to expose device-local memory to rest of kernel. Could be a dma-buf heap? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 0/3] drm: Add support for Cadence MHDP8546 DPI/DP bridge and J721E wrapper.
This patch series adds new DRM bridge driver for Cadence MHDP8546 DPI/DP bridge. The Cadence Display Port IP is also referred as MHDP (Mobile High Definition Link, High-Definition Multimedia Interface, Display Port). Cadence Display Port complies with VESA DisplayPort (DP) and embedded Display Port (eDP) standards. The MHDP bridge driver currently implements Single Stream Transport (SST) mode. It also adds Texas Instruments j721e SoC specific wrapper and adds the device tree bindings in YAML format. Some of the features that will be added later on include (but are not limited to): - Power Management (PM) support: We will implement the PM functions in next stage once there will be a stable driver in upstream - Audio and MST support The patch series has three patches in the below sequence: 1. 0001-dt-bindings-drm-bridge-Document-Cadence-MHDP8546-.patch Documents the bindings in yaml format. 2. 0002-drm-bridge-Add-support-for-Cadence-MHDP8546-DPI-D.patch This patch adds new DRM bridge driver for Cadence MHDP Display Port. The patch implements support for single stream transport mode. 3. 0003-drm-bridge-cdns-mhdp8546-Add-TI-J721E-wrapper.patch Adds Texas Instruments (TI) j721e wrapper for MHDP. The wrapper configures MHDP clocks and muxes as required by SoC. This patch series is dependent on PHY patch series [1] to add new PHY APIs to get/set PHY attributes which is under review and not merged yet. [1] https://lkml.org/lkml/2020/8/24/1586 Version History: v9: In 1/3 - Rename bindings file to cdns,mhdp8546.yaml. - Minor changes replacing mhdp with mhdp8546 to include IP part number. - Add 4 input ports and one output port supporting MST for DP bridge. In 2/3 - Add driver files in cadence folder under drm/bridge. - Rename driver files to include part number mhdp8546. - Remove link training calls from atomic_check. - Support DRM_BRIDGE_OP_HPD with hpd_enable, hpd_disable callbacks. - Remove unnecessary fw states. - Fix other review comments for v8 patches. In 3/3 - Add input_bus_flags specific for J721E in drm_bridge_timings. - Fix other review comments for v8 patches. v8: In 1/3 - Fix error reported by dt_binding_check - Fix indent in the example - Fix other comments given for v7 patches. In 2/3: - Implement bridge connector operations .get_edid() and .detect(). - Make connector creation optional based on DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. - Fix other comments given for v7 patches. In 3/3 - Fix comments given for v7 patches. v7: In 1/3 - No change In 2/3 - Switch to atomic versions of bridge operations - Implement atomic_check() handler to perform all validation checks - Add struct cdns_mhdp_bridge_state with subclassed bridge state - Use PHY API[1] to get PHY attributes instead of reading from PHY DT node - Updated HPD handling and link configuration in IRQ handler - Add "link_mutex" protecting the access to all the link parameters - Add support to check and print FW version information - Add separate function to initialize host parameters to simplify probe - Use waitqueue instead of manual loop in cdns_mhdp_remove - Add forward declarations and header files in cdns-mhdp-core.h file - Use bool instead of single bit values in struct cdns_mhdp_device - Fix for other minor comments given for v6 patches In 3/3 - Use of_device_is_compatible() to set compatible string specific values - Move mhdp_ti_j721e_ops structure to cdns-mhdp-j721e.c - Remove duplicate Copyright message - Remove CONFIG_DRM_CDNS_MHDP_J721E check - Add Reviewed-by: Laurent Pinchart v6: - Added minor fixes in YAML file. - Added Reviewed-by: Laurent Pinchart to the YAML patch. - Removed all the FIXME comments which are invalid in drm driver. - Reduced the mailbox timeout from 5s to 2s. - Added Reviewed-by: Tomi Valkeinen to the 003-drm-mhdp-add-j721e-wrapper patch. - Added Signed-off all the module authors. - Fixed the compiler error Reported-by: kbuild test robot . v5: - Added Signed-off-by: Jyri Sarha tag to the code patches. v4: - Added SPDX dual license tag to YAML bindings. - Corrected indentation of the child node properties. - Removed the maxItems in the conditional statement. - Add Reviewed-by: Rob Herring tag to the Document Cadence MHDP bridge bindings patch. - Renamed the DRM driver executable name from mhdp8546 to cdns-mhdp in Makefile. - Renamed the DRM driver and header file from cdns-mhdp to cdns-mhdp-core. v3: - Added if / then clause to validate that the reg length is proper based on the value of the compatible property. - Updated phy property description in YAML to a generic one. - Renamed num_lanes and max_bit_rate property strings to cdns,num-lanes and cdns,max-bit-rate. v2: - Use enum in compatible property of YAML file. - Add reg-names property to YAML file - Add minItems and maxItems to reg property in YAML. - Remove cdns_mhdp_link_probe function to remove duplication of reading dpcd capabilities. Swapnil Jakhade (2): drm: bridge: Add support for Cadence MHDP8546 DPI/DP
Re: [PATCH 09/18] iommu/mediatek-v1: Add IOMMU_DOMAIN_DMA support
On Thu, 2020-08-20 at 16:08 +0100, Robin Murphy wrote:
> Now that arch/arm is wired up for default domains and iommu-dma,
> implement the corresponding driver-side support for groups and DMA
> domains to replace the shared mapping workaround.
>
> Signed-off-by: Robin Murphy
> ---
> drivers/iommu/mtk_iommu.h| 2 -
> drivers/iommu/mtk_iommu_v1.c | 153 +++
> 2 files changed, 48 insertions(+), 107 deletions(-)
Hi Robin,
Thanks very much for this patch, It makes the code much cleaner.
Please help squash the little change in this patch,
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -555,6 +555,7 @@ static int mtk_iommu_probe(struct platform_device
*pdev)
return ret;
iommu_device_set_ops(>iommu, _iommu_ops);
+ iommu_device_set_fwnode(>iommu, >of_node->fwnode);
ret = iommu_device_register(>iommu);
if (ret)
Then,
Tested-by: Yong Wu
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 122925dbe547..6253e98d810c 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -67,8 +67,6 @@ struct mtk_iommu_data {
> struct iommu_device iommu;
> const struct mtk_iommu_plat_data *plat_data;
>
> - struct dma_iommu_mapping*mapping; /* For mtk_iommu_v1.c */
> -
> struct list_headlist;
> struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
> };
> diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
> index 82ddfe9170d4..40c89b8d3ac4 100644
> --- a/drivers/iommu/mtk_iommu_v1.c
> +++ b/drivers/iommu/mtk_iommu_v1.c
> @@ -28,7 +28,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -240,13 +239,18 @@ static struct iommu_domain
> *mtk_iommu_domain_alloc(unsigned type)
> {
> struct mtk_iommu_domain *dom;
>
> - if (type != IOMMU_DOMAIN_UNMANAGED)
> + if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA)
> return NULL;
>
> dom = kzalloc(sizeof(*dom), GFP_KERNEL);
> if (!dom)
> return NULL;
>
> + if (type == IOMMU_DOMAIN_DMA && iommu_get_dma_cookie(>domain)) {
> + kfree(dom);
> + return NULL;
> + }
> +
> return >domain;
> }
>
> @@ -257,6 +261,7 @@ static void mtk_iommu_domain_free(struct iommu_domain
> *domain)
>
> dma_free_coherent(data->dev, M2701_IOMMU_PGT_SIZE,
> dom->pgt_va, dom->pgt_pa);
> + iommu_put_dma_cookie(domain);
> kfree(to_mtk_domain(domain));
> }
>
> @@ -265,14 +270,8 @@ static int mtk_iommu_attach_device(struct iommu_domain
> *domain,
> {
> struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
> struct mtk_iommu_domain *dom = to_mtk_domain(domain);
> - struct dma_iommu_mapping *mtk_mapping;
> int ret;
>
> - /* Only allow the domain created internally. */
> - mtk_mapping = data->mapping;
> - if (mtk_mapping->domain != domain)
> - return 0;
> -
> if (!data->m4u_dom) {
> data->m4u_dom = dom;
> ret = mtk_iommu_domain_finalise(data);
> @@ -358,18 +357,39 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct
> iommu_domain *domain,
>
> static const struct iommu_ops mtk_iommu_ops;
>
> -/*
> - * MTK generation one iommu HW only support one iommu domain, and all the
> client
> - * sharing the same iova address space.
> - */
> -static int mtk_iommu_create_mapping(struct device *dev,
> - struct of_phandle_args *args)
> +static struct iommu_device *mtk_iommu_probe_device(struct device *dev)
> {
> struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> struct mtk_iommu_data *data;
> +
> + if (!fwspec || fwspec->ops != _iommu_ops)
> + return ERR_PTR(-ENODEV); /* Not a iommu client device */
> +
> + data = dev_iommu_priv_get(dev);
> +
> + return >iommu;
> +}
> +
> +static void mtk_iommu_release_device(struct device *dev)
> +{
> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> +
> + if (!fwspec || fwspec->ops != _iommu_ops)
> + return;
> +
> + iommu_fwspec_free(dev);
> +}
> +
> +static struct iommu_group *mtk_iommu_device_group(struct device *dev)
> +{
> + struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
> +
> + return iommu_group_ref_get(data->m4u_group);
> +}
> +
> +static int mtk_iommu_of_xlate(struct device *dev, struct of_phandle_args
> *args)
> +{
> struct platform_device *m4updev;
> - struct dma_iommu_mapping *mtk_mapping;
> - int ret;
>
> if (args->args_count != 1) {
> dev_err(dev, "invalid #iommu-cells(%d) property for IOMMU\n",
> @@ -377,15 +397,6 @@ static int mtk_iommu_create_mapping(struct device *dev,
> return -EINVAL;
> }
>
> - if (!fwspec) {
> - ret = iommu_fwspec_init(dev,
Re: [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline
Hi Maxime, On 7/9/20 2:41 AM, Maxime Ripard wrote: > 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 and DSI > outputs have been tested too). > > Let me know if you have any comments > Maxime > > Cc: bcm-kernel-feedback-l...@broadcom.com > Cc: devicet...@vger.kernel.org > Cc: Kamal Dasu > Cc: linux-...@vger.kernel.org > Cc: Michael Turquette > Cc: Philipp Zabel > Cc: Rob Herring > Cc: Stephen Boyd > > Changes from v3: > - Rebased on top of next-20200708 > - Added a name to the HDMI audio codec component > - Only disable the BCM2711 HDMI pixelvalves at boot > - Fixed an error in the HVS binding > - Fix a framebuffer size condition that was inverted > - Changed the channel allocation algorithm using Eric's suggestion > - Always write the muxing values instead of updating if needed > - Improved a bit the hvs_available_channels comment in the structure > - Change atomic_complete_commit code to use for_each_new_crtc_in_state > - Change the muxing code to take into account disparities between the > BCM2711 and previous SoCs. > - Only change the clock rate on BCM2711 during a modeset > - Fix a crash at atomic_disable > - Use clk_set_min_rate for the core clock too > - Add a few defines, and simplify the FIFO level stuff > - Reordered the patches according to Eric's reviews > - Fixed a regression with VID_CTL setting on RPI3 > > Changes from v2: > - Rebased on top of next-20200526 > - Split the firmware clock series away > - Removed the stuck pixel (with all the subsequent pixels being shifted > by one > - Fixed the writeback issue too. > - Fix the dual output > - Fixed the return value of phy_get_cp_current > - Enhanced the comment on the reset delay > - Increase the max width and height > - Made a proper Kconfig option for the DVP clock driver > - Fixed the alsa card name collision > > 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 (7): > drm/vc4: Add support for the BCM2711 HVS5 > drm/vc4: plane: Change LBM alignment constraint on LBM > drm/vc4: plane: Optimize the LBM allocation size > 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 > > Maxime Ripard (71): > dt-bindings: display: Add support for the BCM2711 HVS > drm/vc4: hvs: Boost the core clock during modeset > drm/vc4: plane: Create more planes > drm/vc4: crtc: Deal with different number of pixel per clock > drm/vc4: crtc: Use a shared interrupt > 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: kms: Convert to for_each_new_crtc_state > 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: Disable color management for HVS5 > drm/vc4:
[bug report] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hello Guido Günther,
The patch 72967d5616d3: "drm/panel: Add panel driver for the Mantix
MLAF057WE51-X DSI panel" from Aug 17, 2020, leads to the following
static checker warning:
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c:205 mantix_get_modes()
error: we previously assumed 'mode' could be null (see line 204)
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
197 static int mantix_get_modes(struct drm_panel *panel,
198 struct drm_connector *connector)
199 {
200 struct mantix *ctx = panel_to_mantix(panel);
201 struct drm_display_mode *mode;
202
203 mode = drm_mode_duplicate(connector->dev, _mode);
204 if (!mode) {
205 dev_err(ctx->dev, "Failed to add mode %ux%u@%u\n",
206 default_mode.hdisplay, default_mode.vdisplay,
207 drm_mode_vrefresh(mode));
This will lead to a NULL dereference.
208 return -ENOMEM;
209 }
210
211 drm_mode_set_name(mode);
212
213 mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
214 connector->display_info.width_mm = mode->width_mm;
215 connector->display_info.height_mm = mode->height_mm;
216 drm_mode_probed_add(connector, mode);
217
218 return 1;
219 }
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 07/17] pwm: lpss: Always update state and set update bit
Hi,
On 8/31/20 10:56 AM, Andy Shevchenko wrote:
On Sun, Aug 30, 2020 at 02:57:43PM +0200, Hans de Goede wrote:
This commit removes a check where we would skip writing the ctrl register
and then setting the update bit in case the ctrl register already contains
the correct values.
In a perfect world skipping the update should be fine in these cases, but
on Cherry Trail devices the AML code in the GFX0 devices' PS0 and PS3
methods messes with the PWM controller.
The "ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase" patch
earlier in this series stops the GFX0._PS0 method from messing with the PWM
controller and on the DSDT-s inspected sofar the _PS3 method only reads
from the PWM controller (and turns it off before we get a change to do so):
{
PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PSAT |= 0x03
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
}
The PWM controller getting turning off before we do this ourselves is
a bit annoying but not really an issue.
The problem this patch fixes comes from a new variant of the GFX0._PS3 code
messing with the PWM controller found on the Acer One 10 S1003 (1):
{
PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PWMT &= 0xFFFF
PWMT |= 0xC000
PWMC = PWMT /* \_SB_.PCI0.GFX0.PWMT */
PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
Sleep (0x64)
PWMB &= 0x3FFF
PWMC = PWMB /* \_SB_.PCI0.GFX0.PWMB */
PSAT |= 0x03
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
}
This "beautiful" piece of code clears the base-unit part of the ctrl-reg,
which effectively disables the controller, and it sets the update flag
to apply this change. Then after this it restores the original ctrl-reg
value, so we do not see it has mucked with the controller.
*But* it does not set the update flag when restoring the original value.
So the check to see if we can skip writing the ctrl register succeeds
but since the update flag was not set, the old base-unit value of 0 is
still in use and the PWM controller is effectively disabled.
IOW this PWM controller poking means that we cannot trust the base-unit /
on-time-div value we read back from the PWM controller since it may not
have been applied/committed. Thus we must always update the ctrl-register
and set the update bit.
1) And once I knew what to look for also in a bunch of other devices
including the popular Lenovo Ideapad Miix 310 and 320 models and
various Medion models.
Despite the above mentioned issue I'm always in favour of not micro-optimizing
I/O.
Reviewed-by: Andy Shevchenko
Thank you.
Regards,
Hans
Signed-off-by: Hans de Goede
---
Changes in v8:
- New patch in v8 of this patch-set
---
drivers/pwm/pwm-lpss.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 9a7400c6fb6e..20f6b6d6f874 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -85,7 +85,7 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm,
struct pwm_device *pwm,
unsigned long long on_time_div;
unsigned long c = lpwm->info->clk_rate, base_unit_range;
unsigned long long base_unit, freq = NSEC_PER_SEC;
- u32 orig_ctrl, ctrl;
+ u32 ctrl;
do_div(freq, period_ns);
@@ -104,16 +104,14 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, struct pwm_device *pwm,
do_div(on_time_div, period_ns);
on_time_div = 255ULL - on_time_div;
- orig_ctrl = ctrl = pwm_lpss_read(pwm);
+ ctrl = pwm_lpss_read(pwm);
ctrl &= ~PWM_ON_TIME_DIV_MASK;
ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
ctrl |= on_time_div;
- if (orig_ctrl != ctrl) {
- pwm_lpss_write(pwm, ctrl);
- pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
- }
+ pwm_lpss_write(pwm, ctrl);
+ pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
}
static inline void pwm_lpss_cond_enable(struct pwm_device *pwm, bool cond)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/10] dt-bindings: mfd: syscon: Document Samsung Exynos compatibles
On Mon, Aug 31, 2020 at 02:30:52PM +0200, Sylwester Nawrocki wrote: > On 29.08.2020 16:24, Krzysztof Kozlowski wrote: > > Samsung Exynos SoCs use syscon for system registers so document its > > compatibles. > > > > Signed-off-by: Krzysztof Kozlowski > > --- > > Documentation/devicetree/bindings/mfd/syscon.yaml | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml > > b/Documentation/devicetree/bindings/mfd/syscon.yaml > > index 049ec2ffc7f9..0f21943dea28 100644 > > --- a/Documentation/devicetree/bindings/mfd/syscon.yaml > > +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml > > @@ -40,6 +40,10 @@ properties: > >- allwinner,sun50i-a64-system-controller > >- microchip,sparx5-cpu-syscon > >- mstar,msc313-pmsleep > > + - samsung,exynos3-sysreg > > + - samsung,exynos4-sysreg > > + - samsung,exynos5-sysreg > > + - samsung,exynos5433-sysreg > > Reviewed-by: Sylwester Nawrocki > > Do you also have a patch updating Documentation/devicetree/ > bindings/arm/samsung/sysreg.yaml with new compatibles? Good point. This file should be probably dropped as everything is documented in syscon. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFT 3/4] ARM: dts: exynos: Move CMU assigned ISP clocks to buses in Exynos3250
On Mon, Aug 31, 2020 at 10:11:02AM +0200, Marek Szyprowski wrote:
> Hi Krzysztof,
>
> On 29.08.2020 19:25, Krzysztof Kozlowski wrote:
> > Commit 52005dece527 ("ARM: dts: Add assigned clock parents to CMU node
> > for exynos3250") added assigned clocks under Clock Management Unit to
> > fix hangs when accessing ISP registers.
> >
> > This is not the place for it as CMU does not have a required "clocks"
> > property:
> >
> >arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml:
> > clock-controller@1003: 'clocks' is a dependency of 'assigned-clocks'
> >
> > Signed-off-by: Krzysztof Kozlowski
> >
> > ---
> >
> > Not tested and I wonder whether actually correct. For example, what will
> > happen if devfreq (exynos-bus) is not built in?
> >
> > Could someone verify it?
>
> Sorry, but this patch is not correct. Those clocks has noting with
> bus-freq. The assigned clocks property should stay where it is. Maybe
> one need to fix the schemas for dts verification. Those clocks has to be
> set (and so generic clock framework does) according to the assigned
> clocks properties once the clock controller is instantiated.
>
> The only alternative would be to add exynos-subcmu variant to properly
> link CMU with the ISP power domain, but assuming that there is no Exynos
> 3250 ISP driver in mainline (and probably never will be), it is safe to
> keep those clocks sourced from 24MHz crystal.
Thanks for the clarification. Another solution to silence the warning
could be to add a "clocks" property for FIN_PLL, although the driver
actually does not take it.
This is the only remaining dtschema check warning on Exynos3250 so it
would be nice to at least silence it. My goal is to have all them
schema-correct, or as close as possible (for Exynos4 the camera node is
a trouble).
Best regards,
Krzysztof
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFT 3/4] ARM: dts: exynos: Move CMU assigned ISP clocks to buses in Exynos3250
Hi Krzysztof,
On 31.08.2020 10:19, Krzysztof Kozlowski wrote:
> On Mon, Aug 31, 2020 at 10:11:02AM +0200, Marek Szyprowski wrote:
>> On 29.08.2020 19:25, Krzysztof Kozlowski wrote:
>>> Commit 52005dece527 ("ARM: dts: Add assigned clock parents to CMU node
>>> for exynos3250") added assigned clocks under Clock Management Unit to
>>> fix hangs when accessing ISP registers.
>>>
>>> This is not the place for it as CMU does not have a required "clocks"
>>> property:
>>>
>>> arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml:
>>> clock-controller@1003: 'clocks' is a dependency of 'assigned-clocks'
>>>
>>> Signed-off-by: Krzysztof Kozlowski
>>>
>>> ---
>>>
>>> Not tested and I wonder whether actually correct. For example, what will
>>> happen if devfreq (exynos-bus) is not built in?
>>>
>>> Could someone verify it?
>> Sorry, but this patch is not correct. Those clocks has noting with
>> bus-freq. The assigned clocks property should stay where it is. Maybe
>> one need to fix the schemas for dts verification. Those clocks has to be
>> set (and so generic clock framework does) according to the assigned
>> clocks properties once the clock controller is instantiated.
>>
>> The only alternative would be to add exynos-subcmu variant to properly
>> link CMU with the ISP power domain, but assuming that there is no Exynos
>> 3250 ISP driver in mainline (and probably never will be), it is safe to
>> keep those clocks sourced from 24MHz crystal.
> Thanks for the clarification. Another solution to silence the warning
> could be to add a "clocks" property for FIN_PLL, although the driver
> actually does not take it.
Okay, that would be fine. It would make dts match better the hardware
and this would even help generic clock framework to always instantiate
CMU after the oscilator fixed-clock (there have been some hacks there at
some point for that...)
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 v9 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge
Hi Swapnil,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on linus/master v5.9-rc3 next-20200828]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Swapnil-Jakhade/drm-Add-support-for-Cadence-MHDP8546-DPI-DP-bridge-and-J721E-wrapper/20200831-162549
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/linux/err.h:5,
from include/linux/clk.h:12,
from drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:22:
include/linux/scatterlist.h: In function 'sg_set_buf':
arch/m68k/include/asm/page_mm.h:169:49: warning: ordered comparison of
pointer with null pointer [-Wextra]
169 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void
*)PAGE_OFFSET && (void *)(kaddr) < high_memory)
| ^~
include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
78 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
include/linux/scatterlist.h:143:2: note: in expansion of macro 'BUG_ON'
143 | BUG_ON(!virt_addr_valid(buf));
| ^~
include/linux/scatterlist.h:143:10: note: in expansion of macro
'virt_addr_valid'
143 | BUG_ON(!virt_addr_valid(buf));
| ^~~
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
'cdns_mhdp_fill_host_caps':
>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:1355:2: error: implicit
>> declaration of function 'phy_get_attrs'
>> [-Werror=implicit-function-declaration]
1355 | phy_get_attrs(mhdp->phy, );
| ^
>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:1361:19: error: 'struct
>> phy_attrs' has no member named 'max_link_rate'
1361 | link_rate = attrs.max_link_rate;
| ^
cc1: some warnings being treated as errors
#
https://github.com/0day-ci/linux/commit/f9a2fb8569e017b7eaba3a94afc9581179c2b62b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Swapnil-Jakhade/drm-Add-support-for-Cadence-MHDP8546-DPI-DP-bridge-and-J721E-wrapper/20200831-162549
git checkout f9a2fb8569e017b7eaba3a94afc9581179c2b62b
vim +/phy_get_attrs +1355 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
1348
1349 static void cdns_mhdp_fill_host_caps(struct cdns_mhdp_device *mhdp)
1350 {
1351 unsigned int link_rate;
1352 struct phy_attrs attrs;
1353
1354 /* Get source capabilities based on PHY attributes */
> 1355 phy_get_attrs(mhdp->phy, );
1356
1357 mhdp->host.lanes_cnt = attrs.bus_width;
1358 if (!mhdp->host.lanes_cnt)
1359 mhdp->host.lanes_cnt = 4;
1360
> 1361 link_rate = attrs.max_link_rate;
1362 if (!link_rate)
1363 link_rate = drm_dp_bw_code_to_link_rate(DP_LINK_BW_8_1);
1364 else
1365 /* PHY uses Mb/s, DRM uses tens of kb/s. */
1366 link_rate *= 100;
1367
1368 mhdp->host.link_rate = link_rate;
1369 mhdp->host.volt_swing = CDNS_VOLT_SWING(3);
1370 mhdp->host.pre_emphasis = CDNS_PRE_EMPHASIS(3);
1371 mhdp->host.pattern_supp = CDNS_SUPPORT_TPS(1) |
1372CDNS_SUPPORT_TPS(2) |
CDNS_SUPPORT_TPS(3) |
1373CDNS_SUPPORT_TPS(4);
1374 mhdp->host.lane_mapping = CDNS_LANE_MAPPING_NORMAL;
1375 mhdp->host.fast_link = false;
1376 mhdp->host.enhanced = true;
1377 mhdp->host.scrambler = true;
1378 mhdp->host.ssc = false;
1379 }
1380
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/5] Add support for iMX8MQ Display Controller Subsystem
Hi Laurentiu, On Fr, 2020-08-28 at 11:36 +0300, Laurentiu Palcu wrote: > Hi Lucas, > > I was wondering about the plans to merge this series. Since not many > people can test it properly due to lack of DCSS support in the upstream > NWL driver (which I heard it's coming soon) and a completely nonexistent > HDP driver, are we going to take a leap of faith and merge it as is? Or > should we wait? I think even if the bridges aren't ready yet, the driver is in a good enough shape to merge it. There's no point in letting it accumulate bitrot while waiting for the bridges to land. Also I guess it will make bridge driver development a lot easier when the DCSS driver is in-tree. > As to who is going to do the actual merge, I know we had a brief > discussion about it some time ago and I was supposed to apply for > drm-misc rights, however it feels a little awkward to merge my own > code... :) Though, I might not even qualify for drm-misc rights anyway, > considering I haven't been very active in this area... :/ Please consider applying for drm-misc merge rights. Even if you don't do the initial merge I think it will come in handy in the long run. > On that note, I will probably need help with the merging, provided it's > still happenning. Will you be able to help me out with this? Sure, I'm having some time available this week. I'll give this v9 another spin on my boards and will do the merge after that. Regards, Lucas > Thanks, > laurentiu > > On Fri, Jul 31, 2020 at 11:18:28AM +0300, Laurentiu Palcu wrote: > > From: Laurentiu Palcu > > > > Hi, > > > > This patchset adds initial DCSS support for iMX8MQ chip. Initial support > > includes only graphics plane support (no video planes), no HDR10 > > capabilities, > > no graphics decompression (only linear, tiled and super-tiled buffers > > allowed). > > > > Support for the rest of the features will be added incrementally, in > > subsequent > > patches. > > > > The patchset was tested with both HDP driver (in the downstream tree) and > > the upstream > > MIPI-DSI driver (with a couple of patches on top, to make it work correctly > > with DCSS). > > > > Thanks, > > Laurentiu > > > > Changes in v9: > > * Fixed a compilation issue found by Guido in his setup: 'select > >VIDEOMODE_HELPERS' was missing from Kconfig; > > * Use imx8mq-clock.h in the bindings file so one can understand what > >those clock values mean; > > * no other changes done. Couldn't address the hang Guido reported as > >it's not happening in my setup. However, in my tree, there are some > >extra NWL and ADV patches applied on top of upstream ones... Also, > >removing them and testing only with upstream, even if there's no > >image out, does not produce a hang... :/ > > > > Changes in v8: > > * Removed 'select RESET_CONTROLLER" from Kconfig as Philipp pointed > >out. SRC is not used in DCSS driver; > > * Nothing else changed; > > > > Changes in v7: > > * Added a patch to initialize the connector using the drm_bridge_connector > >API as Sam suggested. Tested it using NWL_DSI and ADV7535 with > >Guido's patch [1] applied and one fix for ADV [2]. Also, some extra > >patches for ADV and NWL were needed, from our downstream tree, which > >will be upstreamed soon by their author; > > * Rest of the patches are untouched; > > > > [1] https://lists.freedesktop.org/archives/dri-devel/2020-July/273025.html > > [2] https://lists.freedesktop.org/archives/dri-devel/2020-July/273132.html > > > > Changes in v6: > > * Addressed Rob's comment and added "additionalProperties: false" at > >the end of the bindings' properties. However, this change surfaced > >an issue with the assigned-clock* properties not being documented in > >the properties section. Added the descriptions and the bindings patch > >will need another review; > > * Added an entry for DCSS driver in the MAINTAINERS file; > > * Removed the component framework patch altogether; > > > > Changes in v5: > > * Rebased to latest; > > * Took out component framework support and made it a separate patch so > >that people can still test with HDP driver, which makes use of it. > >But the idea is to get rid of it once HDP driver's next versions > >will remove component framework as well; > > * Slight improvement to modesetting: avoid cutting off the pixel clock > >if the new mode and the old one are equal. Also, in this case, is > >not necessary to wait for DTG to shut off. This would allow to switch > >from 8b RGB to 12b YUV422, for example, with no interruptions (at least > >from DCSS point of view); > > * Do not fire off CTXLD when going to suspend, unless it still has > >entries that need to be committed to DCSS; > > * Addressed Rob's comments on bindings; > > > > Changes in v4: > > * Addressed Lucas and Philipp's comments: > >* Added DRM_KMS_CMA_HELPER dependency in Kconfig; > >* Removed usage of devm_ functions since I'm
Re: [PATCH v9 0/5] Add support for iMX8MQ Display Controller Subsystem
Hi Lucas, Sam, On Mon, Aug 31, 2020 at 12:37:23PM +0200, Lucas Stach wrote: > Hi Laurentiu, > > On Fr, 2020-08-28 at 11:36 +0300, Laurentiu Palcu wrote: > > Hi Lucas, > > > > I was wondering about the plans to merge this series. Since not many > > people can test it properly due to lack of DCSS support in the upstream > > NWL driver (which I heard it's coming soon) and a completely nonexistent > > HDP driver, are we going to take a leap of faith and merge it as is? Or > > should we wait? > > I think even if the bridges aren't ready yet, the driver is in a good > enough shape to merge it. There's no point in letting it accumulate > bitrot while waiting for the bridges to land. Also I guess it will make > bridge driver development a lot easier when the DCSS driver is in-tree. OK, fair enough. > > > As to who is going to do the actual merge, I know we had a brief > > discussion about it some time ago and I was supposed to apply for > > drm-misc rights, however it feels a little awkward to merge my own > > code... :) Though, I might not even qualify for drm-misc rights anyway, > > considering I haven't been very active in this area... :/ > > Please consider applying for drm-misc merge rights. Even if you don't > do the initial merge I think it will come in handy in the long run. OK, I'll apply for drm-misc rights. Sam also encouraged me to do this in a previous email. Since this series will be followed by a bunch of other patches, enabling support for video planes, among other things, I guess I'll need the rights anyway. > > > On that note, I will probably need help with the merging, provided it's > > still happenning. Will you be able to help me out with this? > > Sure, I'm having some time available this week. I'll give this v9 > another spin on my boards and will do the merge after that. Thanks Lucas. As a matter of fact, after Sam's email, I was preparing a v10 after rebasing to latest drm-next. However, no conflicts were encountered and the v9 series applied cleanly. Let me know if you encounter any issues and I can resend it. Thanks, Laurentiu > > Regards, > Lucas > > > Thanks, > > laurentiu > > > > On Fri, Jul 31, 2020 at 11:18:28AM +0300, Laurentiu Palcu wrote: > > > From: Laurentiu Palcu > > > > > > Hi, > > > > > > This patchset adds initial DCSS support for iMX8MQ chip. Initial support > > > includes only graphics plane support (no video planes), no HDR10 > > > capabilities, > > > no graphics decompression (only linear, tiled and super-tiled buffers > > > allowed). > > > > > > Support for the rest of the features will be added incrementally, in > > > subsequent > > > patches. > > > > > > The patchset was tested with both HDP driver (in the downstream tree) and > > > the upstream > > > MIPI-DSI driver (with a couple of patches on top, to make it work > > > correctly with DCSS). > > > > > > Thanks, > > > Laurentiu > > > > > > Changes in v9: > > > * Fixed a compilation issue found by Guido in his setup: 'select > > >VIDEOMODE_HELPERS' was missing from Kconfig; > > > * Use imx8mq-clock.h in the bindings file so one can understand what > > >those clock values mean; > > > * no other changes done. Couldn't address the hang Guido reported as > > >it's not happening in my setup. However, in my tree, there are some > > >extra NWL and ADV patches applied on top of upstream ones... Also, > > >removing them and testing only with upstream, even if there's no > > >image out, does not produce a hang... :/ > > > > > > Changes in v8: > > > * Removed 'select RESET_CONTROLLER" from Kconfig as Philipp pointed > > >out. SRC is not used in DCSS driver; > > > * Nothing else changed; > > > > > > Changes in v7: > > > * Added a patch to initialize the connector using the > > > drm_bridge_connector > > >API as Sam suggested. Tested it using NWL_DSI and ADV7535 with > > >Guido's patch [1] applied and one fix for ADV [2]. Also, some extra > > >patches for ADV and NWL were needed, from our downstream tree, which > > >will be upstreamed soon by their author; > > > * Rest of the patches are untouched; > > > > > > [1] https://lists.freedesktop.org/archives/dri-devel/2020-July/273025.html > > > [2] https://lists.freedesktop.org/archives/dri-devel/2020-July/273132.html > > > > > > Changes in v6: > > > * Addressed Rob's comment and added "additionalProperties: false" at > > >the end of the bindings' properties. However, this change surfaced > > >an issue with the assigned-clock* properties not being documented in > > >the properties section. Added the descriptions and the bindings patch > > >will need another review; > > > * Added an entry for DCSS driver in the MAINTAINERS file; > > > * Removed the component framework patch altogether; > > > > > > Changes in v5: > > > * Rebased to latest; > > > * Took out component framework support and made it a separate patch so > > >that people can still test with HDP driver, which makes
Re: [PATCH v8 06/17] pwm: lpss: Use pwm_lpss_restore() when restoring state on resume
Hi,
On 8/31/20 1:10 PM, Thierry Reding wrote:
On Sun, Aug 30, 2020 at 02:57:42PM +0200, Hans de Goede wrote:
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main consumer
(the i915 driver) was always making duty-cycle changes on resume.
With the conversion of the i915 driver to the atomic PWM API the
driver now only disables/enables the PWM on suspend/resume leaving
the output-freq and duty as is, triggering this problem.
Doesn't this imply that there's another bug at play here? At the PWM API
level you're applying a state and it's up to the driver to ensure that
the hardware state after ->apply() is what the software has requested.
If you only switch the enable state and that doesn't cause period and
duty cycle to be updated it means that your driver isn't writing those
registers when it should be.
Right, the driver was not committing those as it should *on resume*,
that and it skips setting the update bit on the subsequent enable,
which is an optimization which gets removed in 7/17.
Before switching the i915 driver over to atomic, when the LPSS-PWM
was used for the backlight we got the following order on suspend/resume
1. Set duty-cycle to 0%
2. Set enabled to 0
3. Save ctrl reg
4. Power-off PWM controller, it now looses all its state
5. Power-on PWM ctrl
6. Restore ctrl reg (as a single reg write)
7. Set enabled to 1, at this point one would expect the
duty/freq from the restored ctrl-reg to apply, but:
a) The resume code never sets the update bit (which this commit fixes); and
b) On applying the pwm_state with enabled=1 the code applying the
state does this (before setting the enabled bit in the ctrl reg):
if (orig_ctrl != ctrl) {
pwm_lpss_write(pwm, ctrl);
pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
}
and since the restore of the ctrl reg set the old duty/freq the
writes are skipped, so the update bit never gets set.
8. Set duty-cycle to the pre-suspend value (which is not 0)
this does cause a change in the ctrl-reg, so now the update flag
does get set.
Note that 1-2 and 7-8 are both done by the non atomic i915 code,
when moving the i915 code to atomic I decided that having these
2 separate steps here is non-sense, so the new i915 code just
toggles the enable bit. So in essence the new atomic PWM
i915 code drops step 1 and 8.
Dropping steps 8 means that the update bit never gets set and we
end up with the PWM running at its power-on-reset duty cycle.
You are correct in your remark to patch 7/17 that since that removes
the if (orig_ctrl != ctrl) for the writes that now step 7 will be
sufficient to get the PWM to work again. But that only takes the i915
usage into account.
What if the PWM is used through the sysfs userspace API?
Then only steps 3-6 will happen on suspend-resume and without
fixing step 6 to properly restore the PWM controller in its
pre-resume state (this patch) it will once again be running at
its power-on-reset defaults instead of the values from the
restored control register.
So at step 6, if the PWM was enabled before, we must set the update
bit, and then wait for it to clear again so the controller is
ready for subsequent updates. The waiting for it to clear again
needs to happen before or after setting the enable bit depending
on the hw generation, which leads to this patch.
I hope that helps explain why this patch is the correct thing
to do.
The LPSS PWM controller has a mechanism where the ctrl register value
and the actual base-unit and on-time-div values used are latched. When
software sets the SW_UPDATE bit then at the end of the current PWM cycle,
the new values from the ctrl-register will be latched into the actual
registers, and the SW_UPDATE bit will be cleared.
The problem is that before this commit our suspend/resume handling
consisted of simply saving the PWM ctrl register on suspend and
restoring it on resume, without setting the PWM_SW_UPDATE bit.
When the controller has lost its state over a suspend/resume and thus
has been reset to the defaults, just restoring the register is not
enough. We must also set the SW_UPDATE bit to tell the controller to
latch the restored values into the actual registers.
Fixing this problem is not as simple as just or-ing in the value which
is being restored with SW_UPDATE. If the PWM was enabled before we must
write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE.
We must also wait for PWM_SW_UPDATE to become 0 again and depending on the
model we must do this either before or after the setting of PWM_ENABLE.
All the necessary logic for doing this is already present inside
pwm_lpss_apply(), so instead of duplicating this inside the resume
handler, this commit adds a new pwm_lpss_restore() helper which mirrors
Re: [PATCH 01/10] dt-bindings: arm: samsung: pmu: Use unevaluatedProperties
On 29.08.2020 16:24, Krzysztof Kozlowski wrote: > Additional properties actually might appear (e.g. assigned-clocks) so > use unevaluatedProperties to fix dtbs_check warnings like: > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: > system-controller@105c: > 'assigned-clock-parents', 'assigned-clocks' do not match any of the > regexes: 'pinctrl-[0-9]+' > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sylwester Nawrocki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: fix kernel-doc warning in dma-fence.c
Am 31.08.20 um 06:17 schrieb Randy Dunlap: Add @cookie to dma_fence_end_signalling() to prevent kernel-doc warning in drivers/dma-buf/dma-fence.c: ../drivers/dma-buf/dma-fence.c:291: warning: Function parameter or member 'cookie' not described in 'dma_fence_end_signalling' Signed-off-by: Randy Dunlap Cc: Sumit Semwal Cc: Gustavo Padovan Cc: Christian König Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Acked-by: Christian König --- drivers/dma-buf/dma-fence.c |1 + 1 file changed, 1 insertion(+) --- lnx-59-rc3.orig/drivers/dma-buf/dma-fence.c +++ lnx-59-rc3/drivers/dma-buf/dma-fence.c @@ -283,6 +283,7 @@ EXPORT_SYMBOL(dma_fence_begin_signalling /** * dma_fence_end_signalling - end a critical DMA fence signalling section + * @cookie: opaque cookie from dma_fence_begin_signalling() * * Closes a critical section annotation opened by dma_fence_begin_signalling(). */ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 05/17] pwm: lpss: Add pwm_lpss_prepare_enable() helper
On Sun, Aug 30, 2020 at 02:57:41PM +0200, Hans de Goede wrote: > In the not-enabled -> enabled path pwm_lpss_apply() needs to get a > runtime-pm reference; and then on any errors it needs to release it > again. > > This leads to somewhat hard to read code. This commit introduces a new > pwm_lpss_prepare_enable() helper and moves all the steps necessary for > the not-enabled -> enabled transition there, so that we can error check > the entire transition in a single place and only have one pm_runtime_put() > on failure call site. > > While working on this I noticed that the enabled -> enabled (update > settings) path was quite similar, so I've added an enable parameter to > the new pwm_lpss_prepare_enable() helper, which allows using it in that > path too. > > Suggested-by: Andy Shevchenko > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > drivers/pwm/pwm-lpss.c | 45 -- > 1 file changed, 26 insertions(+), 19 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFT 2/4] ARM: dts: exynos: Move fixed clocks under root node in Exynos3250
On 29.08.2020 19:25, Krzysztof Kozlowski wrote:
> The fixed clocks are kept under dedicated node fixed-rate-clocks, thus a
> fake "reg" was added. This is not correct with dtschema as fixed-clock
> binding does not have a "reg" property:
>
>arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml: clock@0: 'reg' does not
> match any of the regexes: 'pinctrl-[0-9]+'
>
> Signed-off-by: Krzysztof Kozlowski
Tested-by: Marek Szyprowski
> ---
> arch/arm/boot/dts/exynos3250.dtsi | 42 +--
> 1 file changed, 17 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> index d3fb45a56527..c67c70e46794 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -97,33 +97,25 @@
> };
> };
>
> - fixed-rate-clocks {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - xusbxti: clock@0 {
> - compatible = "fixed-clock";
> - reg = <0>;
> - clock-frequency = <0>;
> - #clock-cells = <0>;
> - clock-output-names = "xusbxti";
> - };
> + xusbxti: clock-0 {
> + compatible = "fixed-clock";
> + clock-frequency = <0>;
> + #clock-cells = <0>;
> + clock-output-names = "xusbxti";
> + };
>
> - xxti: clock@1 {
> - compatible = "fixed-clock";
> - reg = <1>;
> - clock-frequency = <0>;
> - #clock-cells = <0>;
> - clock-output-names = "xxti";
> - };
> + xxti: clock-1 {
> + compatible = "fixed-clock";
> + clock-frequency = <0>;
> + #clock-cells = <0>;
> + clock-output-names = "xxti";
> + };
>
> - xtcxo: clock@2 {
> - compatible = "fixed-clock";
> - reg = <2>;
> - clock-frequency = <0>;
> - #clock-cells = <0>;
> - clock-output-names = "xtcxo";
> - };
> + xtcxo: clock-2 {
> + compatible = "fixed-clock";
> + clock-frequency = <0>;
> + #clock-cells = <0>;
> + clock-output-names = "xtcxo";
> };
>
> pmu {
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: [RFT 09/10] arm64: dts: exynos: Correct port of USB-C connector node on Exynos5433 TM2
Hi Krzysztof,
On 29.08.2020 16:25, Krzysztof Kozlowski wrote:
> The USB-C connector bindings require port@0. Such port was already
> described in DTS but outside of the connector itself. Put it into
> proper place to fix dtbs_check warnings like:
>
>arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: musb_connector: ports:
> 'port@0' is a required property
>
> Signed-off-by: Krzysztof Kozlowski
I'm not sure if topic should be about USB-C, I will call it simply USB
connector node. TM2(e) uses Samsung's 11-pin micro USB 2.0 connector,
which has nothing in common with USB Type-C.
Anyway, this patch breaks DWC3 (tested in Device mode) driver operation,
so something has to be somehow adjusted or fixed. Added CC Andrzej
Hajda, who actually worked on this.
> ---
>
> Not tested on HQ. Please kindly review and test.
>
> Best regards,
> Krzysztof
> ---
> .../boot/dts/exynos/exynos5433-tm2-common.dtsi| 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> index 6246cce2a15e..bab6c1addd5f 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> @@ -871,6 +871,13 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> + port@0 {
> + reg = <0>;
> + muic_to_usb: endpoint {
> + remote-endpoint =
> <_to_muic>;
> + };
> + };
> +
> port@3 {
> reg = <3>;
> musb_con_to_mhl: endpoint {
> @@ -879,14 +886,6 @@
> };
> };
> };
> -
> - ports {
> - port {
> - muic_to_usb: endpoint {
> - remote-endpoint =
> <_to_muic>;
> - };
> - };
> - };
> };
>
> regulators {
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: [bug report] drm/dp: annotate implicit fall throughs
On Fri, Aug 28, 2020 at 12:53:32PM +0300, Jani Nikula wrote:
> On Tue, 25 Aug 2020, Dan Carpenter wrote:
> > Hello Mathieu Malaterre,
> >
> > The patch e9c0c874711b: "drm/dp: annotate implicit fall throughs"
> > from Jan 14, 2019, leads to the following static checker warning:
> >
> > drivers/gpu/drm/drm_dp_helper.c:495 drm_dp_downstream_max_bpc()
> > warn: ignoring unreachable code.
> >
> > drivers/gpu/drm/drm_dp_helper.c
> >467 int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> >468const u8 port_cap[4])
> >469 {
> >470 int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
> >471 bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> >472 DP_DETAILED_CAP_INFO_AVAILABLE;
> >473 int bpc;
> >474
> >475 if (!detailed_cap_info)
> >476 return 0;
> >477
> >478 switch (type) {
> >479 case DP_DS_PORT_TYPE_VGA:
> >480 case DP_DS_PORT_TYPE_DVI:
> >481 case DP_DS_PORT_TYPE_HDMI:
> >482 case DP_DS_PORT_TYPE_DP_DUALMODE:
> >483 bpc = port_cap[2] & DP_DS_MAX_BPC_MASK;
> > ^^
> > This is 0x3.
> >
> >484
> >485 switch (bpc) {
> >486 case DP_DS_8BPC:
> >487 return 8;
> >488 case DP_DS_10BPC:
> >489 return 10;
> >490 case DP_DS_12BPC:
> >491 return 12;
> >492 case DP_DS_16BPC:
> >493 return 16;
> >494 }
> >495 fallthrough;
> >
> > This fallthrough is impossible. Probably the way to work around the
> > bogus warning is the change the fallthough to "return 0; /* impossible */"
> > otherwise the fallthrough is sort of misleading...
>
> Won't that be unreachable as well?
>
> Maybe just add the default label to switch (bpc)?
A default switch is going to be unreachable as well... But adding a
return 0 is the older more traditional ways way of marking these so
people and checkers are used to it.
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/crtc: add drmm_crtc_alloc_with_planes()
Hi Philipp,
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Philipp-Zabel/drm-add-drmm_encoder_alloc/20200826-203629
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-m001-20200826 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
smatch warnings:
drivers/gpu/drm/drm_crtc.c:343 drm_crtc_init_with_planes() error: uninitialized
symbol 'ap'.
drivers/gpu/drm/drm_crtc.c:383 __drmm_crtc_alloc_with_planes() error:
uninitialized symbol 'ap'.
#
https://github.com/0day-ci/linux/commit/236b7bc44ae0fdecc8e80c5aba0655ca14fdfb23
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Philipp-Zabel/drm-add-drmm_encoder_alloc/20200826-203629
git checkout 236b7bc44ae0fdecc8e80c5aba0655ca14fdfb23
vim +/ap +343 drivers/gpu/drm/drm_crtc.c
236b7bc44ae0fd Philipp Zabel 2020-08-26 331 int
drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
236b7bc44ae0fd Philipp Zabel 2020-08-26 332 struct
drm_plane *primary,
236b7bc44ae0fd Philipp Zabel 2020-08-26 333 struct
drm_plane *cursor,
236b7bc44ae0fd Philipp Zabel 2020-08-26 334 const
struct drm_crtc_funcs *funcs,
236b7bc44ae0fd Philipp Zabel 2020-08-26 335 const
char *name, ...)
236b7bc44ae0fd Philipp Zabel 2020-08-26 336 {
236b7bc44ae0fd Philipp Zabel 2020-08-26 337va_list ap;
236b7bc44ae0fd Philipp Zabel 2020-08-26 338int ret;
236b7bc44ae0fd Philipp Zabel 2020-08-26 339
236b7bc44ae0fd Philipp Zabel 2020-08-26 340if (name)
236b7bc44ae0fd Philipp Zabel 2020-08-26 341va_start(ap, name);
236b7bc44ae0fd Philipp Zabel 2020-08-26 342ret =
drm_crtc_init_with_planes(dev, crtc, primary, cursor, funcs,
236b7bc44ae0fd Philipp Zabel 2020-08-26 @343
name, ap);
^^
236b7bc44ae0fd Philipp Zabel 2020-08-26 344if (name)
236b7bc44ae0fd Philipp Zabel 2020-08-26 345va_end(ap);
236b7bc44ae0fd Philipp Zabel 2020-08-26 346
236b7bc44ae0fd Philipp Zabel 2020-08-26 347return ret;
236b7bc44ae0fd Philipp Zabel 2020-08-26 348 }
e13161af80c185 Matt Roper2014-04-01 349
EXPORT_SYMBOL(drm_crtc_init_with_planes);
f453ba0460742a Dave Airlie 2008-11-07 350
236b7bc44ae0fd Philipp Zabel 2020-08-26 351 static void
drmm_crtc_alloc_with_planes_cleanup(struct drm_device *dev,
236b7bc44ae0fd Philipp Zabel 2020-08-26 352
void *ptr)
236b7bc44ae0fd Philipp Zabel 2020-08-26 353 {
236b7bc44ae0fd Philipp Zabel 2020-08-26 354struct drm_crtc *crtc = ptr;
236b7bc44ae0fd Philipp Zabel 2020-08-26 355
236b7bc44ae0fd Philipp Zabel 2020-08-26 356drm_crtc_cleanup(crtc);
236b7bc44ae0fd Philipp Zabel 2020-08-26 357 }
236b7bc44ae0fd Philipp Zabel 2020-08-26 358
236b7bc44ae0fd Philipp Zabel 2020-08-26 359 void
*__drmm_crtc_alloc_with_planes(struct drm_device *dev,
236b7bc44ae0fd Philipp Zabel 2020-08-26 360
size_t size, size_t offset,
236b7bc44ae0fd Philipp Zabel 2020-08-26 361
struct drm_plane *primary,
236b7bc44ae0fd Philipp Zabel 2020-08-26 362
struct drm_plane *cursor,
236b7bc44ae0fd Philipp Zabel 2020-08-26 363
const struct drm_crtc_funcs *funcs,
236b7bc44ae0fd Philipp Zabel 2020-08-26 364
const char *name, ...)
236b7bc44ae0fd Philipp Zabel 2020-08-26 365 {
236b7bc44ae0fd Philipp Zabel 2020-08-26 366void *container;
236b7bc44ae0fd Philipp Zabel 2020-08-26 367struct drm_crtc *crtc;
236b7bc44ae0fd Philipp Zabel 2020-08-26 368va_list ap;
236b7bc44ae0fd Philipp Zabel 2020-08-26 369int ret;
236b7bc44ae0fd Philipp Zabel 2020-08-26 370
236b7bc44ae0fd Philipp Zabel 2020-08-26 371if (!funcs || funcs->destroy)
236b7bc44ae0fd Philipp Zabel 2020-08-26 372return ERR_PTR(-EINVAL);
236b7bc44ae0fd Philipp Zabel 2020-08-26 373
236b7bc44ae0fd Philipp Zabel 2020-08-26 374container = drmm_kzalloc(dev,
size, GFP_KERNEL);
236b7bc44ae0fd Philipp Zabel 2020-08-26 375if (!container)
236b7bc44ae0fd Philipp Zabel 2020-08-26 376return ERR_PTR(-ENOMEM);
236b7bc44ae0fd Philipp Zabel 2020-08-26 377
236b7bc44ae0fd Philipp Zabel 2020-08-26 378crtc = container + offset;
236b7bc44ae0fd Philipp Zabel 2020-08-26 379
236b7bc44ae0fd Philipp Zabel 2020-08-26 380if (name)
236b7bc44ae0fd Philipp Zabel 2020-08-26 381va_start(ap, name);
236b7bc44ae0fd Philipp Zabel 2020-08-26 382ret =
__drm_crtc_init_with_planes(dev, crtc, primary, cursor, funcs,
Re: [PATCH v8 04/17] pwm: lpss: Add range limit check for the base_unit register value
On Sun, Aug 30, 2020 at 02:57:40PM +0200, Hans de Goede wrote:
> When the user requests a high enough period ns value, then the
> calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
>
> But according to the data-sheet the way the PWM controller works is that
> each input clock-cycle the base_unit gets added to a N bit counter and
> that counter overflowing determines the PWM output frequency. Adding 0
> to the counter is a no-op. The data-sheet even explicitly states that
> writing 0 to the base_unit bits will result in the PWM outputting a
> continuous 0 signal.
>
> When the user requestes a low enough period ns value, then the
> calculations in pwm_lpss_prepare() might result in a base_unit value
> which is bigger then base_unit_range - 1. Currently the codes for this
> deals with this by applying a mask:
>
> base_unit &= (base_unit_range - 1);
>
> But this means that we let the value overflow the range, we throw away the
> higher bits and store whatever value is left in the lower bits into the
> register leading to a random output frequency, rather then clamping the
> output frequency to the highest frequency which the hardware can do.
>
> This commit fixes both issues by clamping the base_unit value to be
> between 1 and (base_unit_range - 1).
>
> Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
> Reviewed-by: Andy Shevchenko
> Signed-off-by: Hans de Goede
> ---
> Changes in v5:
> - Use clamp_val(... instead of clam_t(unsigned long long, ...
>
> Changes in v3:
> - Change upper limit of clamp to (base_unit_range - 1)
> - Add Fixes tag
> ---
> drivers/pwm/pwm-lpss.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 03/17] pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()
On Sun, Aug 30, 2020 at 02:57:39PM +0200, Hans de Goede wrote:
> According to the data-sheet the way the PWM controller works is that
> each input clock-cycle the base_unit gets added to a N bit counter and
> that counter overflowing determines the PWM output frequency.
>
> So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
> after 65535 input clock-cycles the counter has been increased from 0 to
> 65535 and it will overflow on the next cycle, so it will overflow after
> every 65536 clock cycles and thus the calculations done in
> pwm_lpss_prepare() should use 65536 and not 65535.
>
> This commit fixes this. Note this also aligns the calculations in
> pwm_lpss_prepare() with those in pwm_lpss_get_state().
>
> Note this effectively reverts commit 684309e5043e ("pwm: lpss: Avoid
> potential overflow of base_unit"). The next patch in this series really
> fixes the potential overflow of the base_unit value.
>
> Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
> Reviewed-by: Andy Shevchenko
> Acked-by: Uwe Kleine-König
> Signed-off-by: Hans de Goede
> ---
> Changes in v3:
> - Add Fixes tag
> - Add Reviewed-by: Andy Shevchenko tag
> ---
> drivers/pwm/pwm-lpss.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 10/17] pwm: crc: Fix period changes not having any effect
On Sun, Aug 30, 2020 at 02:57:46PM +0200, Hans de Goede wrote: > The pwm-crc code is using 2 different enable bits: > 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE) > 2. bit 0 of the BACKLIGHT_EN register > > The BACKLIGHT_EN register at address 0x51 really controls a separate > output-only GPIO which is earmarked to be used as output connected to the > backlight-enable pin for LCD panels, this GPO is part of the PMIC's > "Display Panel Control Block." . This pin should probably be moved over > to a GPIO provider driver (and consumers modified accordingly), but that > is something for an(other) patch. > > Enabling / disabling the actual PWM output is controlled by the > PWM_OUTPUT_ENABLE bit of the PWM0_CLK_DIV register. > > As the comment in the old code already indicates we must disable the PWM > before we can change the clock divider. But the crc_pwm_disable() and > crc_pwm_enable() calls the old code make for this only change the > BACKLIGHT_EN register; and the value of that register does not matter for > changing the period / the divider. What does matter is that the > PWM_OUTPUT_ENABLE bit must be cleared before a new value can be written. > > This commit modifies crc_pwm_config() to clear PWM_OUTPUT_ENABLE instead > when changing the period, so that period changes actually work. > > Note this fix will cause a significant behavior change on some devices > using the CRC PWM output to drive their backlight. Before the PWM would > always run with the output frequency configured by the BIOS at boot, now > the period time specified by the i915 driver will actually be honored. > > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > drivers/pwm/pwm-crc.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 11/17] pwm: crc: Enable/disable PWM output on enable/disable
On Sun, Aug 30, 2020 at 02:57:47PM +0200, Hans de Goede wrote: > The pwm-crc code is using 2 different enable bits: > 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE) > 2. bit 0 of the BACKLIGHT_EN register > > So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM, > this commit makes crc_pwm_disable() clear it on disable and makes > crc_pwm_enable() set it again on re-enable. > > Acked-by: Uwe Kleine-König > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > Changes in v3: > - Remove paragraph about tri-stating the output from the commit message, > we don't have a datasheet so this was just an unfounded guess > --- > drivers/pwm/pwm-crc.c | 4 > 1 file changed, 4 insertions(+) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 09/17] pwm: crc: Fix off-by-one error in the clock-divider calculations
On Sun, Aug 30, 2020 at 02:57:45PM +0200, Hans de Goede wrote: > The CRC PWM controller has a clock-divider which divides the clock with > a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx > defines, this range maps to a register value of 0-127. > > So after calculating the clock-divider we must subtract 1 to get the > register value, unless the requested frequency was so high that the > calculation has already resulted in a (rounded) divider value of 0. > > Note that before this fix, setting a period of PWM_MAX_PERIOD_NS which > corresponds to the max. divider value of 128 could have resulted in a > bug where the code would use 128 as divider-register value which would > have resulted in an actual divider value of 0 (and the enable bit being > set). A rounding error stopped this bug from actually happen. This > same rounding error means that after the subtraction of 1 it is impossible > to set the divider to 128. Also bump PWM_MAX_PERIOD_NS by 1 ns to allow > setting a divider of 128 (register-value 127). > > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > Changes in v3: > - Introduce crc_pwm_calc_clk_div() here instead of later in the patch-set > to reduce the amount of churn in the patch-set a bit > --- > drivers/pwm/pwm-crc.c | 17 ++--- > 1 file changed, 14 insertions(+), 3 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/10] dt-bindings: gpu: arm,mali-midgard: Use unevaluatedProperties
On 29.08.2020 16:24, Krzysztof Kozlowski wrote: > Additional properties or nodes actually might appear (e.g. operating > points table) so use unevaluatedProperties to fix dtbs_check warnings > like: > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: gpu@14ac: > 'opp_table' does not match any of the regexes: 'pinctrl-[0-9]+' > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sylwester Nawrocki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/10] dt-bindings: timer: exynos4210-mct: Use unevaluatedProperties
On 29.08.2020 16:24, Krzysztof Kozlowski wrote: > Additional properties actually might appear (e.g. clocks) so use > unevaluatedProperties to fix dtbs_check warnings like: > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: timer@101c: > 'clock-names', 'clocks' do not match any of the regexes: 'pinctrl-[0-9]+' > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sylwester Nawrocki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 07/17] pwm: lpss: Always update state and set update bit
On Sun, Aug 30, 2020 at 02:57:43PM +0200, Hans de Goede wrote:
> This commit removes a check where we would skip writing the ctrl register
> and then setting the update bit in case the ctrl register already contains
> the correct values.
>
> In a perfect world skipping the update should be fine in these cases, but
> on Cherry Trail devices the AML code in the GFX0 devices' PS0 and PS3
> methods messes with the PWM controller.
>
> The "ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase" patch
> earlier in this series stops the GFX0._PS0 method from messing with the PWM
> controller and on the DSDT-s inspected sofar the _PS3 method only reads
> from the PWM controller (and turns it off before we get a change to do so):
>
> {
> PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> PSAT |= 0x03
> Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> }
>
> The PWM controller getting turning off before we do this ourselves is
> a bit annoying but not really an issue.
>
> The problem this patch fixes comes from a new variant of the GFX0._PS3 code
> messing with the PWM controller found on the Acer One 10 S1003 (1):
>
> {
> PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> PWMT &= 0xFFFF
> PWMT |= 0xC000
> PWMC = PWMT /* \_SB_.PCI0.GFX0.PWMT */
> PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
> Sleep (0x64)
> PWMB &= 0x3FFF
> PWMC = PWMB /* \_SB_.PCI0.GFX0.PWMB */
> PSAT |= 0x03
> Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> }
>
> This "beautiful" piece of code clears the base-unit part of the ctrl-reg,
> which effectively disables the controller, and it sets the update flag
> to apply this change. Then after this it restores the original ctrl-reg
> value, so we do not see it has mucked with the controller.
>
> *But* it does not set the update flag when restoring the original value.
> So the check to see if we can skip writing the ctrl register succeeds
> but since the update flag was not set, the old base-unit value of 0 is
> still in use and the PWM controller is effectively disabled.
>
> IOW this PWM controller poking means that we cannot trust the base-unit /
> on-time-div value we read back from the PWM controller since it may not
> have been applied/committed. Thus we must always update the ctrl-register
> and set the update bit.
Doesn't this now make patch 6/17 obsolete?
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 08/17] pwm: crc: Fix period / duty_cycle times being off by a factor of 256
On Sun, Aug 30, 2020 at 02:57:44PM +0200, Hans de Goede wrote: > While looking into adding atomic-pwm support to the pwm-crc driver I > noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and > there is a clock-divider which divides this with a value between 1-128, > and there are 256 duty-cycle steps. > > The pwm-crc code before this commit assumed that a clock-divider > setting of 1 means that the PWM output is running at 6 MHZ, if that > is true, where do these 256 duty-cycle steps come from? > > This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that > seems unlikely for a PMIC which is using a silicon process optimized for > power-switching transistors. It is way more likely that there is an 8 > bit counter for the duty cycle which acts as an extra fixed divider > wrt the PWM output frequency. > > The main user of the pwm-crc driver is the i915 GPU driver which uses it > for backlight control. Lets compare the PWM register values set by the > video-BIOS (the GOP), assuming the extra fixed divider is present versus > the PWM frequency specified in the Video-BIOS-Tables: > > Device: PWM Hz set by BIOS PWM Hz specified in VBT > Asus T100TA 200 200 > Asus T100HA 200 200 > Lenovo Miix 2 8 23437 2 > Toshiba WT8-A 23437 2 > > So as we can see if we assume the extra division by 256 then the register > values set by the GOP are an exact match for the VBT values, where as > otherwise the values would be of by a factor of 256. > > This commit fixes the period / duty_cycle calculations to take the > extra division by 256 into account. > > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > Changes in v3: > - Use NSEC_PER_USEC instead of adding a new (non-sensical) NSEC_PER_MHZ define > --- > drivers/pwm/pwm-crc.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 08/17] pwm: crc: Fix period / duty_cycle times being off by a factor of 256
On Sun, Aug 30, 2020 at 02:57:44PM +0200, Hans de Goede wrote: > While looking into adding atomic-pwm support to the pwm-crc driver I > noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and > there is a clock-divider which divides this with a value between 1-128, > and there are 256 duty-cycle steps. > > The pwm-crc code before this commit assumed that a clock-divider > setting of 1 means that the PWM output is running at 6 MHZ, if that > is true, where do these 256 duty-cycle steps come from? > > This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that > seems unlikely for a PMIC which is using a silicon process optimized for > power-switching transistors. It is way more likely that there is an 8 > bit counter for the duty cycle which acts as an extra fixed divider > wrt the PWM output frequency. > > The main user of the pwm-crc driver is the i915 GPU driver which uses it > for backlight control. Lets compare the PWM register values set by the > video-BIOS (the GOP), assuming the extra fixed divider is present versus > the PWM frequency specified in the Video-BIOS-Tables: > > Device: PWM Hz set by BIOS PWM Hz specified in VBT > Asus T100TA 200 200 > Asus T100HA 200 200 > Lenovo Miix 2 8 23437 2 > Toshiba WT8-A 23437 2 > > So as we can see if we assume the extra division by 256 then the register > values set by the GOP are an exact match for the VBT values, where as > otherwise the values would be of by a factor of 256. > > This commit fixes the period / duty_cycle calculations to take the > extra division by 256 into account. > > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > Changes in v3: > - Use NSEC_PER_USEC instead of adding a new (non-sensical) NSEC_PER_MHZ define > --- > drivers/pwm/pwm-crc.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 07/17] pwm: lpss: Always update state and set update bit
Hi,
On 8/31/20 1:13 PM, Thierry Reding wrote:
On Sun, Aug 30, 2020 at 02:57:43PM +0200, Hans de Goede wrote:
This commit removes a check where we would skip writing the ctrl register
and then setting the update bit in case the ctrl register already contains
the correct values.
In a perfect world skipping the update should be fine in these cases, but
on Cherry Trail devices the AML code in the GFX0 devices' PS0 and PS3
methods messes with the PWM controller.
The "ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase" patch
earlier in this series stops the GFX0._PS0 method from messing with the PWM
controller and on the DSDT-s inspected sofar the _PS3 method only reads
from the PWM controller (and turns it off before we get a change to do so):
{
PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PSAT |= 0x03
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
}
The PWM controller getting turning off before we do this ourselves is
a bit annoying but not really an issue.
The problem this patch fixes comes from a new variant of the GFX0._PS3 code
messing with the PWM controller found on the Acer One 10 S1003 (1):
{
PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PWMT &= 0xFFFF
PWMT |= 0xC000
PWMC = PWMT /* \_SB_.PCI0.GFX0.PWMT */
PWMT = PWMC /* \_SB_.PCI0.GFX0.PWMC */
Sleep (0x64)
PWMB &= 0x3FFF
PWMC = PWMB /* \_SB_.PCI0.GFX0.PWMB */
PSAT |= 0x03
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
}
This "beautiful" piece of code clears the base-unit part of the ctrl-reg,
which effectively disables the controller, and it sets the update flag
to apply this change. Then after this it restores the original ctrl-reg
value, so we do not see it has mucked with the controller.
*But* it does not set the update flag when restoring the original value.
So the check to see if we can skip writing the ctrl register succeeds
but since the update flag was not set, the old base-unit value of 0 is
still in use and the PWM controller is effectively disabled.
IOW this PWM controller poking means that we cannot trust the base-unit /
on-time-div value we read back from the PWM controller since it may not
have been applied/committed. Thus we must always update the ctrl-register
and set the update bit.
Doesn't this now make patch 6/17 obsolete?
No, there is no guarantee we will get any changes soon after resume,
so we must restore the state properly on resume, before 5.17
we were just blindly restoring the old ctrl reg state, but
if either the freq-div or the duty-cycle changes, we should
also set the update bit in that case to apply the new freq-div/
duty-cycle.
This actually also helps with that case since patch 6/17 uses
pwm_lpss_prepare and this makes pwm_lpss_prepare set the
update but unconditionally.
Also on resume we most do the set the enable bit vs set
the update bit in the right order, depending on the
generation of the SoC in which the PWM controller is
embedded. 6/17 fixes all this by resume, by treating
resume as a special case of apply() taking all the
steps apply does.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: add support for gamma_set interface
On Saturday, August 29, 2020 4:06 PM, Sidong Yang wrote:
> Currently vkms module doesn't support gamma function for userspace. so igt
> subtests in kms_plane(pixel-format-pipe-A-plan) failed for calling
> drmModeCrtcSetGamma().
It doesn't seem like this IGT test's goal is to exercise support for
gamma LUTs. Does the test just tries to reset the gamma LUT to linear?
If so, I think the IGT test should be fixed to ignore "I don't support
gamma" errors.
> This patch set gamma_set interface in vkms_crtc_funcs for
> support gamma function. With initializing crtc, added calls for setting gamma
> size. it pass the test after this patch.
>
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
>
> Signed-off-by: Sidong Yang
> ---
> drivers/gpu/drm/vkms/vkms_crtc.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index ac85e17428f8..643435fb2ee6 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -160,6 +160,7 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
> .get_crc_sources= vkms_get_crc_sources,
> .set_crc_source = vkms_set_crc_source,
> .verify_crc_source = vkms_verify_crc_source,
> + .gamma_set = drm_atomic_helper_legacy_gamma_set,
Why does VKMS need to use a legacy helper?
It seems like this patch just advertises support for gamma LUTs, but
ignores any value set by user-space. If VKMS advertises support for
gamma LUTs, it needs to take the LUT into account when blending planes.
> };
>
> static int vkms_crtc_atomic_check(struct drm_crtc *crtc,
> @@ -275,6 +276,13 @@ int vkms_crtc_init(struct drm_device *dev, struct
> drm_crtc *crtc,
> return ret;
> }
>
> + ret = drm_mode_crtc_set_gamma_size(crtc, 256);
> + if (ret) {
> + DRM_ERROR("Failed to set gamma size\n");
> + return ret;
> + }
> + drm_crtc_enable_color_mgmt(crtc, 0, false, 256);
> +
> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
>
> spin_lock_init(_out->lock);
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] drm/mcde: Add new driver for ST-Ericsson MCDE
Hello Linus Walleij, The patch 5fc537bfd000: "drm/mcde: Add new driver for ST-Ericsson MCDE" from May 24, 2019, leads to the following static checker warning: drivers/gpu/drm/mcde/mcde_display.c:570 mcde_configure_channel() error: uninitialized symbol 'val'. drivers/gpu/drm/mcde/mcde_display.c 552 case MCDE_VIDEO_TE_FLOW: 553 val = MCDE_CHNLXSYNCHMOD_SRC_SYNCH_HARDWARE 554 << MCDE_CHNLXSYNCHMOD_SRC_SYNCH_SHIFT; 555 val |= MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_TE0 556 << MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_SHIFT; 557 break; 558 case MCDE_VIDEO_FORMATTER_FLOW: 559 val = MCDE_CHNLXSYNCHMOD_SRC_SYNCH_HARDWARE 560 << MCDE_CHNLXSYNCHMOD_SRC_SYNCH_SHIFT; 561 val |= MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_FORMATTER 562 << MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_SHIFT; 563 break; 564 default: 565 dev_err(mcde->dev, "unknown flow mode %d\n", 566 mcde->flow_mode); "val" not initialized on this path. 567 break; 568 } 569 570 writel(val, mcde->regs + sync); 571 572 /* Set up pixels per line and lines per frame */ regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/10] dt-bindings: mfd: syscon: Document Samsung Exynos compatibles
On 29.08.2020 16:24, Krzysztof Kozlowski wrote: > Samsung Exynos SoCs use syscon for system registers so document its > compatibles. > > Signed-off-by: Krzysztof Kozlowski > --- > Documentation/devicetree/bindings/mfd/syscon.yaml | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml > b/Documentation/devicetree/bindings/mfd/syscon.yaml > index 049ec2ffc7f9..0f21943dea28 100644 > --- a/Documentation/devicetree/bindings/mfd/syscon.yaml > +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml > @@ -40,6 +40,10 @@ properties: >- allwinner,sun50i-a64-system-controller >- microchip,sparx5-cpu-syscon >- mstar,msc313-pmsleep > + - samsung,exynos3-sysreg > + - samsung,exynos4-sysreg > + - samsung,exynos5-sysreg > + - samsung,exynos5433-sysreg Reviewed-by: Sylwester Nawrocki Do you also have a patch updating Documentation/devicetree/ bindings/arm/samsung/sysreg.yaml with new compatibles? -- Regards, Sylwester ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Experimental DMA-BUF Device Heaps
Hi James, On Sun, Aug 23, 2020 at 03:53:50PM -0700, James Jones wrote: > On 8/23/20 1:46 PM, Laurent Pinchart wrote: > > On Sun, Aug 23, 2020 at 01:04:43PM -0700, James Jones wrote: > >> On 8/20/20 1:15 AM, Ezequiel Garcia wrote: > >>> On Mon, 2020-08-17 at 20:49 -0700, James Jones wrote: > On 8/17/20 8:18 AM, Brian Starkey wrote: > > On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote: > >> This heap is basically a wrapper around DMA-API dma_alloc_attrs, > >> which will allocate memory suitable for the given device. > >> > >> The implementation is mostly a port of the Contiguous Videobuf2 > >> memory allocator (see videobuf2/videobuf2-dma-contig.c) > >> over to the DMA-BUF Heap interface. > >> > >> The intention of this allocator is to provide applications > >> with a more system-agnostic API: the only thing the application > >> needs to know is which device to get the buffer for. > >> > >> Whether the buffer is backed by CMA, IOMMU or a DMA Pool > >> is unknown to the application. > >> > >> I'm not really expecting this patch to be correct or even > >> a good idea, but just submitting it to start a discussion on DMA-BUF > >> heap discovery and negotiation. > >> > > > > My initial reaction is that I thought dmabuf heaps are meant for use > > to allocate buffers for sharing across devices, which doesn't fit very > > well with having per-device heaps. > > > > For single-device allocations, would using the buffer allocation > > functionality of that device's native API be better in most > > cases? (Some other possibly relevant discussion at [1]) > > > > I can see that this can save some boilerplate for devices that want > > to expose private chunks of memory, but might it also lead to 100 > > aliases for the system's generic coherent memory pool? > > > > I wonder if a set of helpers to allow devices to expose whatever they > > want with minimal effort would be better. > > I'm rather interested on where this goes, as I was toying with using > some sort of heap ID as a basis for a "device-local" constraint in the > memory constraints proposals Simon and I will be discussing at XDC this > year. It would be rather elegant if there was one type of heap ID used > universally throughout the kernel that could provide a unique handle for > the shared system memory heap(s), as well as accelerator-local heaps on > fancy NICs, GPUs, NN accelerators, capture devices, etc. so apps could > negotiate a location among themselves. This patch seems to be a step > towards that in a way, but I agree it would be counterproductive if a > bunch of devices that were using the same underlying system memory ended > up each getting their own heap ID just because they used some SW > framework that worked that way. > > Would appreciate it if you could send along a pointer to your BoF if it > happens! > >>> > >>> Here is it: > >>> > >>> https://linuxplumbersconf.org/event/7/contributions/818/ > >>> > >>> It would be great to see you there and discuss this, > >>> given I was hoping we could talk about how to meet a > >>> userspace allocator library expectations as well. > >> > >> Thanks! I hadn't registered for LPC and it looks like it's sold out, > >> but I'll try to watch the live stream. > >> > >> This is very interesting, in that it looks like we're both trying to > >> solve roughly the same set of problems but approaching it from different > >> angles. From what I gather, your approach is that a "heap" encompasses > >> all the allocation constraints a device may have. > >> > >> The approach Simon Ser and I are tossing around so far is somewhat > >> different, but may potentially leverage dma-buf heaps a bit as well. > >> > >> Our approach looks more like what I described at XDC a few years ago, > >> where memory constraints for a given device's usage of an image are > >> exposed up to applications, which can then somehow perform boolean > >> intersection/union operations on them to arrive at a common set of > >> constraints that describe something compatible with all the devices & > >> usages desired (or fail to do so, and fall back to copying things around > >> presumably). I believe this is more flexible than your initial proposal > >> in that devices often support multiple usages (E.g., different formats, > >> different proprietary layouts represented by format modifiers, etc.), > >> and it avoids adding a combinatorial number of heaps to manage that. > >> > >> In my view, heaps are more like blobs of memory that can be allocated > >> from in various different ways to satisfy constraints. I realize heaps > >> mean something specific in the dma-buf heap design (specifically, > >> something closer to an association between an "allocation mechanism" and > >> "physical memory"), but I hope we don't
[Bug 209091] New: i915: drm:fw_domains_get [i915] *ERROR* render: timed out waiting for forcewake ack request.
https://bugzilla.kernel.org/show_bug.cgi?id=209091 Bug ID: 209091 Summary: i915: drm:fw_domains_get [i915] *ERROR* render: timed out waiting for forcewake ack request. Product: Drivers Version: 2.5 Kernel Version: 5.8.5 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: madc...@atlas.cz Regression: No I have been seeing this error ever since I last updated my system packages. I see the following error message every time during boot: [ 11.504795] [drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake ack request. [ 11.509800] [ cut here ] [ 11.509801] i915 :00:02.0: Unclaimed read from register 0x235c [ 11.509850] WARNING: CPU: 4 PID: 494 at drivers/gpu/drm/i915/intel_uncore.c:1182 __unclaimed_reg_debug+0x77/0x90 [i915] [ 11.509851] Modules linked in: bnep joydev mousedev intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp kvm_intel iwldvm kvm mac80211 irqbypass snd_hda_codec_hdmi crct10dif_pclmul libarc4 crc32_pclmul snd_hda_codec_conexant ghash_clmulni_intel snd_hda_codec_generic nls_iso8859_1 mei_wdt mei_hdcp iwlwifi aesni_intel nls_cp437 iTCO_wdt btusb snd_hda_intel btrtl crypto_simd vfat btbcm cryptd fat snd_intel_dspcfg btintel glue_helper intel_pmc_bxt wmi_bmof rapl at24 iTCO_vendor_support intel_cstate snd_hda_codec bluetooth snd_hda_core thinkpad_acpi psmouse ecdh_generic snd_hwdep intel_uncore cfg80211 ecc nvram input_leds snd_pcm mei_me pcspkr ledtrig_audio e1000e lpc_ich i2c_i801 tpm_tis tpm_tis_core i2c_smbus snd_timer rfkill mei tpm snd wmi soundcore rng_core evdev battery ac mac_hid usbip_host usbip_core coretemp msr pkcs8_key_parser sg crypto_user ip_tables x_tables ext4 sdhci_pci cqhci serio_raw atkbd sdhci crc32c_generic libps2 crc16 ehci_pci mbcache i8042 jbd2 [ 11.509872] crc32c_intel mmc_core ehci_hcd serio i915 intel_gtt i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm agpgart [ 11.509878] CPU: 4 PID: 494 Comm: Xorg Tainted: GW I 5.8.5-arch1-1 #1 [ 11.509878] Hardware name: LENOVO 4236B87/4236B87, BIOS 83ET79WW (1.49 ) 09/05/2016 [ 11.509899] RIP: 0010:__unclaimed_reg_debug+0x77/0x90 [i915] [ 11.509900] Code: 48 8b 78 18 4c 8b 77 50 4d 85 f6 74 30 e8 f1 7e 58 ef 45 89 e0 4c 89 e9 4c 89 f2 48 89 c6 48 c7 c7 40 7e 49 c0 e8 8f b1 f5 ee <0f> 0b 83 2d a0 64 21 00 01 5b 5d 41 5c 41 5d 41 5e c3 c3 4c 8b 37 [ 11.509901] RSP: 0018:b6198089fd28 EFLAGS: 00010082 [ 11.509902] RAX: RBX: 965446d107e0 RCX: [ 11.509902] RDX: 0003 RSI: b056ac7f RDI: [ 11.509903] RBP: R08: 0521 R09: 0004 [ 11.509903] R10: R11: 0001 R12: 235c [ 11.509904] R13: c04c00ef R14: 96544b06df90 R15: 965446d107f8 [ 11.509905] FS: 7fc0db350540() GS:96544e30() knlGS: [ 11.509906] CS: 0010 DS: ES: CR0: 80050033 [ 11.509906] CR2: 7fc0da07d070 CR3: 0003ef1aa006 CR4: 000606e0 [ 11.509907] Call Trace: [ 11.509931] gen6_read32+0x1da/0x1f0 [i915] [ 11.509952] i915_reg_read_ioctl+0xc0/0x130 [i915] [ 11.509968] ? drm_gem_handle_delete+0x73/0x90 [drm] [ 11.509988] ? intel_uncore_fini_mmio+0xa0/0xa0 [i915] [ 11.509998] drm_ioctl_kernel+0xb2/0x100 [drm] [ 11.510008] drm_ioctl+0x208/0x360 [drm] [ 11.510029] ? intel_uncore_fini_mmio+0xa0/0xa0 [i915] [ 11.510033] ksys_ioctl+0x82/0xc0 [ 11.510035] __x64_sys_ioctl+0x16/0x20 [ 11.510038] do_syscall_64+0x44/0x70 [ 11.510040] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 11.510042] RIP: 0033:0x7fc0dbd08f6b [ 11.510043] Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c ff ff ff 85 c0 78 ba 4c 89 e0 5b 5d 41 5c c3 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d d5 ae 0c 00 f7 d8 64 89 01 48 [ 11.510044] RSP: 002b:7ffeffa77968 EFLAGS: 0246 ORIG_RAX: 0010 [ 11.510045] RAX: ffda RBX: 7ffeffa77a10 RCX: 7fc0dbd08f6b [ 11.510045] RDX: 7ffeffa77a10 RSI: c0106471 RDI: 000f [ 11.510046] RBP: c0106471 R08: R09: 55bf48dc6010 [ 11.510046] R10: 7ffeffb17080 R11: 0246 R12: [ 11.510047] R13: 000f R14: 55bf48e23b00 R15: 0003 [ 11.510049] ---[ end trace cc066b47ea04e946 ]--- The system still kind of works but the rendering performance seems reduced and noticeably sluggish. There are some more [drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake ack request.
[PATCH AUTOSEL 4.14 3/9] drm/msm: add shutdown support for display platform_driver
From: Krishna Manikandan
[ Upstream commit 9d5cbf5fe46e350715389d89d0c350d83289a102 ]
Define shutdown callback for display drm driver,
so as to disable all the CRTCS when shutdown
notification is received by the driver.
This change will turn off the timing engine so
that no display transactions are requested
while mmu translations are getting disabled
during reboot sequence.
Signed-off-by: Krishna Manikandan
Changes in v2:
- Remove NULL check from msm_pdev_shutdown (Stephen Boyd)
- Change commit text to reflect when this issue
was uncovered (Sai Prakash Ranjan)
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index d9c0687435a05..c59240b566d83 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1134,6 +1134,13 @@ static int msm_pdev_remove(struct platform_device *pdev)
return 0;
}
+static void msm_pdev_shutdown(struct platform_device *pdev)
+{
+ struct drm_device *drm = platform_get_drvdata(pdev);
+
+ drm_atomic_helper_shutdown(drm);
+}
+
static const struct of_device_id dt_match[] = {
{ .compatible = "qcom,mdp4", .data = (void *)4 }, /* MDP4 */
{ .compatible = "qcom,mdss", .data = (void *)5 }, /* MDP5 MDSS */
@@ -1144,6 +1151,7 @@ MODULE_DEVICE_TABLE(of, dt_match);
static struct platform_driver msm_platform_driver = {
.probe = msm_pdev_probe,
.remove = msm_pdev_remove,
+ .shutdown = msm_pdev_shutdown,
.driver = {
.name = "msm",
.of_match_table = dt_match,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 06/42] drm/msm/dpu: fix unitialized variable error
From: Rob Clark
[ Upstream commit 35c719da95c0d28560bff7bafeaf07ebb212665e ]
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:817 dpu_crtc_enable() error:
uninitialized symbol 'request_bandwidth'.
Reported-by: kernel test robot
Signed-off-by: Rob Clark
Reviewed-by: Sean Paul
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 969d95aa873c4..1026e1e5bec10 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -827,7 +827,7 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
{
struct dpu_crtc *dpu_crtc;
struct drm_encoder *encoder;
- bool request_bandwidth;
+ bool request_bandwidth = false;
if (!crtc) {
DPU_ERROR("invalid crtc\n");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 09/42] drm/msm: add shutdown support for display platform_driver
From: Krishna Manikandan
[ Upstream commit 9d5cbf5fe46e350715389d89d0c350d83289a102 ]
Define shutdown callback for display drm driver,
so as to disable all the CRTCS when shutdown
notification is received by the driver.
This change will turn off the timing engine so
that no display transactions are requested
while mmu translations are getting disabled
during reboot sequence.
Signed-off-by: Krishna Manikandan
Changes in v2:
- Remove NULL check from msm_pdev_shutdown (Stephen Boyd)
- Change commit text to reflect when this issue
was uncovered (Sai Prakash Ranjan)
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index f6ce40bf36998..b4d61af7a104e 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1328,6 +1328,13 @@ static int msm_pdev_remove(struct platform_device *pdev)
return 0;
}
+static void msm_pdev_shutdown(struct platform_device *pdev)
+{
+ struct drm_device *drm = platform_get_drvdata(pdev);
+
+ drm_atomic_helper_shutdown(drm);
+}
+
static const struct of_device_id dt_match[] = {
{ .compatible = "qcom,mdp4", .data = (void *)KMS_MDP4 },
{ .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
@@ -1340,6 +1347,7 @@ MODULE_DEVICE_TABLE(of, dt_match);
static struct platform_driver msm_platform_driver = {
.probe = msm_pdev_probe,
.remove = msm_pdev_remove,
+ .shutdown = msm_pdev_shutdown,
.driver = {
.name = "msm",
.of_match_table = dt_match,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 28/42] drm/omap: fix incorrect lock state
From: Tomi Valkeinen
[ Upstream commit 7fd5b25499bcec157dd4de9a713425efcf4571cd ]
After commit 92cc68e35863c1c61c449efa2b2daef6e9926048 ("drm/vblank: Use
spin_(un)lock_irq() in drm_crtc_vblank_on()") omapdrm locking is broken:
WARNING: inconsistent lock state
5.8.0-rc2-00483-g92cc68e35863 #13 Tainted: GW
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
ea98222c (>event_lock#2){?.+.}-{2:2}, at: drm_handle_vblank+0x4c/0x520
[drm]
{HARDIRQ-ON-W} state was registered at:
trace_hardirqs_on+0x9c/0x1ec
_raw_spin_unlock_irq+0x20/0x58
omap_crtc_atomic_enable+0x54/0xa0 [omapdrm]
drm_atomic_helper_commit_modeset_enables+0x218/0x270 [drm_kms_helper]
omap_atomic_commit_tail+0x48/0xc4 [omapdrm]
commit_tail+0x9c/0x190 [drm_kms_helper]
drm_atomic_helper_commit+0x154/0x188 [drm_kms_helper]
drm_client_modeset_commit_atomic+0x228/0x268 [drm]
drm_client_modeset_commit_locked+0x60/0x1d0 [drm]
drm_client_modeset_commit+0x24/0x40 [drm]
drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa8 [drm_kms_helper]
drm_fb_helper_set_par+0x2c/0x5c [drm_kms_helper]
drm_fb_helper_hotplug_event.part.0+0xa0/0xbc [drm_kms_helper]
drm_kms_helper_hotplug_event+0x24/0x30 [drm_kms_helper]
output_poll_execute+0x1a8/0x1c0 [drm_kms_helper]
process_one_work+0x268/0x800
worker_thread+0x30/0x4e0
kthread+0x164/0x190
ret_from_fork+0x14/0x20
The reason for this is that omapdrm calls drm_crtc_vblank_on() while
holding event_lock taken with spin_lock_irq().
It is not clear why drm_crtc_vblank_on() and drm_crtc_vblank_get() are
called while holding event_lock. I don't see any problem with moving
those calls outside the lock, which is what this patch does.
Signed-off-by: Tomi Valkeinen
Link:
https://patchwork.freedesktop.org/patch/msgid/20200819103021.440288-1-tomi.valkei...@ti.com
Reviewed-by: Laurent Pinchart
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index fce7e944a280b..dbf91b3fd6f08 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -451,11 +451,12 @@ static void omap_crtc_atomic_enable(struct drm_crtc *crtc,
if (omap_state->manually_updated)
return;
- spin_lock_irq(>dev->event_lock);
drm_crtc_vblank_on(crtc);
+
ret = drm_crtc_vblank_get(crtc);
WARN_ON(ret != 0);
+ spin_lock_irq(>dev->event_lock);
omap_crtc_arm_event(crtc);
spin_unlock_irq(>dev->event_lock);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 13/42] drm/msm: enable vblank during atomic commits
From: Rob Clark
[ Upstream commit 43906812eaab06423f56af5cca9a9fcdbb4ac454 ]
This has roughly the same effect as drm_atomic_helper_wait_for_vblanks(),
basically just ensuring that vblank accounting is enabled so that we get
valid timestamp/seqn on pageflip events.
Signed-off-by: Rob Clark
Tested-by: Stephen Boyd
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_atomic.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 5ccfad794c6a5..561bfa48841c3 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -27,6 +27,34 @@ int msm_atomic_prepare_fb(struct drm_plane *plane,
return msm_framebuffer_prepare(new_state->fb, kms->aspace);
}
+/*
+ * Helpers to control vblanks while we flush.. basically just to ensure
+ * that vblank accounting is switched on, so we get valid seqn/timestamp
+ * on pageflip events (if requested)
+ */
+
+static void vblank_get(struct msm_kms *kms, unsigned crtc_mask)
+{
+ struct drm_crtc *crtc;
+
+ for_each_crtc_mask(kms->dev, crtc, crtc_mask) {
+ if (!crtc->state->active)
+ continue;
+ drm_crtc_vblank_get(crtc);
+ }
+}
+
+static void vblank_put(struct msm_kms *kms, unsigned crtc_mask)
+{
+ struct drm_crtc *crtc;
+
+ for_each_crtc_mask(kms->dev, crtc, crtc_mask) {
+ if (!crtc->state->active)
+ continue;
+ drm_crtc_vblank_put(crtc);
+ }
+}
+
static void msm_atomic_async_commit(struct msm_kms *kms, int crtc_idx)
{
unsigned crtc_mask = BIT(crtc_idx);
@@ -44,6 +72,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
kms->funcs->enable_commit(kms);
+ vblank_get(kms, crtc_mask);
+
/*
* Flush hardware updates:
*/
@@ -58,6 +88,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
kms->funcs->wait_flush(kms, crtc_mask);
trace_msm_atomic_wait_flush_finish(crtc_mask);
+ vblank_put(kms, crtc_mask);
+
mutex_lock(>commit_lock);
kms->funcs->complete_commit(kms, crtc_mask);
mutex_unlock(>commit_lock);
@@ -221,6 +253,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
*/
kms->pending_crtc_mask &= ~crtc_mask;
+ vblank_get(kms, crtc_mask);
+
/*
* Flush hardware updates:
*/
@@ -235,6 +269,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
kms->funcs->wait_flush(kms, crtc_mask);
trace_msm_atomic_wait_flush_finish(crtc_mask);
+ vblank_put(kms, crtc_mask);
+
mutex_lock(>commit_lock);
kms->funcs->complete_commit(kms, crtc_mask);
mutex_unlock(>commit_lock);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 36/42] drm/amd/display: Revert HDCP disable sequence change
From: Jaehyun Chung [ Upstream commit b61f05622ace5b9498ae279cdfd1c9f0c1ce3f75 ] [Why] Revert HDCP disable sequence change that blanks stream before disabling HDCP. PSP and HW teams are currently investigating the root cause of why HDCP cannot be disabled before stream blank, which is expected to work without issues. Signed-off-by: Jaehyun Chung Reviewed-by: Wenjing Liu Acked-by: Eryk Brol Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 31aa31c280ee6..bdddb46727b1f 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -3265,10 +3265,10 @@ void core_link_disable_stream(struct pipe_ctx *pipe_ctx) core_link_set_avmute(pipe_ctx, true); } - dc->hwss.blank_stream(pipe_ctx); #if defined(CONFIG_DRM_AMD_DC_HDCP) update_psp_stream_config(pipe_ctx, true); #endif + dc->hwss.blank_stream(pipe_ctx); if (pipe_ctx->stream->signal == SIGNAL_TYPE_DISPLAY_PORT_MST) deallocate_mst_payload(pipe_ctx); -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 35/42] drivers: gpu: amd: Initialize amdgpu_dm_backlight_caps object to 0 in amdgpu_dm_update_backlight_caps
From: Furquan Shaikh [ Upstream commit 5896585512e5156482335e902f7c7393b940da51 ] In `amdgpu_dm_update_backlight_caps()`, there is a local `amdgpu_dm_backlight_caps` object that is filled in by `amdgpu_acpi_get_backlight_caps()`. However, this object is uninitialized before the call and hence the subsequent check for aux_support can fail since it is not initialized by `amdgpu_acpi_get_backlight_caps()` as well. This change initializes this local `amdgpu_dm_backlight_caps` object to 0. Reviewed-by: Christian König Signed-off-by: Furquan Shaikh Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 0a39a8558b294..0682fd363cb50 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2844,6 +2844,8 @@ static void amdgpu_dm_update_backlight_caps(struct amdgpu_display_manager *dm) #if defined(CONFIG_ACPI) struct amdgpu_dm_backlight_caps caps; + memset(, 0, sizeof(caps)); + if (dm->backlight_caps.caps_valid) return; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 34/42] drm/amd/display: Reject overlay plane configurations in multi-display scenarios
From: Nicholas Kazlauskas
[ Upstream commit 168f09cdadbd547c2b202246ef9a8183da725f13 ]
[Why]
These aren't stable on some platform configurations when driving
multiple displays, especially on higher resolution.
In particular the delay in asserting p-state and validating from
x86 outweights any power or performance benefit from the hardware
composition.
Under some configurations this will manifest itself as extreme stutter
or unresponsiveness especially when combined with cursor movement.
[How]
Disable these for now. Exposing overlays to userspace doesn't guarantee
that they'll be able to use them in any and all configurations and it's
part of the DRM contract to have userspace gracefully handle validation
failures when they occur.
Valdiation occurs as part of DC and this in particular affects RV, so
disable this in dcn10_global_validation.
Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Hersen Wu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
index 17d5cb422025e..8939541ad7afc 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
@@ -1213,6 +1213,7 @@ static enum dc_status dcn10_validate_global(struct dc
*dc, struct dc_state *cont
bool video_large = false;
bool desktop_large = false;
bool dcc_disabled = false;
+ bool mpo_enabled = false;
for (i = 0; i < context->stream_count; i++) {
if (context->stream_status[i].plane_count == 0)
@@ -1221,6 +1222,9 @@ static enum dc_status dcn10_validate_global(struct dc
*dc, struct dc_state *cont
if (context->stream_status[i].plane_count > 2)
return DC_FAIL_UNSUPPORTED_1;
+ if (context->stream_status[i].plane_count > 1)
+ mpo_enabled = true;
+
for (j = 0; j < context->stream_status[i].plane_count; j++) {
struct dc_plane_state *plane =
context->stream_status[i].plane_states[j];
@@ -1244,6 +1248,10 @@ static enum dc_status dcn10_validate_global(struct dc
*dc, struct dc_state *cont
}
}
+ /* Disable MPO in multi-display configurations. */
+ if (context->stream_count > 1 && mpo_enabled)
+ return DC_FAIL_UNSUPPORTED_1;
+
/*
* Workaround: On DCN10 there is UMC issue that causes underflow when
* playing 4k video on 4k desktop with video downscaled and single
channel
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 21/42] drm/msm/a6xx: fix gmu start on newer firmware
From: Dmitry Baryshkov
[ Upstream commit f5749d6181fa7df5ae741788e5d96f593d3a60b6 ]
New Qualcomm firmware has changed a way it reports back the 'started'
event. Support new register values.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 1d330204c465c..2dd1cf1ffbe25 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -207,6 +207,16 @@ static int a6xx_gmu_start(struct a6xx_gmu *gmu)
{
int ret;
u32 val;
+ u32 mask, reset_val;
+
+ val = gmu_read(gmu, REG_A6XX_GMU_CM3_DTCM_START + 0xff8);
+ if (val <= 0x20010004) {
+ mask = 0x;
+ reset_val = 0xbabeface;
+ } else {
+ mask = 0x1ff;
+ reset_val = 0x100;
+ }
gmu_write(gmu, REG_A6XX_GMU_CM3_SYSRESET, 1);
@@ -218,7 +228,7 @@ static int a6xx_gmu_start(struct a6xx_gmu *gmu)
gmu_write(gmu, REG_A6XX_GMU_CM3_SYSRESET, 0);
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_CM3_FW_INIT_RESULT, val,
- val == 0xbabeface, 100, 1);
+ (val & mask) == reset_val, 100, 1);
if (ret)
DRM_DEV_ERROR(gmu->dev, "GMU firmware initialization timed
out\n");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 33/42] drm/amd/display: should check error using DC_OK
From: Tong Zhang [ Upstream commit ed9ab229fea24cbcab17f484297dc8344afb7ea9 ] core_link_read_dpcd returns only DC_OK(1) and DC_ERROR_UNEXPECTED(-1), the caller should check error using DC_OK instead of checking against 0 Signed-off-by: Tong Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c index 91cd884d6f257..7728fd71d1f3a 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c @@ -4346,9 +4346,9 @@ bool dc_link_get_backlight_level_nits(struct dc_link *link, link->connector_signal != SIGNAL_TYPE_DISPLAY_PORT)) return false; - if (!core_link_read_dpcd(link, DP_SOURCE_BACKLIGHT_CURRENT_PEAK, + if (core_link_read_dpcd(link, DP_SOURCE_BACKLIGHT_CURRENT_PEAK, dpcd_backlight_get.raw, - sizeof(union dpcd_source_backlight_get))) + sizeof(union dpcd_source_backlight_get)) != DC_OK) return false; *backlight_millinits_avg = @@ -4387,9 +4387,9 @@ bool dc_link_read_default_bl_aux(struct dc_link *link, uint32_t *backlight_milli link->connector_signal != SIGNAL_TYPE_DISPLAY_PORT)) return false; - if (!core_link_read_dpcd(link, DP_SOURCE_BACKLIGHT_LEVEL, + if (core_link_read_dpcd(link, DP_SOURCE_BACKLIGHT_LEVEL, (uint8_t *) backlight_millinits, - sizeof(uint32_t))) + sizeof(uint32_t)) != DC_OK) return false; return true; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 04/42] drm/msm/dpu: Fix reservation failures in modeset
From: Kalyan Thota
[ Upstream commit ccc862b957c6413b008fbe458034372847992d7f ]
In TEST_ONLY commit, rm global_state will duplicate the
object and request for new reservations, once they pass
then the new state will be swapped with the old and will
be available for the Atomic Commit.
This patch fixes some of missing links in the resource
reservation sequence mentioned above.
1) Creation of duplicate state in test_only commit (Rob)
2) Allocate and release the resources on every modeset.
3) Avoid allocation only when active is false.
In a modeset operation, swap state happens well before
disable. Hence clearing reservations in disable will
cause failures in modeset enable.
Allow reservations to be cleared/allocated before swap,
such that only newly committed resources are pushed to HW.
Changes in v1:
- Move the rm release to atomic_check.
- Ensure resource allocation and free happens when active
is not changed i.e only when mode is changed.(Rob)
Changes in v2:
- Handle dpu_kms_get_global_state API failure as it may
return EDEADLK (swboyd).
Signed-off-by: Kalyan Thota
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 0946a86b37b28..c0cd936314e66 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -586,7 +586,10 @@ static int dpu_encoder_virt_atomic_check(
dpu_kms = to_dpu_kms(priv->kms);
mode = _state->mode;
adj_mode = _state->adjusted_mode;
- global_state = dpu_kms_get_existing_global_state(dpu_kms);
+ global_state = dpu_kms_get_global_state(crtc_state->state);
+ if (IS_ERR(global_state))
+ return PTR_ERR(global_state);
+
trace_dpu_enc_atomic_check(DRMID(drm_enc));
/*
@@ -621,12 +624,15 @@ static int dpu_encoder_virt_atomic_check(
/* Reserve dynamic resources now. */
if (!ret) {
/*
-* Avoid reserving resources when mode set is pending. Topology
-* info may not be available to complete reservation.
+* Release and Allocate resources on every modeset
+* Dont allocate when active is false.
*/
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
- ret = dpu_rm_reserve(_kms->rm, global_state,
- drm_enc, crtc_state, topology);
+ dpu_rm_release(global_state, drm_enc);
+
+ if (!crtc_state->active_changed || crtc_state->active)
+ ret = dpu_rm_reserve(_kms->rm, global_state,
+ drm_enc, crtc_state, topology);
}
}
@@ -1175,7 +1181,6 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
struct dpu_encoder_virt *dpu_enc = NULL;
struct msm_drm_private *priv;
struct dpu_kms *dpu_kms;
- struct dpu_global_state *global_state;
int i = 0;
if (!drm_enc) {
@@ -1194,7 +1199,6 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
priv = drm_enc->dev->dev_private;
dpu_kms = to_dpu_kms(priv->kms);
- global_state = dpu_kms_get_existing_global_state(dpu_kms);
trace_dpu_enc_disable(DRMID(drm_enc));
@@ -1224,8 +1228,6 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
DPU_DEBUG_ENC(dpu_enc, "encoder disabled\n");
- dpu_rm_release(global_state, drm_enc);
-
mutex_unlock(_enc->enc_lock);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
