[PATCH v8 6/6] MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver
Add myself as the maintainer of the i.MX8qxp DPU DRM driver. Signed-off-by: Liu Ying --- v7->v8: * No change. v6->v7: * No change. v5->v6: * No change. v4->v5: * No change. v3->v4: * No change. v2->v3: * No change. v1->v2: * No change. MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 63bd69c..08cd9cd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5892,6 +5892,15 @@ F: Documentation/devicetree/bindings/display/imx/ F: drivers/gpu/drm/imx/ F: drivers/gpu/ipu-v3/ +DRM DRIVERS FOR FREESCALE i.MX8QXP +M: Liu Ying +L: dri-devel@lists.freedesktop.org +S: Maintained +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml +F: drivers/gpu/drm/imx/dpu/ + DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets) M: Patrik Jakobsson L: dri-devel@lists.freedesktop.org -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 4/6] drm/atomic: Avoid unused-but-set-variable warning on for_each_old_plane_in_state
Artificially use 'plane' and 'old_plane_state' to avoid 'not used' warning. The precedent has already been set by other macros in the same file. Acked-by: Daniel Vetter Signed-off-by: Liu Ying --- v7->v8: * No change. v6->v7: * No change. v5->v6: * Fix commit message typo - s/Artifically/Artificially/ v4->v5: * No change. v3->v4: * Add Daniel's A-b tag. v2->v3: * Add a missing blank line. v1->v2: * No change. include/drm/drm_atomic.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index ac5a28e..76d8dee 100644 --- a/include/drm/drm_atomic.h +++ b/include/drm/drm_atomic.h @@ -912,7 +912,10 @@ void drm_state_dump(struct drm_device *dev, struct drm_printer *p); (__i)++) \ for_each_if ((__state)->planes[__i].ptr && \ ((plane) = (__state)->planes[__i].ptr, \ - (old_plane_state) = (__state)->planes[__i].old_state, 1)) + (void)(plane) /* Only to avoid unused-but-set-variable warning */, \ + (old_plane_state) = (__state)->planes[__i].old_state, \ + (void)(old_plane_state) /* Only to avoid unused-but-set-variable warning */, 1)) + /** * for_each_new_plane_in_state - iterate over all planes in an atomic update * @__state: drm_atomic_state pointer -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 3/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v7->v8:
* No change.
v6->v7:
* No change.
v5->v6:
* No change.
v4->v5:
* No change.
v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.
v2->v3:
* No change.
v1->v2:
* Use new dt binding way to add clocks in the example.
.../bindings/display/imx/fsl,imx8qxp-dprc.yaml | 87 ++
1 file changed, 87 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
diff --git
a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
new file mode 100644
index ..9e05c83
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dprc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Channel
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The i.MX8qm/qxp Display Prefetch Resolve Channel(DPRC) is an engine which
+ fetches display data before the display pipeline needs the data to drive
+ pixels in the active display region. This data is transformed, or resolved,
+ from a variety of tiled buffer formats into linear format, if needed.
+ The DPR works with a double bank memory structure. This memory structure is
+ implemented in the Resolve Tile Memory(RTRAM) and the banks are referred to
+ as A and B. Each bank is either 4 or 8 lines high depending on the source
+ frame buffer format.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8qxp-dpr-channel
+ - fsl,imx8qm-dpr-channel
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: apb clock
+ - description: b clock
+ - description: rtram clock
+
+ clock-names:
+items:
+ - const: apb
+ - const: b
+ - const: rtram
+
+ fsl,sc-resource:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: The SCU resource ID associated with this DPRC instance.
+
+ fsl,prgs:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: |
+ List of phandle which points to Prefetch Resolve Gaskets(PRGs)
+ associated with this DPRC instance.
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - fsl,sc-resource
+ - fsl,prgs
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+dpr-channel@5610 {
+compatible = "fsl,imx8qxp-dpr-channel";
+reg = <0x5610 0x1>;
+interrupts = ;
+clocks = <_dpr1_lpcg IMX_LPCG_CLK_4>,
+ <_dpr1_lpcg IMX_LPCG_CLK_5>,
+ <_rtram1_lpcg IMX_LPCG_CLK_0>;
+clock-names = "apb", "b", "rtram";
+fsl,sc-resource = ;
+fsl,prgs = <_prg4>, <_prg5>;
+power-domains = < IMX_SC_R_DC_0>;
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 2/6] dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Gasket.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v7->v8:
* No change.
v6->v7:
* No change.
v5->v6:
* No change.
v4->v5:
* No change.
v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.
v2->v3:
* No change.
v1->v2:
* Use new dt binding way to add clocks in the example.
.../bindings/display/imx/fsl,imx8qxp-prg.yaml | 60 ++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
new file mode 100644
index ..3ff46e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-prg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Gasket
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The i.MX8qm/qxp Prefetch Resolve Gasket (PRG) is a gasket interface between
+ RTRAM controller and Display Controller. The main function is to convert
+ the AXI interface to the RTRAM interface, which includes re-mapping the
+ ARADDR to a RTRAM address.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8qxp-prg
+ - fsl,imx8qm-prg
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: rtram clock
+ - description: apb clock
+
+ clock-names:
+items:
+ - const: rtram
+ - const: apb
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+prg@5604 {
+compatible = "fsl,imx8qxp-prg";
+reg = <0x5604 0x1>;
+clocks = <_prg0_lpcg IMX_LPCG_CLK_0>,
+ <_prg0_lpcg IMX_LPCG_CLK_4>;
+clock-names = "rtram", "apb";
+power-domains = < IMX_SC_R_DC_0>;
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding
This patch adds bindings for i.MX8qxp/qm Display Processing Unit. Reviewed-by: Rob Herring Signed-off-by: Liu Ying --- v7->v8: * No change. v6->v7: * Add Rob's R-b tag back. v5->v6: * Use graph schema. So, drop Rob's R-b tag as review is needed. v4->v5: * No change. v3->v4: * Improve compatible property by using enum instead of oneOf+const. (Rob) * Add Rob's R-b tag. v2->v3: * No change. v1->v2: * Fix yamllint warnings. * Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm, as the display controller subsystem spec does say that they exist. * Use new dt binding way to add clocks in the example. * Trivial tweaks for the example. .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 387 + 1 file changed, 387 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml new file mode 100644 index ..9da9560 --- /dev/null +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml @@ -0,0 +1,387 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8qm/qxp Display Processing Unit + +maintainers: + - Liu Ying + +description: | + The Freescale i.MX8qm/qxp Display Processing Unit(DPU) is comprised of two + main components that include a blit engine for 2D graphics accelerations + and a display controller for display output processing, as well as a command + sequencer. + +properties: + compatible: +enum: + - fsl,imx8qxp-dpu + - fsl,imx8qm-dpu + + reg: +maxItems: 1 + + interrupts: +items: + - description: | + store9 shadow load interrupt(blit engine) + - description: | + store9 frame complete interrupt(blit engine) + - description: | + store9 sequence complete interrupt(blit engine) + - description: | + extdst0 shadow load interrupt + (display controller, content stream 0) + - description: | + extdst0 frame complete interrupt + (display controller, content stream 0) + - description: | + extdst0 sequence complete interrupt + (display controller, content stream 0) + - description: | + extdst4 shadow load interrupt + (display controller, safety stream 0) + - description: | + extdst4 frame complete interrupt + (display controller, safety stream 0) + - description: | + extdst4 sequence complete interrupt + (display controller, safety stream 0) + - description: | + extdst1 shadow load interrupt + (display controller, content stream 1) + - description: | + extdst1 frame complete interrupt + (display controller, content stream 1) + - description: | + extdst1 sequence complete interrupt + (display controller, content stream 1) + - description: | + extdst5 shadow load interrupt + (display controller, safety stream 1) + - description: | + extdst5 frame complete interrupt + (display controller, safety stream 1) + - description: | + extdst5 sequence complete interrupt + (display controller, safety stream 1) + - description: | + disengcfg0 shadow load interrupt + (display controller, display stream 0) + - description: | + disengcfg0 frame complete interrupt + (display controller, display stream 0) + - description: | + disengcfg0 sequence complete interrupt + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt0 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt1 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt2 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt3 + (display controller, display stream 0) + - description: | + signature0 shadow load interrupt + (display controller, display stream 0) + - description: | + signature0 measurement valid interrupt + (display controller, display stream 0) + - description: | + signature0 error condition interrupt + (display controller, display stream 0) + - description: | + disengcfg1 shadow load interrupt + (display controller, display stream 1) + - description: | + disengcfg1 frame complete interrupt + (display controller, display stream 1) + - description: | +
[PATCH v8 0/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM
Hi, This is the v8 series to introduce i.MX8qm/qxp Display Processing Unit(DPU) DRM support. DPU is comprised of a blit engine for 2D graphics, a display controller and a command sequencer. Outside of DPU, optional prefetch engines can fetch data from memory prior to some DPU fetchunits of blit engine and display controller. The pre-fetchers support linear formats and Vivante GPU tile formats. Reference manual can be found at: https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM This patch set adds kernel modesetting support for the display controller part. It supports two CRTCs per display controller, several planes, prefetch engines and some properties of CRTC and plane. Currently, the registers of the controller is accessed without command sequencer involved, instead just by using CPU. DRM connectors would be created from the DPU KMS driver. If people want to try this series with i.MX8qxp, clock patches have already landed in 5.12-rc1, and power domain patches have already landed in 5.11-rc1. Version2 dropped the device tree patches because we'll use new dt binding way to support i.MX8qm/qxp clocks. It depends on the below series to do basic conversions for the platforms which has not landed yet: https://www.spinics.net/lists/linux-mmc/msg61965.html I've sent the below series to add downstream bridges(embedded in i.MX8qm/qxp) to support LVDS displays: https://www.spinics.net/lists/arm-kernel/msg876784.html Patch 1 ~ 3 add dt-bindings for DPU and prefetch engines. Patch 4 is a minor improvement of a macro to suppress warning as the KMS driver uses it. Patch 5 introduces the DPU DRM support. Patch 6 updates MAINTAINERS. Welcome comments, thanks. v7->v8: * Rebase this series up onto the latest drm-misc-next branch, due to DRM plane helper functions API change(atomic_check and atomic_update) from DRM atomic core. So, dpu_plane_atomic_check() and dpu_plane_atomic_update() are updated accordingly in patch 5/6. Also, rename plane->state variables and relevant DPU plane state variables in those two functions to reflect they are new states, like the patch 'drm: Rename plane->state variables in atomic update and disable' recently landed in drm-misc-next. * Replace drm_gem_fb_prepare_fb() with drm_gem_plane_helper_prepare_fb() in patch 5/6, due to DRM core API change. * Improve DPR burst length for GPU standard tile and 32bpp GPU super tile in patch 5/6 to align with the latest version of internal HW documention. v6->v7: * Fix return value of dpu_get_irqs() if platform_get_irq() fails. (Laurentiu) * Use the function array dpu_irq_handler[] to store individual DPU irq handlers. (Laurentiu) * Call get/put() hooks directly to get/put DPU fetchunits for DPU plane groups. (Laurentiu) * Shorten the names of individual DPU irq handlers by using DPU unit abbrev names to make writing dpu_irq_handler[] easier. * Add Rob's R-b tag back on DPU dt-binding patch as change in v6 was reviewed. v5->v6: * Use graph schema in the DPU dt-binding. * Do not use macros where possible in the DPU DRM driver. (Laurentiu) * Break dpu_plane_atomic_check() into some smaller functions. (Laurentiu) * Address some minor comments from Laurentiu on the DPU DRM driver. * Add dpu_crtc_err() helper marco in the DPU DRM driver to tell dmesg which CRTC generates error. * Drop calling dev_set_drvdata() from dpu_drm_bind/unbind() in the DPU DRM driver as it is done in dpu_drm_probe(). * Some trivial tweaks. v4->v5: * Rebase up onto the latest drm-misc-next branch and remove the hook to drm_atomic_helper_legacy_gamma_set() from patch 5/6, because it was dropped by the newly landed commit 'drm: automatic legacy gamma support'. * Remove a redundant blank line from dpu_plane_atomic_update() in patch 5/6. v3->v4: * Improve compatible properties in DPU and prefetch engines' dt bindings by using enum instead of oneOf+const. * Add Rob's R-b tags on dt binding patches(patch 1/6, 2/6 and 3/6). * Add Daniel's A-b tag on patch 4/6. v2->v3: * Fix DPU DRM driver build warnings which are Reported-by: kernel test robot . * Drop DPU DRM driver build dependency on IMX_SCU, as dummy SCU functions have been added in header files by the patch 'firmware: imx: add dummy functions' which has landed in linux-next/master branch. * Add a missing blank line in include/drm/drm_atomic.h. v1->v2: * Test this patch set also with i.MX8qm LVDS displays. * Drop the device tree patches because we'll use new dt binding way to support i.MX8qm/qxp clocks. This depends on a not-yet-landed patch set to do basic conversions for the platforms. * Fix dt binding yamllint warnings. * Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm in DPU's dt binding documentation. * Use new dt binding way to add clocks in the dt binding examples. * Address several comments from Laurentiu on the DPU DRM patch. Liu Ying (6): dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding dt-bindings: display: imx: Add i.MX8qxp/qm
[PATCH 04/44] vgacon: comment on vga_rolled_over
Long time ago, I figured out what this number is good for and documented that locally. But never submitted, so do it now. Signed-off-by: Jiri Slaby Cc: dri-devel@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org --- drivers/video/console/vgacon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c index 962c12be9774..0d26e821e73b 100644 --- a/drivers/video/console/vgacon.c +++ b/drivers/video/console/vgacon.c @@ -96,7 +96,7 @@ static bool vga_is_gfx; static boolvga_512_chars; static int vga_video_font_height; static int vga_scan_lines __read_mostly; -static unsigned intvga_rolled_over; +static unsigned intvga_rolled_over; /* last vc_origin offset before wrap */ static bool vgacon_text_mode_force; static bool vga_hardscroll_enabled; -- 2.30.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: ioremap buffer according to TTM mem caching setting
Hi Oak,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip linus/master v5.12-rc1 next-20210302]
[cannot apply to tegra-drm/drm/tegra/for-next drm-exynos/exynos-drm-next
drm/drm-next]
[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/Oak-Zeng/drm-ttm-ioremap-buffer-according-to-TTM-mem-caching-setting/20210302-064500
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: parisc-randconfig-r012-20210302 (attached as .config)
compiler: hppa-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
#
https://github.com/0day-ci/linux/commit/225bb3711439ec559dd72ae5af8e62d34ea60a64
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Oak-Zeng/drm-ttm-ioremap-buffer-according-to-TTM-mem-caching-setting/20210302-064500
git checkout 225bb3711439ec559dd72ae5af8e62d34ea60a64
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=parisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_resource_ioremap':
>> drivers/gpu/drm/ttm/ttm_bo_util.c:95:11: error: implicit declaration of
>> function 'ioremap_cache'; did you mean 'ioremap_uc'?
>> [-Werror=implicit-function-declaration]
95 |addr = ioremap_cache(mem->bus.offset, bus_size);
| ^
| ioremap_uc
drivers/gpu/drm/ttm/ttm_bo_util.c:95:9: warning: assignment to 'void *' from
'int' makes pointer from integer without a cast [-Wint-conversion]
95 |addr = ioremap_cache(mem->bus.offset, bus_size);
| ^
drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_ioremap':
drivers/gpu/drm/ttm/ttm_bo_util.c:379:17: warning: assignment to 'void *'
from 'int' makes pointer from integer without a cast [-Wint-conversion]
379 |map->virtual = ioremap_cache(bo->mem.bus.offset + offset,
| ^
drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_vmap':
drivers/gpu/drm/ttm/ttm_bo_util.c:500:16: warning: assignment to 'void *'
from 'int' makes pointer from integer without a cast [-Wint-conversion]
500 |vaddr_iomem = ioremap_cache(mem->bus.offset,
|^
cc1: some warnings being treated as errors
vim +95 drivers/gpu/drm/ttm/ttm_bo_util.c
74
75 static int ttm_resource_ioremap(struct ttm_bo_device *bdev,
76 struct ttm_resource *mem,
77 void **virtual)
78 {
79 int ret;
80 void *addr;
81
82 *virtual = NULL;
83 ret = ttm_mem_io_reserve(bdev, mem);
84 if (ret || !mem->bus.is_iomem)
85 return ret;
86
87 if (mem->bus.addr) {
88 addr = mem->bus.addr;
89 } else {
90 size_t bus_size = (size_t)mem->num_pages << PAGE_SHIFT;
91
92 if (mem->bus.caching == ttm_write_combined)
93 addr = ioremap_wc(mem->bus.offset, bus_size);
94 else if (mem->bus.caching == ttm_cached)
> 95 addr = ioremap_cache(mem->bus.offset, bus_size);
96 else
97 addr = ioremap(mem->bus.offset, bus_size);
98 if (!addr) {
99 ttm_mem_io_free(bdev, mem);
100 return -ENOMEM;
101 }
102 }
103 *virtual = addr;
104 return 0;
105 }
106
---
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] drm/fb-helper: only unmap if buffer not null
Hi Tomas, I think the issue could be possibly caused by the following, Please correct me if I'm wrong. drm_fb_helper_single_fb_probe() can fail with "Cannot find any crtc or sizes" which will cause fb_helper->funcs->fb_probe not being called, thus fb_helper->buffer remains NULL -- Since there could be the case that the fb_probe is never called, a subsequent modprobe -r will cause the following drm_client_buffer_vunmap(NULL) in drm_fbdev_cleanup() Best, - Tong On Mon, Mar 1, 2021 at 3:26 AM Thomas Zimmermann wrote: > > Hi > > Am 28.02.21 um 05:46 schrieb Tong Zhang: > > drm_fbdev_cleanup() can be called when fb_helper->buffer is null, hence > > fb_helper->buffer should be checked before calling > > drm_client_buffer_vunmap(). This buffer is also checked in > > drm_client_framebuffer_delete(), so we should also do the same thing for > > drm_client_buffer_vunmap(). > > I think a lot of drivers are affected by this problem; probably most of > the ones that use the generic fbdev code. How did you produce the error? > > What I'm more concerned about is why the buffer is NULL. Was ther eno > hotplug event? Do you have a display attached? > > Best regards > Thomas > > > > > > [ 199.128742] RIP: 0010:drm_client_buffer_vunmap+0xd/0x20 > > [ 199.129031] Code: 43 18 48 8b 53 20 49 89 45 00 49 89 55 08 5b 44 89 e0 > > 41 5c 41 5d 41 5e 5d > > c3 0f 1f 00 53 48 89 fb 48 8d 7f 10 e8 73 7d a1 ff <48> 8b 7b 10 48 8d 73 > > 18 5b e9 75 53 fc ff 0 > > f 1f 44 00 00 48 b8 00 > > [ 199.130041] RSP: 0018:888103f3fc88 EFLAGS: 00010282 > > [ 199.130329] RAX: 0001 RBX: RCX: > > 8214d46d > > [ 199.130733] RDX: 1079c6b9 RSI: 0246 RDI: > > 83ce35c8 > > [ 199.131119] RBP: 888103d25458 R08: 0001 R09: > > fbfff0791761 > > [ 199.131505] R10: 83c8bb07 R11: fbfff0791760 R12: > > > > [ 199.131891] R13: 888103d25468 R14: 888103d25418 R15: > > 888103f18120 > > [ 199.132277] FS: 7f36fdcbb6a0() GS:88815b40() > > knlGS: > > [ 199.132721] CS: 0010 DS: ES: CR0: 80050033 > > [ 199.133033] CR2: 0010 CR3: 000103d26000 CR4: > > 06f0 > > [ 199.133420] DR0: DR1: DR2: > > > > [ 199.133807] DR3: DR6: fffe0ff0 DR7: > > 0400 > > [ 199.134195] Call Trace: > > [ 199.134333] drm_fbdev_cleanup+0x179/0x1a0 > > [ 199.134562] drm_fbdev_client_unregister+0x2b/0x40 > > [ 199.134828] drm_client_dev_unregister+0xa8/0x180 > > [ 199.135088] drm_dev_unregister+0x61/0x110 > > [ 199.135315] mgag200_pci_remove+0x38/0x52 [mgag200] > > [ 199.135586] pci_device_remove+0x62/0xe0 > > [ 199.135806] device_release_driver_internal+0x148/0x270 > > [ 199.136094] driver_detach+0x76/0xe0 > > [ 199.136294] bus_remove_driver+0x7e/0x100 > > [ 199.136521] pci_unregister_driver+0x28/0xf0 > > [ 199.136759] __x64_sys_delete_module+0x268/0x300 > > [ 199.137016] ? __ia32_sys_delete_module+0x300/0x300 > > [ 199.137285] ? call_rcu+0x3e4/0x580 > > [ 199.137481] ? fpregs_assert_state_consistent+0x4d/0x60 > > [ 199.137767] ? exit_to_user_mode_prepare+0x2f/0x130 > > [ 199.138037] do_syscall_64+0x33/0x40 > > [ 199.138237] entry_SYSCALL_64_after_hwframe+0x44/0xae > > [ 199.138517] RIP: 0033:0x7f36fdc3dcf7 > > > > Signed-off-by: Tong Zhang > > --- > > drivers/gpu/drm/drm_fb_helper.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c > > b/drivers/gpu/drm/drm_fb_helper.c > > index b9a616737c0e..f6baa2046124 100644 > > --- a/drivers/gpu/drm/drm_fb_helper.c > > +++ b/drivers/gpu/drm/drm_fb_helper.c > > @@ -2048,7 +2048,7 @@ static void drm_fbdev_cleanup(struct drm_fb_helper > > *fb_helper) > > > > if (shadow) > > vfree(shadow); > > - else > > + else if (fb_helper->buffer) > > drm_client_buffer_vunmap(fb_helper->buffer); > > > > drm_client_framebuffer_delete(fb_helper->buffer); > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos/decon5433: Clean up GPIO includes
remove the legacy GPIO headers but what it really uses is since only gpio_desc structs are ever referenced. Signed-off-by: Tian Tao --- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c index 1f79bc2..9fc51a6 100644 --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c @@ -11,9 +11,9 @@ #include #include #include +#include #include #include -#include #include #include #include -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v2 2/2] dma-buf: heaps: Fix the name used when exporting dmabufs to be the actual heap name
By default dma_buf_export() sets the exporter name to be KBUILD_MODNAME. Unfortunately this may not be identical to the string used as the heap name (ie: "system" vs "system_heap"). This can cause some minor confusion with tooling, and there is the future potential where multiple heap types may be exported by the same module (but would all have the same name). So to avoid all this, set the exporter exp_name to the heap name. Cc: Daniel Vetter Cc: Sumit Semwal Cc: Liam Mark Cc: Chris Goldsworthy Cc: Laura Abbott Cc: Brian Starkey Cc: Hridya Valsaraju Cc: Suren Baghdasaryan Cc: Sandeep Patil Cc: Daniel Mentz Cc: Ørjan Eide Cc: Robin Murphy Cc: Ezequiel Garcia Cc: Simon Ser Cc: James Jones Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: John Stultz --- drivers/dma-buf/heaps/cma_heap.c| 1 + drivers/dma-buf/heaps/system_heap.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index 5d64eccd21d6..0c05b79870f9 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -339,6 +339,7 @@ static struct dma_buf *cma_heap_allocate(struct dma_heap *heap, buffer->pagecount = pagecount; /* create the dmabuf */ + exp_info.exp_name = dma_heap_get_name(heap); exp_info.ops = _heap_buf_ops; exp_info.size = buffer->len; exp_info.flags = fd_flags; diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 29e49ac17251..23a7e74ef966 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -390,6 +390,7 @@ static struct dma_buf *system_heap_allocate(struct dma_heap *heap, } /* create the dmabuf */ + exp_info.exp_name = dma_heap_get_name(heap); exp_info.ops = _heap_buf_ops; exp_info.size = buffer->len; exp_info.flags = fd_flags; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND][PATCH v2 1/2] dma-buf: dma-heap: Provide accessor to get heap name
It can be useful to access the name for the heap,
so provide an accessor to do so.
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Make sure to use "const char *" as Reported-by: kernel test robot
---
drivers/dma-buf/dma-heap.c | 12
include/linux/dma-heap.h | 9 +
2 files changed, 21 insertions(+)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 6b5db954569f..56bf5ad01ad5 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -202,6 +202,18 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
return heap->priv;
}
+/**
+ * dma_heap_get_name() - get heap name
+ * @heap: DMA-Heap to retrieve private data for
+ *
+ * Returns:
+ * The char* for the heap name.
+ */
+const char *dma_heap_get_name(struct dma_heap *heap)
+{
+ return heap->name;
+}
+
struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
{
struct dma_heap *heap, *h, *err_ret;
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 5bc5c946af58..0c05561cad6e 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -50,6 +50,15 @@ struct dma_heap_export_info {
*/
void *dma_heap_get_drvdata(struct dma_heap *heap);
+/**
+ * dma_heap_get_name() - get heap name
+ * @heap: DMA-Heap to retrieve private data for
+ *
+ * Returns:
+ * The char* for the heap name.
+ */
+const char *dma_heap_get_name(struct dma_heap *heap);
+
/**
* dma_heap_add - adds a heap to dmabuf heaps
* @exp_info: information needed to register this heap
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: heaps: Set VM_PFNMAP in mmap for system and cma heaps
On Sat, Feb 27, 2021 at 1:44 AM Christoph Hellwig wrote: > > On Fri, Feb 26, 2021 at 08:36:55AM +0100, Daniel Vetter wrote: > > Also given that both deal with struct page there's a ton of divergence > > between these two that doesn't make much sense. Maybe could even share > > the code fully, aside from how you allocate the struct pages. > > I've been saying that since the code was first submitted. Once pages > are allocated from CMA they should be treated not different from normal > pages. > > Please take a look at how the DMA contigous allocator manages to share > all code for handling CMA vs alloc_pages pages. I'll take a look at that! Thanks for the pointer! -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: ioremap buffer according to TTM mem caching setting
Hi Oak,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip linus/master v5.12-rc1
next-20210301]
[cannot apply to tegra-drm/drm/tegra/for-next drm-exynos/exynos-drm-next
drm/drm-next]
[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/Oak-Zeng/drm-ttm-ioremap-buffer-according-to-TTM-mem-caching-setting/20210302-064500
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: parisc-randconfig-r012-20210302 (attached as .config)
compiler: hppa-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
#
https://github.com/0day-ci/linux/commit/225bb3711439ec559dd72ae5af8e62d34ea60a64
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Oak-Zeng/drm-ttm-ioremap-buffer-according-to-TTM-mem-caching-setting/20210302-064500
git checkout 225bb3711439ec559dd72ae5af8e62d34ea60a64
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=parisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_resource_ioremap':
drivers/gpu/drm/ttm/ttm_bo_util.c:95:11: error: implicit declaration of
function 'ioremap_cache'; did you mean 'ioremap_uc'?
[-Werror=implicit-function-declaration]
95 |addr = ioremap_cache(mem->bus.offset, bus_size);
| ^
| ioremap_uc
>> drivers/gpu/drm/ttm/ttm_bo_util.c:95:9: warning: assignment to 'void *' from
>> 'int' makes pointer from integer without a cast [-Wint-conversion]
95 |addr = ioremap_cache(mem->bus.offset, bus_size);
| ^
drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_ioremap':
drivers/gpu/drm/ttm/ttm_bo_util.c:379:17: warning: assignment to 'void *'
from 'int' makes pointer from integer without a cast [-Wint-conversion]
379 |map->virtual = ioremap_cache(bo->mem.bus.offset + offset,
| ^
drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_vmap':
drivers/gpu/drm/ttm/ttm_bo_util.c:500:16: warning: assignment to 'void *'
from 'int' makes pointer from integer without a cast [-Wint-conversion]
500 |vaddr_iomem = ioremap_cache(mem->bus.offset,
|^
cc1: some warnings being treated as errors
vim +95 drivers/gpu/drm/ttm/ttm_bo_util.c
74
75 static int ttm_resource_ioremap(struct ttm_bo_device *bdev,
76 struct ttm_resource *mem,
77 void **virtual)
78 {
79 int ret;
80 void *addr;
81
82 *virtual = NULL;
83 ret = ttm_mem_io_reserve(bdev, mem);
84 if (ret || !mem->bus.is_iomem)
85 return ret;
86
87 if (mem->bus.addr) {
88 addr = mem->bus.addr;
89 } else {
90 size_t bus_size = (size_t)mem->num_pages << PAGE_SHIFT;
91
92 if (mem->bus.caching == ttm_write_combined)
93 addr = ioremap_wc(mem->bus.offset, bus_size);
94 else if (mem->bus.caching == ttm_cached)
> 95 addr = ioremap_cache(mem->bus.offset, bus_size);
96 else
97 addr = ioremap(mem->bus.offset, bus_size);
98 if (!addr) {
99 ttm_mem_io_free(bdev, mem);
100 return -ENOMEM;
101 }
102 }
103 *virtual = addr;
104 return 0;
105 }
106
---
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 v4 05/14] drm/bridge: imx: Add i.MX8qm/qxp pixel combiner support
On Mon, 2021-03-01 at 11:56 +0100, Robert Foss wrote: > On Mon, 1 Mar 2021 at 10:07, Liu Ying wrote: > > Hi Robert, > > > > On Fri, 2021-02-26 at 14:07 +0100, Robert Foss wrote: > > > Hey Liu, > > > > > > With the below nit straightened out, feel free to add my r-b. > > > > > > Reviewed-by: Robert Foss > > > > Thanks for reviewing this patch. > > > > > On Thu, 18 Feb 2021 at 04:58, Liu Ying wrote: > > > > This patch adds a drm bridge driver for i.MX8qm/qxp pixel combiner. > > > > The pixel combiner takes two output streams from a single display > > > > controller and manipulates the two streams to support a number > > > > of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured > > > > as either one screen, two screens, or virtual screens. The pixel > > > > combiner is also responsible for generating some of the control signals > > > > for the pixel link output channel. For now, the driver only supports > > > > the bypass mode. > > > > > > > > Signed-off-by: Liu Ying > > > > --- > > > > v3->v4: > > > > * No change. > > > > > > > > v2->v3: > > > > * No change. > > > > > > > > v1->v2: > > > > * No change. > > > > > > > > drivers/gpu/drm/bridge/Kconfig | 2 + > > > > drivers/gpu/drm/bridge/Makefile| 1 + > > > > drivers/gpu/drm/bridge/imx/Kconfig | 8 + > > > > drivers/gpu/drm/bridge/imx/Makefile| 1 + > > > > .../gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c| 452 > > > > + > > > > 5 files changed, 464 insertions(+) > > > > create mode 100644 drivers/gpu/drm/bridge/imx/Kconfig > > > > create mode 100644 drivers/gpu/drm/bridge/imx/Makefile > > > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c > > > > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig > > > > b/drivers/gpu/drm/bridge/Kconfig > > > > index e4110d6c..84944e0 100644 > > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > > @@ -256,6 +256,8 @@ source "drivers/gpu/drm/bridge/adv7511/Kconfig" > > > > > > > > source "drivers/gpu/drm/bridge/cadence/Kconfig" > > > > > > > > +source "drivers/gpu/drm/bridge/imx/Kconfig" > > > > + > > > > source "drivers/gpu/drm/bridge/synopsys/Kconfig" > > > > > > > > endmenu > > > > diff --git a/drivers/gpu/drm/bridge/Makefile > > > > b/drivers/gpu/drm/bridge/Makefile > > > > index 86e7acc..bc80cae 100644 > > > > --- a/drivers/gpu/drm/bridge/Makefile > > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > > @@ -27,4 +27,5 @@ obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o > > > > > > > > obj-y += analogix/ > > > > obj-y += cadence/ > > > > +obj-y += imx/ > > > > obj-y += synopsys/ > > > > diff --git a/drivers/gpu/drm/bridge/imx/Kconfig > > > > b/drivers/gpu/drm/bridge/imx/Kconfig > > > > new file mode 100644 > > > > index ..f1c91b6 > > > > --- /dev/null > > > > +++ b/drivers/gpu/drm/bridge/imx/Kconfig > > > > @@ -0,0 +1,8 @@ > > > > +config DRM_IMX8QXP_PIXEL_COMBINER > > > > + tristate "Freescale i.MX8QM/QXP pixel combiner" > > > > + depends on OF > > > > + depends on COMMON_CLK > > > > + select DRM_KMS_HELPER > > > > + help > > > > + Choose this to enable pixel combiner found in > > > > + Freescale i.MX8qm/qxp processors. > > > > diff --git a/drivers/gpu/drm/bridge/imx/Makefile > > > > b/drivers/gpu/drm/bridge/imx/Makefile > > > > new file mode 100644 > > > > index ..7d7c8d6 > > > > --- /dev/null > > > > +++ b/drivers/gpu/drm/bridge/imx/Makefile > > > > @@ -0,0 +1 @@ > > > > +obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o > > > > diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c > > > > b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c > > > > new file mode 100644 > > > > index ..cd5b1be > > > > --- /dev/null > > > > +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c > > > > @@ -0,0 +1,452 @@ > > > > +// SPDX-License-Identifier: GPL-2.0+ > > > > + > > > > +/* > > > > + * Copyright 2020 NXP > > > > + */ > > > > + > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > + > > > > +#include > > > > +#include > > > > +#include > > > > + > > > > +#define PC_CTRL_REG0x0 > > > > +#define PC_COMBINE_ENABLE BIT(0) > > > > +#define PC_DISP_BYPASS(n) BIT(1 + 21 * (n)) > > > > +#define PC_DISP_HSYNC_POLARITY(n) BIT(2 + 11 * (n)) > > > > +#define PC_DISP_HSYNC_POLARITY_POS(n) DISP_HSYNC_POLARITY(n) > > > > +#define PC_DISP_VSYNC_POLARITY(n) BIT(3 + 11 * (n)) > > > > +#define PC_DISP_VSYNC_POLARITY_POS(n) DISP_VSYNC_POLARITY(n) > > > > +#define PC_DISP_DVALID_POLARITY(n)BIT(4 + 11 * (n)) > > > > +#define PC_DISP_DVALID_POLARITY_POS(n)DISP_DVALID_POLARITY(n) > > > > +#define PC_VSYNC_MASK_ENABLE BIT(5) > > > > +#define
Re: [PATCH v3 1/8] mm: Remove special swap entry functions
On Tuesday, 2 March 2021 4:46:42 AM AEDT Jason Gunthorpe wrote:
>
> I wish you could come up with a more descriptive word that special
> here
>
> What I understand is this is true when the swap_offset is a pfn?
Correct, and that points to a better name. Maybe is_pfn_swap_entry()? In which
case adding a helper as Christoph suggested makes some more sense. Eg:
pfn_swap_entry_to_page()
> > -static inline struct page *migration_entry_to_page(swp_entry_t entry)
> > -{
> > - struct page *p = pfn_to_page(swp_offset(entry));
> > - /*
> > -* Any use of migration entries may only occur while the
> > -* corresponding page is locked
> > -*/
> > - BUG_ON(!PageLocked(compound_head(p)));
> > - return p;
>
> And this constraint has been completely lost?
Yes, sorry I should have called that out. I didn't think loosing the check was
a big deal, but I can add some checks to some of the call sites which would
catch a page being incorrectly unlocked.
> A comment in front of the is_special_entry explaining all the rule
> would help alot
Will add one.
> Transformation looks fine otherwise
Thanks.
- Alistair
> Jason
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/8] mm: Device exclusive memory access
On Fri, Feb 26, 2021 at 06:18:29PM +1100, Alistair Popple wrote:
> +/**
> + * make_device_exclusive_range() - Mark a range for exclusive use by a device
> + * @mm: mm_struct of assoicated target process
> + * @start: start of the region to mark for exclusive device access
> + * @end: end address of region
> + * @pages: returns the pages which were successfully mark for exclusive acces
> + *
> + * Returns: number of pages successfully marked for exclusive access
> + *
> + * This function finds the ptes mapping page(s) to the given address range
> and
> + * replaces them with special swap entries preventing userspace CPU access.
> On
> + * fault these entries are replaced with the original mapping after calling
> MMU
> + * notifiers.
> + */
> +int make_device_exclusive_range(struct mm_struct *mm, unsigned long start,
> + unsigned long end, struct page **pages)
> +{
> + long npages = (end - start) >> PAGE_SHIFT;
> + long i;
> +
> + npages = get_user_pages_remote(mm, start, npages,
> +FOLL_GET | FOLL_WRITE | FOLL_SPLIT_PMD,
> +pages, NULL, NULL);
> + for (i = 0; i < npages; i++) {
> + if (!trylock_page(pages[i])) {
> + put_page(pages[i]);
> + pages[i] = NULL;
> + continue;
> + }
> +
> + if (!try_to_protect(pages[i])) {
Isn't this racy? get_user_pages returns the ptes at an instant in
time, they could have already been changed to something else?
I would think you'd want to switch to the swap entry atomically under
th PTLs?
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 23/24] drm/msm/dsi: drop global msm_dsi_phy_type enumaration
With the current upstream driver the msm_dsi_phy_type enum does not make
much sense: all DSI PHYs are probed using the dt bindings, the phy type
is not passed between drivers. Use quirks in phy individual PHY drivers
to differentiate minor harware differences and drop the enum.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.h | 12
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 4
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 11 ++-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 2 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c | 1 -
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 15 ---
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c| 1 -
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 18 ++
8 files changed, 24 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 351bfbeb53bd..5c32ee2b3605 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -23,18 +23,6 @@
struct msm_dsi_phy_shared_timings;
struct msm_dsi_phy_clk_request;
-enum msm_dsi_phy_type {
- MSM_DSI_PHY_28NM_HPM,
- MSM_DSI_PHY_28NM_LP,
- MSM_DSI_PHY_20NM,
- MSM_DSI_PHY_28NM_8960,
- MSM_DSI_PHY_14NM,
- MSM_DSI_PHY_10NM,
- MSM_DSI_PHY_7NM,
- MSM_DSI_PHY_7NM_V4_1,
- MSM_DSI_PHY_MAX
-};
-
enum msm_dsi_phy_usecase {
MSM_DSI_PHY_STANDALONE,
MSM_DSI_PHY_MASTER,
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 0aa2729ed4b5..8e828c5ca8f4 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -17,9 +17,6 @@
#define dsi_phy_write_udelay(offset, data, delay_us) { msm_writel((data),
(offset)); udelay(delay_us); }
#define dsi_phy_write_ndelay(offset, data, delay_ns) { msm_writel((data),
(offset)); ndelay(delay_ns); }
-/* v3.0.0 10nm implementation that requires the old timings settings */
-#define V3_0_0_10NM_OLD_TIMINGS_QUIRK BIT(0)
-
struct msm_dsi_phy_ops {
int (*pll_init)(struct msm_dsi_phy *phy);
int (*enable)(struct msm_dsi_phy *phy, int src_pll_id,
@@ -30,7 +27,6 @@ struct msm_dsi_phy_ops {
};
struct msm_dsi_phy_cfg {
- enum msm_dsi_phy_type type;
struct dsi_reg_config reg_cfg;
struct msm_dsi_phy_ops ops;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index 5456ba67245c..6bb6507d6a2f 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -38,6 +38,9 @@
#define VCO_REF_CLK_RATE 1920
#define FRAC_BITS 18
+/* v3.0.0 10nm implementation that requires the old timings settings */
+#define DSI_PHY_10NM_QUIRK_OLD_TIMINGS BIT(0)
+
struct dsi_pll_config {
bool enable_ssc;
bool ssc_center;
@@ -741,7 +744,7 @@ static void dsi_phy_hw_v3_0_lane_settings(struct
msm_dsi_phy *phy)
u8 tx_dctrl[] = { 0x00, 0x00, 0x00, 0x04, 0x01 };
void __iomem *lane_base = phy->lane_base;
- if (phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK)
+ if (phy->cfg->quirks & DSI_PHY_10NM_QUIRK_OLD_TIMINGS)
tx_dctrl[3] = 0x02;
/* Strength ctrl settings */
@@ -776,7 +779,7 @@ static void dsi_phy_hw_v3_0_lane_settings(struct
msm_dsi_phy *phy)
tx_dctrl[i]);
}
- if (!(phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK)) {
+ if (!(phy->cfg->quirks & DSI_PHY_10NM_QUIRK_OLD_TIMINGS)) {
/* Toggle BIT 0 to release freeze I/0 */
dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3),
0x05);
dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(3),
0x04);
@@ -916,7 +919,6 @@ static void dsi_10nm_phy_disable(struct msm_dsi_phy *phy)
}
const struct msm_dsi_phy_cfg dsi_phy_10nm_cfgs = {
- .type = MSM_DSI_PHY_10NM,
.src_pll_truthtable = { {false, false}, {true, false} },
.has_phy_lane = true,
.reg_cfg = {
@@ -939,7 +941,6 @@ const struct msm_dsi_phy_cfg dsi_phy_10nm_cfgs = {
};
const struct msm_dsi_phy_cfg dsi_phy_10nm_8998_cfgs = {
- .type = MSM_DSI_PHY_10NM,
.src_pll_truthtable = { {false, false}, {true, false} },
.has_phy_lane = true,
.reg_cfg = {
@@ -959,5 +960,5 @@ const struct msm_dsi_phy_cfg dsi_phy_10nm_8998_cfgs = {
.max_pll_rate = 35UL,
.io_start = { 0xc994400, 0xc996400 },
.num_dsi_phy = 2,
- .quirks = V3_0_0_10NM_OLD_TIMINGS_QUIRK,
+ .quirks = DSI_PHY_10NM_QUIRK_OLD_TIMINGS,
};
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
index 88800d68b1bb..b4257434e4ee 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
@@ -1022,7 +1022,6 @@ static void
[RFC 22/24] drm/msm/dsi: remove temp data from global pll structure
The 7nm, 10nm and 14nm drivers would store interim data used during
VCO/PLL rate setting in the global dsi_pll_Nnm structure. Move this data
structures to the onstack storage. While we are at it, drop
unused/static 'config' data, unused config fields, etc.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 167 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 342 +++--
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 161 --
3 files changed, 221 insertions(+), 449 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index e5ea16e4459f..5456ba67245c 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -36,40 +36,22 @@
*/
#define VCO_REF_CLK_RATE 1920
-
-struct dsi_pll_regs {
- u32 pll_prop_gain_rate;
- u32 pll_lockdet_rate;
- u32 decimal_div_start;
- u32 frac_div_start_low;
- u32 frac_div_start_mid;
- u32 frac_div_start_high;
- u32 pll_clock_inverters;
- u32 ssc_stepsize_low;
- u32 ssc_stepsize_high;
- u32 ssc_div_per_low;
- u32 ssc_div_per_high;
- u32 ssc_adjper_low;
- u32 ssc_adjper_high;
- u32 ssc_control;
-};
+#define FRAC_BITS 18
struct dsi_pll_config {
- u32 ref_freq;
- bool div_override;
- u32 output_div;
- bool ignore_frac;
- bool disable_prescaler;
bool enable_ssc;
bool ssc_center;
- u32 dec_bits;
- u32 frac_bits;
- u32 lock_timer;
u32 ssc_freq;
u32 ssc_offset;
u32 ssc_adj_per;
- u32 thresh_cycles;
- u32 refclk_cycles;
+
+ /* out */
+ u32 pll_prop_gain_rate;
+ u32 decimal_div_start;
+ u32 frac_div_start;
+ u32 pll_clock_inverters;
+ u32 ssc_stepsize;
+ u32 ssc_div_per;
};
struct pll_10nm_cached_state {
@@ -85,15 +67,11 @@ struct dsi_pll_10nm {
struct msm_dsi_phy *phy;
- u64 vco_ref_clk_rate;
u64 vco_current_rate;
/* protects REG_DSI_10nm_PHY_CMN_CLK_CFG0 register */
spinlock_t postdiv_lock;
- struct dsi_pll_config pll_configuration;
- struct dsi_pll_regs reg_setup;
-
struct pll_10nm_cached_state cached_state;
struct dsi_pll_10nm *slave;
@@ -107,34 +85,19 @@ struct dsi_pll_10nm {
*/
static struct dsi_pll_10nm *pll_10nm_list[DSI_MAX];
-static void dsi_pll_setup_config(struct dsi_pll_10nm *pll)
+static void dsi_pll_setup_config(struct dsi_pll_config *config)
{
- struct dsi_pll_config *config = >pll_configuration;
-
- config->ref_freq = pll->vco_ref_clk_rate;
- config->output_div = 1;
- config->dec_bits = 8;
- config->frac_bits = 18;
- config->lock_timer = 64;
config->ssc_freq = 31500;
config->ssc_offset = 5000;
config->ssc_adj_per = 2;
- config->thresh_cycles = 32;
- config->refclk_cycles = 256;
-
- config->div_override = false;
- config->ignore_frac = false;
- config->disable_prescaler = false;
config->enable_ssc = false;
- config->ssc_center = 0;
+ config->ssc_center = false;
}
-static void dsi_pll_calc_dec_frac(struct dsi_pll_10nm *pll)
+static void dsi_pll_calc_dec_frac(struct dsi_pll_10nm *pll, struct
dsi_pll_config *config)
{
- struct dsi_pll_config *config = >pll_configuration;
- struct dsi_pll_regs *regs = >reg_setup;
- u64 fref = pll->vco_ref_clk_rate;
+ u64 fref = VCO_REF_CLK_RATE;
u64 pll_freq;
u64 divider;
u64 dec, dec_multiple;
@@ -143,40 +106,32 @@ static void dsi_pll_calc_dec_frac(struct dsi_pll_10nm
*pll)
pll_freq = pll->vco_current_rate;
- if (config->disable_prescaler)
- divider = fref;
- else
- divider = fref * 2;
+ divider = fref * 2;
- multiplier = 1 << config->frac_bits;
+ multiplier = 1 << FRAC_BITS;
dec_multiple = div_u64(pll_freq * multiplier, divider);
dec = div_u64_rem(dec_multiple, multiplier, );
if (pll_freq <= 19UL)
- regs->pll_prop_gain_rate = 8;
+ config->pll_prop_gain_rate = 8;
else if (pll_freq <= 30UL)
- regs->pll_prop_gain_rate = 10;
+ config->pll_prop_gain_rate = 10;
else
- regs->pll_prop_gain_rate = 12;
+ config->pll_prop_gain_rate = 12;
if (pll_freq < 11UL)
- regs->pll_clock_inverters = 8;
+ config->pll_clock_inverters = 8;
else
- regs->pll_clock_inverters = 0;
+ config->pll_clock_inverters = 0;
- regs->pll_lockdet_rate = config->lock_timer;
- regs->decimal_div_start = dec;
- regs->frac_div_start_low = (frac & 0xff);
- regs->frac_div_start_mid = (frac & 0xff00) >> 8;
-
[RFC 24/24] arm64: dts: qcom: sdm845: assign DSI clock source parents
Assign DSI clock source parents to DSI PHY clocks.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 454f794af547..2166549382c1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -4113,6 +4113,9 @@ dsi0: dsi@ae94000 {
"core",
"iface",
"bus";
+ assigned-clocks = <
DISP_CC_MDSS_BYTE0_CLK_SRC>, < DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <_phy 0>,
<_phy 1>;
+
operating-points-v2 = <_opp_table>;
power-domains = < SDM845_CX>;
@@ -4179,6 +4182,9 @@ dsi1: dsi@ae96000 {
"core",
"iface",
"bus";
+ assigned-clocks = <
DISP_CC_MDSS_BYTE1_CLK_SRC>, < DISP_CC_MDSS_PCLK1_CLK_SRC>;
+ assigned-clock-parents = <_phy 0>,
<_phy 1>;
+
operating-points-v2 = <_opp_table>;
power-domains = < SDM845_CX>;
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 21/24] drm/msm/dsi: remove duplicate fields from dsi_pll_Nnm instances
Drop duplicate fields pdev and id from dsi_pll_Nnm instances. Reuse
those fields from the provided msm_dsi_phy.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 72 +--
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 54 +++---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 51 ++---
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 26 +++
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 68 --
5 files changed, 119 insertions(+), 152 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index 65e6ca2038c8..e5ea16e4459f 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -83,9 +83,6 @@ struct pll_10nm_cached_state {
struct dsi_pll_10nm {
struct clk_hw clk_hw;
- int id;
- struct platform_device *pdev;
-
struct msm_dsi_phy *phy;
u64 vco_ref_clk_rate;
@@ -298,7 +295,7 @@ static int dsi_pll_10nm_vco_set_rate(struct clk_hw *hw,
unsigned long rate,
{
struct dsi_pll_10nm *pll_10nm = to_pll_10nm(hw);
- DBG("DSI PLL%d rate=%lu, parent's=%lu", pll_10nm->id, rate,
+ DBG("DSI PLL%d rate=%lu, parent's=%lu", pll_10nm->phy->id, rate,
parent_rate);
pll_10nm->vco_current_rate = rate;
@@ -324,7 +321,7 @@ static int dsi_pll_10nm_vco_set_rate(struct clk_hw *hw,
unsigned long rate,
static int dsi_pll_10nm_lock_status(struct dsi_pll_10nm *pll)
{
- struct device *dev = >pdev->dev;
+ struct device *dev = >phy->pdev->dev;
int rc;
u32 status = 0;
u32 const delay_us = 100;
@@ -338,7 +335,7 @@ static int dsi_pll_10nm_lock_status(struct dsi_pll_10nm
*pll)
timeout_us);
if (rc)
DRM_DEV_ERROR(dev, "DSI PLL(%d) lock failed, status=0x%08x\n",
- pll->id, status);
+ pll->phy->id, status);
return rc;
}
@@ -384,7 +381,7 @@ static void dsi_pll_enable_global_clk(struct dsi_pll_10nm
*pll)
static int dsi_pll_10nm_vco_prepare(struct clk_hw *hw)
{
struct dsi_pll_10nm *pll_10nm = to_pll_10nm(hw);
- struct device *dev = _10nm->pdev->dev;
+ struct device *dev = _10nm->phy->pdev->dev;
int rc;
dsi_pll_enable_pll_bias(pll_10nm);
@@ -410,7 +407,7 @@ static int dsi_pll_10nm_vco_prepare(struct clk_hw *hw)
/* Check for PLL lock */
rc = dsi_pll_10nm_lock_status(pll_10nm);
if (rc) {
- DRM_DEV_ERROR(dev, "PLL(%d) lock failed\n", pll_10nm->id);
+ DRM_DEV_ERROR(dev, "PLL(%d) lock failed\n", pll_10nm->phy->id);
goto error;
}
@@ -491,7 +488,7 @@ static unsigned long dsi_pll_10nm_vco_recalc_rate(struct
clk_hw *hw,
vco_rate = pll_freq;
DBG("DSI PLL%d returning vco rate = %lu, dec = %x, frac = %x",
- pll_10nm->id, (unsigned long)vco_rate, dec, frac);
+ pll_10nm->phy->id, (unsigned long)vco_rate, dec, frac);
return (unsigned long)vco_rate;
}
@@ -540,7 +537,7 @@ static void dsi_10nm_save_state(struct msm_dsi_phy *phy)
cached->pll_mux = cmn_clk_cfg1 & 0x3;
DBG("DSI PLL%d outdiv %x bit_clk_div %x pix_clk_div %x pll_mux %x",
- pll_10nm->id, cached->pll_out_div, cached->bit_clk_div,
+ pll_10nm->phy->id, cached->pll_out_div, cached->bit_clk_div,
cached->pix_clk_div, cached->pll_mux);
}
@@ -567,12 +564,12 @@ static int dsi_10nm_restore_state(struct msm_dsi_phy *phy)
ret = dsi_pll_10nm_vco_set_rate(phy->vco_hw,
pll_10nm->vco_current_rate, pll_10nm->vco_ref_clk_rate);
if (ret) {
- DRM_DEV_ERROR(_10nm->pdev->dev,
+ DRM_DEV_ERROR(_10nm->phy->pdev->dev,
"restore vco rate failed. ret=%d\n", ret);
return ret;
}
- DBG("DSI PLL%d", pll_10nm->id);
+ DBG("DSI PLL%d", pll_10nm->phy->id);
return 0;
}
@@ -583,13 +580,13 @@ static int dsi_10nm_set_usecase(struct msm_dsi_phy *phy)
void __iomem *base = pll_10nm->phy->base;
u32 data = 0x0; /* internal PLL */
- DBG("DSI PLL%d", pll_10nm->id);
+ DBG("DSI PLL%d", pll_10nm->phy->id);
switch (phy->usecase) {
case MSM_DSI_PHY_STANDALONE:
break;
case MSM_DSI_PHY_MASTER:
- pll_10nm->slave = pll_10nm_list[(pll_10nm->id + 1) % DSI_MAX];
+ pll_10nm->slave = pll_10nm_list[(pll_10nm->phy->id + 1) %
DSI_MAX];
break;
case MSM_DSI_PHY_SLAVE:
data = 0x1; /* external PLL */
@@ -621,21 +618,21 @@ static int pll_10nm_register(struct dsi_pll_10nm
*pll_10nm, struct clk_hw_onecel
.flags = CLK_IGNORE_UNUSED,
.ops = _ops_dsi_pll_10nm_vco,
};
- struct device *dev = _10nm->pdev->dev;
+
[RFC 20/24] drm/msm/dsi: move ioremaps to dsi_phy_driver_probe
All PHY drivers would map dsi_pll area. Some PHY drivers would also
map dsi_phy area again (a leftover from old PHY/PLL separation). Move
all ioremaps to the common dsi_phy driver code and drop individual
ioremapped areas from PHY drivers.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 7 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 75 +++---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 49
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 40 +++---
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 27 +++
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 79 ---
7 files changed, 108 insertions(+), 170 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 2ef9abaf052d..5b1cba4ba672 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -682,6 +682,13 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
goto fail;
}
+ phy->pll_base = msm_ioremap(pdev, "dsi_pll", "DSI_PLL");
+ if (IS_ERR(phy->pll_base)) {
+ DRM_DEV_ERROR(>dev, "%s: failed to map pll base\n",
__func__);
+ ret = -ENOMEM;
+ goto fail;
+ }
+
if (phy->cfg->has_phy_lane) {
phy->lane_base = msm_ioremap(pdev, "dsi_phy_lane",
"DSI_PHY_LANE");
if (IS_ERR(phy->lane_base)) {
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 43c4b43cb41f..0aa2729ed4b5 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -92,6 +92,7 @@ struct msm_dsi_dphy_timing {
struct msm_dsi_phy {
struct platform_device *pdev;
void __iomem *base;
+ void __iomem *pll_base;
void __iomem *reg_base;
void __iomem *lane_base;
int id;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index 6eb18a159bf5..65e6ca2038c8 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -88,9 +88,6 @@ struct dsi_pll_10nm {
struct msm_dsi_phy *phy;
- void __iomem *phy_cmn_mmio;
- void __iomem *mmio;
-
u64 vco_ref_clk_rate;
u64 vco_current_rate;
@@ -225,7 +222,7 @@ static void dsi_pll_calc_ssc(struct dsi_pll_10nm *pll)
static void dsi_pll_ssc_commit(struct dsi_pll_10nm *pll)
{
- void __iomem *base = pll->mmio;
+ void __iomem *base = pll->phy->pll_base;
struct dsi_pll_regs *regs = >reg_setup;
if (pll->pll_configuration.enable_ssc) {
@@ -250,7 +247,7 @@ static void dsi_pll_ssc_commit(struct dsi_pll_10nm *pll)
static void dsi_pll_config_hzindep_reg(struct dsi_pll_10nm *pll)
{
- void __iomem *base = pll->mmio;
+ void __iomem *base = pll->phy->pll_base;
dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_ANALOG_CONTROLS_ONE, 0x80);
dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_ANALOG_CONTROLS_TWO, 0x03);
@@ -276,7 +273,7 @@ static void dsi_pll_config_hzindep_reg(struct dsi_pll_10nm
*pll)
static void dsi_pll_commit(struct dsi_pll_10nm *pll)
{
- void __iomem *base = pll->mmio;
+ void __iomem *base = pll->phy->pll_base;
struct dsi_pll_regs *reg = >reg_setup;
dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_CORE_INPUT_OVERRIDE, 0x12);
@@ -333,7 +330,7 @@ static int dsi_pll_10nm_lock_status(struct dsi_pll_10nm
*pll)
u32 const delay_us = 100;
u32 const timeout_us = 5000;
- rc = readl_poll_timeout_atomic(pll->mmio +
+ rc = readl_poll_timeout_atomic(pll->phy->pll_base +
REG_DSI_10nm_PHY_PLL_COMMON_STATUS_ONE,
status,
((status & BIT(0)) > 0),
@@ -348,21 +345,21 @@ static int dsi_pll_10nm_lock_status(struct dsi_pll_10nm
*pll)
static void dsi_pll_disable_pll_bias(struct dsi_pll_10nm *pll)
{
- u32 data = dsi_phy_read(pll->phy_cmn_mmio +
REG_DSI_10nm_PHY_CMN_CTRL_0);
+ u32 data = dsi_phy_read(pll->phy->base + REG_DSI_10nm_PHY_CMN_CTRL_0);
- dsi_phy_write(pll->mmio + REG_DSI_10nm_PHY_PLL_SYSTEM_MUXES, 0);
- dsi_phy_write(pll->phy_cmn_mmio + REG_DSI_10nm_PHY_CMN_CTRL_0,
+ dsi_phy_write(pll->phy->pll_base + REG_DSI_10nm_PHY_PLL_SYSTEM_MUXES,
0);
+ dsi_phy_write(pll->phy->base + REG_DSI_10nm_PHY_CMN_CTRL_0,
data & ~BIT(5));
ndelay(250);
}
static void dsi_pll_enable_pll_bias(struct dsi_pll_10nm *pll)
{
- u32 data = dsi_phy_read(pll->phy_cmn_mmio +
REG_DSI_10nm_PHY_CMN_CTRL_0);
+ u32 data = dsi_phy_read(pll->phy->base + REG_DSI_10nm_PHY_CMN_CTRL_0);
- dsi_phy_write(pll->phy_cmn_mmio + REG_DSI_10nm_PHY_CMN_CTRL_0,
+
[RFC 19/24] drm/msm/dsi: drop PLL accessor functions
Replace PLL accessor functions (pll_read/pll_write*) with the DSI PHY
accessors, reducing duplication.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 24 +--
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 124
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 126
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 118 +++
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 54 +++
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 140 +-
6 files changed, 283 insertions(+), 303 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index b8e865979650..43c4b43cb41f 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -14,6 +14,8 @@
#define dsi_phy_read(offset) msm_readl((offset))
#define dsi_phy_write(offset, data) msm_writel((data), (offset))
+#define dsi_phy_write_udelay(offset, data, delay_us) { msm_writel((data),
(offset)); udelay(delay_us); }
+#define dsi_phy_write_ndelay(offset, data, delay_ns) { msm_writel((data),
(offset)); ndelay(delay_ns); }
/* v3.0.0 10nm implementation that requires the old timings settings */
#define V3_0_0_10NM_OLD_TIMINGS_QUIRK BIT(0)
@@ -124,27 +126,5 @@ int msm_dsi_dphy_timing_calc_v4(struct msm_dsi_dphy_timing
*timing,
struct msm_dsi_phy_clk_request *clk_req);
void msm_dsi_phy_set_src_pll(struct msm_dsi_phy *phy, int pll_id, u32 reg,
u32 bit_mask);
-/* PLL accessors */
-static inline void pll_write(void __iomem *reg, u32 data)
-{
- msm_writel(data, reg);
-}
-
-static inline u32 pll_read(const void __iomem *reg)
-{
- return msm_readl(reg);
-}
-
-static inline void pll_write_udelay(void __iomem *reg, u32 data, u32 delay_us)
-{
- pll_write(reg, data);
- udelay(delay_us);
-}
-
-static inline void pll_write_ndelay(void __iomem *reg, u32 data, u32 delay_ns)
-{
- pll_write((reg), data);
- ndelay(delay_ns);
-}
#endif /* __DSI_PHY_H__ */
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index 7bcef1cfd515..6eb18a159bf5 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -231,19 +231,19 @@ static void dsi_pll_ssc_commit(struct dsi_pll_10nm *pll)
if (pll->pll_configuration.enable_ssc) {
pr_debug("SSC is enabled\n");
- pll_write(base + REG_DSI_10nm_PHY_PLL_SSC_STEPSIZE_LOW_1,
+ dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_SSC_STEPSIZE_LOW_1,
regs->ssc_stepsize_low);
- pll_write(base + REG_DSI_10nm_PHY_PLL_SSC_STEPSIZE_HIGH_1,
+ dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_SSC_STEPSIZE_HIGH_1,
regs->ssc_stepsize_high);
- pll_write(base + REG_DSI_10nm_PHY_PLL_SSC_DIV_PER_LOW_1,
+ dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_SSC_DIV_PER_LOW_1,
regs->ssc_div_per_low);
- pll_write(base + REG_DSI_10nm_PHY_PLL_SSC_DIV_PER_HIGH_1,
+ dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_SSC_DIV_PER_HIGH_1,
regs->ssc_div_per_high);
- pll_write(base + REG_DSI_10nm_PHY_PLL_SSC_DIV_ADJPER_LOW_1,
+ dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_SSC_DIV_ADJPER_LOW_1,
regs->ssc_adjper_low);
- pll_write(base + REG_DSI_10nm_PHY_PLL_SSC_DIV_ADJPER_HIGH_1,
+ dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_SSC_DIV_ADJPER_HIGH_1,
regs->ssc_adjper_high);
- pll_write(base + REG_DSI_10nm_PHY_PLL_SSC_CONTROL,
+ dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_SSC_CONTROL,
SSC_EN | regs->ssc_control);
}
}
@@ -252,26 +252,26 @@ static void dsi_pll_config_hzindep_reg(struct
dsi_pll_10nm *pll)
{
void __iomem *base = pll->mmio;
- pll_write(base + REG_DSI_10nm_PHY_PLL_ANALOG_CONTROLS_ONE, 0x80);
- pll_write(base + REG_DSI_10nm_PHY_PLL_ANALOG_CONTROLS_TWO, 0x03);
- pll_write(base + REG_DSI_10nm_PHY_PLL_ANALOG_CONTROLS_THREE, 0x00);
- pll_write(base + REG_DSI_10nm_PHY_PLL_DSM_DIVIDER, 0x00);
- pll_write(base + REG_DSI_10nm_PHY_PLL_FEEDBACK_DIVIDER, 0x4e);
- pll_write(base + REG_DSI_10nm_PHY_PLL_CALIBRATION_SETTINGS, 0x40);
- pll_write(base + REG_DSI_10nm_PHY_PLL_BAND_SEL_CAL_SETTINGS_THREE,
+ dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_ANALOG_CONTROLS_ONE, 0x80);
+ dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_ANALOG_CONTROLS_TWO, 0x03);
+ dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_ANALOG_CONTROLS_THREE, 0x00);
+ dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_DSM_DIVIDER, 0x00);
+ dsi_phy_write(base + REG_DSI_10nm_PHY_PLL_FEEDBACK_DIVIDER, 0x4e);
+
[RFC 17/24] drm/msm/dsi: make save_state/restore_state callbacks accept msm_dsi_phy
Make save_state/restore callbacks accept struct msm_dsi_phy rather than
struct msm_dsi_pll. This moves them to struct msm_dsi_phy_ops, allowing
us to drop struct msm_dsi_pll_ops.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 12 +++
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 11 +++
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 22 ++---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 24 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 32 ---
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 18 +--
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 22 ++---
7 files changed, 59 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index e9424a4c636e..2ef9abaf052d 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -847,9 +847,9 @@ void msm_dsi_phy_set_usecase(struct msm_dsi_phy *phy,
void msm_dsi_phy_save_state(struct msm_dsi_phy *phy)
{
- if (phy->cfg->pll_ops.save_state) {
- phy->cfg->pll_ops.save_state(phy->pll);
- phy->pll->state_saved = true;
+ if (phy->cfg->ops.save_state) {
+ phy->cfg->ops.save_state(phy);
+ phy->state_saved = true;
}
}
@@ -857,12 +857,12 @@ int msm_dsi_phy_restore_state(struct msm_dsi_phy *phy)
{
int ret;
- if (phy->cfg->pll_ops.restore_state && phy->pll->state_saved) {
- ret = phy->cfg->pll_ops.restore_state(phy->pll);
+ if (phy->cfg->ops.restore_state && phy->state_saved) {
+ ret = phy->cfg->ops.restore_state(phy);
if (ret)
return ret;
- phy->pll->state_saved = false;
+ phy->state_saved = false;
}
return 0;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 0fff9e3afb53..179027b2c4e3 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -20,7 +20,6 @@
struct msm_dsi_pll {
struct clk_hw clk_hw;
boolpll_on;
- boolstate_saved;
const struct msm_dsi_phy_cfg *cfg;
};
@@ -32,18 +31,14 @@ struct msm_dsi_phy_ops {
int (*enable)(struct msm_dsi_phy *phy, int src_pll_id,
struct msm_dsi_phy_clk_request *clk_req);
void (*disable)(struct msm_dsi_phy *phy);
-};
-
-struct msm_dsi_pll_ops {
- void (*save_state)(struct msm_dsi_pll *pll);
- int (*restore_state)(struct msm_dsi_pll *pll);
+ void (*save_state)(struct msm_dsi_phy *phy);
+ int (*restore_state)(struct msm_dsi_phy *phy);
};
struct msm_dsi_phy_cfg {
enum msm_dsi_phy_type type;
struct dsi_reg_config reg_cfg;
struct msm_dsi_phy_ops ops;
- const struct msm_dsi_pll_ops pll_ops;
unsigned long min_pll_rate;
unsigned long max_pll_rate;
@@ -119,6 +114,8 @@ struct msm_dsi_phy {
struct msm_dsi_pll *pll;
struct clk_hw_onecell_data *provided_clocks;
+
+ bool state_saved;
};
/*
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index 7533db8955a5..1a470c7356ea 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -515,9 +515,9 @@ static const struct clk_ops clk_ops_dsi_pll_10nm_vco = {
* PLL Callbacks
*/
-static void dsi_pll_10nm_save_state(struct msm_dsi_pll *pll)
+static void dsi_10nm_save_state(struct msm_dsi_phy *phy)
{
- struct dsi_pll_10nm *pll_10nm = to_pll_10nm(pll);
+ struct dsi_pll_10nm *pll_10nm = to_pll_10nm(phy->pll);
struct pll_10nm_cached_state *cached = _10nm->cached_state;
void __iomem *phy_base = pll_10nm->phy_cmn_mmio;
u32 cmn_clk_cfg0, cmn_clk_cfg1;
@@ -538,9 +538,9 @@ static void dsi_pll_10nm_save_state(struct msm_dsi_pll *pll)
cached->pix_clk_div, cached->pll_mux);
}
-static int dsi_pll_10nm_restore_state(struct msm_dsi_pll *pll)
+static int dsi_10nm_restore_state(struct msm_dsi_phy *phy)
{
- struct dsi_pll_10nm *pll_10nm = to_pll_10nm(pll);
+ struct dsi_pll_10nm *pll_10nm = to_pll_10nm(phy->pll);
struct pll_10nm_cached_state *cached = _10nm->cached_state;
void __iomem *phy_base = pll_10nm->phy_cmn_mmio;
u32 val;
@@ -559,7 +559,7 @@ static int dsi_pll_10nm_restore_state(struct msm_dsi_pll
*pll)
val |= cached->pll_mux;
pll_write(phy_base + REG_DSI_10nm_PHY_CMN_CLK_CFG1, val);
- ret = dsi_pll_10nm_vco_set_rate(>clk_hw,
pll_10nm->vco_current_rate, pll_10nm->vco_ref_clk_rate);
+ ret = dsi_pll_10nm_vco_set_rate(>pll->clk_hw,
pll_10nm->vco_current_rate, pll_10nm->vco_ref_clk_rate);
if (ret) {
DRM_DEV_ERROR(_10nm->pdev->dev,
[RFC 18/24] drm/msm/dsi: drop msm_dsi_pll abstracton
Drop the struct msm_dsi_pll abstraction, by including vco's clk_hw
directly into struct msm_dsi_phy.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig | 8 --
drivers/gpu/drm/msm/Makefile | 2 -
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 36 +---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 66 +++---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 71 ---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 89 ++-
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 65 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 74 +++
drivers/gpu/drm/msm/dsi/phy/dsi_pll.c | 23 -
drivers/gpu/drm/msm/dsi/phy/dsi_pll.h | 44 -
10 files changed, 220 insertions(+), 258 deletions(-)
delete mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_pll.c
delete mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_pll.h
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index dabb4a1ccdcf..1f0b3f0e7149 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -76,14 +76,6 @@ config DRM_MSM_DSI
Choose this option if you have a need for MIPI DSI connector
support.
-config DRM_MSM_DSI_PLL
- bool "Enable DSI PLL driver in MSM DRM"
- depends on DRM_MSM_DSI && COMMON_CLK
- default y
- help
- Choose this option to enable DSI PLL driver which provides DSI
- source clocks under common clock framework.
-
config DRM_MSM_DSI_28NM_PHY
bool "Enable DSI 28nm PHY driver in MSM DRM"
depends on DRM_MSM_DSI
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 1be6996b80b7..610d630326bb 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -136,6 +136,4 @@ msm-$(CONFIG_DRM_MSM_DSI_14NM_PHY) += dsi/phy/dsi_phy_14nm.o
msm-$(CONFIG_DRM_MSM_DSI_10NM_PHY) += dsi/phy/dsi_phy_10nm.o
msm-$(CONFIG_DRM_MSM_DSI_7NM_PHY) += dsi/phy/dsi_phy_7nm.o
-msm-$(CONFIG_DRM_MSM_DSI_PLL) += dsi/phy/dsi_pll.o
-
obj-$(CONFIG_DRM_MSM) += msm.o
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 179027b2c4e3..b8e865979650 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -7,6 +7,7 @@
#define __DSI_PHY_H__
#include
+#include
#include
#include "dsi.h"
@@ -17,15 +18,6 @@
/* v3.0.0 10nm implementation that requires the old timings settings */
#define V3_0_0_10NM_OLD_TIMINGS_QUIRK BIT(0)
-struct msm_dsi_pll {
- struct clk_hw clk_hw;
- boolpll_on;
-
- const struct msm_dsi_phy_cfg *cfg;
-};
-
-#define hw_clk_to_pll(x) container_of(x, struct msm_dsi_pll, clk_hw)
-
struct msm_dsi_phy_ops {
int (*pll_init)(struct msm_dsi_phy *phy);
int (*enable)(struct msm_dsi_phy *phy, int src_pll_id,
@@ -111,7 +103,8 @@ struct msm_dsi_phy {
enum msm_dsi_phy_usecase usecase;
bool regulator_ldo_mode;
- struct msm_dsi_pll *pll;
+ struct clk_hw *vco_hw;
+ bool pll_on;
struct clk_hw_onecell_data *provided_clocks;
@@ -131,6 +124,27 @@ int msm_dsi_dphy_timing_calc_v4(struct msm_dsi_dphy_timing
*timing,
struct msm_dsi_phy_clk_request *clk_req);
void msm_dsi_phy_set_src_pll(struct msm_dsi_phy *phy, int pll_id, u32 reg,
u32 bit_mask);
+/* PLL accessors */
+static inline void pll_write(void __iomem *reg, u32 data)
+{
+ msm_writel(data, reg);
+}
+
+static inline u32 pll_read(const void __iomem *reg)
+{
+ return msm_readl(reg);
+}
+
+static inline void pll_write_udelay(void __iomem *reg, u32 data, u32 delay_us)
+{
+ pll_write(reg, data);
+ udelay(delay_us);
+}
+
+static inline void pll_write_ndelay(void __iomem *reg, u32 data, u32 delay_ns)
+{
+ pll_write((reg), data);
+ ndelay(delay_ns);
+}
#endif /* __DSI_PHY_H__ */
-
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index 1a470c7356ea..7bcef1cfd515 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -7,7 +7,6 @@
#include
#include
-#include "dsi_pll.h"
#include "dsi_phy.h"
#include "dsi.xml.h"
@@ -82,11 +81,13 @@ struct pll_10nm_cached_state {
};
struct dsi_pll_10nm {
- struct msm_dsi_pll base;
+ struct clk_hw clk_hw;
int id;
struct platform_device *pdev;
+ struct msm_dsi_phy *phy;
+
void __iomem *phy_cmn_mmio;
void __iomem *mmio;
@@ -101,11 +102,10 @@ struct dsi_pll_10nm {
struct pll_10nm_cached_state cached_state;
- enum msm_dsi_phy_usecase uc;
struct dsi_pll_10nm *slave;
};
-#define to_pll_10nm(x) container_of(x, struct dsi_pll_10nm, base)
+#define to_pll_10nm(x) container_of(x, struct dsi_pll_10nm, clk_hw)
/*
* Global list of private DSI
[RFC 16/24] drm/msi/dsi: inline msm_dsi_pll_helper_clk_prepare/unprepare
10nm and 7nm already do not use these helpers, as they handle setting
slave DSI clocks after enabling VCO. Modify the rest of PHY drivers to
remove unnecessary indirection and drop enable_seq/disable_seq PLL
callbacks.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 2 -
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 87 +++--
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 88 -
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 120 ++
drivers/gpu/drm/msm/dsi/phy/dsi_pll.c | 35 -
drivers/gpu/drm/msm/dsi/phy/dsi_pll.h | 2 -
6 files changed, 170 insertions(+), 164 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 75fc24f9f013..0fff9e3afb53 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -35,8 +35,6 @@ struct msm_dsi_phy_ops {
};
struct msm_dsi_pll_ops {
- int (*enable_seq)(struct msm_dsi_pll *pll);
- void (*disable_seq)(struct msm_dsi_pll *pll);
void (*save_state)(struct msm_dsi_pll *pll);
int (*restore_state)(struct msm_dsi_pll *pll);
};
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
index 023727623847..23f198164c0e 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
@@ -652,12 +652,58 @@ static unsigned long dsi_pll_14nm_vco_recalc_rate(struct
clk_hw *hw,
return (unsigned long)vco_rate;
}
+static int dsi_pll_14nm_vco_prepare(struct clk_hw *hw)
+{
+ struct msm_dsi_pll *pll = hw_clk_to_pll(hw);
+ struct dsi_pll_14nm *pll_14nm = to_pll_14nm(pll);
+ void __iomem *base = pll_14nm->mmio;
+ void __iomem *cmn_base = pll_14nm->phy_cmn_mmio;
+ bool locked;
+
+ DBG("");
+
+ if (unlikely(pll->pll_on))
+ return 0;
+
+ pll_write(base + REG_DSI_14nm_PHY_PLL_VREF_CFG1, 0x10);
+ pll_write(cmn_base + REG_DSI_14nm_PHY_CMN_PLL_CNTRL, 1);
+
+ locked = pll_14nm_poll_for_ready(pll_14nm, POLL_MAX_READS,
+POLL_TIMEOUT_US);
+
+ if (unlikely(!locked)) {
+ DRM_DEV_ERROR(_14nm->pdev->dev, "DSI PLL lock failed\n");
+ return -EINVAL;
+ }
+
+ DBG("DSI PLL lock success");
+ pll->pll_on = true;
+
+ return 0;
+}
+
+static void dsi_pll_14nm_vco_unprepare(struct clk_hw *hw)
+{
+ struct msm_dsi_pll *pll = hw_clk_to_pll(hw);
+ struct dsi_pll_14nm *pll_14nm = to_pll_14nm(pll);
+ void __iomem *cmn_base = pll_14nm->phy_cmn_mmio;
+
+ DBG("");
+
+ if (unlikely(!pll->pll_on))
+ return;
+
+ pll_write(cmn_base + REG_DSI_14nm_PHY_CMN_PLL_CNTRL, 0);
+
+ pll->pll_on = false;
+}
+
static const struct clk_ops clk_ops_dsi_pll_14nm_vco = {
.round_rate = msm_dsi_pll_helper_clk_round_rate,
.set_rate = dsi_pll_14nm_vco_set_rate,
.recalc_rate = dsi_pll_14nm_vco_recalc_rate,
- .prepare = msm_dsi_pll_helper_clk_prepare,
- .unprepare = msm_dsi_pll_helper_clk_unprepare,
+ .prepare = dsi_pll_14nm_vco_prepare,
+ .unprepare = dsi_pll_14nm_vco_unprepare,
};
/*
@@ -749,39 +795,6 @@ static const struct clk_ops clk_ops_dsi_pll_14nm_postdiv =
{
* PLL Callbacks
*/
-static int dsi_pll_14nm_enable_seq(struct msm_dsi_pll *pll)
-{
- struct dsi_pll_14nm *pll_14nm = to_pll_14nm(pll);
- void __iomem *base = pll_14nm->mmio;
- void __iomem *cmn_base = pll_14nm->phy_cmn_mmio;
- bool locked;
-
- DBG("");
-
- pll_write(base + REG_DSI_14nm_PHY_PLL_VREF_CFG1, 0x10);
- pll_write(cmn_base + REG_DSI_14nm_PHY_CMN_PLL_CNTRL, 1);
-
- locked = pll_14nm_poll_for_ready(pll_14nm, POLL_MAX_READS,
-POLL_TIMEOUT_US);
-
- if (unlikely(!locked))
- DRM_DEV_ERROR(_14nm->pdev->dev, "DSI PLL lock failed\n");
- else
- DBG("DSI PLL lock success");
-
- return locked ? 0 : -EINVAL;
-}
-
-static void dsi_pll_14nm_disable_seq(struct msm_dsi_pll *pll)
-{
- struct dsi_pll_14nm *pll_14nm = to_pll_14nm(pll);
- void __iomem *cmn_base = pll_14nm->phy_cmn_mmio;
-
- DBG("");
-
- pll_write(cmn_base + REG_DSI_14nm_PHY_CMN_PLL_CNTRL, 0);
-}
-
static void dsi_pll_14nm_save_state(struct msm_dsi_pll *pll)
{
struct dsi_pll_14nm *pll_14nm = to_pll_14nm(pll);
@@ -1158,8 +1171,6 @@ const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs = {
.pll_ops = {
.save_state = dsi_pll_14nm_save_state,
.restore_state = dsi_pll_14nm_restore_state,
- .disable_seq = dsi_pll_14nm_disable_seq,
- .enable_seq = dsi_pll_14nm_enable_seq,
},
.min_pll_rate = VCO_MIN_RATE,
.max_pll_rate = VCO_MAX_RATE,
@@ -1185,8 +1196,6 @@ const struct msm_dsi_phy_cfg
[RFC 14/24] drm/msm/dsi: make save/restore_state phy-level functions
Morph msm_dsi_pll_save/restore_state() into msm_dsi_phy_save/restore_state(),
thus removing last bits of knowledge about msm_dsi_pll from dsi_manager.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.h | 18 ++-
drivers/gpu/drm/msm/dsi/dsi_manager.c | 6 ++--
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 35 +++---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 11 +++
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 2 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 2 +-
drivers/gpu/drm/msm/dsi/phy/dsi_pll.c | 26
drivers/gpu/drm/msm/dsi/phy/dsi_pll.h | 11 ---
8 files changed, 42 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index c4a3ef4a3c09..351bfbeb53bd 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -104,21 +104,6 @@ static inline bool msm_dsi_device_connected(struct msm_dsi
*msm_dsi)
struct drm_encoder *msm_dsi_get_encoder(struct msm_dsi *msm_dsi);
-/* dsi pll */
-struct msm_dsi_pll;
-#ifdef CONFIG_DRM_MSM_DSI_PLL
-void msm_dsi_pll_save_state(struct msm_dsi_pll *pll);
-int msm_dsi_pll_restore_state(struct msm_dsi_pll *pll);
-#else
-static inline void msm_dsi_pll_save_state(struct msm_dsi_pll *pll)
-{
-}
-static inline int msm_dsi_pll_restore_state(struct msm_dsi_pll *pll)
-{
- return 0;
-}
-#endif
-
/* dsi host */
struct msm_dsi_host;
int msm_dsi_host_xfer_prepare(struct mipi_dsi_host *host,
@@ -192,9 +177,10 @@ int msm_dsi_phy_enable(struct msm_dsi_phy *phy, int
src_pll_id,
void msm_dsi_phy_disable(struct msm_dsi_phy *phy);
void msm_dsi_phy_get_shared_timings(struct msm_dsi_phy *phy,
struct msm_dsi_phy_shared_timings *shared_timing);
-struct msm_dsi_pll *msm_dsi_phy_get_pll(struct msm_dsi_phy *phy);
void msm_dsi_phy_set_usecase(struct msm_dsi_phy *phy,
enum msm_dsi_phy_usecase uc);
+void msm_dsi_phy_save_state(struct msm_dsi_phy *phy);
+int msm_dsi_phy_restore_state(struct msm_dsi_phy *phy);
#endif /* __DSI_CONNECTOR_H__ */
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 6b65d86d116a..2976b09a881d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -493,7 +493,6 @@ static void dsi_mgr_bridge_post_disable(struct drm_bridge
*bridge)
struct msm_dsi *msm_dsi1 = dsi_mgr_get_dsi(DSI_1);
struct mipi_dsi_host *host = msm_dsi->host;
struct drm_panel *panel = msm_dsi->panel;
- struct msm_dsi_pll *src_pll;
bool is_dual_dsi = IS_DUAL_DSI();
int ret;
@@ -527,9 +526,8 @@ static void dsi_mgr_bridge_post_disable(struct drm_bridge
*bridge)
id, ret);
}
- /* Save PLL status if it is a clock source */
- src_pll = msm_dsi_phy_get_pll(msm_dsi->phy);
- msm_dsi_pll_save_state(src_pll);
+ /* Save PHY status if it is a clock source */
+ msm_dsi_phy_save_state(msm_dsi->phy);
ret = msm_dsi_host_power_off(host);
if (ret)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 4535cc5d22a5..e9424a4c636e 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -799,9 +799,9 @@ int msm_dsi_phy_enable(struct msm_dsi_phy *phy, int
src_pll_id,
* source.
*/
if (phy->usecase != MSM_DSI_PHY_SLAVE) {
- ret = msm_dsi_pll_restore_state(phy->pll);
+ ret = msm_dsi_phy_restore_state(phy);
if (ret) {
- DRM_DEV_ERROR(dev, "%s: failed to restore pll state,
%d\n",
+ DRM_DEV_ERROR(dev, "%s: failed to restore phy state,
%d\n",
__func__, ret);
goto pll_restor_fail;
}
@@ -838,17 +838,32 @@ void msm_dsi_phy_get_shared_timings(struct msm_dsi_phy
*phy,
sizeof(*shared_timings));
}
-struct msm_dsi_pll *msm_dsi_phy_get_pll(struct msm_dsi_phy *phy)
-{
- if (!phy)
- return NULL;
-
- return phy->pll;
-}
-
void msm_dsi_phy_set_usecase(struct msm_dsi_phy *phy,
enum msm_dsi_phy_usecase uc)
{
if (phy)
phy->usecase = uc;
}
+
+void msm_dsi_phy_save_state(struct msm_dsi_phy *phy)
+{
+ if (phy->cfg->pll_ops.save_state) {
+ phy->cfg->pll_ops.save_state(phy->pll);
+ phy->pll->state_saved = true;
+ }
+}
+
+int msm_dsi_phy_restore_state(struct msm_dsi_phy *phy)
+{
+ int ret;
+
+ if (phy->cfg->pll_ops.restore_state && phy->pll->state_saved) {
+ ret = phy->cfg->pll_ops.restore_state(phy->pll);
+ if (ret)
+ return ret;
+
+ phy->pll->state_saved = false;
+ }
+
+
[RFC 15/24] drm/msm/dsi: limit vco_delay to 28nm PHY
Only 28nm PHY requires sleeping during the VCO rate setting procedure.
Rewrite sleeping for 28nm and drop vco_delay from the rest of PHYs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 3 ---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 4
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 10 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 3 ---
4 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index 81ca0cf2a3ad..7533db8955a5 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -96,7 +96,6 @@ struct dsi_pll_10nm {
/* protects REG_DSI_10nm_PHY_CMN_CLK_CFG0 register */
spinlock_t postdiv_lock;
- int vco_delay;
struct dsi_pll_config pll_configuration;
struct dsi_pll_regs reg_setup;
@@ -768,8 +767,6 @@ static int dsi_pll_10nm_init(struct msm_dsi_phy *phy)
pll = _10nm->base;
pll->cfg = phy->cfg;
- pll_10nm->vco_delay = 1;
-
ret = pll_10nm_register(pll_10nm, phy->provided_clocks);
if (ret) {
DRM_DEV_ERROR(>dev, "failed to register PLL: %d\n", ret);
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
index c531ddf26521..023727623847 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
@@ -122,8 +122,6 @@ struct dsi_pll_14nm {
void __iomem *phy_cmn_mmio;
void __iomem *mmio;
- int vco_delay;
-
struct dsi_pll_input in;
struct dsi_pll_output out;
@@ -1012,8 +1010,6 @@ static int dsi_pll_14nm_init(struct msm_dsi_phy *phy)
pll = _14nm->base;
pll->cfg = phy->cfg;
- pll_14nm->vco_delay = 1;
-
ret = pll_14nm_register(pll_14nm, phy->provided_clocks);
if (ret) {
DRM_DEV_ERROR(>dev, "failed to register PLL: %d\n", ret);
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
index fa96bfc21fdb..e77b21f0d3bf 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
@@ -69,8 +69,6 @@ struct dsi_pll_28nm {
struct platform_device *pdev;
void __iomem *mmio;
- int vco_delay;
-
struct pll_28nm_cached_state cached_state;
};
@@ -209,8 +207,10 @@ static int dsi_pll_28nm_clk_set_rate(struct clk_hw *hw,
unsigned long rate,
pll_write(base + REG_DSI_28nm_PHY_PLL_SDM_CFG4, 0x00);
/* Add hardware recommended delay for correct PLL configuration */
- if (pll_28nm->vco_delay)
- udelay(pll_28nm->vco_delay);
+ if (pll->cfg->type == MSM_DSI_PHY_28NM_HPM)
+ udelay(1);
+ else /* LP */
+ udelay(1000);
pll_write(base + REG_DSI_28nm_PHY_PLL_REFCLK_CFG, refclk_cfg);
pll_write(base + REG_DSI_28nm_PHY_PLL_PWRGEN_CFG, 0x00);
@@ -576,7 +576,6 @@ static int dsi_pll_28nm_hpm_init(struct msm_dsi_phy *phy)
}
pll = _28nm->base;
- pll_28nm->vco_delay = 1;
pll->cfg = phy->cfg;
@@ -616,7 +615,6 @@ static int dsi_pll_28nm_lp_init(struct msm_dsi_phy *phy)
}
pll = _28nm->base;
- pll_28nm->vco_delay = 1000;
pll->cfg = phy->cfg;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
index c6f0aca66fa9..d3fea4a2b498 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
@@ -96,7 +96,6 @@ struct dsi_pll_7nm {
/* protects REG_DSI_7nm_PHY_CMN_CLK_CFG0 register */
spinlock_t postdiv_lock;
- int vco_delay;
struct dsi_pll_config pll_configuration;
struct dsi_pll_regs reg_setup;
@@ -793,8 +792,6 @@ static int dsi_pll_7nm_init(struct msm_dsi_phy *phy)
pll = _7nm->base;
pll->cfg = phy->cfg;
- pll_7nm->vco_delay = 1;
-
ret = pll_7nm_register(pll_7nm, phy->provided_clocks);
if (ret) {
DRM_DEV_ERROR(>dev, "failed to register PLL: %d\n", ret);
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 13/24] drm/msm/dsi: replace PHY's init callback with configurable data
DSI PHY init callback would either map dsi_phy_regulator or dsi_phy_lane
depending on the PHY type. Replace those callbacks with configuration
options governing mapping those regions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 42 ---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 4 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 19 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 19 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c| 2 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 6 +--
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 2 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 19 +
8 files changed, 31 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 0c26451db310..4535cc5d22a5 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -638,24 +638,6 @@ static int dsi_phy_get_id(struct msm_dsi_phy *phy)
return -EINVAL;
}
-int msm_dsi_phy_init_common(struct msm_dsi_phy *phy)
-{
- struct platform_device *pdev = phy->pdev;
- int ret = 0;
-
- phy->reg_base = msm_ioremap(pdev, "dsi_phy_regulator",
- "DSI_PHY_REG");
- if (IS_ERR(phy->reg_base)) {
- DRM_DEV_ERROR(>dev, "%s: failed to map phy regulator
base\n",
- __func__);
- ret = -ENOMEM;
- goto fail;
- }
-
-fail:
- return ret;
-}
-
static int dsi_phy_driver_probe(struct platform_device *pdev)
{
struct msm_dsi_phy *phy;
@@ -700,6 +682,24 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
goto fail;
}
+ if (phy->cfg->has_phy_lane) {
+ phy->lane_base = msm_ioremap(pdev, "dsi_phy_lane",
"DSI_PHY_LANE");
+ if (IS_ERR(phy->lane_base)) {
+ DRM_DEV_ERROR(>dev, "%s: failed to map phy lane
base\n", __func__);
+ ret = -ENOMEM;
+ goto fail;
+ }
+ }
+
+ if (phy->cfg->has_phy_regulator) {
+ phy->reg_base = msm_ioremap(pdev, "dsi_phy_regulator",
"DSI_PHY_REG");
+ if (IS_ERR(phy->reg_base)) {
+ DRM_DEV_ERROR(>dev, "%s: failed to map phy
regulator base\n", __func__);
+ ret = -ENOMEM;
+ goto fail;
+ }
+ }
+
ret = dsi_phy_regulator_init(phy);
if (ret)
goto fail;
@@ -711,12 +711,6 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
goto fail;
}
- if (phy->cfg->ops.init) {
- ret = phy->cfg->ops.init(phy);
- if (ret)
- goto fail;
- }
-
/* PLL init will call into clk_register which requires
* register access, so we need to enable power and ahb clock.
*/
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 049feaaa479f..06e560548c8e 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -17,7 +17,6 @@
#define V3_0_0_10NM_OLD_TIMINGS_QUIRK BIT(0)
struct msm_dsi_phy_ops {
- int (*init) (struct msm_dsi_phy *phy);
int (*pll_init)(struct msm_dsi_phy *phy);
int (*enable)(struct msm_dsi_phy *phy, int src_pll_id,
struct msm_dsi_phy_clk_request *clk_req);
@@ -49,6 +48,8 @@ struct msm_dsi_phy_cfg {
const resource_size_t io_start[DSI_MAX];
const int num_dsi_phy;
const int quirks;
+ bool has_phy_regulator;
+ bool has_phy_lane;
};
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_cfgs;
@@ -124,7 +125,6 @@ int msm_dsi_dphy_timing_calc_v4(struct msm_dsi_dphy_timing
*timing,
struct msm_dsi_phy_clk_request *clk_req);
void msm_dsi_phy_set_src_pll(struct msm_dsi_phy *phy, int pll_id, u32 reg,
u32 bit_mask);
-int msm_dsi_phy_init_common(struct msm_dsi_phy *phy);
#endif /* __DSI_PHY_H__ */
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index 6ddf852782a4..9910cee8c9a5 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -992,24 +992,10 @@ static void dsi_10nm_phy_disable(struct msm_dsi_phy *phy)
DBG("DSI%d PHY disabled", phy->id);
}
-static int dsi_10nm_phy_init(struct msm_dsi_phy *phy)
-{
- struct platform_device *pdev = phy->pdev;
-
- phy->lane_base = msm_ioremap(pdev, "dsi_phy_lane",
-"DSI_PHY_LANE");
- if (IS_ERR(phy->lane_base)) {
- DRM_DEV_ERROR(>dev, "%s: failed to map phy lane base\n",
- __func__);
- return -ENOMEM;
[RFC 12/24] drm/msm/dsi: use devm_of_clk_add_hw_provider
Use devm_of_clk_add_hw_provider() to register provided clocks. This
allows dropping the remove function alltogether.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 22 +-
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 8c0bc5ccba8f..0c26451db310 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -734,7 +734,7 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
}
}
- ret = of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get,
+ ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
phy->provided_clocks);
if (ret) {
DRM_DEV_ERROR(dev, "%s: failed to register clk provider: %d\n",
__func__, ret);
@@ -748,31 +748,11 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
return 0;
fail:
- if (phy->pll) {
- of_clk_del_provider(dev->of_node);
- phy->pll = NULL;
- }
-
return ret;
}
-static int dsi_phy_driver_remove(struct platform_device *pdev)
-{
- struct msm_dsi_phy *phy = platform_get_drvdata(pdev);
-
- if (phy && phy->pll) {
- of_clk_del_provider(pdev->dev.of_node);
- phy->pll = NULL;
- }
-
- platform_set_drvdata(pdev, NULL);
-
- return 0;
-}
-
static struct platform_driver dsi_phy_platform_driver = {
.probe = dsi_phy_driver_probe,
- .remove = dsi_phy_driver_remove,
.driver = {
.name = "msm_dsi_phy",
.of_match_table = dsi_phy_dt_match,
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 07/24] arm64: dts: qcom: sm8250: assign DSI clock source parents
Assign DSI clock source parents to DSI PHY clocks.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 947e1accae3a..b6ed94497e8a 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -2445,6 +2445,9 @@ dsi0: dsi@ae94000 {
"iface",
"bus";
+ assigned-clocks = <
DISP_CC_MDSS_BYTE0_CLK_SRC>, < DISP_CC_MDSS_PCLK0_CLK_SRC>;
+ assigned-clock-parents = <_phy 0>,
<_phy 1>;
+
operating-points-v2 = <_opp_table>;
power-domains = < SM8250_MMCX>;
@@ -2512,6 +2515,9 @@ dsi1: dsi@ae96000 {
"iface",
"bus";
+ assigned-clocks = <
DISP_CC_MDSS_BYTE1_CLK_SRC>, < DISP_CC_MDSS_PCLK1_CLK_SRC>;
+ assigned-clock-parents = <_phy 0>,
<_phy 1>;
+
operating-points-v2 = <_opp_table>;
power-domains = < SM8250_MMCX>;
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 10/24] clk: divider: add devm_clk_hw_register_divider
Add devm_clk_hw_register_divider() - devres version of clk_hw_register_divider(). Signed-off-by: Dmitry Baryshkov --- include/linux/clk-provider.h | 17 + 1 file changed, 17 insertions(+) diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index 3eb15e0262f5..162a2e5546a3 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -785,6 +785,23 @@ struct clk *clk_register_divider_table(struct device *dev, const char *name, (parent_data), (flags), (reg), (shift), \ (width), (clk_divider_flags), (table), \ (lock)) +/** + * devm_clk_hw_register_divider - register a divider clock with the clock framework + * @dev: device registering this clock + * @name: name of this clock + * @parent_name: name of clock's parent + * @flags: framework-specific flags + * @reg: register address to adjust divider + * @shift: number of bits to shift the bitfield + * @width: width of the bitfield + * @clk_divider_flags: divider-specific flags for this clock + * @lock: shared register lock for this clock + */ +#define devm_clk_hw_register_divider(dev, name, parent_name, flags, reg, shift,\ + width, clk_divider_flags, lock) \ + __devm_clk_hw_register_divider((dev), NULL, (name), (parent_name), NULL, \ + NULL, (flags), (reg), (shift), (width), \ + (clk_divider_flags), NULL, (lock)) /** * devm_clk_hw_register_divider_table - register a table based divider clock * with the clock framework (devres variant) -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 11/24] drm/msm/dsi: use devm_clk_*register to registe DSI PHY clocks
Use devres-enabled version of clock registration functions. This lets us
remove dsi_pll destroy callbacks completely.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.h | 4 -
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 -
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 -
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 84 ---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 35 +---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 50 +--
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 39 +++--
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 84 ---
drivers/gpu/drm/msm/dsi/phy/dsi_pll.c | 17
drivers/gpu/drm/msm/dsi/phy/dsi_pll.h | 4 -
10 files changed, 71 insertions(+), 249 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index da59f8bc8d2c..c4a3ef4a3c09 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -107,13 +107,9 @@ struct drm_encoder *msm_dsi_get_encoder(struct msm_dsi
*msm_dsi);
/* dsi pll */
struct msm_dsi_pll;
#ifdef CONFIG_DRM_MSM_DSI_PLL
-void msm_dsi_pll_destroy(struct msm_dsi_pll *pll);
void msm_dsi_pll_save_state(struct msm_dsi_pll *pll);
int msm_dsi_pll_restore_state(struct msm_dsi_pll *pll);
#else
-static inline void msm_dsi_pll_destroy(struct msm_dsi_pll *pll)
-{
-}
static inline void msm_dsi_pll_save_state(struct msm_dsi_pll *pll)
{
}
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 2742b18168b7..8c0bc5ccba8f 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -750,7 +750,6 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
fail:
if (phy->pll) {
of_clk_del_provider(dev->of_node);
- msm_dsi_pll_destroy(phy->pll);
phy->pll = NULL;
}
@@ -763,7 +762,6 @@ static int dsi_phy_driver_remove(struct platform_device
*pdev)
if (phy && phy->pll) {
of_clk_del_provider(pdev->dev.of_node);
- msm_dsi_pll_destroy(phy->pll);
phy->pll = NULL;
}
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index cb461c39c204..049feaaa479f 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -27,7 +27,6 @@ struct msm_dsi_phy_ops {
struct msm_dsi_pll_ops {
int (*enable_seq)(struct msm_dsi_pll *pll);
void (*disable_seq)(struct msm_dsi_pll *pll);
- void (*destroy)(struct msm_dsi_pll *pll);
void (*save_state)(struct msm_dsi_pll *pll);
int (*restore_state)(struct msm_dsi_pll *pll);
};
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index 6dc1c104d2f6..6ddf852782a4 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -100,15 +100,6 @@ struct dsi_pll_10nm {
struct dsi_pll_config pll_configuration;
struct dsi_pll_regs reg_setup;
- /* private clocks: */
- struct clk_hw *out_div_clk_hw;
- struct clk_hw *bit_clk_hw;
- struct clk_hw *byte_clk_hw;
- struct clk_hw *by_2_bit_clk_hw;
- struct clk_hw *post_out_div_clk_hw;
- struct clk_hw *pclk_mux_hw;
- struct clk_hw *out_dsiclk_hw;
-
struct pll_10nm_cached_state cached_state;
enum msm_dsi_phy_usecase uc;
@@ -611,22 +602,6 @@ static int dsi_pll_10nm_set_usecase(struct msm_dsi_pll
*pll,
return 0;
}
-static void dsi_pll_10nm_destroy(struct msm_dsi_pll *pll)
-{
- struct dsi_pll_10nm *pll_10nm = to_pll_10nm(pll);
-
- DBG("DSI PLL%d", pll_10nm->id);
-
- clk_hw_unregister_divider(pll_10nm->out_dsiclk_hw);
- clk_hw_unregister_mux(pll_10nm->pclk_mux_hw);
- clk_hw_unregister_fixed_factor(pll_10nm->post_out_div_clk_hw);
- clk_hw_unregister_fixed_factor(pll_10nm->by_2_bit_clk_hw);
- clk_hw_unregister_fixed_factor(pll_10nm->byte_clk_hw);
- clk_hw_unregister_divider(pll_10nm->bit_clk_hw);
- clk_hw_unregister_divider(pll_10nm->out_div_clk_hw);
- clk_hw_unregister(_10nm->base.clk_hw);
-}
-
/*
* The post dividers and mux clocks are created using the standard divider and
* mux API. Unlike the 14nm PHY, the slave PLL doesn't need its dividers/mux
@@ -653,30 +628,28 @@ static int pll_10nm_register(struct dsi_pll_10nm
*pll_10nm, struct clk_hw_onecel
snprintf(vco_name, 32, "dsi%dvco_clk", pll_10nm->id);
pll_10nm->base.clk_hw.init = _init;
- ret = clk_hw_register(dev, _10nm->base.clk_hw);
+ ret = devm_clk_hw_register(dev, _10nm->base.clk_hw);
if (ret)
return ret;
snprintf(clk_name, 32, "dsi%d_pll_out_div_clk", pll_10nm->id);
snprintf(parent, 32, "dsi%dvco_clk", pll_10nm->id);
- hw =
[RFC 09/24] clk: mux: provide devm_clk_hw_register_mux()
Add devm_clk_hw_register_mux() - devres-managed version of
clk_hw_register_mux().
Signed-off-by: Dmitry Baryshkov
---
drivers/clk/clk-mux.c| 35 +++
include/linux/clk-provider.h | 13 +
2 files changed, 48 insertions(+)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index e54e79714818..20582aae7a35 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include
#include
#include
@@ -206,6 +207,40 @@ struct clk_hw *__clk_hw_register_mux(struct device *dev,
struct device_node *np,
}
EXPORT_SYMBOL_GPL(__clk_hw_register_mux);
+static void devm_clk_hw_release_mux(struct device *dev, void *res)
+{
+ clk_hw_unregister_mux(*(struct clk_hw **)res);
+}
+
+struct clk_hw *__devm_clk_hw_register_mux(struct device *dev, struct
device_node *np,
+ const char *name, u8 num_parents,
+ const char * const *parent_names,
+ const struct clk_hw **parent_hws,
+ const struct clk_parent_data *parent_data,
+ unsigned long flags, void __iomem *reg, u8 shift, u32 mask,
+ u8 clk_mux_flags, u32 *table, spinlock_t *lock)
+{
+ struct clk_hw **ptr, *hw;
+
+ ptr = devres_alloc(devm_clk_hw_release_mux, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ hw = __clk_hw_register_mux(dev, np, name, num_parents, parent_names,
parent_hws,
+ parent_data, flags, reg, shift, mask,
+ clk_mux_flags, table, lock);
+
+ if (!IS_ERR(hw)) {
+ *ptr = hw;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return hw;
+}
+EXPORT_SYMBOL_GPL(__devm_clk_hw_register_mux);
+
struct clk *clk_register_mux_table(struct device *dev, const char *name,
const char * const *parent_names, u8 num_parents,
unsigned long flags, void __iomem *reg, u8 shift, u32 mask,
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 58f6fe866ae9..3eb15e0262f5 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -868,6 +868,13 @@ struct clk_hw *__clk_hw_register_mux(struct device *dev,
struct device_node *np,
const struct clk_parent_data *parent_data,
unsigned long flags, void __iomem *reg, u8 shift, u32 mask,
u8 clk_mux_flags, u32 *table, spinlock_t *lock);
+struct clk_hw *__devm_clk_hw_register_mux(struct device *dev, struct
device_node *np,
+ const char *name, u8 num_parents,
+ const char * const *parent_names,
+ const struct clk_hw **parent_hws,
+ const struct clk_parent_data *parent_data,
+ unsigned long flags, void __iomem *reg, u8 shift, u32 mask,
+ u8 clk_mux_flags, u32 *table, spinlock_t *lock);
struct clk *clk_register_mux_table(struct device *dev, const char *name,
const char * const *parent_names, u8 num_parents,
unsigned long flags, void __iomem *reg, u8 shift, u32 mask,
@@ -902,6 +909,12 @@ struct clk *clk_register_mux_table(struct device *dev,
const char *name,
__clk_hw_register_mux((dev), NULL, (name), (num_parents), NULL, NULL, \
(parent_data), (flags), (reg), (shift), \
BIT((width)) - 1, (clk_mux_flags), NULL, (lock))
+#define devm_clk_hw_register_mux(dev, name, parent_names, num_parents, flags,
reg, \
+ shift, width, clk_mux_flags, lock)\
+ __devm_clk_hw_register_mux((dev), NULL, (name), (num_parents),\
+ (parent_names), NULL, NULL, (flags), (reg), \
+ (shift), BIT((width)) - 1, (clk_mux_flags), \
+ NULL, (lock))
int clk_mux_val_to_index(struct clk_hw *hw, u32 *table, unsigned int flags,
unsigned int val);
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 08/24] drm/msm/dsi: push provided clocks handling into a generic code
All MSM DSI PHYs provide two clocks: byte and pixel ones.
Register/unregister provided clocks from the generic place, removing
boilerplate code from all MSM DSI PHY drivers.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 23 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 6 +++
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 36 ++-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 36 ++-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 44 ---
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 41 -
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 36 ++-
drivers/gpu/drm/msm/dsi/phy/dsi_pll.c | 5 +--
drivers/gpu/drm/msm/dsi/phy/dsi_pll.h | 3 +-
9 files changed, 59 insertions(+), 171 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 33abeff16a6f..2742b18168b7 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -3,6 +3,7 @@
* Copyright (c) 2015, The Linux Foundation. All rights reserved.
*/
+#include
#include
#include "dsi_phy.h"
@@ -670,6 +671,14 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
if (!match)
return -ENODEV;
+ phy->provided_clocks = devm_kzalloc(dev, sizeof(*phy->provided_clocks) +
+ NUM_PROVIDED_CLKS * sizeof(struct clk_hw *),
+ GFP_KERNEL);
+ if (!phy->provided_clocks)
+ return -ENOMEM;
+
+ phy->provided_clocks->num = NUM_PROVIDED_CLKS;
+
phy->cfg = match->data;
phy->pdev = pdev;
@@ -725,6 +734,13 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
}
}
+ ret = of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get,
+phy->provided_clocks);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "%s: failed to register clk provider: %d\n",
__func__, ret);
+ goto fail;
+ }
+
dsi_phy_disable_resource(phy);
platform_set_drvdata(pdev, phy);
@@ -732,6 +748,12 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
return 0;
fail:
+ if (phy->pll) {
+ of_clk_del_provider(dev->of_node);
+ msm_dsi_pll_destroy(phy->pll);
+ phy->pll = NULL;
+ }
+
return ret;
}
@@ -740,6 +762,7 @@ static int dsi_phy_driver_remove(struct platform_device
*pdev)
struct msm_dsi_phy *phy = platform_get_drvdata(pdev);
if (phy && phy->pll) {
+ of_clk_del_provider(pdev->dev.of_node);
msm_dsi_pll_destroy(phy->pll);
phy->pll = NULL;
}
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index ea1bd375b9ff..cb461c39c204 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -87,6 +87,10 @@ struct msm_dsi_dphy_timing {
u8 hs_halfbyte_en_ckln;
};
+#define DSI_BYTE_PLL_CLK 0
+#define DSI_PIXEL_PLL_CLK 1
+#define NUM_PROVIDED_CLKS 2
+
struct msm_dsi_phy {
struct platform_device *pdev;
void __iomem *base;
@@ -104,6 +108,8 @@ struct msm_dsi_phy {
bool regulator_ldo_mode;
struct msm_dsi_pll *pll;
+
+ struct clk_hw_onecell_data *provided_clocks;
};
/*
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index fee080677c36..6dc1c104d2f6 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -36,10 +36,6 @@
* dsi0_pll_post_out_div_clk
*/
-#define DSI_BYTE_PLL_CLK 0
-#define DSI_PIXEL_PLL_CLK 1
-#define NUM_PROVIDED_CLKS 2
-
#define VCO_REF_CLK_RATE 1920
struct dsi_pll_regs {
@@ -113,9 +109,6 @@ struct dsi_pll_10nm {
struct clk_hw *pclk_mux_hw;
struct clk_hw *out_dsiclk_hw;
- /* clock-provider: */
- struct clk_hw_onecell_data *hw_data;
-
struct pll_10nm_cached_state cached_state;
enum msm_dsi_phy_usecase uc;
@@ -621,10 +614,8 @@ static int dsi_pll_10nm_set_usecase(struct msm_dsi_pll
*pll,
static void dsi_pll_10nm_destroy(struct msm_dsi_pll *pll)
{
struct dsi_pll_10nm *pll_10nm = to_pll_10nm(pll);
- struct device *dev = _10nm->pdev->dev;
DBG("DSI PLL%d", pll_10nm->id);
- of_clk_del_provider(dev->of_node);
clk_hw_unregister_divider(pll_10nm->out_dsiclk_hw);
clk_hw_unregister_mux(pll_10nm->pclk_mux_hw);
@@ -642,7 +633,7 @@ static void dsi_pll_10nm_destroy(struct msm_dsi_pll *pll)
* state to follow the master PLL's divider/mux state. Therefore, we don't
* require special clock ops
[RFC 06/24] drm/msm/dsi: stop setting clock parents manually
There is no reason to set clock parents manually, use device tree to
assign DSI/display clock parents to DSI PHY clocks. Dropping this manual
setup allows us to drop repeating code and to move registration of hw
clock providers to generic place.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.h | 9
drivers/gpu/drm/msm/dsi/dsi_host.c| 51 ---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 12 -
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 19 ---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 17 ---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 18 ---
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 16 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 19 ---
drivers/gpu/drm/msm/dsi/phy/dsi_pll.c | 11
10 files changed, 175 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index a130330b97b6..da59f8bc8d2c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -108,19 +108,12 @@ struct drm_encoder *msm_dsi_get_encoder(struct msm_dsi
*msm_dsi);
struct msm_dsi_pll;
#ifdef CONFIG_DRM_MSM_DSI_PLL
void msm_dsi_pll_destroy(struct msm_dsi_pll *pll);
-int msm_dsi_pll_get_clk_provider(struct msm_dsi_pll *pll,
- struct clk **byte_clk_provider, struct clk **pixel_clk_provider);
void msm_dsi_pll_save_state(struct msm_dsi_pll *pll);
int msm_dsi_pll_restore_state(struct msm_dsi_pll *pll);
#else
static inline void msm_dsi_pll_destroy(struct msm_dsi_pll *pll)
{
}
-static inline int msm_dsi_pll_get_clk_provider(struct msm_dsi_pll *pll,
- struct clk **byte_clk_provider, struct clk **pixel_clk_provider)
-{
- return -ENODEV;
-}
static inline void msm_dsi_pll_save_state(struct msm_dsi_pll *pll)
{
}
@@ -155,8 +148,6 @@ unsigned long msm_dsi_host_get_mode_flags(struct
mipi_dsi_host *host);
struct drm_bridge *msm_dsi_host_get_bridge(struct mipi_dsi_host *host);
int msm_dsi_host_register(struct mipi_dsi_host *host, bool check_defer);
void msm_dsi_host_unregister(struct mipi_dsi_host *host);
-int msm_dsi_host_set_src_pll(struct mipi_dsi_host *host,
- struct msm_dsi_pll *src_pll);
void msm_dsi_host_reset_phy(struct mipi_dsi_host *host);
void msm_dsi_host_get_phy_clk_req(struct mipi_dsi_host *host,
struct msm_dsi_phy_clk_request *clk_req,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index ab281cba0f08..bf3468ccc965 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -2225,57 +2225,6 @@ void msm_dsi_host_cmd_xfer_commit(struct mipi_dsi_host
*host, u32 dma_base,
wmb();
}
-int msm_dsi_host_set_src_pll(struct mipi_dsi_host *host,
- struct msm_dsi_pll *src_pll)
-{
- struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
- struct clk *byte_clk_provider, *pixel_clk_provider;
- int ret;
-
- ret = msm_dsi_pll_get_clk_provider(src_pll,
- _clk_provider, _clk_provider);
- if (ret) {
- pr_info("%s: can't get provider from pll, don't set parent\n",
- __func__);
- return 0;
- }
-
- ret = clk_set_parent(msm_host->byte_clk_src, byte_clk_provider);
- if (ret) {
- pr_err("%s: can't set parent to byte_clk_src. ret=%d\n",
- __func__, ret);
- goto exit;
- }
-
- ret = clk_set_parent(msm_host->pixel_clk_src, pixel_clk_provider);
- if (ret) {
- pr_err("%s: can't set parent to pixel_clk_src. ret=%d\n",
- __func__, ret);
- goto exit;
- }
-
- if (msm_host->dsi_clk_src) {
- ret = clk_set_parent(msm_host->dsi_clk_src, pixel_clk_provider);
- if (ret) {
- pr_err("%s: can't set parent to dsi_clk_src. ret=%d\n",
- __func__, ret);
- goto exit;
- }
- }
-
- if (msm_host->esc_clk_src) {
- ret = clk_set_parent(msm_host->esc_clk_src, byte_clk_provider);
- if (ret) {
- pr_err("%s: can't set parent to esc_clk_src. ret=%d\n",
- __func__, ret);
- goto exit;
- }
- }
-
-exit:
- return ret;
-}
-
void msm_dsi_host_reset_phy(struct mipi_dsi_host *host)
{
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 1d28dfba2c9b..6b65d86d116a 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -70,7 +70,6 @@ static int dsi_mgr_setup_components(int id)
struct msm_dsi *other_dsi = dsi_mgr_get_other_dsi(id);
struct msm_dsi
[RFC 05/24] drm/msm/dsi: remove msm_dsi_pll_set_usecase
msm_dsi_pll_set_usecase() function is not used outside of individual DSI
PHY drivers, so drop it in favour of calling the the respective
set_usecase functions directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.h | 7 ---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 2 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 4 +---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 4 +---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 4 +---
drivers/gpu/drm/msm/dsi/phy/dsi_pll.c | 9 -
6 files changed, 3 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 21cf883fb6f1..a130330b97b6 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -112,8 +112,6 @@ int msm_dsi_pll_get_clk_provider(struct msm_dsi_pll *pll,
struct clk **byte_clk_provider, struct clk **pixel_clk_provider);
void msm_dsi_pll_save_state(struct msm_dsi_pll *pll);
int msm_dsi_pll_restore_state(struct msm_dsi_pll *pll);
-int msm_dsi_pll_set_usecase(struct msm_dsi_pll *pll,
- enum msm_dsi_phy_usecase uc);
#else
static inline void msm_dsi_pll_destroy(struct msm_dsi_pll *pll)
{
@@ -130,11 +128,6 @@ static inline int msm_dsi_pll_restore_state(struct
msm_dsi_pll *pll)
{
return 0;
}
-static inline int msm_dsi_pll_set_usecase(struct msm_dsi_pll *pll,
- enum msm_dsi_phy_usecase uc)
-{
- return -ENODEV;
-}
#endif
/* dsi host */
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index ce2969c63927..b8dd8072d24c 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -33,8 +33,6 @@ struct msm_dsi_pll_ops {
void (*destroy)(struct msm_dsi_pll *pll);
void (*save_state)(struct msm_dsi_pll *pll);
int (*restore_state)(struct msm_dsi_pll *pll);
- int (*set_usecase)(struct msm_dsi_pll *pll,
- enum msm_dsi_phy_usecase uc);
};
struct msm_dsi_phy_cfg {
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index 799d7f44cf6d..339f7a56e555 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -1046,7 +1046,7 @@ static int dsi_10nm_phy_enable(struct msm_dsi_phy *phy,
int src_pll_id,
/* Select full-rate mode */
dsi_phy_write(base + REG_DSI_10nm_PHY_CMN_CTRL_2, 0x40);
- ret = msm_dsi_pll_set_usecase(phy->pll, phy->usecase);
+ ret = dsi_pll_10nm_set_usecase(phy->pll, phy->usecase);
if (ret) {
DRM_DEV_ERROR(>pdev->dev, "%s: set pll usecase failed,
%d\n",
__func__, ret);
@@ -1122,7 +1122,6 @@ const struct msm_dsi_phy_cfg dsi_phy_10nm_cfgs = {
.destroy = dsi_pll_10nm_destroy,
.save_state = dsi_pll_10nm_save_state,
.restore_state = dsi_pll_10nm_restore_state,
- .set_usecase = dsi_pll_10nm_set_usecase,
},
.min_pll_rate = 10UL,
.max_pll_rate = 35UL,
@@ -1150,7 +1149,6 @@ const struct msm_dsi_phy_cfg dsi_phy_10nm_8998_cfgs = {
.destroy = dsi_pll_10nm_destroy,
.save_state = dsi_pll_10nm_save_state,
.restore_state = dsi_pll_10nm_restore_state,
- .set_usecase = dsi_pll_10nm_set_usecase,
},
.min_pll_rate = 10UL,
.max_pll_rate = 35UL,
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
index cd66b01ad17d..a141c37d86ab 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
@@ -1190,7 +1190,7 @@ static int dsi_14nm_phy_enable(struct msm_dsi_phy *phy,
int src_pll_id,
REG_DSI_14nm_PHY_CMN_GLBL_TEST_CTRL,
DSI_14nm_PHY_CMN_GLBL_TEST_CTRL_BITCLK_HS_SEL);
- ret = msm_dsi_pll_set_usecase(phy->pll, phy->usecase);
+ ret = dsi_pll_14nm_set_usecase(phy->pll, phy->usecase);
if (ret) {
DRM_DEV_ERROR(>pdev->dev, "%s: set pll usecase failed,
%d\n",
__func__, ret);
@@ -1247,7 +1247,6 @@ const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs = {
.destroy = dsi_pll_14nm_destroy,
.save_state = dsi_pll_14nm_save_state,
.restore_state = dsi_pll_14nm_restore_state,
- .set_usecase = dsi_pll_14nm_set_usecase,
.disable_seq = dsi_pll_14nm_disable_seq,
.enable_seq = dsi_pll_14nm_enable_seq,
},
@@ -1277,7 +1276,6 @@ const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs = {
.destroy = dsi_pll_14nm_destroy,
.save_state = dsi_pll_14nm_save_state,
.restore_state = dsi_pll_14nm_restore_state,
-
[RFC 04/24] drm/msm/dsi: move min/max PLL rate to phy config
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 +++
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 6 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 6 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 10 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 4 ++--
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 12
drivers/gpu/drm/msm/dsi/phy/dsi_pll.c | 8
drivers/gpu/drm/msm/dsi/phy/dsi_pll.h | 3 ---
8 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 45ab2f23ac5b..ce2969c63927 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -43,6 +43,9 @@ struct msm_dsi_phy_cfg {
struct msm_dsi_phy_ops ops;
const struct msm_dsi_pll_ops pll_ops;
+ unsigned long min_pll_rate;
+ unsigned long max_pll_rate;
+
/*
* Each cell {phy_id, pll_id} of the truth table indicates
* if the source PLL selection bit should be set for each PHY.
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index 49eb1440a269..799d7f44cf6d 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -861,8 +861,6 @@ static int dsi_pll_10nm_init(struct msm_dsi_phy *phy)
spin_lock_init(_10nm->postdiv_lock);
pll = _10nm->base;
- pll->min_rate = 10UL;
- pll->max_rate = 35UL;
pll->cfg = phy->cfg;
pll_10nm->vco_delay = 1;
@@ -1126,6 +1124,8 @@ const struct msm_dsi_phy_cfg dsi_phy_10nm_cfgs = {
.restore_state = dsi_pll_10nm_restore_state,
.set_usecase = dsi_pll_10nm_set_usecase,
},
+ .min_pll_rate = 10UL,
+ .max_pll_rate = 35UL,
.io_start = { 0xae94400, 0xae96400 },
.num_dsi_phy = 2,
};
@@ -1152,6 +1152,8 @@ const struct msm_dsi_phy_cfg dsi_phy_10nm_8998_cfgs = {
.restore_state = dsi_pll_10nm_restore_state,
.set_usecase = dsi_pll_10nm_set_usecase,
},
+ .min_pll_rate = 10UL,
+ .max_pll_rate = 35UL,
.io_start = { 0xc994400, 0xc996400 },
.num_dsi_phy = 2,
.quirks = V3_0_0_10NM_OLD_TIMINGS_QUIRK,
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
index 82e5d225d83e..cd66b01ad17d 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
@@ -1078,8 +1078,6 @@ static int dsi_pll_14nm_init(struct msm_dsi_phy *phy)
spin_lock_init(_14nm->postdiv_lock);
pll = _14nm->base;
- pll->min_rate = VCO_MIN_RATE;
- pll->max_rate = VCO_MAX_RATE;
pll->cfg = phy->cfg;
pll_14nm->vco_delay = 1;
@@ -1253,6 +1251,8 @@ const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs = {
.disable_seq = dsi_pll_14nm_disable_seq,
.enable_seq = dsi_pll_14nm_enable_seq,
},
+ .min_pll_rate = VCO_MIN_RATE,
+ .max_pll_rate = VCO_MAX_RATE,
.io_start = { 0x994400, 0x996400 },
.num_dsi_phy = 2,
};
@@ -1281,6 +1281,8 @@ const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs = {
.disable_seq = dsi_pll_14nm_disable_seq,
.enable_seq = dsi_pll_14nm_enable_seq,
},
+ .min_pll_rate = VCO_MIN_RATE,
+ .max_pll_rate = VCO_MAX_RATE,
.io_start = { 0xc994400, 0xc996000 },
.num_dsi_phy = 2,
};
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
index 7330672d95c0..4ddb68f5a82a 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
@@ -622,8 +622,6 @@ static int dsi_pll_28nm_hpm_init(struct msm_dsi_phy *phy)
}
pll = _28nm->base;
- pll->min_rate = VCO_MIN_RATE;
- pll->max_rate = VCO_MAX_RATE;
pll_28nm->vco_delay = 1;
pll->cfg = phy->cfg;
@@ -664,8 +662,6 @@ static int dsi_pll_28nm_lp_init(struct msm_dsi_phy *phy)
}
pll = _28nm->base;
- pll->min_rate = VCO_MIN_RATE;
- pll->max_rate = VCO_MAX_RATE;
pll_28nm->vco_delay = 1000;
pll->cfg = phy->cfg;
@@ -849,6 +845,8 @@ const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_cfgs = {
.disable_seq = dsi_pll_28nm_disable_seq,
.enable_seq = dsi_pll_28nm_enable_seq_hpm,
},
+ .min_pll_rate = VCO_MIN_RATE,
+ .max_pll_rate = VCO_MAX_RATE,
.io_start = { 0xfd922b00, 0xfd923100 },
.num_dsi_phy = 2,
};
@@ -876,6 +874,8 @@ const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_famb_cfgs = {
.disable_seq = dsi_pll_28nm_disable_seq,
.enable_seq = dsi_pll_28nm_enable_seq_hpm,
},
+
[RFC 03/24] drm/msm/dsi: move all PLL callbacks into PHY config struct
Move all PLL-related callbacks into struct msm_dsi_phy_cfg. This limits
the amount of data in the struct msm_dsi_pll.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.h | 6 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 14 +--
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 15 +++
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 38 ---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 47 ++---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 99 +++
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 33 ---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 48 ++---
drivers/gpu/drm/msm/dsi/phy/dsi_pll.c | 67 +++--
drivers/gpu/drm/msm/dsi/phy/dsi_pll.h | 65 +---
10 files changed, 226 insertions(+), 206 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 78ef5d4ed922..21cf883fb6f1 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -107,8 +107,6 @@ struct drm_encoder *msm_dsi_get_encoder(struct msm_dsi
*msm_dsi);
/* dsi pll */
struct msm_dsi_pll;
#ifdef CONFIG_DRM_MSM_DSI_PLL
-struct msm_dsi_pll *msm_dsi_pll_init(struct platform_device *pdev,
- enum msm_dsi_phy_type type, int dsi_id);
void msm_dsi_pll_destroy(struct msm_dsi_pll *pll);
int msm_dsi_pll_get_clk_provider(struct msm_dsi_pll *pll,
struct clk **byte_clk_provider, struct clk **pixel_clk_provider);
@@ -117,10 +115,6 @@ int msm_dsi_pll_restore_state(struct msm_dsi_pll *pll);
int msm_dsi_pll_set_usecase(struct msm_dsi_pll *pll,
enum msm_dsi_phy_usecase uc);
#else
-static inline struct msm_dsi_pll *msm_dsi_pll_init(struct platform_device
*pdev,
-enum msm_dsi_phy_type type, int id) {
- return ERR_PTR(-ENODEV);
-}
static inline void msm_dsi_pll_destroy(struct msm_dsi_pll *pll)
{
}
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index e8c1a727179c..33abeff16a6f 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -715,12 +715,14 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
if (ret)
goto fail;
- phy->pll = msm_dsi_pll_init(pdev, phy->cfg->type, phy->id);
- if (IS_ERR_OR_NULL(phy->pll)) {
- DRM_DEV_INFO(dev,
- "%s: pll init failed: %ld, need separate pll clk
driver\n",
- __func__, PTR_ERR(phy->pll));
- phy->pll = NULL;
+ if (phy->cfg->ops.pll_init) {
+ ret = phy->cfg->ops.pll_init(phy);
+ if (ret) {
+ DRM_DEV_INFO(dev,
+ "%s: pll init failed: %d, need separate pll clk
driver\n",
+ __func__, ret);
+ goto fail;
+ }
}
dsi_phy_disable_resource(phy);
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index d2bd74b6f357..45ab2f23ac5b 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -18,15 +18,30 @@
struct msm_dsi_phy_ops {
int (*init) (struct msm_dsi_phy *phy);
+ int (*pll_init)(struct msm_dsi_phy *phy);
int (*enable)(struct msm_dsi_phy *phy, int src_pll_id,
struct msm_dsi_phy_clk_request *clk_req);
void (*disable)(struct msm_dsi_phy *phy);
};
+struct msm_dsi_pll_ops {
+ int (*enable_seq)(struct msm_dsi_pll *pll);
+ void (*disable_seq)(struct msm_dsi_pll *pll);
+ int (*get_provider)(struct msm_dsi_pll *pll,
+ struct clk **byte_clk_provider,
+ struct clk **pixel_clk_provider);
+ void (*destroy)(struct msm_dsi_pll *pll);
+ void (*save_state)(struct msm_dsi_pll *pll);
+ int (*restore_state)(struct msm_dsi_pll *pll);
+ int (*set_usecase)(struct msm_dsi_pll *pll,
+ enum msm_dsi_phy_usecase uc);
+};
+
struct msm_dsi_phy_cfg {
enum msm_dsi_phy_type type;
struct dsi_reg_config reg_cfg;
struct msm_dsi_phy_ops ops;
+ const struct msm_dsi_pll_ops pll_ops;
/*
* Each cell {phy_id, pll_id} of the truth table indicates
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index 535d7e2393ae..49eb1440a269 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -828,15 +828,17 @@ static int pll_10nm_register(struct dsi_pll_10nm
*pll_10nm)
return ret;
}
-struct msm_dsi_pll *msm_dsi_pll_10nm_init(struct platform_device *pdev, int id)
+static int dsi_pll_10nm_init(struct msm_dsi_phy *phy)
{
+ struct platform_device *pdev = phy->pdev;
+ int id = phy->id;
struct dsi_pll_10nm *pll_10nm;
[RFC 02/24] drm/msm/dsi: drop multiple pll enable_seq support
The only PLL using multiple enable sequences is the 28nm PLL, which just
does the single step in the loop. Push that support back into the PLL
code.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 3 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 23 +--
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 3 +-
drivers/gpu/drm/msm/dsi/phy/dsi_pll.c | 65 +++
drivers/gpu/drm/msm/dsi/phy/dsi_pll.h | 4 +-
5 files changed, 42 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
index 4cf289ff8d7e..bd73aa612e76 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
@@ -1087,8 +1087,7 @@ struct msm_dsi_pll *msm_dsi_pll_14nm_init(struct
platform_device *pdev, int id)
pll_14nm->vco_delay = 1;
- pll->en_seq_cnt = 1;
- pll->enable_seqs[0] = dsi_pll_14nm_enable_seq;
+ pll->enable_seq = dsi_pll_14nm_enable_seq;
ret = pll_14nm_register(pll_14nm);
if (ret) {
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
index b2eac57700ce..e92070633b5f 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
@@ -311,7 +311,7 @@ static const struct clk_ops clk_ops_dsi_pll_28nm_vco = {
/*
* PLL Callbacks
*/
-static int dsi_pll_28nm_enable_seq_hpm(struct msm_dsi_pll *pll)
+static int _dsi_pll_28nm_enable_seq_hpm(struct msm_dsi_pll *pll)
{
struct dsi_pll_28nm *pll_28nm = to_pll_28nm(pll);
struct device *dev = _28nm->pdev->dev;
@@ -386,6 +386,19 @@ static int dsi_pll_28nm_enable_seq_hpm(struct msm_dsi_pll
*pll)
return locked ? 0 : -EINVAL;
}
+static int dsi_pll_28nm_enable_seq_hpm(struct msm_dsi_pll *pll)
+{
+ int i, ret;
+
+ for (i = 0; i < 3; i++) {
+ ret = _dsi_pll_28nm_enable_seq_hpm(pll);
+ if (!ret)
+ return 0;
+ }
+
+ return ret;
+}
+
static int dsi_pll_28nm_enable_seq_lp(struct msm_dsi_pll *pll)
{
struct dsi_pll_28nm *pll_28nm = to_pll_28nm(pll);
@@ -619,15 +632,11 @@ struct msm_dsi_pll *msm_dsi_pll_28nm_init(struct
platform_device *pdev,
if (type == MSM_DSI_PHY_28NM_HPM) {
pll_28nm->vco_delay = 1;
- pll->en_seq_cnt = 3;
- pll->enable_seqs[0] = dsi_pll_28nm_enable_seq_hpm;
- pll->enable_seqs[1] = dsi_pll_28nm_enable_seq_hpm;
- pll->enable_seqs[2] = dsi_pll_28nm_enable_seq_hpm;
+ pll->enable_seq = dsi_pll_28nm_enable_seq_hpm;
} else if (type == MSM_DSI_PHY_28NM_LP) {
pll_28nm->vco_delay = 1000;
- pll->en_seq_cnt = 1;
- pll->enable_seqs[0] = dsi_pll_28nm_enable_seq_lp;
+ pll->enable_seq = dsi_pll_28nm_enable_seq_lp;
} else {
DRM_DEV_ERROR(>dev, "phy type (%d) is not 28nm\n", type);
return ERR_PTR(-EINVAL);
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c
index 50ed935a5d3e..1b9a5abc9275 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c
@@ -515,8 +515,7 @@ struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct
platform_device *pdev,
pll->save_state = dsi_pll_28nm_save_state;
pll->restore_state = dsi_pll_28nm_restore_state;
- pll->en_seq_cnt = 1;
- pll->enable_seqs[0] = dsi_pll_28nm_enable_seq;
+ pll->enable_seq = dsi_pll_28nm_enable_seq;
ret = pll_28nm_register(pll_28nm);
if (ret) {
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_pll.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_pll.c
index a45fe95aff49..b409ae2874b4 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_pll.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_pll.c
@@ -5,46 +5,6 @@
#include "dsi_pll.h"
-static int dsi_pll_enable(struct msm_dsi_pll *pll)
-{
- int i, ret = 0;
-
- /*
-* Certain PLLs do not allow VCO rate update when it is on.
-* Keep track of their status to turn on/off after set rate success.
-*/
- if (unlikely(pll->pll_on))
- return 0;
-
- /* Try all enable sequences until one succeeds */
- for (i = 0; i < pll->en_seq_cnt; i++) {
- ret = pll->enable_seqs[i](pll);
- DBG("DSI PLL %s after sequence #%d",
- ret ? "unlocked" : "locked", i + 1);
- if (!ret)
- break;
- }
-
- if (ret) {
- DRM_ERROR("DSI PLL failed to lock\n");
- return ret;
- }
-
- pll->pll_on = true;
-
- return 0;
-}
-
-static void dsi_pll_disable(struct msm_dsi_pll *pll)
-{
- if (unlikely(!pll->pll_on))
- return;
-
-
[RFC 00/24] drm/msm/dsi: refactor MSM DSI PHY/PLL drivers
This is an RFC attempt to restructure MSM DSI PHY drivers. What started as an attempt to grok the overcomplicated PHY drivers, has lead up to the idea of merging PHY and PLL code, reducing abstractions, code duplication, dropping dead code, etc. The patches were mainly tested on RB5 (sm8250, 7nm) and lightly tested on RB3 (sdm845, 10nm), DB410c (apq8016, 28nm-lp). The following changes since commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8: Linux 5.12-rc1 (2021-02-28 16:05:19 -0800) are available in the Git repository at: ssh://g...@git.linaro.org/people/dmitry.baryshkov/kernel.git dsi-phy-rfc for you to fetch changes up to 819a9071587f1acba14a6780f422d78fdb55d671: arm64: dts: qcom: sdm845: assign DSI clock source parents (2021-03-02 02:23:14 +0300) Dmitry Baryshkov (24): drm/msm/dsi: fuse dsi_pll_* code into dsi_phy_* code drm/msm/dsi: drop multiple pll enable_seq support drm/msm/dsi: move all PLL callbacks into PHY config struct drm/msm/dsi: move min/max PLL rate to phy config drm/msm/dsi: remove msm_dsi_pll_set_usecase drm/msm/dsi: stop setting clock parents manually arm64: dts: qcom: sm8250: assign DSI clock source parents drm/msm/dsi: push provided clocks handling into a generic code clk: mux: provide devm_clk_hw_register_mux() clk: divider: add devm_clk_hw_register_divider drm/msm/dsi: use devm_clk_*register to registe DSI PHY clocks drm/msm/dsi: use devm_of_clk_add_hw_provider drm/msm/dsi: replace PHY's init callback with configurable data drm/msm/dsi: make save/restore_state phy-level functions drm/msm/dsi: limit vco_delay to 28nm PHY drm/msi/dsi: inline msm_dsi_pll_helper_clk_prepare/unprepare drm/msm/dsi: make save_state/restore_state callbacks accept msm_dsi_phy drm/msm/dsi: drop msm_dsi_pll abstracton drm/msm/dsi: drop PLL accessor functions drm/msm/dsi: move ioremaps to dsi_phy_driver_probe drm/msm/dsi: remove duplicate fields from dsi_pll_Nnm instances drm/msm/dsi: remove temp data from global pll structure drm/msm/dsi: drop global msm_dsi_phy_type enumaration arm64: dts: qcom: sdm845: assign DSI clock source parents arch/arm64/boot/dts/qcom/sdm845.dtsi|6 + arch/arm64/boot/dts/qcom/sm8250.dtsi|6 + drivers/clk/clk-mux.c | 35 + drivers/gpu/drm/msm/Kconfig |8 - drivers/gpu/drm/msm/Makefile|9 - drivers/gpu/drm/msm/dsi/dsi.h | 56 +- drivers/gpu/drm/msm/dsi/dsi_host.c | 51 -- drivers/gpu/drm/msm/dsi/dsi_manager.c | 18 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 129 +-- drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 31 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 741 ++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 925 ++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c |3 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 662 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 476 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 769 +++- drivers/gpu/drm/msm/dsi/pll/dsi_pll.c | 184 drivers/gpu/drm/msm/dsi/pll/dsi_pll.h | 130 --- drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 881 -- drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c | 1096 --- drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c | 643 - drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c | 526 --- drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c | 912 --- include/linux/clk-provider.h| 30 + 24 files changed, 3678 insertions(+), 4649 deletions(-) delete mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll.c delete mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll.h delete mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c delete mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c delete mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c delete mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c delete mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 6/8] mm: Selftests for exclusive device memory
> From: Alistair Popple
> Sent: Thursday, February 25, 2021 11:19 PM
> To: linux...@kvack.org; nouv...@lists.freedesktop.org;
> bske...@redhat.com; a...@linux-foundation.org
> Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; John Hubbard ; Ralph
> Campbell ; jgli...@redhat.com; Jason Gunthorpe
> ; h...@infradead.org; dan...@ffwll.ch; Alistair Popple
>
> Subject: [PATCH v3 6/8] mm: Selftests for exclusive device memory
>
> Adds some selftests for exclusive device memory.
>
> Signed-off-by: Alistair Popple
One minor nit below, but you can add
Tested-by: Ralph Campbell
Reviewed-by: Ralph Campbell
> +static int dmirror_exclusive(struct dmirror *dmirror,
> + struct hmm_dmirror_cmd *cmd)
> +{
> + unsigned long start, end, addr;
> + unsigned long size = cmd->npages << PAGE_SHIFT;
> + struct mm_struct *mm = dmirror->notifier.mm;
> + struct page *pages[64];
> + struct dmirror_bounce bounce;
> + unsigned long next;
> + int ret;
> +
> + start = cmd->addr;
> + end = start + size;
> + if (end < start)
> + return -EINVAL;
> +
> + /* Since the mm is for the mirrored process, get a reference first. */
> + if (!mmget_not_zero(mm))
> + return -EINVAL;
> +
> + mmap_read_lock(mm);
> + for (addr = start; addr < end; addr = next) {
> + int i, mapped;
> +
> + if (end < addr + (64 << PAGE_SHIFT))
> + next = end;
> + else
> + next = addr + (64 << PAGE_SHIFT);
I suggest using ARRAY_SIZE(pages) instead of '64' to make the meaning clear.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 5/8] mm: Device exclusive memory access
> From: Alistair Popple
> Sent: Thursday, February 25, 2021 11:18 PM
> To: linux...@kvack.org; nouv...@lists.freedesktop.org;
> bske...@redhat.com; a...@linux-foundation.org
> Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; John Hubbard ; Ralph
> Campbell ; jgli...@redhat.com; Jason Gunthorpe
> ; h...@infradead.org; dan...@ffwll.ch; Alistair Popple
>
> Subject: [PATCH v3 5/8] mm: Device exclusive memory access
>
> Some devices require exclusive write access to shared virtual memory (SVM)
> ranges to perform atomic operations on that memory. This requires CPU page
> tables to be updated to deny access whilst atomic operations are occurring.
>
> In order to do this introduce a new swap entry type (SWP_DEVICE_EXCLUSIVE).
> When a SVM range needs to be marked for exclusive access by a device all page
> table mappings for the particular range are replaced with device exclusive
> swap
> entries. This causes any CPU access to the page to result in a fault.
>
> Faults are resovled by replacing the faulting entry with the original
> mapping. This
> results in MMU notifiers being called which a driver uses to update access
> permissions such as revoking atomic access. After notifiers have been called
> the
> device will no longer have exclusive access to the region.
>
> Signed-off-by: Alistair Popple
> ---
> Documentation/vm/hmm.rst | 15
> include/linux/rmap.h | 3 +
> include/linux/swap.h | 4 +-
> include/linux/swapops.h | 44 ++-
> mm/hmm.c | 5 ++
> mm/memory.c | 108 +-
> mm/mprotect.c| 8 ++
> mm/page_vma_mapped.c | 9 ++-
> mm/rmap.c| 163 +++
> 9 files changed, 352 insertions(+), 7 deletions(-)
...
> +int make_device_exclusive_range(struct mm_struct *mm, unsigned long start,
> + unsigned long end, struct page **pages) {
> + long npages = (end - start) >> PAGE_SHIFT;
> + long i;
Nit: you should use unsigned long for 'i' and 'npages' to match start/end.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: ioremap buffer according to TTM mem caching setting
If tbo.mem.bus.caching is cached, buffer is intended to be mapped
as cached from CPU. Map it with ioremap_cache.
This wasn't necessary before as device memory was never mapped
as cached from CPU side. It becomes necessary for aldebaran as
device memory is mapped cached from CPU.
Signed-off-by: Oak Zeng
Reviewed-by: Christian Konig
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 031e581..8c65a13 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -91,6 +91,8 @@ static int ttm_resource_ioremap(struct ttm_device *bdev,
if (mem->bus.caching == ttm_write_combined)
addr = ioremap_wc(mem->bus.offset, bus_size);
+ else if (mem->bus.caching == ttm_cached)
+ addr = ioremap_cache(mem->bus.offset, bus_size);
else
addr = ioremap(mem->bus.offset, bus_size);
if (!addr) {
@@ -372,6 +374,9 @@ static int ttm_bo_ioremap(struct ttm_buffer_object *bo,
if (mem->bus.caching == ttm_write_combined)
map->virtual = ioremap_wc(bo->mem.bus.offset + offset,
size);
+ else if (mem->bus.caching == ttm_cached)
+ map->virtual = ioremap_cache(bo->mem.bus.offset +
offset,
+ size);
else
map->virtual = ioremap(bo->mem.bus.offset + offset,
size);
@@ -490,6 +495,9 @@ int ttm_bo_vmap(struct ttm_buffer_object *bo, struct
dma_buf_map *map)
else if (mem->bus.caching == ttm_write_combined)
vaddr_iomem = ioremap_wc(mem->bus.offset,
bo->base.size);
+ else if (mem->bus.caching == ttm_cached)
+ vaddr_iomem = ioremap_cache(mem->bus.offset,
+ bo->base.size);
else
vaddr_iomem = ioremap(mem->bus.offset, bo->base.size);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu/drm/msm: fix shutdown hook in case GPU components failed to bind
if GPU components have failed to bind, shutdown callback would fail with
the following backtrace. Add safeguard check to stop that oops from
happening and allow the board to reboot.
[ 66.617046] Unable to handle kernel NULL pointer dereference at virtual
address
[ 66.626066] Mem abort info:
[ 66.628939] ESR = 0x9606
[ 66.632088] EC = 0x25: DABT (current EL), IL = 32 bits
[ 66.637542] SET = 0, FnV = 0
[ 66.640688] EA = 0, S1PTW = 0
[ 66.643924] Data abort info:
[ 66.646889] ISV = 0, ISS = 0x0006
[ 66.650832] CM = 0, WnR = 0
[ 66.653890] user pgtable: 4k pages, 48-bit VAs, pgdp=000107f81000
[ 66.660505] [] pgd=000100bb2003, p4d=000100bb2003,
pud=000100897003, pmd=
[ 66.671398] Internal error: Oops: 9606 [#1] PREEMPT SMP
[ 66.677115] Modules linked in:
[ 66.680261] CPU: 6 PID: 352 Comm: reboot Not tainted
5.11.0-rc2-00309-g79e3faa756b2 #38
[ 66.688473] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
[ 66.695347] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[ 66.701507] pc : msm_atomic_commit_tail+0x78/0x4e0
[ 66.706437] lr : commit_tail+0xa4/0x184
[ 66.710381] sp : 8000108f3af0
[ 66.713791] x29: 8000108f3af0 x28: 418c44337000
[ 66.719242] x27: x26: 418c40a24490
[ 66.724693] x25: d3a842a4f1a0 x24: 0008
[ 66.730146] x23: d3a84313f030 x22: 418c444ce000
[ 66.735598] x21: 418c408a4980 x20:
[ 66.741049] x19: x18: 800010710fbc
[ 66.746500] x17: 000c x16: 0001
[ 66.751954] x15: 00010008 x14: 0068
[ 66.757405] x13: 0001 x12:
[ 66.762855] x11: 0001 x10: 09b0
[ 66.768306] x9 : d3a843192000 x8 : 418c44337000
[ 66.773757] x7 : x6 : a401b34e
[ 66.779210] x5 : 00ff x4 :
[ 66.784660] x3 : x2 : 418c444ce000
[ 66.790111] x1 : d3a841dce530 x0 : 418c444cf000
[ 66.795563] Call trace:
[ 66.798075] msm_atomic_commit_tail+0x78/0x4e0
[ 66.802633] commit_tail+0xa4/0x184
[ 66.806217] drm_atomic_helper_commit+0x160/0x390
[ 66.811051] drm_atomic_commit+0x4c/0x60
[ 66.815082] drm_atomic_helper_disable_all+0x1f4/0x210
[ 66.820355] drm_atomic_helper_shutdown+0x80/0x130
[ 66.825276] msm_pdev_shutdown+0x14/0x20
[ 66.829303] platform_shutdown+0x28/0x40
[ 66.80] device_shutdown+0x158/0x330
[ 66.837357] kernel_restart+0x40/0xa0
[ 66.841122] __do_sys_reboot+0x228/0x250
[ 66.845148] __arm64_sys_reboot+0x28/0x34
[ 66.849264] el0_svc_common.constprop.0+0x74/0x190
[ 66.854187] do_el0_svc+0x24/0x90
[ 66.857595] el0_svc+0x14/0x20
[ 66.860739] el0_sync_handler+0x1a4/0x1b0
[ 66.864858] el0_sync+0x174/0x180
[ 66.868269] Code: 1ac020a0 2a000273 eb02007f 5401 (f9400285)
[ 66.874525] ---[ end trace 20dedb2a3229fec8 ]---
Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display
platform_driver")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_atomic.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 6a326761dc4a..2fd0cf6421ad 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -207,7 +207,12 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
struct msm_kms *kms = priv->kms;
struct drm_crtc *async_crtc = NULL;
unsigned crtc_mask = get_crtc_mask(state);
- bool async = kms->funcs->vsync_time &&
+ bool async;
+
+ if (!kms)
+ return;
+
+ async = kms->funcs->vsync_time &&
can_do_async(state, _crtc);
trace_msm_atomic_commit_tail_start(async, crtc_mask);
--
2.30.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/3] drm: Add GUD USB Display driver
Den 01.03.2021 19.31, skrev Peter Stuge: > Hi Noralf, > > Peter Stuge wrote: >> I'll prepare a test setup for the RGB-TFT on the weekend. > > So implementing a GUD and looking at the protocol from yet another > angle gives more new insights - surprise. :) > Yep, my Raspberry Pi Pico implementation discovered a bug in the compression code. Running X on a 240x135 display produced some 2x2 buffer rectangles which was so small that they failed to compress. > Here are some thoughts so far: > > * GUD_REQ_SET_VERSION does still rub me wrong; it seems potentially > quite complex to maintain compatibility in two places; both for host > and device. I don't want to insist on removing it, but at a minimum > it's quite unusual. > Part of the idea in USB is that host software updates are easy if > not fully automated but device firmware updates less so, thus > complexity is rather placed in the host. > Alright, I'll remove it :) This can also be accomplished in the device by having a switch that turns it into a version 1 device. > * It's unclear to me from reading the header files in this v6 patch set > which GUD_REQ:s and which properties are actually mandatory in devices. > I'm getting hints from your STM32 device and reading the driver code in > detail, but what do you think is a good way to document what's required > vs. optional? > The device must respond to all requests, but can return zero on some like the property requests. I intend to do a writeup on the wiki later with some more details around the protocol and how DRM works for this usecase. My RPi Pico implementation will also serve as a guide. I've put the protocol handling in one file for possible reuse: - gud.h: https://gist.github.com/notro/26bbf918fa59fb89caf155d51d57a40f - gud.c: https://gist.github.com/notro/c1b32cea591f84d3d1c94f30812c1ba6 I will publish it when I have cleaned up the rest of the code. > * GUD_REQ_SET_BUFFER my old nemesis. :) It's great that it's optional! > But do you see any way to turn it into a bulk message, in order to > remove the memory barrier effect of a control transfer before bulk? > On a 1920x1080 RGB565 full update (4MB), the control request is negligible. I did measure it (USB 2.0), but I don't remember the numbers, a few milliseconds. > I think it would be possible to noticeably improve performance later, > by changing the host driver to submit asynchronous bulk transfers for > frame data rather than waiting for each transfer to finish; bulk > transfers will then pack optimally on the wire - but with a control > transfer in between there's no chance of achieving that. > > Having only one kind of transfer in the hot path would also simplify > canceling still pending transfers (when using async later) if new data > gets flushed before the previous frame is completely transfered. > The device is the bottle neck (unless it's powerful like a Pi4): Host: compresses buffer Host: sends ctrl transfer Host: sends bulk transfer Device: Decompresses buffer, much slower than a desktop CPU Host: compresses buffer Host: sends ctrl transfer, waits for device to respond Device: Has decompressed, and is ready Host: sends bulk transfer I would have preferred to do a test on a USB 3.0 device which would put more stress on the host, but I couldn't find an affordable one with mainline Linux support. As you say this can be optimized later. By using double buffering it's possible to compress the next buffer while the previous is in transit. lz4 compression has worked really well in my testing, always 2x or better. I will reconsider the ctrl req if you provide me with numbers that show it's a performance problem. > * A fair bit of the EDID isn't used or has dummy values. Have you already > considered and dismissed some other ways of accomplishing the same? > EDID is optional (return zero in v7), but useful if you want userspace to give a name to the monitor in the GUI for instance. This comment will be present in version 7: /* * Display modes can be fetched as either EDID data or an array of _display_mode_req. * * If GUD_REQ_GET_CONNECTOR_MODES returns zero, EDID is used to create display modes. * If both display modes and EDID are returned, EDID is just passed on to userspace * in the EDID connector property. */ > * Sorry if I've asked before - but what's the purpose of > GUD_REQ_SET_STATE_CHECK and GUD_REQ_SET_STATE_COMMIT? Why/when does > drm do pipe check vs. update? > DRM atomic mode setting has 2 stages: - Check to see if the mode is supported, return -EINVAL if not - Commit the mode, this is not allowed to fail. Userspace can also do just the check phase when figuring out which combination of options that is supported. > * How do you feel about passing the parameters for > GUD_REQ_SET_CONTROLLER_ENABLE and GUD_REQ_SET_DISPLAY_ENABLE in wValue? > It would save the transfer data stage. > That would make the request different form the others, wValue is only
[Bug 209713] amdgpu drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_link_encoder.c:483 dcn10_get_dig_frontend+0x9e/0xc0 [amdgpu] when resuming from S3 state
https://bugzilla.kernel.org/show_bug.cgi?id=209713 --- Comment #20 from Oliver Reeh (oli...@diereehs.de) --- Still no problem here with the 5.11.x kernels. -- You may reply to this email to add a comment. 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 v2] drm/bridge: lt9611: Fix handling of 4k panels
On Thu, Jan 21, 2021 at 1:50 AM Robert Foss wrote: > +Sam Ravnborg > > I think this patch is ready to get pulled into the drm-misc tree. > > On Thu, 17 Dec 2020 at 15:09, Robert Foss wrote: > > > > 4k requires two dsi pipes, so don't report MODE_OK when only a > > single pipe is configured. But rather report MODE_PANEL to > > signal that requirements of the panel are not being met. Hey All, I just wanted to follow up on this patch as it seems like it missed 5.12 ? Just wanted to make sure it didn't slip through the cracks. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: rcar_du_kms.c:781:24: error: passing argument 1 of '__drmm_add_action' from incompatible pointer type
On 01/03/2021 18:52, Greg Kroah-Hartman wrote: > On Mon, Mar 01, 2021 at 11:11:26PM +0530, Naresh Kamboju wrote: >> On stable rc 5.11 the x86_64 build failed due to below errors/warnings. >> >> drivers/gpu/drm/rcar-du/rcar_du_kms.c: In function 'rcar_du_modeset_cleanup': >> drivers/gpu/drm/rcar-du/rcar_du_kms.c:754:32: error: implicit >> declaration of function 'to_rcar_du_device'; did you mean >> 'to_rtc_device'? [-Werror=implicit-function-declaration] >> struct rcar_du_device *rcdu = to_rcar_du_device(dev); >> ^ >> to_rtc_device >> drivers/gpu/drm/rcar-du/rcar_du_kms.c:754:32: warning: initialization >> makes pointer from integer without a cast [-Wint-conversion] >> In file included from drivers/gpu/drm/rcar-du/rcar_du_kms.c:17:0: >> drivers/gpu/drm/rcar-du/rcar_du_kms.c: In function 'rcar_du_modeset_init': >> drivers/gpu/drm/rcar-du/rcar_du_kms.c:781:24: error: passing argument >> 1 of '__drmm_add_action' from incompatible pointer type >> [-Werror=incompatible-pointer-types] >> ret = drmm_add_action(>ddev, rcar_du_modeset_cleanup, NULL); >> ^ >> include/drm/drm_managed.h:25:20: note: in definition of macro >> 'drmm_add_action' >> __drmm_add_action(dev, action, data, #action) >> ^~~ >> include/drm/drm_managed.h:27:18: note: expected 'struct drm_device *' >> but argument is of type 'struct drm_device **' >> int __must_check __drmm_add_action(struct drm_device *dev, >> ^ >> cc1: some warnings being treated as errors >> >> Reported-by: Naresh Kamboju > > Very odd, my builds here didn't trigger that, sorry. I'll go drop the > offending patch... Hrm, I believe this should have been fixed by: https://lore.kernel.org/dri-devel/20210113170253.443820-1-kieran.bingham+rene...@ideasonboard.com/ But it doesn't seem to have made it upstream yet. I've pinged the patch today, but that won't help stable trees until it lands. -- Kieran ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: rcar_du_kms.c:781:24: error: passing argument 1 of '__drmm_add_action' from incompatible pointer type
On Mon, Mar 01, 2021 at 11:11:26PM +0530, Naresh Kamboju wrote: > On stable rc 5.11 the x86_64 build failed due to below errors/warnings. > > drivers/gpu/drm/rcar-du/rcar_du_kms.c: In function 'rcar_du_modeset_cleanup': > drivers/gpu/drm/rcar-du/rcar_du_kms.c:754:32: error: implicit > declaration of function 'to_rcar_du_device'; did you mean > 'to_rtc_device'? [-Werror=implicit-function-declaration] > struct rcar_du_device *rcdu = to_rcar_du_device(dev); > ^ > to_rtc_device > drivers/gpu/drm/rcar-du/rcar_du_kms.c:754:32: warning: initialization > makes pointer from integer without a cast [-Wint-conversion] > In file included from drivers/gpu/drm/rcar-du/rcar_du_kms.c:17:0: > drivers/gpu/drm/rcar-du/rcar_du_kms.c: In function 'rcar_du_modeset_init': > drivers/gpu/drm/rcar-du/rcar_du_kms.c:781:24: error: passing argument > 1 of '__drmm_add_action' from incompatible pointer type > [-Werror=incompatible-pointer-types] > ret = drmm_add_action(>ddev, rcar_du_modeset_cleanup, NULL); > ^ > include/drm/drm_managed.h:25:20: note: in definition of macro > 'drmm_add_action' > __drmm_add_action(dev, action, data, #action) > ^~~ > include/drm/drm_managed.h:27:18: note: expected 'struct drm_device *' > but argument is of type 'struct drm_device **' > int __must_check __drmm_add_action(struct drm_device *dev, > ^ > cc1: some warnings being treated as errors > > Reported-by: Naresh Kamboju Very odd, my builds here didn't trigger that, sorry. I'll go drop the offending patch... greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/3] drm: Add GUD USB Display driver
Hi Noralf, Peter Stuge wrote: > I'll prepare a test setup for the RGB-TFT on the weekend. So implementing a GUD and looking at the protocol from yet another angle gives more new insights - surprise. :) Here are some thoughts so far: * GUD_REQ_SET_VERSION does still rub me wrong; it seems potentially quite complex to maintain compatibility in two places; both for host and device. I don't want to insist on removing it, but at a minimum it's quite unusual. Part of the idea in USB is that host software updates are easy if not fully automated but device firmware updates less so, thus complexity is rather placed in the host. * It's unclear to me from reading the header files in this v6 patch set which GUD_REQ:s and which properties are actually mandatory in devices. I'm getting hints from your STM32 device and reading the driver code in detail, but what do you think is a good way to document what's required vs. optional? * GUD_REQ_SET_BUFFER my old nemesis. :) It's great that it's optional! But do you see any way to turn it into a bulk message, in order to remove the memory barrier effect of a control transfer before bulk? I think it would be possible to noticeably improve performance later, by changing the host driver to submit asynchronous bulk transfers for frame data rather than waiting for each transfer to finish; bulk transfers will then pack optimally on the wire - but with a control transfer in between there's no chance of achieving that. Having only one kind of transfer in the hot path would also simplify canceling still pending transfers (when using async later) if new data gets flushed before the previous frame is completely transfered. * A fair bit of the EDID isn't used or has dummy values. Have you already considered and dismissed some other ways of accomplishing the same? * Sorry if I've asked before - but what's the purpose of GUD_REQ_SET_STATE_CHECK and GUD_REQ_SET_STATE_COMMIT? Why/when does drm do pipe check vs. update? * How do you feel about passing the parameters for GUD_REQ_SET_CONTROLLER_ENABLE and GUD_REQ_SET_DISPLAY_ENABLE in wValue? It would save the transfer data stage. Kind regards //Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
rcar_du_kms.c:781:24: error: passing argument 1 of '__drmm_add_action' from incompatible pointer type
On stable rc 5.11 the x86_64 build failed due to below errors/warnings. drivers/gpu/drm/rcar-du/rcar_du_kms.c: In function 'rcar_du_modeset_cleanup': drivers/gpu/drm/rcar-du/rcar_du_kms.c:754:32: error: implicit declaration of function 'to_rcar_du_device'; did you mean 'to_rtc_device'? [-Werror=implicit-function-declaration] struct rcar_du_device *rcdu = to_rcar_du_device(dev); ^ to_rtc_device drivers/gpu/drm/rcar-du/rcar_du_kms.c:754:32: warning: initialization makes pointer from integer without a cast [-Wint-conversion] In file included from drivers/gpu/drm/rcar-du/rcar_du_kms.c:17:0: drivers/gpu/drm/rcar-du/rcar_du_kms.c: In function 'rcar_du_modeset_init': drivers/gpu/drm/rcar-du/rcar_du_kms.c:781:24: error: passing argument 1 of '__drmm_add_action' from incompatible pointer type [-Werror=incompatible-pointer-types] ret = drmm_add_action(>ddev, rcar_du_modeset_cleanup, NULL); ^ include/drm/drm_managed.h:25:20: note: in definition of macro 'drmm_add_action' __drmm_add_action(dev, action, data, #action) ^~~ include/drm/drm_managed.h:27:18: note: expected 'struct drm_device *' but argument is of type 'struct drm_device **' int __must_check __drmm_add_action(struct drm_device *dev, ^ cc1: some warnings being treated as errors Reported-by: Naresh Kamboju Build link, https://ci.linaro.org/job/openembedded-lkft-linux-stable-rc-5.11/DISTRO=lkft,MACHINE=ls2088ardb,label=docker-buster-lkft/8/consoleText -- Linaro LKFT https://lkft.linaro.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: rcar_du_kms.c:781:24: error: passing argument 1 of '__drmm_add_action' from incompatible pointer type
On Mon, 1 Mar 2021 at 23:11, Naresh Kamboju wrote: > > On stable rc 5.11 the x86_64 build failed due to below errors/warnings. These build failures were also noticed on stable rc 5.10 for arm64, arm, x86_64, and i386 architectures. > > drivers/gpu/drm/rcar-du/rcar_du_kms.c: In function 'rcar_du_modeset_cleanup': > drivers/gpu/drm/rcar-du/rcar_du_kms.c:754:32: error: implicit > declaration of function 'to_rcar_du_device'; did you mean > 'to_rtc_device'? [-Werror=implicit-function-declaration] > struct rcar_du_device *rcdu = to_rcar_du_device(dev); > ^ > to_rtc_device > drivers/gpu/drm/rcar-du/rcar_du_kms.c:754:32: warning: initialization > makes pointer from integer without a cast [-Wint-conversion] > In file included from drivers/gpu/drm/rcar-du/rcar_du_kms.c:17:0: > drivers/gpu/drm/rcar-du/rcar_du_kms.c: In function 'rcar_du_modeset_init': > drivers/gpu/drm/rcar-du/rcar_du_kms.c:781:24: error: passing argument > 1 of '__drmm_add_action' from incompatible pointer type > [-Werror=incompatible-pointer-types] > ret = drmm_add_action(>ddev, rcar_du_modeset_cleanup, NULL); > ^ > include/drm/drm_managed.h:25:20: note: in definition of macro > 'drmm_add_action' > __drmm_add_action(dev, action, data, #action) > ^~~ > include/drm/drm_managed.h:27:18: note: expected 'struct drm_device *' > but argument is of type 'struct drm_device **' > int __must_check __drmm_add_action(struct drm_device *dev, > ^ > cc1: some warnings being treated as errors > > Reported-by: Naresh Kamboju > > Build link, > https://ci.linaro.org/job/openembedded-lkft-linux-stable-rc-5.11/DISTRO=lkft,MACHINE=ls2088ardb,label=docker-buster-lkft/8/consoleText > > -- > Linaro LKFT > https://lkft.linaro.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 6/8] mm: Selftests for exclusive device memory
> From: Jason Gunthorpe > Sent: Monday, March 1, 2021 9:56 AM > To: Alistair Popple > Cc: linux...@kvack.org; nouv...@lists.freedesktop.org; > bske...@redhat.com; a...@linux-foundation.org; linux-...@vger.kernel.org; > linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; John Hubbard > ; Ralph Campbell ; > jgli...@redhat.com; h...@infradead.org; dan...@ffwll.ch > Subject: Re: [PATCH v3 6/8] mm: Selftests for exclusive device memory > > On Fri, Feb 26, 2021 at 06:18:30PM +1100, Alistair Popple wrote: > > Adds some selftests for exclusive device memory. > > > > Signed-off-by: Alistair Popple > > --- > > lib/test_hmm.c | 124 ++ > > lib/test_hmm_uapi.h| 2 + > > tools/testing/selftests/vm/hmm-tests.c | 219 + > > 3 files changed, 345 insertions(+) > > Please get Ralph to review this, otherwise: > > Acked-by: Jason Gunthorpe > > Jason I'm working on it. Thanks for encouragement. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.11 621/775] drm/nouveau/kms: handle mDP connectors
From: Karol Herbst
commit d1f5a3fc85566e9ddce9361ef180f070367e6eab upstream.
In some cases we have the handle those explicitly as the fallback
connector type detection fails and marks those as eDP connectors.
Attempting to use such a connector with mutter leads to a crash of mutter
as it ends up with two eDP displays.
Information is taken from the official DCB documentation.
Cc: sta...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Ben Skeggs
Reported-by: Mark Pearson
Tested-by: Mark Pearson
Signed-off-by: Karol Herbst
Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h |1 +
drivers/gpu/drm/nouveau/nouveau_connector.c |1 +
2 files changed, 2 insertions(+)
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h
@@ -14,6 +14,7 @@ enum dcb_connector_type {
DCB_CONNECTOR_LVDS_SPWG = 0x41,
DCB_CONNECTOR_DP = 0x46,
DCB_CONNECTOR_eDP = 0x47,
+ DCB_CONNECTOR_mDP = 0x48,
DCB_CONNECTOR_HDMI_0 = 0x60,
DCB_CONNECTOR_HDMI_1 = 0x61,
DCB_CONNECTOR_HDMI_C = 0x63,
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1210,6 +1210,7 @@ drm_conntype_from_dcb(enum dcb_connector
case DCB_CONNECTOR_DMS59_DP0:
case DCB_CONNECTOR_DMS59_DP1:
case DCB_CONNECTOR_DP :
+ case DCB_CONNECTOR_mDP :
case DCB_CONNECTOR_USB_C: return DRM_MODE_CONNECTOR_DisplayPort;
case DCB_CONNECTOR_eDP : return DRM_MODE_CONNECTOR_eDP;
case DCB_CONNECTOR_HDMI_0 :
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.11 513/775] drm/msm/dp: Add a missing semi-colon
From: Stephen Boyd
[ Upstream commit 182b4a2d251305201b6f9cae29067f7112f05835 ]
A missing semicolon here causes my external display to stop working.
Indeed, missing the semicolon on the return statement leads to
dp_panel_update_tu_timings() not existing because the compiler thinks
it's part of the return statement of a void function, so it must not be
important.
$ ./scripts/bloat-o-meter before.o after.o
add/remove: 1/1 grow/shrink: 0/1 up/down: 7400/-7540 (-140)
Function old new delta
dp_panel_update_tu_timings -7400 +7400
_dp_ctrl_calc_tu.constprop 18024 17900-124
dp_panel_update_tu_timings.constprop7416 - -7416
Total: Before=54440, After=54300, chg -0.26%
Add a semicolon so this function works like it used to.
Cc: Sean Paul
Cc: Kuogee Hsieh
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: Lee Jones
Fixes: cc9014bf63a4 ("drm/msm/dp/dp_ctrl: Move 'tu' from the stack to the heap")
Signed-off-by: Stephen Boyd
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index e3462f5d96d75..6cbe10af0a7af 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -631,7 +631,7 @@ static void _dp_ctrl_calc_tu(struct dp_tu_calc_input *in,
tu = kzalloc(sizeof(*tu), GFP_KERNEL);
if (!tu)
- return
+ return;
dp_panel_update_tu_timings(in, tu);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 6/8] mm: Selftests for exclusive device memory
On Fri, Feb 26, 2021 at 06:18:30PM +1100, Alistair Popple wrote: > Adds some selftests for exclusive device memory. > > Signed-off-by: Alistair Popple > --- > lib/test_hmm.c | 124 ++ > lib/test_hmm_uapi.h| 2 + > tools/testing/selftests/vm/hmm-tests.c | 219 + > 3 files changed, 345 insertions(+) Please get Ralph to review this, otherwise: Acked-by: Jason Gunthorpe Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/8] mm: Device exclusive memory access
On Fri, Feb 26, 2021 at 06:18:29PM +1100, Alistair Popple wrote: > Some devices require exclusive write access to shared virtual > memory (SVM) ranges to perform atomic operations on that memory. This > requires CPU page tables to be updated to deny access whilst atomic > operations are occurring. > > In order to do this introduce a new swap entry > type (SWP_DEVICE_EXCLUSIVE). When a SVM range needs to be marked for > exclusive access by a device all page table mappings for the particular > range are replaced with device exclusive swap entries. This causes any > CPU access to the page to result in a fault. > > Faults are resovled by replacing the faulting entry with the original > mapping. This results in MMU notifiers being called which a driver uses > to update access permissions such as revoking atomic access. After > notifiers have been called the device will no longer have exclusive > access to the region. This makes alot more sense than the prior versions! I don't know the migration area especially well, but nothing caught my eye in here Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [WARNING] v5.12-rc1 in intel_pipe_disable tracepoint
On Mon, 1 Mar 2021 19:20:59 +0200 Ville Syrjälä wrote: > > ilk_crtc_disable+0x85/0x390 [i915] > > But this part is confusing me. intel_crtc_get_vblank_counter() is > only supposed to do drm_crtc_accurate_vblank_count() fallback when > the hardware lacks a working frame counter, and that should only > be the case for ancient gen2 or semi-ancient i965gm TV output, > ilk_crtc_disable() is not the function we should be calling in > either of those cases. > > What hardware do you have? > According to "lspci -vvv" 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) DeviceName: Onboard VGA Subsystem: Hewlett-Packard Company Device 339a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.11 430/775] kselftests: dmabuf-heaps: Fix Makefiles inclusion of the kernels usr/include dir
From: John Stultz
[ Upstream commit 64ba3d591c9d2be2a9c09e99b00732afe002ad0d ]
Copied in from somewhere else, the makefile was including
the kerne's usr/include dir, which caused the asm/ioctl.h file
to be used.
Unfortunately, that file has different values for _IOC_SIZEBITS
and _IOC_WRITE than include/uapi/asm-generic/ioctl.h which then
causes the _IOCW macros to give the wrong ioctl numbers,
specifically for DMA_BUF_IOCTL_SYNC.
This patch simply removes the extra include from the Makefile
Cc: Shuah Khan
Cc: Brian Starkey
Cc: Sumit Semwal
Cc: Laura Abbott
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kselft...@vger.kernel.org
Fixes: a8779927fd86c ("kselftests: Add dma-heap test")
Signed-off-by: John Stultz
Signed-off-by: Shuah Khan
Signed-off-by: Sasha Levin
---
tools/testing/selftests/dmabuf-heaps/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile
b/tools/testing/selftests/dmabuf-heaps/Makefile
index 607c2acd20829..604b43ece15f5 100644
--- a/tools/testing/selftests/dmabuf-heaps/Makefile
+++ b/tools/testing/selftests/dmabuf-heaps/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-CFLAGS += -static -O3 -Wl,-no-as-needed -Wall -I../../../../usr/include
+CFLAGS += -static -O3 -Wl,-no-as-needed -Wall
TEST_GEN_PROGS = dmabuf-heap
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/8] mm/swapops: Rework swap entry manipulation code
On Fri, Feb 26, 2021 at 06:18:26PM +1100, Alistair Popple wrote: > Both migration and device private pages use special swap entries which > are manipluated by a range of inline functions. The arguments to these > are somewhat inconsitent so rework them to remove flag type arguments > and to make the arguments similar for both a read and write entry > creation. > > Signed-off-by: Alistair Popple > --- > include/linux/swapops.h | 56 ++--- > mm/debug_vm_pgtable.c | 12 - > mm/hmm.c| 2 +- > mm/huge_memory.c| 26 +-- > mm/hugetlb.c| 10 +--- > mm/memory.c | 10 +--- > mm/migrate.c| 26 ++- > mm/mprotect.c | 10 +--- > mm/rmap.c | 10 +--- > 9 files changed, 100 insertions(+), 62 deletions(-) Reviewed-by: Jason Gunthorpe ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/8] mm: Remove special swap entry functions
On Fri, Feb 26, 2021 at 06:18:25PM +1100, Alistair Popple wrote:
> Remove the migration and device private entry_to_page() and
> entry_to_pfn() inline functions and instead open code them directly.
> This results in shorter code which is easier to understand.
>
> Signed-off-by: Alistair Popple
> ---
> arch/s390/mm/pgtable.c | 2 +-
> fs/proc/task_mmu.c | 23 +++
> include/linux/swap.h| 4 ++--
> include/linux/swapops.h | 51 -
> mm/hmm.c| 5 ++--
> mm/memcontrol.c | 2 +-
> mm/memory.c | 10
> mm/migrate.c| 6 ++---
> mm/page_vma_mapped.c| 6 ++---
> 9 files changed, 30 insertions(+), 79 deletions(-)
I wish you could come up with a more descriptive word that special
here
What I understand is this is true when the swap_offset is a pfn?
> -static inline struct page *migration_entry_to_page(swp_entry_t entry)
> -{
> - struct page *p = pfn_to_page(swp_offset(entry));
> - /*
> - * Any use of migration entries may only occur while the
> - * corresponding page is locked
> - */
> - BUG_ON(!PageLocked(compound_head(p)));
> - return p;
And this constraint has been completely lost?
A comment in front of the is_special_entry explaining all the rule
would help alot
Transformation looks fine otherwise
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.11 168/775] fbdev: aty: SPARC64 requires FB_ATY_CT
From: Randy Dunlap
[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prevent build errors.
As it currently is, FB_ATY_CT can be disabled, resulting in build
errors:
ERROR: modpost: "aty_postdividers" [drivers/video/fbdev/aty/atyfb.ko] undefined!
ERROR: modpost: "aty_ld_pll_ct" [drivers/video/fbdev/aty/atyfb.ko] undefined!
Reviewed-by: Geert Uytterhoeven
Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
Signed-off-by: Randy Dunlap
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Cc: Tomi Valkeinen
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: Daniel Vetter
Cc: David Airlie
Cc: Bartlomiej Zolnierkiewicz
Cc: Geert Uytterhoeven
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20201127031752.10371-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index cfb7f5612ef0f..4f02db65dedec 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1269,6 +1269,7 @@ config FB_ATY
select FB_CFB_IMAGEBLIT
select FB_BACKLIGHT if FB_ATY_BACKLIGHT
select FB_MACMODES if PPC
+ select FB_ATY_CT if SPARC64 && PCI
help
This driver supports graphics boards with the ATI Mach64 chips.
Say Y if you have such a graphics board.
@@ -1279,7 +1280,6 @@ config FB_ATY
config FB_ATY_CT
bool "Mach64 CT/VT/GT/LT (incl. 3D RAGE) support"
depends on PCI && FB_ATY
- default y if SPARC64 && PCI
help
Say Y here to support use of ATI's 64-bit Rage boards (or other
boards based on the Mach64 CT, VT, GT, and LT chipsets) as a
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208115] amdgpu (likely) - power management and display connection problems with an RX590 card
https://bugzilla.kernel.org/show_bug.cgi?id=208115 --- Comment #3 from Adarion from userland (h_mailingli...@posteo.de) --- A little (and very late, sorry, but I have a v. stressful "real life") update from my side. I recently found the time to plug the RX 590 back into the Zen+ setup. (was running with the HD 5450 (radeonhd) meanwhile) I am on kernel 5.10.x / 5.11. there, recent libdrm, mesa etc.; most recent BIOS I could obtain for the MSI B350 PCMate. I did plug the DP cable into a different port this time. I need to test thoroughly, but now I am on something that seems normal! Screen wakeup seems okay so far, it wakes up from power saving (BACO?), an regains the screen control correctly, without resolution drop or distortion. Full operable. S2Ram works incl. wakeup (tested once only yet, but that gave me hope). And: wall power measurement looks as expected: 51... 55 watts for the whole box. This is on par with the HD 5450 and as I would expect it to be on idle. I'll keep an eye on it, esp. once I start using it as my main box (so far it was mostly used for chroot compiling Gentoo intallations and occasional video encoding), but maybe things have settled? It's sad that I don't know the real reason for the change (different DP port on GPU side? kernel update (PM things should be in the kernel so I don't think it's mesa related), mainboard BIOS update?). If I find the time I'll test it on different mainboards and I'll try to find out if the GPU-side video output port has an influence on behaviour. (But I have very full weeks ahead.) -- You may reply to this email to add a comment. 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
[PATCH] drm/amdgpu: Verify bo size can fit framebuffer size
When creating a new framebuffer, verify that the bo size associated with
it can handle the fb size.
drm_gem_fb_init_with_funcs implements this check by calculating the
minimum expected size of each plane. amdgpu now uses this function to
initialize its fb as it performs the required checks.
The bug was caught using igt-gpu-tools test: kms_addfb_basic.too-high
and kms_addfb_basic.bo-too-small
Suggested-by: Sean Paul
Cc: Alex Deucher
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 8 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 1 +
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 48cb33e5b3826..61684d543b8ef 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -872,13 +872,14 @@ static int amdgpu_display_get_fb_info(const struct
amdgpu_framebuffer *amdgpu_fb
int amdgpu_display_framebuffer_init(struct drm_device *dev,
struct amdgpu_framebuffer *rfb,
+ struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_object *obj)
{
int ret, i;
rfb->base.obj[0] = obj;
- drm_helper_mode_fill_fb_struct(dev, >base, mode_cmd);
- ret = drm_framebuffer_init(dev, >base, _fb_funcs);
+ ret = drm_gem_fb_init_with_funcs(dev, >base, file, mode_cmd,
+_fb_funcs);
if (ret)
goto fail;
@@ -953,7 +954,8 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
return ERR_PTR(-ENOMEM);
}
- ret = amdgpu_display_framebuffer_init(dev, amdgpu_fb, mode_cmd, obj);
+ ret = amdgpu_display_framebuffer_init(dev, amdgpu_fb, file_priv,
+ mode_cmd, obj);
if (ret) {
kfree(amdgpu_fb);
drm_gem_object_put(obj);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 0bf7d36c6686d..2b9c9a621c437 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -233,7 +233,8 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
}
ret = amdgpu_display_framebuffer_init(adev_to_drm(adev), >rfb,
- _cmd, gobj);
+ helper->client.file, _cmd,
+ gobj);
if (ret) {
DRM_ERROR("failed to initialize framebuffer %d\n", ret);
goto out;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index 319cb19e1b99f..997b93674955e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -604,6 +604,7 @@ int amdgpu_display_get_crtc_scanoutpos(struct drm_device
*dev,
int amdgpu_display_framebuffer_init(struct drm_device *dev,
struct amdgpu_framebuffer *rfb,
+ struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_object *obj);
--
2.30.1.766.gb4fecdf3b7-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gem: add checks of drm_gem_object->funcs
+ Andrey
On Mon, Mar 1, 2021 at 5:25 AM Christian König
wrote:
>
>
>
> Am 01.03.21 um 11:04 schrieb Daniel Vetter:
> > On Mon, Mar 1, 2021 at 10:56 AM Thomas Zimmermann
> > wrote:
> >> (cc'ing amd devs)
> >>
> >> Hi
> >>
> >> Am 28.02.21 um 17:10 schrieb Pavel Turinský:
> >>> The checks were removed in commit d693def4fd1c ("drm: Remove obsolete GEM
> >>> and PRIME callbacks from struct drm_driver") and can lead to following
> >>> kernel oops:
> >> Thanks for reporting. All drivers are supposed to set the funcs pointer
> >> in their GEM objects. This looks like a radeon bug. Adding the AMD devs.
> > Looks like we're setting obj->funcs only in radeon_gem_object_create,
> > but should set it in radeon_bo_create instead so it catches internal
> > functions too. I think this was missed in
> >
> > commit ce77038fdae385f947757a37573d90f2e83f0271
> > Author: Gerd Hoffmann
> > Date: Mon Aug 5 16:01:06 2019 +0200
> >
> > drm/radeon: use embedded gem object
>
> Maybe the same problem we had for amdgpu that the function pointer
> wasn't set for imported DMA-bufs?
Perhaps radeon needs some variant of this patch?
commit f8aab60422c371425365d386dfd51e0c6c5b1041
Author: Andrey Grodzovsky
Date: Tue Dec 8 15:16:15 2020 -0500
drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs
For BOs imported from outside of amdgpu, setting of amdgpu_gem_object_funcs
was missing in amdgpu_dma_buf_create_obj. Fix by refactoring BO creation
and amdgpu_gem_object_funcs setting into single function called
from both code paths.
Fixes: d693def4fd1c ("drm: Remove obsolete GEM and PRIME callbacks
from struct drm_driver")
v2: Use use amdgpu_gem_object_create() directly
v3: fix warning
Reviewed-by: Christian König
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
>
> Regards,
> Christian.
>
> >
> > Adding Gerd.
> > -Daniel
> >
> >> Best regards
> >> Thomas
> >>
> >>> [ 139.449098] BUG: kernel NULL pointer dereference, address:
> >>> 0008
> >>> [ 139.449110] #PF: supervisor read access in kernel mode
> >>> [ 139.449113] #PF: error_code(0x) - not-present page
> >>> [ 139.449116] PGD 0 P4D 0
> >>> [ 139.449121] Oops: [#1] PREEMPT SMP PTI
> >>> [ 139.449126] CPU: 4 PID: 1181 Comm: Xorg Not tainted 5.11.2LEdoian #2
> >>> [ 139.449130] Hardware name: Gigabyte Technology Co., Ltd. To be filled
> >>> by O.E.M./Z77-DS3H, BIOS F4 04/25/2012
> >>> [ 139.449133] RIP: 0010:drm_gem_handle_create_tail+0xcb/0x190 [drm]
> >>> [ 139.449185] Code: 00 48 89 ef e8 06 b4 49 f7 45 85 e4 78 77 48 8d 6b
> >>> 18 4c 89 ee 48 89 ef e8 c2 f5 00 00 89 c2 85 c0 75 3e 48 8b 83 40 01 00
> >>> 00 <48> 8b 40 0
> >>> 8 48 85 c0 74 0f 4c 89 ee 48 89 df e8 71 5d 87 f7 85 c0
> >>> [ 139.449190] RSP: 0018:be21c194bd28 EFLAGS: 00010246
> >>> [ 139.449194] RAX: RBX: 9da9b3caf078 RCX:
> >>>
> >>> [ 139.449197] RDX: RSI: c039b893 RDI:
> >>>
> >>> [ 139.449199] RBP: 9da9b3caf090 R08: 0040 R09:
> >>> 9da983b911c0
> >>> [ 139.449202] R10: 9da984749e00 R11: 9da9859bfc38 R12:
> >>> 0007
> >>> [ 139.449204] R13: 9da9859bfc00 R14: 9da9859bfc50 R15:
> >>> 9da9859bfc38
> >>> [ 139.449207] FS: 7f6332a56900() GS:9daea7b0()
> >>> knlGS:
> >>> [ 139.449211] CS: 0010 DS: ES: CR0: 80050033
> >>> [ 139.449214] CR2: 0008 CR3: 0001319b8005 CR4:
> >>> 001706e0
> >>> [ 139.449217] Call Trace:
> >>> [ 139.449224] drm_gem_prime_fd_to_handle+0xff/0x1d0 [drm]
> >>> [ 139.449274] ? drm_prime_destroy_file_private+0x20/0x20 [drm]
> >>> [ 139.449323] drm_ioctl_kernel+0xac/0xf0 [drm]
> >>> [ 139.449363] drm_ioctl+0x20f/0x3b0 [drm]
> >>> [ 139.449403] ? drm_prime_destroy_file_private+0x20/0x20 [drm]
> >>> [ 139.449454] radeon_drm_ioctl+0x49/0x80 [radeon]
> >>> [ 139.449500] __x64_sys_ioctl+0x84/0xc0
> >>> [ 139.449507] do_syscall_64+0x33/0x40
> >>> [ 139.449514] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >>> [ 139.449522] RIP: 0033:0x7f63330fbe6b
> >>> [ 139.449526] Code: ff ff ff 85 c0 79 8b 49 c7 c4 ff ff ff ff 5b 5d 4c
> >>> 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f
> >>> 05 <48> 3d 01 f
> >>> 0 ff ff 73 01 c3 48 8b 0d d5 af 0c 00 f7 d8 64 89 01 48
> >>> [ 139.449529] RSP: 002b:7fff1e9c4438 EFLAGS: 0246 ORIG_RAX:
> >>> 0010
> >>> [ 139.449534] RAX: ffda RBX: 7fff1e9c447c RCX:
> >>> 7f63330fbe6b
> >>> [ 139.449537] RDX: 7fff1e9c447c RSI: c00c642e RDI:
> >>> 0012
> >>> [ 139.449539] RBP: c00c642e R08: 7fff1e9c4520 R09:
> >>> 7f63331c7a60
> >>> [ 139.449542] R10: 7f6329fb9ab0 R11: 0246 R12:
> >>> 55f69810ad40
> >>> [ 139.449544] R13: 0012 R14: 0010 R15:
>
[PATCH 5.10 518/663] drm/nouveau/kms: handle mDP connectors
From: Karol Herbst
commit d1f5a3fc85566e9ddce9361ef180f070367e6eab upstream.
In some cases we have the handle those explicitly as the fallback
connector type detection fails and marks those as eDP connectors.
Attempting to use such a connector with mutter leads to a crash of mutter
as it ends up with two eDP displays.
Information is taken from the official DCB documentation.
Cc: sta...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Ben Skeggs
Reported-by: Mark Pearson
Tested-by: Mark Pearson
Signed-off-by: Karol Herbst
Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h |1 +
drivers/gpu/drm/nouveau/nouveau_connector.c |1 +
2 files changed, 2 insertions(+)
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h
@@ -14,6 +14,7 @@ enum dcb_connector_type {
DCB_CONNECTOR_LVDS_SPWG = 0x41,
DCB_CONNECTOR_DP = 0x46,
DCB_CONNECTOR_eDP = 0x47,
+ DCB_CONNECTOR_mDP = 0x48,
DCB_CONNECTOR_HDMI_0 = 0x60,
DCB_CONNECTOR_HDMI_1 = 0x61,
DCB_CONNECTOR_HDMI_C = 0x63,
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1210,6 +1210,7 @@ drm_conntype_from_dcb(enum dcb_connector
case DCB_CONNECTOR_DMS59_DP0:
case DCB_CONNECTOR_DMS59_DP1:
case DCB_CONNECTOR_DP :
+ case DCB_CONNECTOR_mDP :
case DCB_CONNECTOR_USB_C: return DRM_MODE_CONNECTOR_DisplayPort;
case DCB_CONNECTOR_eDP : return DRM_MODE_CONNECTOR_eDP;
case DCB_CONNECTOR_HDMI_0 :
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [WARNING] v5.12-rc1 in intel_pipe_disable tracepoint
On Mon, Mar 01, 2021 at 11:59:46AM -0500, Steven Rostedt wrote: > > On my test box with latest v5.12-rc1, running with all trace events > enabled, I consistently trigger this warning. > > It appears to get triggered by the trace_intel_pipe_disable() code. > > -- Steve > > [ cut here ] > i915 :00:02.0: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev)) > WARNING: CPU: 7 PID: 1258 at drivers/gpu/drm/drm_vblank.c:728 > drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x319/0x330 [drm] > Modules linked in: ebtable_filter ebtables bridge stp llc vsock vmw_vmci > ipt_REJECT nf_reject_ipv4 iptable_filter ip6t_REJECT nf_reject_ipv6 xt_state > xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6table_filter > ip6_tables snd_hda_codec_hdmi snd_h > ek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg > snd_hda_codec joydev snd_hwdep intel_rapl_msr snd_hda_core hp_wmi i915 > iTCO_wdt snd_seq intel_rapl_common iTCO_vendor_support wmi_bmof sparse_keymap > snd_seq_device rfkill snd_pcm x86_pkg_t > d_timer i2c_algo_bit drm_kms_helper mei_me intel_powerclamp snd mei soundcore > i2c_i801 drm coretemp lpc_ich e1000e kvm_intel i2c_smbus kvm irqbypass > crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel > video tpm_infineon wmi ip_tables > CPU: 7 PID: 1258 Comm: Xorg Tainted: GW 5.12.0-rc1-test+ #12 > Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 > 07/14/2016 > RIP: 0010:drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x319/0x330 > [drm] > Code: 4c 8b 6f 50 4d 85 ed 75 03 4c 8b 2f e8 60 92 45 c2 48 c7 c1 28 a5 3c > c0 4c 89 ea 48 c7 c7 15 5a 3c c0 48 89 c6 e8 1f e7 7b c2 <0f> 0b e9 e2 fe ff > ff e8 fb 6c 81 c2 66 66 2e 0f 1f 84 00 00 00 00 > RSP: 0018:b77580ea7920 EFLAGS: 00010082 > RAX: RBX: 8afe500c RCX: > RDX: 0004 RSI: 833c86b8 RDI: 0001 > RBP: b77580ea7990 R08: 00700c782173 R09: > R10: 0001 R11: 0001 R12: > R13: 8afe41c7eff0 R14: c05e0410 R15: 8afe456a2bf8 > FS: 7f8f91869f00() GS:8afe5aa0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7f9523a6cad0 CR3: 01b78002 CR4: 001706e0 > Call Trace: > drm_get_last_vbltimestamp+0xaa/0xc0 [drm] > drm_update_vblank_count+0x90/0x2d0 [drm] > drm_crtc_accurate_vblank_count+0x3e/0xc0 [drm] > intel_crtc_get_vblank_counter+0x43/0x50 [i915] > trace_event_raw_event_intel_pipe_disable+0x87/0x110 [i915] > intel_disable_pipe+0x1a8/0x210 [i915] Hmm. Yeah we do vblank_off() before pipe_disable() which wants to still grab the frame counter in the tracepoint. I think we could reorder those two without causing any problems. Either that or we put the tracepoint before vblank_off(). > ilk_crtc_disable+0x85/0x390 [i915] But this part is confusing me. intel_crtc_get_vblank_counter() is only supposed to do drm_crtc_accurate_vblank_count() fallback when the hardware lacks a working frame counter, and that should only be the case for ancient gen2 or semi-ancient i965gm TV output, ilk_crtc_disable() is not the function we should be calling in either of those cases. What hardware do you have? > intel_old_crtc_state_disables.isra.0+0x5c/0x110 [i915] > intel_atomic_commit_tail+0xf5d/0x1460 [i915] > ? complete+0x18/0x40 > intel_atomic_commit+0x345/0x3c0 [i915] > drm_atomic_connector_commit_dpms+0xd7/0x100 [drm] > set_property_atomic+0xcc/0x160 [drm] > drm_mode_obj_set_property_ioctl+0xbd/0x100 [drm] > ? drm_connector_set_obj_prop+0x90/0x90 [drm] > drm_connector_property_set_ioctl+0x39/0x60 [drm] > drm_ioctl_kernel+0xad/0x100 [drm] > drm_ioctl+0x1ec/0x390 [drm] > ? drm_connector_set_obj_prop+0x90/0x90 [drm] > ? sched_clock_cpu+0x10/0xd0 > ? lock_release+0x155/0x410 > __x64_sys_ioctl+0x83/0xb0 > do_syscall_64+0x33/0x40 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x7f8f91ce535b > Code: 0f 1e fa 48 8b 05 2d 9b 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff > ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff > 73 01 c3 48 8b 0d fd 9a 0c 00 f7 d8 64 89 01 48 > RSP: 002b:7ffcb4603378 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 7ffcb46033b0 RCX: 7f8f91ce535b > RDX: 7ffcb46033b0 RSI: c01064ab RDI: 000e > RBP: c01064ab R08: 55d68f44ba60 R09: > R10: 55d68f44ba60 R11: 0246 R12: 55d68f5e0010 > R13: 000e R14: R15: 55d68e2275c0 > ---[ end trace d18216ba28a2f0e8 ]--- > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel
[PATCH 5.10 355/663] kselftests: dmabuf-heaps: Fix Makefiles inclusion of the kernels usr/include dir
From: John Stultz
[ Upstream commit 64ba3d591c9d2be2a9c09e99b00732afe002ad0d ]
Copied in from somewhere else, the makefile was including
the kerne's usr/include dir, which caused the asm/ioctl.h file
to be used.
Unfortunately, that file has different values for _IOC_SIZEBITS
and _IOC_WRITE than include/uapi/asm-generic/ioctl.h which then
causes the _IOCW macros to give the wrong ioctl numbers,
specifically for DMA_BUF_IOCTL_SYNC.
This patch simply removes the extra include from the Makefile
Cc: Shuah Khan
Cc: Brian Starkey
Cc: Sumit Semwal
Cc: Laura Abbott
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kselft...@vger.kernel.org
Fixes: a8779927fd86c ("kselftests: Add dma-heap test")
Signed-off-by: John Stultz
Signed-off-by: Shuah Khan
Signed-off-by: Sasha Levin
---
tools/testing/selftests/dmabuf-heaps/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile
b/tools/testing/selftests/dmabuf-heaps/Makefile
index 607c2acd20829..604b43ece15f5 100644
--- a/tools/testing/selftests/dmabuf-heaps/Makefile
+++ b/tools/testing/selftests/dmabuf-heaps/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-CFLAGS += -static -O3 -Wl,-no-as-needed -Wall -I../../../../usr/include
+CFLAGS += -static -O3 -Wl,-no-as-needed -Wall
TEST_GEN_PROGS = dmabuf-heap
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.10 138/663] fbdev: aty: SPARC64 requires FB_ATY_CT
From: Randy Dunlap
[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prevent build errors.
As it currently is, FB_ATY_CT can be disabled, resulting in build
errors:
ERROR: modpost: "aty_postdividers" [drivers/video/fbdev/aty/atyfb.ko] undefined!
ERROR: modpost: "aty_ld_pll_ct" [drivers/video/fbdev/aty/atyfb.ko] undefined!
Reviewed-by: Geert Uytterhoeven
Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
Signed-off-by: Randy Dunlap
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Cc: Tomi Valkeinen
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: Daniel Vetter
Cc: David Airlie
Cc: Bartlomiej Zolnierkiewicz
Cc: Geert Uytterhoeven
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20201127031752.10371-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index cfb7f5612ef0f..4f02db65dedec 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1269,6 +1269,7 @@ config FB_ATY
select FB_CFB_IMAGEBLIT
select FB_BACKLIGHT if FB_ATY_BACKLIGHT
select FB_MACMODES if PPC
+ select FB_ATY_CT if SPARC64 && PCI
help
This driver supports graphics boards with the ATI Mach64 chips.
Say Y if you have such a graphics board.
@@ -1279,7 +1280,6 @@ config FB_ATY
config FB_ATY_CT
bool "Mach64 CT/VT/GT/LT (incl. 3D RAGE) support"
depends on PCI && FB_ATY
- default y if SPARC64 && PCI
help
Say Y here to support use of ATI's 64-bit Rage boards (or other
boards based on the Mach64 CT, VT, GT, and LT chipsets) as a
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.4 259/340] drm/nouveau/kms: handle mDP connectors
From: Karol Herbst
commit d1f5a3fc85566e9ddce9361ef180f070367e6eab upstream.
In some cases we have the handle those explicitly as the fallback
connector type detection fails and marks those as eDP connectors.
Attempting to use such a connector with mutter leads to a crash of mutter
as it ends up with two eDP displays.
Information is taken from the official DCB documentation.
Cc: sta...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Ben Skeggs
Reported-by: Mark Pearson
Tested-by: Mark Pearson
Signed-off-by: Karol Herbst
Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h |1 +
drivers/gpu/drm/nouveau/nouveau_connector.c |1 +
2 files changed, 2 insertions(+)
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h
@@ -14,6 +14,7 @@ enum dcb_connector_type {
DCB_CONNECTOR_LVDS_SPWG = 0x41,
DCB_CONNECTOR_DP = 0x46,
DCB_CONNECTOR_eDP = 0x47,
+ DCB_CONNECTOR_mDP = 0x48,
DCB_CONNECTOR_HDMI_0 = 0x60,
DCB_CONNECTOR_HDMI_1 = 0x61,
DCB_CONNECTOR_HDMI_C = 0x63,
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1240,6 +1240,7 @@ drm_conntype_from_dcb(enum dcb_connector
case DCB_CONNECTOR_DMS59_DP0:
case DCB_CONNECTOR_DMS59_DP1:
case DCB_CONNECTOR_DP :
+ case DCB_CONNECTOR_mDP :
case DCB_CONNECTOR_USB_C: return DRM_MODE_CONNECTOR_DisplayPort;
case DCB_CONNECTOR_eDP : return DRM_MODE_CONNECTOR_eDP;
case DCB_CONNECTOR_HDMI_0 :
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[WARNING] v5.12-rc1 in intel_pipe_disable tracepoint
On my test box with latest v5.12-rc1, running with all trace events enabled, I consistently trigger this warning. It appears to get triggered by the trace_intel_pipe_disable() code. -- Steve [ cut here ] i915 :00:02.0: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev)) WARNING: CPU: 7 PID: 1258 at drivers/gpu/drm/drm_vblank.c:728 drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x319/0x330 [drm] Modules linked in: ebtable_filter ebtables bridge stp llc vsock vmw_vmci ipt_REJECT nf_reject_ipv4 iptable_filter ip6t_REJECT nf_reject_ipv6 xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6table_filter ip6_tables snd_hda_codec_hdmi snd_h ek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg snd_hda_codec joydev snd_hwdep intel_rapl_msr snd_hda_core hp_wmi i915 iTCO_wdt snd_seq intel_rapl_common iTCO_vendor_support wmi_bmof sparse_keymap snd_seq_device rfkill snd_pcm x86_pkg_t d_timer i2c_algo_bit drm_kms_helper mei_me intel_powerclamp snd mei soundcore i2c_i801 drm coretemp lpc_ich e1000e kvm_intel i2c_smbus kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel video tpm_infineon wmi ip_tables CPU: 7 PID: 1258 Comm: Xorg Tainted: GW 5.12.0-rc1-test+ #12 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x319/0x330 [drm] Code: 4c 8b 6f 50 4d 85 ed 75 03 4c 8b 2f e8 60 92 45 c2 48 c7 c1 28 a5 3c c0 4c 89 ea 48 c7 c7 15 5a 3c c0 48 89 c6 e8 1f e7 7b c2 <0f> 0b e9 e2 fe ff ff e8 fb 6c 81 c2 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:b77580ea7920 EFLAGS: 00010082 RAX: RBX: 8afe500c RCX: RDX: 0004 RSI: 833c86b8 RDI: 0001 RBP: b77580ea7990 R08: 00700c782173 R09: R10: 0001 R11: 0001 R12: R13: 8afe41c7eff0 R14: c05e0410 R15: 8afe456a2bf8 FS: 7f8f91869f00() GS:8afe5aa0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f9523a6cad0 CR3: 01b78002 CR4: 001706e0 Call Trace: drm_get_last_vbltimestamp+0xaa/0xc0 [drm] drm_update_vblank_count+0x90/0x2d0 [drm] drm_crtc_accurate_vblank_count+0x3e/0xc0 [drm] intel_crtc_get_vblank_counter+0x43/0x50 [i915] trace_event_raw_event_intel_pipe_disable+0x87/0x110 [i915] intel_disable_pipe+0x1a8/0x210 [i915] ilk_crtc_disable+0x85/0x390 [i915] intel_old_crtc_state_disables.isra.0+0x5c/0x110 [i915] intel_atomic_commit_tail+0xf5d/0x1460 [i915] ? complete+0x18/0x40 intel_atomic_commit+0x345/0x3c0 [i915] drm_atomic_connector_commit_dpms+0xd7/0x100 [drm] set_property_atomic+0xcc/0x160 [drm] drm_mode_obj_set_property_ioctl+0xbd/0x100 [drm] ? drm_connector_set_obj_prop+0x90/0x90 [drm] drm_connector_property_set_ioctl+0x39/0x60 [drm] drm_ioctl_kernel+0xad/0x100 [drm] drm_ioctl+0x1ec/0x390 [drm] ? drm_connector_set_obj_prop+0x90/0x90 [drm] ? sched_clock_cpu+0x10/0xd0 ? lock_release+0x155/0x410 __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f8f91ce535b Code: 0f 1e fa 48 8b 05 2d 9b 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d fd 9a 0c 00 f7 d8 64 89 01 48 RSP: 002b:7ffcb4603378 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 7ffcb46033b0 RCX: 7f8f91ce535b RDX: 7ffcb46033b0 RSI: c01064ab RDI: 000e RBP: c01064ab R08: 55d68f44ba60 R09: R10: 55d68f44ba60 R11: 0246 R12: 55d68f5e0010 R13: 000e R14: R15: 55d68e2275c0 ---[ end trace d18216ba28a2f0e8 ]--- ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.4 070/340] fbdev: aty: SPARC64 requires FB_ATY_CT
From: Randy Dunlap
[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prevent build errors.
As it currently is, FB_ATY_CT can be disabled, resulting in build
errors:
ERROR: modpost: "aty_postdividers" [drivers/video/fbdev/aty/atyfb.ko] undefined!
ERROR: modpost: "aty_ld_pll_ct" [drivers/video/fbdev/aty/atyfb.ko] undefined!
Reviewed-by: Geert Uytterhoeven
Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
Signed-off-by: Randy Dunlap
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Cc: Tomi Valkeinen
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: Daniel Vetter
Cc: David Airlie
Cc: Bartlomiej Zolnierkiewicz
Cc: Geert Uytterhoeven
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20201127031752.10371-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 1e70e838530ee..a7e5f12687b70 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1269,6 +1269,7 @@ config FB_ATY
select FB_CFB_IMAGEBLIT
select FB_BACKLIGHT if FB_ATY_BACKLIGHT
select FB_MACMODES if PPC
+ select FB_ATY_CT if SPARC64 && PCI
help
This driver supports graphics boards with the ATI Mach64 chips.
Say Y if you have such a graphics board.
@@ -1279,7 +1280,6 @@ config FB_ATY
config FB_ATY_CT
bool "Mach64 CT/VT/GT/LT (incl. 3D RAGE) support"
depends on PCI && FB_ATY
- default y if SPARC64 && PCI
help
Say Y here to support use of ATI's 64-bit Rage boards (or other
boards based on the Mach64 CT, VT, GT, and LT chipsets) as a
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 2/2] backlight: qcom-wled: Correct the sync_toggle sequence
On 2021-03-01 15:32, Daniel Thompson wrote: On Mon, Mar 01, 2021 at 02:58:36PM +0530, Kiran Gunda wrote: As per the current implementation, after FSC (Full Scale Current) and brightness update the sync bits are transitioned from set-then-clear. This does not makes sense since there are too many verbs. Set and clear are both verbs so in this context: "the code will set the bit and then the code will clear the bit". Either: s/transitioned from set-then-clear/set-then-cleared/. Or: s/transitioned from set-then-clear/using a set-then-clear approach/. But, the FSC and brightness sync takes place during a clear-then-set transition of the sync bits. Likewise this no longer makes sense and had also become misleading. Two changes of state, clear and then set, do not usually result in a single transition. Either: s/clear-then-set/0 to 1/ Alternatively, if you want to stick exclusively to the set/clear terminology then replace the whole quoted section with: But, the FSC and brightness sync takes place when the sync bits are set (e.g. on a rising edge). So the hardware team recommends a clear-then-set approach in order to guarantee such a transition regardless of the previous register state. Signed-off-by: Kiran Gunda With one of each of the changes proposed above: Reviewed-by: Daniel Thompson Daniel. Apologies for the mistake. I have corrected and submitted the V4 series with the "reviewed-by" tag. --- drivers/video/backlight/qcom-wled.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c index aef52b9..19f83ac 100644 --- a/drivers/video/backlight/qcom-wled.c +++ b/drivers/video/backlight/qcom-wled.c @@ -337,13 +337,13 @@ static int wled3_sync_toggle(struct wled *wled) rc = regmap_update_bits(wled->regmap, wled->ctrl_addr + WLED3_SINK_REG_SYNC, - mask, mask); + mask, WLED3_SINK_REG_SYNC_CLEAR); if (rc < 0) return rc; rc = regmap_update_bits(wled->regmap, wled->ctrl_addr + WLED3_SINK_REG_SYNC, - mask, WLED3_SINK_REG_SYNC_CLEAR); + mask, mask); return rc; } @@ -353,17 +353,17 @@ static int wled5_mod_sync_toggle(struct wled *wled) int rc; u8 val; - val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT : -WLED5_SINK_REG_SYNC_MOD_B_BIT; rc = regmap_update_bits(wled->regmap, wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT, - WLED5_SINK_REG_SYNC_MASK, val); + WLED5_SINK_REG_SYNC_MASK, 0); if (rc < 0) return rc; + val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT : +WLED5_SINK_REG_SYNC_MOD_B_BIT; return regmap_update_bits(wled->regmap, wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT, - WLED5_SINK_REG_SYNC_MASK, 0); + WLED5_SINK_REG_SYNC_MASK, val); } static int wled_ovp_fault_status(struct wled *wled, bool *fault_set) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.19 073/247] fbdev: aty: SPARC64 requires FB_ATY_CT
From: Randy Dunlap
[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prevent build errors.
As it currently is, FB_ATY_CT can be disabled, resulting in build
errors:
ERROR: modpost: "aty_postdividers" [drivers/video/fbdev/aty/atyfb.ko] undefined!
ERROR: modpost: "aty_ld_pll_ct" [drivers/video/fbdev/aty/atyfb.ko] undefined!
Reviewed-by: Geert Uytterhoeven
Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
Signed-off-by: Randy Dunlap
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Cc: Tomi Valkeinen
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: Daniel Vetter
Cc: David Airlie
Cc: Bartlomiej Zolnierkiewicz
Cc: Geert Uytterhoeven
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20201127031752.10371-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index f99558d006bf4..97c4319797d5c 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1303,6 +1303,7 @@ config FB_ATY
select FB_CFB_IMAGEBLIT
select FB_BACKLIGHT if FB_ATY_BACKLIGHT
select FB_MACMODES if PPC
+ select FB_ATY_CT if SPARC64 && PCI
help
This driver supports graphics boards with the ATI Mach64 chips.
Say Y if you have such a graphics board.
@@ -1313,7 +1314,6 @@ config FB_ATY
config FB_ATY_CT
bool "Mach64 CT/VT/GT/LT (incl. 3D RAGE) support"
depends on PCI && FB_ATY
- default y if SPARC64 && PCI
help
Say Y here to support use of ATI's 64-bit Rage boards (or other
boards based on the Mach64 CT, VT, GT, and LT chipsets) as a
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.14 041/176] fbdev: aty: SPARC64 requires FB_ATY_CT
From: Randy Dunlap
[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prevent build errors.
As it currently is, FB_ATY_CT can be disabled, resulting in build
errors:
ERROR: modpost: "aty_postdividers" [drivers/video/fbdev/aty/atyfb.ko] undefined!
ERROR: modpost: "aty_ld_pll_ct" [drivers/video/fbdev/aty/atyfb.ko] undefined!
Reviewed-by: Geert Uytterhoeven
Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
Signed-off-by: Randy Dunlap
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Cc: Tomi Valkeinen
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: Daniel Vetter
Cc: David Airlie
Cc: Bartlomiej Zolnierkiewicz
Cc: Geert Uytterhoeven
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20201127031752.10371-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 5e58f5ec0a28e..d00588d9b0258 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1411,6 +1411,7 @@ config FB_ATY
select FB_CFB_IMAGEBLIT
select FB_BACKLIGHT if FB_ATY_BACKLIGHT
select FB_MACMODES if PPC
+ select FB_ATY_CT if SPARC64 && PCI
help
This driver supports graphics boards with the ATI Mach64 chips.
Say Y if you have such a graphics board.
@@ -1421,7 +1422,6 @@ config FB_ATY
config FB_ATY_CT
bool "Mach64 CT/VT/GT/LT (incl. 3D RAGE) support"
depends on PCI && FB_ATY
- default y if SPARC64 && PCI
help
Say Y here to support use of ATI's 64-bit Rage boards (or other
boards based on the Mach64 CT, VT, GT, and LT chipsets) as a
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP
Hi Parshuram, On Mon, Mar 01, 2021 at 04:14:54PM +, Parshuram Raju Thombare wrote: > Hi Laurent, > > > Is this a property of the hardware, that is, are there multiple versions > > of this IP core covered by the same compatible string that support HDCP > > 1.4 only, DHCP 2.2 only or both ? Or is it a way to select what a given > > system will offer ?[] > > MHDP hardware supports both HDCP 2.2 and 1.4. So, this is a way > to select the version of HDCP, system wish to support. Then I'm not sure this qualifies as a DT property, which should describe the system, not configure it. A way for userspace to configure this would be better. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm/omap: hdmi4: switch to the cec bridge ops
Hi Hans,
On Mon, Mar 01, 2021 at 12:07:56PM +0100, Hans Verkuil wrote:
> On 19/02/2021 13:07, Laurent Pinchart wrote:
> > On Thu, Feb 11, 2021 at 11:37:00AM +0100, Hans Verkuil wrote:
> >> Implement the new CEC bridge ops. This makes it possible to associate
> >> a CEC adapter with a drm connector, which helps userspace determine
> >> with cec device node belongs to which drm connector.
> >>
> >> Signed-off-by: Hans Verkuil
> >> ---
> >> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 28 +
> >> drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 8 ---
> >> drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h | 7 ---
> >> 3 files changed, 28 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> >> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> >> index 8de41e74e8f8..765379380d4b 100644
> >> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> >> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> >> @@ -482,6 +482,21 @@ static struct edid *hdmi4_bridge_get_edid(struct
> >> drm_bridge *bridge,
> >>return edid;
> >> }
> >>
> >> +static int hdmi4_bridge_cec_init(struct drm_bridge *bridge,
> >> + struct drm_connector *conn)
> >> +{
> >> + struct omap_hdmi *hdmi = drm_bridge_to_hdmi(bridge);
> >> +
> >> + return hdmi4_cec_init(hdmi->pdev, >core, >wp, conn);
> >> +}
> >> +
> >> +static void hdmi4_bridge_cec_exit(struct drm_bridge *bridge)
> >> +{
> >> + struct omap_hdmi *hdmi = drm_bridge_to_hdmi(bridge);
> >> +
> >> + hdmi4_cec_uninit(>core);
> >> +}
> >> +
> >> static const struct drm_bridge_funcs hdmi4_bridge_funcs = {
> >>.attach = hdmi4_bridge_attach,
> >>.mode_set = hdmi4_bridge_mode_set,
> >> @@ -492,13 +507,15 @@ static const struct drm_bridge_funcs
> >> hdmi4_bridge_funcs = {
> >>.atomic_disable = hdmi4_bridge_disable,
> >>.hpd_notify = hdmi4_bridge_hpd_notify,
> >>.get_edid = hdmi4_bridge_get_edid,
> >> + .cec_init = hdmi4_bridge_cec_init,
> >> + .cec_exit = hdmi4_bridge_cec_exit,
> >> };
> >>
> >> static void hdmi4_bridge_init(struct omap_hdmi *hdmi)
> >> {
> >>hdmi->bridge.funcs = _bridge_funcs;
> >>hdmi->bridge.of_node = hdmi->pdev->dev.of_node;
> >> - hdmi->bridge.ops = DRM_BRIDGE_OP_EDID;
> >> + hdmi->bridge.ops = DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_CEC;
> >>hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
> >>
> >>drm_bridge_add(>bridge);
> >> @@ -647,14 +664,10 @@ static int hdmi4_bind(struct device *dev, struct
> >> device *master, void *data)
> >>if (r)
> >>goto err_runtime_put;
> >>
> >> - r = hdmi4_cec_init(hdmi->pdev, >core, >wp);
> >> - if (r)
> >> - goto err_pll_uninit;
> >
> > I'm wondering ifwe need to delay the creation of the CEC adapter until
> > the DRM connector is ready, or if we could only delay its registration ?
> > Catching errors related to adapter creation early could be nice, the
> > more error we have to handle at DRM bridge connector creation time, the
> > more complex the error handling will be for bridge support.
>
> I feel that that is overkill, but if you really want this, just let me know.
> Splitting it up would actually make it more complex for me since I would have
> to check whether to call cec_unregister_adapter or cec_delete_adapter,
> depending
> on whether the CEC registration was successful or not.
I don't insist if you think it's not worth it.
> >> -
> >>r = hdmi_audio_register(hdmi);
> >>if (r) {
> >>DSSERR("Registering HDMI audio failed\n");
> >> - goto err_cec_uninit;
> >> + goto err_pll_uninit;
> >>}
> >>
> >>hdmi->debugfs = dss_debugfs_create_file(dss, "hdmi", hdmi_dump_regs,
> >> @@ -664,8 +677,6 @@ static int hdmi4_bind(struct device *dev, struct
> >> device *master, void *data)
> >>
> >>return 0;
> >>
> >> -err_cec_uninit:
> >> - hdmi4_cec_uninit(>core);
> >> err_pll_uninit:
> >>hdmi_pll_uninit(>pll);
> >> err_runtime_put:
> >> @@ -682,7 +693,6 @@ static void hdmi4_unbind(struct device *dev, struct
> >> device *master, void *data)
> >>if (hdmi->audio_pdev)
> >>platform_device_unregister(hdmi->audio_pdev);
> >>
> >> - hdmi4_cec_uninit(>core);
> >>hdmi_pll_uninit(>pll);
> >> }
> >>
> >> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
> >> b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
> >> index 43592c1cf081..64f5ccd0f11b 100644
> >> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
> >> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
> >> @@ -335,10 +335,10 @@ void hdmi4_cec_set_phys_addr(struct hdmi_core_data
> >> *core, u16 pa)
> >> }
> >>
> >> int hdmi4_cec_init(struct platform_device *pdev, struct hdmi_core_data
> >> *core,
> >> -struct hdmi_wp_data *wp)
> >> + struct hdmi_wp_data *wp, struct drm_connector *conn)
> >> {
> >> - const u32 caps = CEC_CAP_TRANSMIT | CEC_CAP_LOG_ADDRS |
> >> - CEC_CAP_PASSTHROUGH | CEC_CAP_RC;
> >> + const u32 caps = CEC_CAP_DEFAULTS |
Re: [PATCH 1/5] drm: drm_bridge: add cec_init/exit bridge ops
Hi Hans,
(CC'ing the DRM bridge maintainers and Daniel Vetter)
On Mon, Mar 01, 2021 at 11:56:28AM +0100, Hans Verkuil wrote:
> On 19/02/2021 13:02, Laurent Pinchart wrote:
> > On Thu, Feb 11, 2021 at 11:36:59AM +0100, Hans Verkuil wrote:
> >> Add bridge cec_init/exit ops. These ops will be responsible for
> >> creating and destroying the CEC adapter for the bridge that supports
> >> CEC.
> >>
> >> Signed-off-by: Hans Verkuil
> >> ---
> >> drivers/gpu/drm/drm_bridge_connector.c | 23 +++
> >> include/drm/drm_bridge.h | 31 ++
> >> 2 files changed, 54 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_bridge_connector.c
> >> b/drivers/gpu/drm/drm_bridge_connector.c
> >> index 791379816837..2ff90f5e468c 100644
> >> --- a/drivers/gpu/drm/drm_bridge_connector.c
> >> +++ b/drivers/gpu/drm/drm_bridge_connector.c
> >> @@ -84,6 +84,13 @@ struct drm_bridge_connector {
> >> * connector modes detection, if any (see _BRIDGE_OP_MODES).
> >> */
> >>struct drm_bridge *bridge_modes;
> >> + /**
> >> + * @bridge_cec:
> >> + *
> >> + * The last bridge in the chain (closest to the connector) that provides
> >> + * cec adapter support, if any (see _BRIDGE_OP_CEC).
> >> + */
> >> + struct drm_bridge *bridge_cec;
> >> };
> >>
> >> #define to_drm_bridge_connector(x) \
> >> @@ -204,6 +211,11 @@ static void drm_bridge_connector_destroy(struct
> >> drm_connector *connector)
> >>struct drm_bridge_connector *bridge_connector =
> >>to_drm_bridge_connector(connector);
> >>
> >> + if (bridge_connector->bridge_cec) {
> >> + struct drm_bridge *cec = bridge_connector->bridge_cec;
> >> +
> >> + cec->funcs->cec_exit(cec);
> >> + }
> >>if (bridge_connector->bridge_hpd) {
> >>struct drm_bridge *hpd = bridge_connector->bridge_hpd;
> >>
> >> @@ -352,6 +364,8 @@ struct drm_connector *drm_bridge_connector_init(struct
> >> drm_device *drm,
> >>bridge_connector->bridge_detect = bridge;
> >>if (bridge->ops & DRM_BRIDGE_OP_MODES)
> >>bridge_connector->bridge_modes = bridge;
> >> + if (bridge->ops & DRM_BRIDGE_OP_CEC)
> >> + bridge_connector->bridge_cec = bridge;
> >>
> >>if (!drm_bridge_get_next_bridge(bridge))
> >>connector_type = bridge->type;
> >> @@ -374,6 +388,15 @@ struct drm_connector
> >> *drm_bridge_connector_init(struct drm_device *drm,
> >>else if (bridge_connector->bridge_detect)
> >>connector->polled = DRM_CONNECTOR_POLL_CONNECT
> >> | DRM_CONNECTOR_POLL_DISCONNECT;
> >> + if (bridge_connector->bridge_cec) {
> >> + struct drm_bridge *bridge = bridge_connector->bridge_cec;
> >> + int ret = bridge->funcs->cec_init(bridge, connector);
> >> +
> >> + if (ret) {
> >> + drm_bridge_connector_destroy(connector);
> >> + return ERR_PTR(ret);
> >> + }
> >> + }
> >>
> >>return connector;
> >> }
> >> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >> index 2195daa289d2..4c83c2657e87 100644
> >> --- a/include/drm/drm_bridge.h
> >> +++ b/include/drm/drm_bridge.h
> >> @@ -629,6 +629,30 @@ struct drm_bridge_funcs {
> >> * the DRM_BRIDGE_OP_HPD flag in their _bridge->ops.
> >> */
> >>void (*hpd_disable)(struct drm_bridge *bridge);
> >> +
> >> + /**
> >> + * @cec_init:
> >> + *
> >> + * Initialize the CEC adapter.
> >> + *
> >> + * This callback is optional and shall only be implemented by bridges
> >> + * that support a CEC adapter. Bridges that implement it shall also
> >> + * implement the @cec_exit callback and set the DRM_BRIDGE_OP_CEC flag
> >> + * in their _bridge->ops.
> >> + */
> >> + int (*cec_init)(struct drm_bridge *bridge, struct drm_connector *conn);
> >> +
> >> + /**
> >> + * @cec_exit:
> >> + *
> >> + * Terminate the CEC adapter.
> >> + *
> >> + * This callback is optional and shall only be implemented by bridges
> >> + * that support a CEC adapter. Bridges that implement it shall also
> >> + * implement the @cec_init callback and set the DRM_BRIDGE_OP_CEC flag
> >> + * in their _bridge->ops.
> >> + */
> >> + void (*cec_exit)(struct drm_bridge *bridge);
> >
> > These are very ad-hoc operations. Would it make sense to have something
> > that could also be reused for other type of intiialization and cleanup
> > that require access to the drm_connector ?
>
> I do not have a very strong opinion, to be honest.
>
> How about this:
>
> /**
>* @DRM_BRIDGE_OP_CONN: The bridge can do additional work when
>* a drm_connector is created or destroyed, such as creating or
>* removing a CEC adapter.
>* _bridge_funcs->conn_init and _bridge_funcs->conn_exit
>* callbacks.
>*/
> DRM_BRIDGE_OP_CONN = BIT(4),
>
> Would that work better for you?
I
[PATCH 4.9 029/134] fbdev: aty: SPARC64 requires FB_ATY_CT
From: Randy Dunlap
[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prevent build errors.
As it currently is, FB_ATY_CT can be disabled, resulting in build
errors:
ERROR: modpost: "aty_postdividers" [drivers/video/fbdev/aty/atyfb.ko] undefined!
ERROR: modpost: "aty_ld_pll_ct" [drivers/video/fbdev/aty/atyfb.ko] undefined!
Reviewed-by: Geert Uytterhoeven
Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
Signed-off-by: Randy Dunlap
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Cc: Tomi Valkeinen
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: Daniel Vetter
Cc: David Airlie
Cc: Bartlomiej Zolnierkiewicz
Cc: Geert Uytterhoeven
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20201127031752.10371-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 5d3b0db5ce0af..c0d4e645f3b51 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1405,6 +1405,7 @@ config FB_ATY
select FB_CFB_IMAGEBLIT
select FB_BACKLIGHT if FB_ATY_BACKLIGHT
select FB_MACMODES if PPC
+ select FB_ATY_CT if SPARC64 && PCI
help
This driver supports graphics boards with the ATI Mach64 chips.
Say Y if you have such a graphics board.
@@ -1415,7 +1416,6 @@ config FB_ATY
config FB_ATY_CT
bool "Mach64 CT/VT/GT/LT (incl. 3D RAGE) support"
depends on PCI && FB_ATY
- default y if SPARC64 && PCI
help
Say Y here to support use of ATI's 64-bit Rage boards (or other
boards based on the Mach64 CT, VT, GT, and LT chipsets) as a
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
2021 X.Org Board of Directions Nomination period ends next Sunday
Unfortunately my previous email seems to not have been received by many people. I will send this email separately to each mailing list to hopefully get better coverage. The nomination period is currently ongoing. So far we have received 3 nominations and will need at least 4 to fill the vacant spots on the board. We hope you will consider putting your nomination forward. To nominate yourself or someone else please send the nomination, along with a personal statement to elections at x dot org. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Deadline of X.Org membership application or renewal: Thu 11th March Publication of Candidates & start of Candidate QA: Mon 15th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Cheers, Harry Wentland, on behalf of the X.Org elections committee ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.4 20/93] fbdev: aty: SPARC64 requires FB_ATY_CT
From: Randy Dunlap
[ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ]
It looks like SPARC64 requires FB_ATY_CT to build without errors,
so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
instead of using "default y if SPARC64 && PCI", which is not strong
enough to prevent build errors.
As it currently is, FB_ATY_CT can be disabled, resulting in build
errors:
ERROR: modpost: "aty_postdividers" [drivers/video/fbdev/aty/atyfb.ko] undefined!
ERROR: modpost: "aty_ld_pll_ct" [drivers/video/fbdev/aty/atyfb.ko] undefined!
Reviewed-by: Geert Uytterhoeven
Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
Signed-off-by: Randy Dunlap
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Cc: Tomi Valkeinen
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: Daniel Vetter
Cc: David Airlie
Cc: Bartlomiej Zolnierkiewicz
Cc: Geert Uytterhoeven
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20201127031752.10371-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 6873be0344486..e24e77e31529e 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1397,6 +1397,7 @@ config FB_ATY
select FB_CFB_IMAGEBLIT
select FB_BACKLIGHT if FB_ATY_BACKLIGHT
select FB_MACMODES if PPC
+ select FB_ATY_CT if SPARC64 && PCI
help
This driver supports graphics boards with the ATI Mach64 chips.
Say Y if you have such a graphics board.
@@ -1407,7 +1408,6 @@ config FB_ATY
config FB_ATY_CT
bool "Mach64 CT/VT/GT/LT (incl. 3D RAGE) support"
depends on PCI && FB_ATY
- default y if SPARC64 && PCI
help
Say Y here to support use of ATI's 64-bit Rage boards (or other
boards based on the Mach64 CT, VT, GT, and LT chipsets) as a
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 1/2] dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP
Hi Laurent, >Is this a property of the hardware, that is, are there multiple versions >of this IP core covered by the same compatible string that support HDCP >1.4 only, DHCP 2.2 only or both ? Or is it a way to select what a given >system will offer ?[] MHDP hardware supports both HDCP 2.2 and 1.4. So, this is a way to select the version of HDCP, system wish to support. Regards, Parshuram Thombare ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V4 2/2] backlight: qcom-wled: Correct the sync_toggle sequence
As per the current implementation, after FSC (Full Scale Current) and brightness update the sync bits are set-then-cleared. But, the FSC and brightness sync takes place when the sync bits are set (e.g. on a rising edge). So the hardware team recommends a clear-then-set approach in order to guarantee such a transition regardless of the previous register state. Signed-off-by: Kiran Gunda Reviewed-by: Daniel Thompson --- drivers/video/backlight/qcom-wled.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c index aef52b9..19f83ac 100644 --- a/drivers/video/backlight/qcom-wled.c +++ b/drivers/video/backlight/qcom-wled.c @@ -337,13 +337,13 @@ static int wled3_sync_toggle(struct wled *wled) rc = regmap_update_bits(wled->regmap, wled->ctrl_addr + WLED3_SINK_REG_SYNC, - mask, mask); + mask, WLED3_SINK_REG_SYNC_CLEAR); if (rc < 0) return rc; rc = regmap_update_bits(wled->regmap, wled->ctrl_addr + WLED3_SINK_REG_SYNC, - mask, WLED3_SINK_REG_SYNC_CLEAR); + mask, mask); return rc; } @@ -353,17 +353,17 @@ static int wled5_mod_sync_toggle(struct wled *wled) int rc; u8 val; - val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT : -WLED5_SINK_REG_SYNC_MOD_B_BIT; rc = regmap_update_bits(wled->regmap, wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT, - WLED5_SINK_REG_SYNC_MASK, val); + WLED5_SINK_REG_SYNC_MASK, 0); if (rc < 0) return rc; + val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT : +WLED5_SINK_REG_SYNC_MOD_B_BIT; return regmap_update_bits(wled->regmap, wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT, - WLED5_SINK_REG_SYNC_MASK, 0); + WLED5_SINK_REG_SYNC_MASK, val); } static int wled_ovp_fault_status(struct wled *wled, bool *fault_set) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/8] mm/rmap: Split try_to_munlock from try_to_unmap
On Fri, Feb 26, 2021 at 06:18:27PM +1100, Alistair Popple wrote:
> The behaviour of try_to_unmap_one() is difficult to follow because it
> performs different operations based on a fairly large set of flags used
> in different combinations.
>
> TTU_MUNLOCK is one such flag. However it is exclusively used by
> try_to_munlock() which specifies no other flags. Therefore rather than
> overload try_to_unmap_one() with unrelated behaviour split this out into
> it's own function and remove the flag.
>
> Signed-off-by: Alistair Popple
>
>
> Given the comments on not needing to hold mmap_lock it was not 100% clear
> to me if it is safe to check vma->vma_flags & VM_LOCKED and if re-checking
> under the ptl was significant. I left the extra check in case it was, but
> it seems one of the checks is redunant as either the first check is racey
> or the second check is unneccsary.
The rmap doesn't hold the mmap_lock so I think both of these cases are
racey.
eg
apply_vma_lock_flags()
vma = find_vma(current->mm, start);
if (!vma || vma->vm_start > start)
return -ENOMEM;
prev = vma->vm_prev;
if (start > vma->vm_start)
prev = vma;
for (nstart = start ; ; ) {
vm_flags_t newflags = vma->vm_flags & VM_LOCKED_CLEAR_MASK;
newflags |= flags;
[...]
mlock_fixup()
/*
* vm_flags is protected by the mmap_lock held in write mode.
* It's okay if try_to_unmap_one unmaps a page just after we
* set VM_LOCKED, populate_vma_page_range will bring it back.
*/
if (lock)
vma->vm_flags = newflags;
else
vma->vm_flags &= VM_LOCKED_CLEAR_MASK;
Which is only done under the mmap_sem
> +static bool try_to_munlock_one(struct page *page, struct vm_area_struct *vma,
> + unsigned long address, void *arg)
> +{
> + struct page_vma_mapped_walk pvmw = {
> + .page = page,
> + .vma = vma,
> + .address = address,
> + };
> + bool ret = true;
> +
> + /* munlock has nothing to gain from examining un-locked vmas */
> + if (!(vma->vm_flags & VM_LOCKED))
> + return true;
The mmap_sem can't be obtained in the rmap walkers due to lock
ordering, the various rmap locks are nested under the mmap_sem
So, when reading data that is not locked it should be written as:
READ_ONCE(vma->vm_flags) & VM_LOCKED
> + while (page_vma_mapped_walk()) {
> + /*
> + * If the page is mlock()d, we cannot swap it out.
> + * If it's recently referenced (perhaps page_referenced
> + * skipped over this mm) then we should reactivate it.
> + */
> + if (vma->vm_flags & VM_LOCKED) {
And since we write the data without holding the PTLs this looks
pointless, unless there is some other VM_LOCKED manipulation
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V4 1/2] backlight: qcom-wled: Fix FSC update issue for WLED5
Currently, for WLED5, the FSC (Full scale current) setting is not
updated properly due to driver toggling the wrong register after
an FSC update.
On WLED5 we should only toggle the MOD_SYNC bit after a brightness
update. For an FSC update we need to toggle the SYNC bits instead.
Fix it by adopting the common wled3_sync_toggle() for WLED5 and
introducing new code to the brightness update path to compensate.
Signed-off-by: Kiran Gunda
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/qcom-wled.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index 3bc7800..aef52b9 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -348,7 +348,7 @@ static int wled3_sync_toggle(struct wled *wled)
return rc;
}
-static int wled5_sync_toggle(struct wled *wled)
+static int wled5_mod_sync_toggle(struct wled *wled)
{
int rc;
u8 val;
@@ -445,10 +445,23 @@ static int wled_update_status(struct backlight_device *bl)
goto unlock_mutex;
}
- rc = wled->wled_sync_toggle(wled);
- if (rc < 0) {
- dev_err(wled->dev, "wled sync failed rc:%d\n", rc);
- goto unlock_mutex;
+ if (wled->version < 5) {
+ rc = wled->wled_sync_toggle(wled);
+ if (rc < 0) {
+ dev_err(wled->dev, "wled sync failed rc:%d\n",
rc);
+ goto unlock_mutex;
+ }
+ } else {
+ /*
+* For WLED5 toggling the MOD_SYNC_BIT updates the
+* brightness
+*/
+ rc = wled5_mod_sync_toggle(wled);
+ if (rc < 0) {
+ dev_err(wled->dev, "wled mod sync failed
rc:%d\n",
+ rc);
+ goto unlock_mutex;
+ }
}
}
@@ -1459,7 +1472,7 @@ static int wled_configure(struct wled *wled)
size = ARRAY_SIZE(wled5_opts);
*cfg = wled5_config_defaults;
wled->wled_set_brightness = wled5_set_brightness;
- wled->wled_sync_toggle = wled5_sync_toggle;
+ wled->wled_sync_toggle = wled3_sync_toggle;
wled->wled_cabc_config = wled5_cabc_config;
wled->wled_ovp_delay = wled5_ovp_delay;
wled->wled_auto_detection_required =
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V4 0/2] Fix WLED FSC Sync and brightness Sync settings
This patch series has the following two WLED fixes 1. As per the current implementation, for WLED5, after the FSC (Full Scale Current) update the driver is incorrectly toggling the MOD_SYNC register instead of toggling the SYNC register. The patch 1/2 fixes this by toggling the SYNC register after FSC update. 2. Currently, the sync bits are set-then-cleared after FSC and brightness update. As per hardware team recommendation the FSC and brightness sync takes place from clear-then-set transition of the sync bits. The patch 2/2 fies this issue. Changes from V3: 1. Updated the patch description as per Daneil's suggestion. 2. Added Daniel's "Reviewed-by" tag for patch 2/2. 3. Updated the cover letter to use "set" and "clear" properly. Changes from V2: 1. Added Daniel's "Reviewed-by" tag for patch 1/2. 2. Updated the patch 2/2 description with "set" and "clear" terminology instead of "1" and "0". 3. Updated the cover letter with "set" and "clear" terminology instead of "1" and "0". Changes from V1: 1. Updated the cover letter. 2. Updated the description of the patches as per Daniel's suggestion. Kiran Gunda (2): backlight: qcom-wled: Fix FSC update issue for WLED5 backlight: qcom-wled: Correct the sync_toggle sequence drivers/video/backlight/qcom-wled.c | 37 + 1 file changed, 25 insertions(+), 12 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used
After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
displays gracefully on reboot"), the DSI panel on a Cherry Trail based
Predia Basic tablet would no longer properly light up after reboot.
The backlight still turns back on after reboot, but the LCD shows an
all black display. The display is also all black during the time that
EFI / the GOP is managing it, so e.g. the grub menu also is not visible.
In this scenario the panel is initialized so that it appears to be working
and the fastboot code skips doing a modeset. Forcing a modeset by doing a
chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
/sys/class/graphics/fb0/blank causes the panel to work again.
Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
a no-op when set; and set this on vlv/chv devices when a DSI panel is
detected, to work around this.
Admittedly this is a bit of a big hammer, but these platforms have been
around for quite some time now and they have always worked fine without
the new behavior to shutdown everything on shutdown/reboot. This approach
simply disables the recently introduced new shutdown behavior in this
specific case where it is known to cause problems. Which is a nice and
simple way to deal with this.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 3 +++
drivers/gpu/drm/i915/i915_drv.c| 3 +++
drivers/gpu/drm/i915/i915_drv.h| 1 +
3 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index f94025ec603a..792ef868b6af 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1949,6 +1949,9 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
vlv_dsi_add_properties(intel_connector);
+ /* Some BIOS-es fail to re-init the DSI panel on reboot if we turn it
off */
+ dev_priv->quirks |= QUIRK_SKIP_SHUTDOWN;
+
return;
err_cleanup_connector:
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8e9cb44e66e5..92f2af55af6d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1048,6 +1048,9 @@ static void intel_shutdown_encoders(struct
drm_i915_private *dev_priv)
void i915_driver_shutdown(struct drm_i915_private *i915)
{
+ if (i915->quirks & QUIRK_SKIP_SHUTDOWN)
+ return;
+
disable_rpm_wakeref_asserts(>runtime_pm);
i915_gem_suspend(i915);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 26d69d06aa6d..272cd7cb22d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -517,6 +517,7 @@ struct i915_psr {
#define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
#define QUIRK_INCREASE_T12_DELAY (1<<6)
#define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
+#define QUIRK_SKIP_SHUTDOWN (1<<8)
struct intel_fbdev;
struct intel_fbc_work;
--
2.30.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP
Hi Parshuram,
Thank you for the patch.
On Mon, Mar 01, 2021 at 12:22:26PM +0100, Parshuram Thombare wrote:
> Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding.
> This binding is not used in any upstreamed DTS yet, so changing
> index of property 'j721e-intg' should not affect anything.
>
> Signed-off-by: Parshuram Thombare
> ---
> .../display/bridge/cdns,mhdp8546.yaml | 29 ---
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> index 63427878715e..5fdadadaac16 100644
> --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> @@ -17,21 +17,24 @@ properties:
>- ti,j721e-mhdp8546
>
>reg:
> -minItems: 1
> -maxItems: 2
> +minItems: 2
> +maxItems: 3
> 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 of mhdptx sapb registers.
>- description:
>Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7
> SoCs.
>
>reg-names:
> -minItems: 1
> -maxItems: 2
> +minItems: 2
> +maxItems: 3
> items:
>- const: mhdptx
> + - const: mhdptx-sapb
>- const: j721e-intg
>
>clocks:
> @@ -53,6 +56,11 @@ properties:
>power-domains:
> maxItems: 1
>
> + hdcp-config:
> +maxItems: 1
> +description:
> + HDCP version supported. Bit [0]:HDCP2.2 [1]:HDCP1.4.
> +
Is this a property of the hardware, that is, are there multiple versions
of this IP core covered by the same compatible string that support HDCP
1.4 only, DHCP 2.2 only or both ? Or is it a way to select what a given
system will offer ?
>interrupts:
> maxItems: 1
>
> @@ -98,15 +106,15 @@ allOf:
> then:
>properties:
> reg:
> - minItems: 2
> + minItems: 3
> reg-names:
> - minItems: 2
> + minItems: 3
> else:
>properties:
> reg:
> - maxItems: 1
> + maxItems: 2
> reg-names:
> - maxItems: 1
> + maxItems: 2
>
> required:
>- compatible
> @@ -129,8 +137,9 @@ examples:
>
> mhdp: dp-bridge@f0fb00 {
> compatible = "cdns,mhdp8546";
> -reg = <0xf0 0xfb00 0x0 0x100>;
> -reg-names = "mhdptx";
> +reg = <0xf0 0xfb00 0x0 0x100>,
> + <0x0 0x4f48000 0x0 0x74>;
> +reg-names = "mhdptx", "mhdptx-sapb";
> clocks = <_clock>;
> phys = <_phy>;
> phy-names = "dpphy";
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/ttm: Ignore signaled move fences
Am 27.02.21 um 04:45 schrieb Felix Kuehling:
Move fences that have already signaled should not prevent memory
allocations with no_wait_gpu.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 3a10bebb75d6..de1ec838cf8b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -730,8 +730,9 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object
*bo,
return 0;
if (no_wait_gpu) {
+ ret = dma_fence_is_signaled(fence) ? 0 : -EBUSY;
dma_fence_put(fence);
- return -EBUSY;
+ return ret;
}
dma_resv_add_shared_fence(bo->base.resv, fence);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap
On Mon, Mar 1, 2021 at 11:17 AM Christian König wrote: > > > > Am 01.03.21 um 10:21 schrieb Thomas Hellström (Intel): > > > > On 3/1/21 10:05 AM, Daniel Vetter wrote: > >> On Mon, Mar 01, 2021 at 09:39:53AM +0100, Thomas Hellström (Intel) > >> wrote: > >>> Hi, > >>> > >>> On 3/1/21 9:28 AM, Daniel Vetter wrote: > On Sat, Feb 27, 2021 at 9:06 AM Thomas Hellström (Intel) > wrote: > > On 2/26/21 2:28 PM, Daniel Vetter wrote: > >> So I think it stops gup. But I haven't verified at all. Would be > >> good > >> if Christian can check this with some direct io to a buffer in > >> system > >> memory. > > Hmm, > > > > Docs (again vm_normal_page() say) > > > > * VM_MIXEDMAP mappings can likewise contain memory with or > > without "struct > > * page" backing, however the difference is that _all_ pages > > with a struct > > * page (that is, those where pfn_valid is true) are refcounted > > and > > considered > > * normal pages by the VM. The disadvantage is that pages are > > refcounted > > * (which can be slower and simply not an option for some PFNMAP > > users). The > > * advantage is that we don't have to follow the strict > > linearity rule of > > * PFNMAP mappings in order to support COWable mappings. > > > > but it's true __vm_insert_mixed() ends up in the insert_pfn() > > path, so > > the above isn't really true, which makes me wonder if and in that > > case > > why there could any longer ever be a significant performance > > difference > > between MIXEDMAP and PFNMAP. > Yeah it's definitely confusing. I guess I'll hack up a patch and see > what sticks. > > > BTW regarding the TTM hugeptes, I don't think we ever landed that > > devmap > > hack, so they are (for the non-gup case) relying on > > vma_is_special_huge(). For the gup case, I think the bug is still > > there. > Maybe there's another devmap hack, but the ttm_vm_insert functions do > use PFN_DEV and all that. And I think that stops gup_fast from trying > to find the underlying page. > -Daniel > >>> Hmm perhaps it might, but I don't think so. The fix I tried out was > >>> to set > >>> > >>> PFN_DEV | PFN_MAP for huge PTEs which causes pfn_devmap() to be > >>> true, and > >>> then > >>> > >>> follow_devmap_pmd()->get_dev_pagemap() which returns NULL and > >>> gup_fast() > >>> backs off, > >>> > >>> in the end that would mean setting in stone that "if there is a huge > >>> devmap > >>> page table entry for which we haven't registered any devmap struct > >>> pages > >>> (get_dev_pagemap returns NULL), we should treat that as a "special" > >>> huge > >>> page table entry". > >>> > >>> From what I can tell, all code calling get_dev_pagemap() already > >>> does that, > >>> it's just a question of getting it accepted and formalizing it. > >> Oh I thought that's already how it works, since I didn't spot anything > >> else that would block gup_fast from falling over. I guess really would > >> need some testcases to make sure direct i/o (that's the easiest to test) > >> fails like we expect. > > > > Yeah, IIRC the "| PFN_MAP" is the missing piece for TTM huge ptes. > > Otherwise pmd_devmap() will not return true and since there is no > > pmd_special() things break. > > Is that maybe the issue we have seen with amdgpu and huge pages? Yeah, essentially when you have a hugepte inserted by ttm, and it happens to point at system memory, then gup will work on that. And create all kinds of havoc. > Apart from that I'm lost guys, that devmap and gup stuff is not > something I have a good knowledge of apart from a one mile high view. I'm not really better, hence would be good to do a testcase and see. This should provoke it: - allocate nicely aligned bo in system memory - mmap, again nicely aligned to 2M - do some direct io from a filesystem into that mmap, that should trigger gup - before the gup completes free the mmap and bo so that ttm recycles the pages, which should trip up on the elevated refcount. If you wait until the direct io is completely, then I think nothing bad can be observed. Ofc if your amdgpu+hugepte issue is something else, then maybe we have another issue. Also usual caveat: I'm not an mm hacker either, so might be completely wrong. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/etnaviv: Use FOLL_FORCE for userptr
On Mon, Mar 1, 2021 at 11:28 AM Lucas Stach wrote:
>
> Am Montag, dem 01.03.2021 um 10:52 +0100 schrieb Daniel Vetter:
> > Nothing checks userptr.ro except this call to pup_fast, which means
> > there's nothing actually preventing userspace from writing to this.
> > Which means you can just read-only mmap any file you want, userptr it
> > and then write to it with the gpu. Not good.
>
> I agree about the "not good" part.
>
> > The right way to handle this is FOLL_WRITE | FOLL_FORCE, which will
> > break any COW mappings and update tracking for MAY_WRITE mappings so
> > there's no exploit and the vm isn't confused about what's going on.
> > For any legit use case there's no difference from what userspace can
> > observe and do.
>
> This however seems pretty heavy handed. Does this mean we do a full COW
> cycle of the userpages on BO creation? This most likely kills a lot of
> the performance benefits that one might seek by using userptr. If
> that's the case I might still take this patch for stable, but then we
> should rather just disallow writable GPU mappings to this BO.
That's not what's happening. If the mmap is writeable already (like
any malloc'ed area, and anything you might vacuum up with Xshm), then
FOLL_FORCE does nothing. The difference only happens when the current
mmap region (or some of the pte at least) is read-only. Then:
- for MAP_SHARED with the VM_MAYWRITE flag set, we simply adjust some
book-keeping (no copying of pages), so that the core mm doesn't get
confused about the potentially changed pages contents due to gpu
writes. Without this you could corrupt fs state (e.g. when the fs
checksums file contents or does in-place mmap and stuff like that).
- for MAP_PRIVATE we force the CoW. Just don't do userptr on these,
really, it doesn't make much sense anyway. And note again, if the
mapping is currently writeable, then there's no copying going on, this
is only when the mmap/pte is currently read-only. This is the "let's
overwrite libc.so" attack vector :-)
So really in practice nothing should happen here aside from plugging
the "not good" part. Note that on recent kernels the CoW breaking on
fork() happens irrespective of FOLL_FORCE or not once you have the
mapping established. So if you do a lot of userptr on MAP_PRIVATE
already and applications are using fork(), then you're already
suffering big time (since 5.10 or so iirc, John probably knows the
exact commit without looking).
-Daniel
> Regards,
> Lucas
>
> >
> > Cc: sta...@vger.kernel.org
> > Cc: John Hubbard
> > Signed-off-by: Daniel Vetter
> > Cc: Lucas Stach
> > Cc: Russell King
> > Cc: Christian Gmeiner
> > Cc: etna...@lists.freedesktop.org
> > ---
> > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > index 6d38c5c17f23..a9e696d05b33 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > @@ -689,7 +689,7 @@ static int etnaviv_gem_userptr_get_pages(struct
> > etnaviv_gem_object *etnaviv_obj)
> > struct page **pages = pvec + pinned;
> >
> >
> >
> >
> >
> >
> >
> >
> > ret = pin_user_pages_fast(ptr, num_pages,
> > - !userptr->ro ? FOLL_WRITE : 0,
> > pages);
> > + FOLL_WRITE | FOLL_FORCE, pages);
> > if (ret < 0) {
> > unpin_user_pages(pvec, pinned);
> > kvfree(pvec);
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/omap: hdmi5: add CEC support
On 19/02/2021 12:09, Tomi Valkeinen wrote:
> Hi Hans,
>
> On 11/02/2021 12:37, Hans Verkuil wrote:
>> Add HDMI CEC support for OMAP5.
>>
>> Many thanks to Tomi for helping out how to enable CEC for omap5.
>>
>> Signed-off-by: Hans Verkuil
>> Thanks-to: Tomi Valkeinen
>> ---
>> drivers/gpu/drm/omapdrm/dss/Kconfig | 8 +
>> drivers/gpu/drm/omapdrm/dss/Makefile | 1 +
>> drivers/gpu/drm/omapdrm/dss/hdmi.h | 1 +
>> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 63 +--
>> drivers/gpu/drm/omapdrm/dss/hdmi5_cec.c | 201 +++
>> drivers/gpu/drm/omapdrm/dss/hdmi5_cec.h | 42 +
>> drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 28 +++-
>> drivers/gpu/drm/omapdrm/dss/hdmi5_core.h | 33 +++-
>> 8 files changed, 358 insertions(+), 19 deletions(-)
>> create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi5_cec.c
>> create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi5_cec.h
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/Kconfig
>> b/drivers/gpu/drm/omapdrm/dss/Kconfig
>> index e11b258a2294..67a1ba14703b 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/Kconfig
>> +++ b/drivers/gpu/drm/omapdrm/dss/Kconfig
>> @@ -83,6 +83,14 @@ config OMAP5_DSS_HDMI
>>Definition Multimedia Interface. See https://www.hdmi.org/ for HDMI
>>specification.
>>
>> +config OMAP5_DSS_HDMI_CEC
>> +bool "Enable HDMI CEC support for OMAP5"
>> +depends on OMAP5_DSS_HDMI
>> +select CEC_CORE
>> +default y
>> +help
>> + When selected the HDMI transmitter will support the CEC feature.
>> +
>> config OMAP2_DSS_SDI
>> bool "SDI support"
>> default n
>> diff --git a/drivers/gpu/drm/omapdrm/dss/Makefile
>> b/drivers/gpu/drm/omapdrm/dss/Makefile
>> index f967e6948f2e..94fe0fa3b3c2 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/Makefile
>> +++ b/drivers/gpu/drm/omapdrm/dss/Makefile
>> @@ -17,4 +17,5 @@ omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_common.o
>> hdmi_wp.o hdmi_pll.o \
>> omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi4_core.o
>> omapdss-$(CONFIG_OMAP4_DSS_HDMI_CEC) += hdmi4_cec.o
>> omapdss-$(CONFIG_OMAP5_DSS_HDMI) += hdmi5.o hdmi5_core.o
>> +omapdss-$(CONFIG_OMAP5_DSS_HDMI_CEC) += hdmi5_cec.o
>> ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG
>> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi.h
>> b/drivers/gpu/drm/omapdrm/dss/hdmi.h
>> index c4a4e07f0b99..72d8ae441da6 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/hdmi.h
>> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi.h
>> @@ -261,6 +261,7 @@ struct hdmi_core_data {
>> struct hdmi_wp_data *wp;
>> unsigned int core_pwr_cnt;
>> struct cec_adapter *adap;
>> +struct clk *cec_clk;
>> };
>>
>> static inline void hdmi_write_reg(void __iomem *base_addr, const u32 idx,
>> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
>> b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
>> index 54e5cb5aa52d..b674d8ba173f 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
>> @@ -29,12 +29,14 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>>
>> #include "omapdss.h"
>> #include "hdmi5_core.h"
>> +#include "hdmi5_cec.h"
>> #include "dss.h"
>>
>> static int hdmi_runtime_get(struct omap_hdmi *hdmi)
>> @@ -104,6 +106,10 @@ static irqreturn_t hdmi_irq_handler(int irq, void *data)
>> } else if (irqstatus & HDMI_IRQ_LINK_DISCONNECT) {
>> hdmi_wp_set_phy_pwr(wp, HDMI_PHYPWRCMD_LDOON);
>> }
>
> Empty line here, please.
>
>> +if (irqstatus & HDMI_IRQ_CORE) {
>> +hdmi5_cec_irq(>core);
>> +hdmi5_core_handle_irqs(>core);
>> +}
>
> It's a bit odd to call two functions here. Would it work if
> hdmi5_core_handle_irqs() would read and clear HDMI_CORE_IH_CEC_STAT0,
> and call hdmi5_cec_irq() if the stat != 0 ?
Makes sense, I'll do that.
>
> And it would be nice if hdmi5_core.c would enable and disable core
> interrupt, but maybe that can be left for later if the need ever comes
> to handle other interrupts than cec.
I prefer to leave it as-is.
>
>>
>> return IRQ_HANDLED;
>> }
>> @@ -112,9 +118,12 @@ static int hdmi_power_on_core(struct omap_hdmi *hdmi)
>> {
>> int r;
>>
>> +if (hdmi->core.core_pwr_cnt++)
>> +return 0;
>> +
>> r = regulator_enable(hdmi->vdda_reg);
>> if (r)
>> -return r;
>> +goto err_reg_enable;
>>
>> r = hdmi_runtime_get(hdmi);
>> if (r)
>> @@ -129,12 +138,17 @@ static int hdmi_power_on_core(struct omap_hdmi *hdmi)
>>
>> err_runtime_get:
>> regulator_disable(hdmi->vdda_reg);
>> +err_reg_enable:
>> +hdmi->core.core_pwr_cnt--;
>>
>> return r;
>> }
>>
>> static void hdmi_power_off_core(struct omap_hdmi *hdmi)
>> {
>> +if (--hdmi->core.core_pwr_cnt)
>> +return;
>> +
>> hdmi->core_enabled = false;
>>
>> hdmi_runtime_put(hdmi);
>> @@ -168,7 +182,7 @@ static int hdmi_power_on_full(struct omap_hdmi *hdmi)
>> pc, _cinfo);
>>
Re: [PATCH] drm: rcar-du: Use drmm_encoder_alloc() to manage encoder
Laurent,
On 01/03/2021 10:30, Geert Uytterhoeven wrote:
> On Thu, Jan 14, 2021 at 11:00 AM Geert Uytterhoeven
> wrote:
>> On Wed, Jan 13, 2021 at 6:02 PM Kieran Bingham
>> wrote:
>>> The encoder allocation was converted to a DRM managed resource at the
>>> same time as the addition of a new helper drmm_encoder_alloc() which
>>> simplifies the same process.
>>>
>>> Convert the custom drm managed resource allocation of the encoder
>>> with the helper to simplify the implementation, and prevent hitting a
>>> WARN_ON() due to the handling the drm_encoder_init() call directly
>>> without registering a .destroy() function op.
>>>
>>> Fixes: f5f16725edbc ("drm: rcar-du: Use DRM-managed allocation for
>>> encoders")
>>> Reported-by: Geert Uytterhoeven
>>> Signed-off-by: Kieran Bingham
>>
>> Tested-by: Geert Uytterhoeven
>> As in "the WARNING from drm_encoder_init() is gone".
>
> JFYI, the WARNING is now in v5.12-rc1, the fix isn't.
Does this patch go through you to get into the DRM tree? Or do I need to
re-send it to someone else?
> Gr{oetje,eeting}s,
>
> Geert
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm: bridge: cdns-mhdp8546: Enable HDCP
This patch enable HDCP in MHDP driver.
Signed-off-by: Parshuram Thombare
Reviewed-by: Robert Foss
---
drivers/gpu/drm/bridge/cadence/Makefile | 2 +-
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 105 +++-
.../drm/bridge/cadence/cdns-mhdp8546-core.h | 21 +
.../drm/bridge/cadence/cdns-mhdp8546-hdcp.c | 578 ++
.../drm/bridge/cadence/cdns-mhdp8546-hdcp.h | 89 +++
.../drm/bridge/cadence/cdns-mhdp8546-j721e.c | 2 +-
6 files changed, 783 insertions(+), 14 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-hdcp.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-hdcp.h
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index 8f647991b374..4d2db8df1bc6 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -1,4 +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-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.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 d0c65610ebb5..adb53dea4e26 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -49,7 +50,7 @@
#include
#include "cdns-mhdp8546-core.h"
-
+#include "cdns-mhdp8546-hdcp.h"
#include "cdns-mhdp8546-j721e.h"
static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
@@ -1614,10 +1615,40 @@ enum drm_mode_status cdns_mhdp_mode_valid(struct
drm_connector *conn,
return MODE_OK;
}
+static int cdns_mhdp_connector_atomic_check(struct drm_connector *conn,
+ struct drm_atomic_state *state)
+{
+ struct drm_connector_state *old_state, *new_state;
+ struct drm_crtc_state *crtc_state;
+ u64 old_cp, new_cp;
+
+ old_state = drm_atomic_get_old_connector_state(state, conn);
+ new_state = drm_atomic_get_new_connector_state(state, conn);
+ old_cp = old_state->content_protection;
+ new_cp = new_state->content_protection;
+
+ if (!new_state->crtc) {
+ if (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED)
+ new_state->content_protection =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ return 0;
+ }
+
+ if (old_cp == new_cp ||
+ (old_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED))
+ return 0;
+
+ crtc_state = drm_atomic_get_new_crtc_state(state, new_state->crtc);
+ crtc_state->mode_changed = true;
+
+ return 0;
+}
+
static const struct drm_connector_helper_funcs cdns_mhdp_conn_helper_funcs = {
.detect_ctx = cdns_mhdp_connector_detect,
.get_modes = cdns_mhdp_get_modes,
.mode_valid = cdns_mhdp_mode_valid,
+ .atomic_check = cdns_mhdp_connector_atomic_check,
};
static const struct drm_connector_funcs cdns_mhdp_conn_funcs = {
@@ -1662,7 +1693,7 @@ static int cdns_mhdp_connector_init(struct
cdns_mhdp_device *mhdp)
return ret;
}
- return 0;
+ return drm_connector_attach_content_protection_property(conn, true);
}
static int cdns_mhdp_attach(struct drm_bridge *bridge,
@@ -1956,6 +1987,13 @@ static void cdns_mhdp_atomic_enable(struct drm_bridge
*bridge,
conn_state = drm_atomic_get_new_connector_state(state, connector);
if (WARN_ON(!conn_state))
goto out;
+ if (conn_state->content_protection ==
+ DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+ mhdp->hw_state == MHDP_HW_READY) {
+ mutex_unlock(>link_mutex);
+ cdns_mhdp_hdcp_enable(mhdp);
+ mutex_lock(>link_mutex);
+ }
crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
if (WARN_ON(!crtc_state))
@@ -2000,6 +2038,7 @@ static void cdns_mhdp_atomic_disable(struct drm_bridge
*bridge,
mutex_lock(>link_mutex);
+ cdns_mhdp_hdcp_disable(mhdp);
mhdp->bridge_enabled = false;
cdns_mhdp_reg_read(mhdp, CDNS_DP_FRAMER_GLOBAL_CONFIG, );
resp &= ~CDNS_DP_FRAMER_EN;
@@ -2288,7 +2327,6 @@ static irqreturn_t cdns_mhdp_irq_handler(int irq, void
*data)
struct cdns_mhdp_device *mhdp = data;
u32 apb_stat, sw_ev0;
bool bridge_attached;
- int ret;
apb_stat = readl(mhdp->regs + CDNS_APB_INT_STATUS);
if (!(apb_stat & CDNS_APB_INT_MASK_SW_EVENT_INT))
@@ -2307,20 +2345,54 @@ static irqreturn_t cdns_mhdp_irq_handler(int irq, void
*data)
spin_unlock(>start_lock);
if (bridge_attached && (sw_ev0 &
[PATCH v2 1/2] dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP
Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding.
This binding is not used in any upstreamed DTS yet, so changing
index of property 'j721e-intg' should not affect anything.
Signed-off-by: Parshuram Thombare
---
.../display/bridge/cdns,mhdp8546.yaml | 29 ---
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
index 63427878715e..5fdadadaac16 100644
--- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
@@ -17,21 +17,24 @@ properties:
- ti,j721e-mhdp8546
reg:
-minItems: 1
-maxItems: 2
+minItems: 2
+maxItems: 3
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 of mhdptx sapb registers.
- description:
Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7
SoCs.
reg-names:
-minItems: 1
-maxItems: 2
+minItems: 2
+maxItems: 3
items:
- const: mhdptx
+ - const: mhdptx-sapb
- const: j721e-intg
clocks:
@@ -53,6 +56,11 @@ properties:
power-domains:
maxItems: 1
+ hdcp-config:
+maxItems: 1
+description:
+ HDCP version supported. Bit [0]:HDCP2.2 [1]:HDCP1.4.
+
interrupts:
maxItems: 1
@@ -98,15 +106,15 @@ allOf:
then:
properties:
reg:
- minItems: 2
+ minItems: 3
reg-names:
- minItems: 2
+ minItems: 3
else:
properties:
reg:
- maxItems: 1
+ maxItems: 2
reg-names:
- maxItems: 1
+ maxItems: 2
required:
- compatible
@@ -129,8 +137,9 @@ examples:
mhdp: dp-bridge@f0fb00 {
compatible = "cdns,mhdp8546";
-reg = <0xf0 0xfb00 0x0 0x100>;
-reg-names = "mhdptx";
+reg = <0xf0 0xfb00 0x0 0x100>,
+ <0x0 0x4f48000 0x0 0x74>;
+reg-names = "mhdptx", "mhdptx-sapb";
clocks = <_clock>;
phys = <_phy>;
phy-names = "dpphy";
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] enable HDCP in Cadence MHDP bridge driver
This patch series enables HDCP in Cadence MHDP DPI/DP bridge driver. Changes since v1: - Move sapb reg block right after apb reg block - Corresponding changes in binding and example Parshuram Thombare (2): dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP drm: bridge: cdns-mhdp8546: Enable HDCP .../display/bridge/cdns,mhdp8546.yaml | 29 +- drivers/gpu/drm/bridge/cadence/Makefile | 2 +- .../drm/bridge/cadence/cdns-mhdp8546-core.c | 105 +++- .../drm/bridge/cadence/cdns-mhdp8546-core.h | 21 + .../drm/bridge/cadence/cdns-mhdp8546-hdcp.c | 578 ++ .../drm/bridge/cadence/cdns-mhdp8546-hdcp.h | 89 +++ .../drm/bridge/cadence/cdns-mhdp8546-j721e.c | 2 +- 7 files changed, 802 insertions(+), 24 deletions(-) create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-hdcp.c create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-hdcp.h -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm/omap: hdmi4: switch to the cec bridge ops
On 19/02/2021 13:07, Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the patch.
>
> On Thu, Feb 11, 2021 at 11:37:00AM +0100, Hans Verkuil wrote:
>> Implement the new CEC bridge ops. This makes it possible to associate
>> a CEC adapter with a drm connector, which helps userspace determine
>> with cec device node belongs to which drm connector.
>>
>> Signed-off-by: Hans Verkuil
>> ---
>> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 28 +
>> drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 8 ---
>> drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h | 7 ---
>> 3 files changed, 28 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
>> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
>> index 8de41e74e8f8..765379380d4b 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
>> @@ -482,6 +482,21 @@ static struct edid *hdmi4_bridge_get_edid(struct
>> drm_bridge *bridge,
>> return edid;
>> }
>>
>> +static int hdmi4_bridge_cec_init(struct drm_bridge *bridge,
>> + struct drm_connector *conn)
>> +{
>> +struct omap_hdmi *hdmi = drm_bridge_to_hdmi(bridge);
>> +
>> +return hdmi4_cec_init(hdmi->pdev, >core, >wp, conn);
>> +}
>> +
>> +static void hdmi4_bridge_cec_exit(struct drm_bridge *bridge)
>> +{
>> +struct omap_hdmi *hdmi = drm_bridge_to_hdmi(bridge);
>> +
>> +hdmi4_cec_uninit(>core);
>> +}
>> +
>> static const struct drm_bridge_funcs hdmi4_bridge_funcs = {
>> .attach = hdmi4_bridge_attach,
>> .mode_set = hdmi4_bridge_mode_set,
>> @@ -492,13 +507,15 @@ static const struct drm_bridge_funcs
>> hdmi4_bridge_funcs = {
>> .atomic_disable = hdmi4_bridge_disable,
>> .hpd_notify = hdmi4_bridge_hpd_notify,
>> .get_edid = hdmi4_bridge_get_edid,
>> +.cec_init = hdmi4_bridge_cec_init,
>> +.cec_exit = hdmi4_bridge_cec_exit,
>> };
>>
>> static void hdmi4_bridge_init(struct omap_hdmi *hdmi)
>> {
>> hdmi->bridge.funcs = _bridge_funcs;
>> hdmi->bridge.of_node = hdmi->pdev->dev.of_node;
>> -hdmi->bridge.ops = DRM_BRIDGE_OP_EDID;
>> +hdmi->bridge.ops = DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_CEC;
>> hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
>>
>> drm_bridge_add(>bridge);
>> @@ -647,14 +664,10 @@ static int hdmi4_bind(struct device *dev, struct
>> device *master, void *data)
>> if (r)
>> goto err_runtime_put;
>>
>> -r = hdmi4_cec_init(hdmi->pdev, >core, >wp);
>> -if (r)
>> -goto err_pll_uninit;
>
> I'm wondering ifwe need to delay the creation of the CEC adapter until
> the DRM connector is ready, or if we could only delay its registration ?
> Catching errors related to adapter creation early could be nice, the
> more error we have to handle at DRM bridge connector creation time, the
> more complex the error handling will be for bridge support.
I feel that that is overkill, but if you really want this, just let me know.
Splitting it up would actually make it more complex for me since I would have
to check whether to call cec_unregister_adapter or cec_delete_adapter, depending
on whether the CEC registration was successful or not.
Regards,
Hans
>
>> -
>> r = hdmi_audio_register(hdmi);
>> if (r) {
>> DSSERR("Registering HDMI audio failed\n");
>> -goto err_cec_uninit;
>> +goto err_pll_uninit;
>> }
>>
>> hdmi->debugfs = dss_debugfs_create_file(dss, "hdmi", hdmi_dump_regs,
>> @@ -664,8 +677,6 @@ static int hdmi4_bind(struct device *dev, struct device
>> *master, void *data)
>>
>> return 0;
>>
>> -err_cec_uninit:
>> -hdmi4_cec_uninit(>core);
>> err_pll_uninit:
>> hdmi_pll_uninit(>pll);
>> err_runtime_put:
>> @@ -682,7 +693,6 @@ static void hdmi4_unbind(struct device *dev, struct
>> device *master, void *data)
>> if (hdmi->audio_pdev)
>> platform_device_unregister(hdmi->audio_pdev);
>>
>> -hdmi4_cec_uninit(>core);
>> hdmi_pll_uninit(>pll);
>> }
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
>> b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
>> index 43592c1cf081..64f5ccd0f11b 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
>> @@ -335,10 +335,10 @@ void hdmi4_cec_set_phys_addr(struct hdmi_core_data
>> *core, u16 pa)
>> }
>>
>> int hdmi4_cec_init(struct platform_device *pdev, struct hdmi_core_data
>> *core,
>> - struct hdmi_wp_data *wp)
>> + struct hdmi_wp_data *wp, struct drm_connector *conn)
>> {
>> -const u32 caps = CEC_CAP_TRANSMIT | CEC_CAP_LOG_ADDRS |
>> - CEC_CAP_PASSTHROUGH | CEC_CAP_RC;
>> +const u32 caps = CEC_CAP_DEFAULTS | CEC_CAP_CONNECTOR_INFO;
>> +struct cec_connector_info conn_info;
>> int ret;
>>
>> core->adap = cec_allocate_adapter(_cec_adap_ops, core,
>> @@ -346,6 +346,8 @@ int hdmi4_cec_init(struct platform_device
Patch "drm/nouveau/kms: handle mDP connectors" has been added to the 5.11-stable tree
This is a note to let you know that I've just added the patch titled
drm/nouveau/kms: handle mDP connectors
to the 5.11-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-nouveau-kms-handle-mdp-connectors.patch
and it can be found in the queue-5.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From d1f5a3fc85566e9ddce9361ef180f070367e6eab Mon Sep 17 00:00:00 2001
From: Karol Herbst
Date: Fri, 27 Nov 2020 19:39:09 +0100
Subject: drm/nouveau/kms: handle mDP connectors
From: Karol Herbst
commit d1f5a3fc85566e9ddce9361ef180f070367e6eab upstream.
In some cases we have the handle those explicitly as the fallback
connector type detection fails and marks those as eDP connectors.
Attempting to use such a connector with mutter leads to a crash of mutter
as it ends up with two eDP displays.
Information is taken from the official DCB documentation.
Cc: sta...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Ben Skeggs
Reported-by: Mark Pearson
Tested-by: Mark Pearson
Signed-off-by: Karol Herbst
Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h |1 +
drivers/gpu/drm/nouveau/nouveau_connector.c |1 +
2 files changed, 2 insertions(+)
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h
@@ -14,6 +14,7 @@ enum dcb_connector_type {
DCB_CONNECTOR_LVDS_SPWG = 0x41,
DCB_CONNECTOR_DP = 0x46,
DCB_CONNECTOR_eDP = 0x47,
+ DCB_CONNECTOR_mDP = 0x48,
DCB_CONNECTOR_HDMI_0 = 0x60,
DCB_CONNECTOR_HDMI_1 = 0x61,
DCB_CONNECTOR_HDMI_C = 0x63,
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1210,6 +1210,7 @@ drm_conntype_from_dcb(enum dcb_connector
case DCB_CONNECTOR_DMS59_DP0:
case DCB_CONNECTOR_DMS59_DP1:
case DCB_CONNECTOR_DP :
+ case DCB_CONNECTOR_mDP :
case DCB_CONNECTOR_USB_C: return DRM_MODE_CONNECTOR_DisplayPort;
case DCB_CONNECTOR_eDP : return DRM_MODE_CONNECTOR_eDP;
case DCB_CONNECTOR_HDMI_0 :
Patches currently in stable-queue which might be from kher...@redhat.com are
queue-5.11/drm-nouveau-kms-handle-mdp-connectors.patch
queue-5.11/drm-nouveau-bail-out-of-nouveau_channel_new-if-chann.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm: drm_bridge: add cec_init/exit bridge ops
On 19/02/2021 13:02, Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the patch.
>
> On Thu, Feb 11, 2021 at 11:36:59AM +0100, Hans Verkuil wrote:
>> Add bridge cec_init/exit ops. These ops will be responsible for
>> creating and destroying the CEC adapter for the bridge that supports
>> CEC.
>>
>> Signed-off-by: Hans Verkuil
>> ---
>> drivers/gpu/drm/drm_bridge_connector.c | 23 +++
>> include/drm/drm_bridge.h | 31 ++
>> 2 files changed, 54 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_bridge_connector.c
>> b/drivers/gpu/drm/drm_bridge_connector.c
>> index 791379816837..2ff90f5e468c 100644
>> --- a/drivers/gpu/drm/drm_bridge_connector.c
>> +++ b/drivers/gpu/drm/drm_bridge_connector.c
>> @@ -84,6 +84,13 @@ struct drm_bridge_connector {
>> * connector modes detection, if any (see _BRIDGE_OP_MODES).
>> */
>> struct drm_bridge *bridge_modes;
>> +/**
>> + * @bridge_cec:
>> + *
>> + * The last bridge in the chain (closest to the connector) that provides
>> + * cec adapter support, if any (see _BRIDGE_OP_CEC).
>> + */
>> +struct drm_bridge *bridge_cec;
>> };
>>
>> #define to_drm_bridge_connector(x) \
>> @@ -204,6 +211,11 @@ static void drm_bridge_connector_destroy(struct
>> drm_connector *connector)
>> struct drm_bridge_connector *bridge_connector =
>> to_drm_bridge_connector(connector);
>>
>> +if (bridge_connector->bridge_cec) {
>> +struct drm_bridge *cec = bridge_connector->bridge_cec;
>> +
>> +cec->funcs->cec_exit(cec);
>> +}
>> if (bridge_connector->bridge_hpd) {
>> struct drm_bridge *hpd = bridge_connector->bridge_hpd;
>>
>> @@ -352,6 +364,8 @@ struct drm_connector *drm_bridge_connector_init(struct
>> drm_device *drm,
>> bridge_connector->bridge_detect = bridge;
>> if (bridge->ops & DRM_BRIDGE_OP_MODES)
>> bridge_connector->bridge_modes = bridge;
>> +if (bridge->ops & DRM_BRIDGE_OP_CEC)
>> +bridge_connector->bridge_cec = bridge;
>>
>> if (!drm_bridge_get_next_bridge(bridge))
>> connector_type = bridge->type;
>> @@ -374,6 +388,15 @@ struct drm_connector *drm_bridge_connector_init(struct
>> drm_device *drm,
>> else if (bridge_connector->bridge_detect)
>> connector->polled = DRM_CONNECTOR_POLL_CONNECT
>>| DRM_CONNECTOR_POLL_DISCONNECT;
>> +if (bridge_connector->bridge_cec) {
>> +struct drm_bridge *bridge = bridge_connector->bridge_cec;
>> +int ret = bridge->funcs->cec_init(bridge, connector);
>> +
>> +if (ret) {
>> +drm_bridge_connector_destroy(connector);
>> +return ERR_PTR(ret);
>> +}
>> +}
>>
>> return connector;
>> }
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index 2195daa289d2..4c83c2657e87 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -629,6 +629,30 @@ struct drm_bridge_funcs {
>> * the DRM_BRIDGE_OP_HPD flag in their _bridge->ops.
>> */
>> void (*hpd_disable)(struct drm_bridge *bridge);
>> +
>> +/**
>> + * @cec_init:
>> + *
>> + * Initialize the CEC adapter.
>> + *
>> + * This callback is optional and shall only be implemented by bridges
>> + * that support a CEC adapter. Bridges that implement it shall also
>> + * implement the @cec_exit callback and set the DRM_BRIDGE_OP_CEC flag
>> + * in their _bridge->ops.
>> + */
>> +int (*cec_init)(struct drm_bridge *bridge, struct drm_connector *conn);
>> +
>> +/**
>> + * @cec_exit:
>> + *
>> + * Terminate the CEC adapter.
>> + *
>> + * This callback is optional and shall only be implemented by bridges
>> + * that support a CEC adapter. Bridges that implement it shall also
>> + * implement the @cec_init callback and set the DRM_BRIDGE_OP_CEC flag
>> + * in their _bridge->ops.
>> + */
>> +void (*cec_exit)(struct drm_bridge *bridge);
>
> These are very ad-hoc operations. Would it make sense to have something
> that could also be reused for other type of intiialization and cleanup
> that require access to the drm_connector ?
I do not have a very strong opinion, to be honest.
How about this:
/**
* @DRM_BRIDGE_OP_CONN: The bridge can do additional work when
* a drm_connector is created or destroyed, such as creating or
* removing a CEC adapter.
* _bridge_funcs->conn_init and _bridge_funcs->conn_exit
* callbacks.
*/
DRM_BRIDGE_OP_CONN = BIT(4),
Would that work better for you?
Regards,
Hans
>
>> };
>>
>> /**
>> @@ -698,6 +722,13 @@ enum drm_bridge_ops {
>> * this flag shall implement the _bridge_funcs->get_modes callback.
>> */
>>
